Michael Lloyd

MrPLC Member
  • Content count

    855
  • Joined

  • Last visited

Community Reputation

72 Excellent

2 Followers

About Michael Lloyd

  • Rank
    Random Pixel Generator
  • Birthday 06/01/58

Profile Information

  • Gender Male
  • Location Texas
  • Country United States
  • Interests Photography, Flying, Electronics, Long Range Shooting, Reloading, Fishing, Hunting

Recent Profile Visitors

4750 profile views
  1. Compactlogix 1769 L32e

    You have to add an Ethernet connection in RsLinx.    Your laptop IP has to be on the same subnet as the PLC IP address otherwise BootP won’t work (probably the most mistake I’ve made) edit - it looks like you added the Ethernet gateway but it’s not expanded out
  2. Clx to micro820 heartbeat

    We did something like this in the PLC's on the oil system I worked on. If the HMI didn't reset the heartbeat timer within 10 minutes we shut the station down. The HMI was in Houston and the PLC's were scattered from Corpus Christi to Laredo to San Antonio. The HMI (could just as easily be your master PLC) would send a bit every X seconds. The bit would move the current timer value to a register so we could see elapsed time, then reset the timer before it tripped the done bit. If it tripped the done bit then the station tripped on Comm Fail You basically toss a ball (bit) from one PLC (the Master) to the other PLC. If the other PLC catches the ball (bit) then it sends it back to the other PLC. Each bit transfer resets a timer. If the Master ever reaches the DN bit in the comm fail timer then comm has failed. I have no doubt that you'll work this out. PS - the link in the post above this has some great ideas explained in more detail than I've gone to.
  3. Best Practice Rack 0

    We are 100% in agreement and I've enjoyed those conversations. I have no refinery or power plant experience but I know there is a big difference between either of those tripping off and a gas plant tripping off. Things go bad quickly when a refinery has an unplanned shutdown. What we do is simple by comparison. I went to an SIS design training class led by Paul Gruhn many years ago. We had people from TAPS (Trans-Alaska Pipeline System, we are working on owning that and a bunch of other North Slope assets as I type this), refinery, chemical, power, and even pharmaceutical people in the class. They had some very interesting problems to solve. I spoke to Paul after class because I wanted to see if my take on his class was correct. My take was that by many orders of magnitude, the gas processing industry was simpler than any other represented industry in the class. Paraphrasing, he said that he wasn't sure why we had signed up for the 4.5 day class but he was glad we came. In our world, If a control function is even assigned a SIL rating, it's typically only 1 (I'm not talking about the MOC process). 1oo1 voting is adequate however I do like to use a level transmitter in conjunction with a level switch. ESD systems are mostly hard-wired relay based. If it's a safety critical analog device we usually install two wired to the same PLC and different IO card but we don't have many of those.  Some locations, purchased from others, have Triconix and AB Safety Rated hardware but those aren't even used in a way that makes sense (one transmitter wired to two inputs for 1oo2 voting?) Our DCS systems are redundant. Some PLC systems are redundant but it's not what I prefer, in a gas plant. We can usually solve the problem where a processor fails pretty easily. Everything fails safe by design and while we don't like downtime it's manageable, so shut down, we pull a new processor out of the parts bin, reload the program, and start back up. I've seen that once with an Allen Bradley in 15 years and a lot of different facilities and, though it took a few months for the real problem to manifest itself (bad IO rack) the problem showed up again. This time in such way as to indicate that the backplane was bad, which explained why the processor we sent to AB came back as tested good. Ie we can tolerate an outage much easier than other industries can. Well... it depends on the size of the facility. A BCF/Day is not something you want to see go down. A 10,000 horsepower pipeline pump station with 5 days of storage is much easier to deal with.  A redundant GE system of ours failed a couple of years ago. I was managing the plant at the time and the operator called to ask me a few questions about a problem he was having. No urgency but the problem was strange enough that I drove out and, though I'm not familiar with GE, I was able to troubleshoot well enough to call a friend / coworker and ask if it was possible for both processors on the redundant racks to lose their mind. It turns out, for GE, it is. The primary and secondary controller lost the entire program. No clue why. GE couldn't figure it out (but they were happy to charge us to check the processor out), and it wasn't a power issue. All of the IO held last position because that's what the programmer told it to do (not how I would have done it) and the plant continued to run. We talked to the operator and he said that there was only one loop not working and "there wasn't that much on the PLC". We supplied fuel to a refinery that was about 1/2 mile away. Shutting down was always sketchy due to being the source of fuel to a fairly large refinery. Going on bypass was the usual solution to any problem. Their fuel would go rich but they just blended it out. So, with that in mind, the engineer and I decided to run until Monday morning (1/2 a day) until our GE guy could come reload the programs. The PLC "wasn't doing anything anyway". It ran perfectly all night. But, um... yeah, there were 23 control loops, 18 were real important. It's a wonder the place didn't come down but that is how simple gas processing, by comparison, is. And luck counts. We found out the hard way that the control parameters, I think there are over 20 for each loop, do not save with the program. So when he loaded the program and switched the controller to run "stuff" started hitting the fan when all of the control valves moved to 0% input. Primary overpressure protections is a relief valve in our plants. Those started "working" and we tripped the ESD to bring the plant to a safer state. We were already on bypass. The flare system worked fine. There was some confusion for why the loops weren't working. Finally someone checked parameters and they were all 0. Thankfully whoever built the HMI historized all of the parameters and we were able to pull them and reset all of the loops. It took two guys about 4 hours to fix them.  The plant was online about an hour after startup began. We were running on a new processor and redundant processor. We had two in stock. If not for the control loop issue everything would have been resolved much sooner. I'm not a fan of GE PLC's...
  4. Best Practice Rack 0

    That's what I like about this forum. I don't come from a background in redundancy so I didn't even think about the answer in that way, however, there are many, very good, voices here. I'm glad that you got your answer.
  5. Best Practice Rack 0

    I'm sure there are significant differences in the different industry practices as well as the practices of the company that operates the boiler. In our industry (Oil and Gas Processing) and in the companies I have worked for in the past (contract as well as being an employee), Fired heaters follow the NFPA 87 standard (I made ours more stringent and it tends to be very close to NFPA 85), Ovens and Furnaces, which we don't use, should follow NFPA 86, and of course boilers should follow NFPA 85. Interestingly enough, the BMS on the two Cogens across the road from me, have a fairly primitive form of BMS. Controls were in the Foxboro DCS and the BMS is a Honeywell relay based system (that has a known flaw that has caused one explosion that I'm aware of. The aftermath of the result of the flaw is actually what got me into BMS design a long time ago). If we start them back up I'm not sure what we will do for the BMS other than we will not leave the relay system in place. It'll probably be an Allen Bradley CLX.  Chapter 4 and 5 of NFPA 85 is where the control system requirements are laid out. They are pretty specific but don't require specific hardware or redundancy. The do require separate controls (what used to be called the boiler fireman, which in the "old days" was an actual person that adjusted a valve) than the burner management system (lighting and shutdown control). If my customer said thou shalt use redundant PLC's I'd have more than happily provided them with the solution they wanted for the appropriate fee :o)
  6. Best Practice Rack 0

    I've got three very large boilers about 250' from me. Not one of them has a redundant controller. The requirement is for the control PLC to be separate from the burner management PLC. They have that. For process heaters, we've never used redundant controllers (personally not a fan of redundancy but I'm sure it has a use somewhere). We also do not separate the process control from the BMS for non-boiler applications. In truth, you DON'T NEED a separate process control PLC for a boiler IF you control the process with a DCS or some other control system (technically that is separate). Some companies sell the 2 PLC approach but that's a sales of service thing, not an absolute requirement if you already have good process control in place. I spent the better part of 25 years designing and implementing "non-boiler" burner BMS on everything from a 1MMBTU/Hr glycol reboiler to a couple of hundred MMBTU hot oil heaters. The last BMS was for a 20MMBtu/Hr lean oil still reboiler. NFPA recommendations are pretty clear for the various types of heaters. NFPA 85, 86, and 87 define what is needed for the type of heater and they are easy to read and understand.  No redundancy required. Of course this is industry dependent and I'm only talking about the oil and gas industry.
  7. Best Practice Rack 0

    Burner management, especially for boilers, has some specific requirements but I’ve never seen anything that excludes DI and/or DO from being in the same rack. By way of example, my racks typically look like this (can be more or less for any card). Processor Ethernet (SCADA and HMI) Ethernet (Remote IO if required. Different subnet, typically 10.) DI DI DO DO AI AI AO AO I don’t think putting the Ethernet cards next to the processor is as critical in AB as it can be with other PLC’s but I prefer the order I listed. 
  8. Sharing descriptions while online

    Have you tried export / import (Excel) of the tag database? I know it’s not ideal, especially if both of you are creating descriptions    
  9. I/O ACTIVE

    You could cross reference each point (right click the address) but if the programmer used a tag alias or some other form of redirection I don’t know if the xref function will so you much good.
  10. controllogix cellular remote sites

    My bad... Yes. that should still be the method. You'll just use a tag that contains everything. If that works <-- I don't recall that ever tried that. I normally only moved a bit between PLC's.
  11. Generating UDT Templates from Excel

    I see. You're using Logic Designer. I don't think that existed when I started writing CLX programs. If it did I wasn't aware of it and I rolled my own way of dealing with it. My UDT's are specific to Oil transportation and Gas processing. I use the attached for anything driven by an electric motor. I typed it out by hand. From what you just posted it looks like what you want to do should work but I don't have any experience with the Data Type Editor Motor.L5X
  12. controllogix cellular remote sites

    You can write but do you want to? You'll want to move, copy, or use structured text (my favorite) the IO point data to the tag data and then read the new tag with the message Here's an example (real life) of discrete IO mapping using structured text. You can also use ladder. --||----( ) where the contact is the Local:blahblah tag and the coil is the leftmost tag. // Booster Pump Motor IO Mapping P2050.Stop_I := Local:3:I.Data.9; P2050.Start_I := Local:3:I.Data.10; P2050.RunStat := Local:3:I.Data.11; Local:6:O.Data.0 := P2050.Run; The UDT is attached Motor.L5X
  13. Generating UDT Templates from Excel

    When you export a UDT you get an L5X file. It's format us XML. CSV, Comma Separated Variable, is not the same format. I have made "templates" in Excel to create a way to map tags to IO. It might give you an idea for how to create the same thing. You basically only need the Member Name and Data Type. Everything else looks the same. So you create a template in Excel with those two things as data entry points and use the & function to build the text. Copy the text to a file in Notepad, save as L5X. Import the L5X. I'd do one or two lines like that and test it... Tag Builder Test.xlsx IOM Builder Rev 2.xls
  14. controllogix cellular remote sites

    Think of the UDT as a tag structure or container. Ie once you have a UDT you can create a bunch of tags of the type you name the UDT. Book, real, int are all “types”
  15. controllogix cellular remote sites

    Look for User Defined. It's on the left, a couple of sections below the programs and above the processor / IO sheet (going off memory). This only works if you have UDT's on the Micro. I think they do but I basically hate their software enough that I don't use them.  Create a UDT with the structure that you want. Give it a short name that makes sense. You can't use names that are already in the AB tag structure. Just as an example you could call it RmtIO. Keep the first column in the UDT simple but usable. Don't do: Pump Suction #1 for the West Reflux Pump, in the first column. Instead do: S1 or AI1 and make the type Real if you're moving floating point values (10.6582) vs INT (11) BOOL is correct for DI/DO Make the structure a little larger than you need. In your case, use all of the AI's if it's a small count. Same with the DI's: AI1 FLOAT (or INT) AI2 etc  AI3 etc AI4 etc DI1 BOOL DI2 etc DI3 etc DI4 etc DO1 BOOL if needed or desired DO2 etc DO3 etc DO4 etc You can always get wordy in the Description of the tag later (and you should). If you put a Description in the UDT more often than not it won't work for every instance of the UDT.  Now create a tag that makes sense, Station number for instance (like if there's a pump number called P-101, call it Stn101, of the type RmtIO <-- this shows up in the type dropdown. That will create a tag array. Inside of it you'll have your mixed IO in the order that it is in the UDT. Like this Stn101.AI1; Stn101.AI2, etc. Notice what is to the right of the "dot". A nice short reference and a nice short tag structure. A couple of letters more wouldn't seem to make a difference but if you have to type this tag in HMI software for a 1,000 IO point program you will quickly realize that letter count adds up and time is money. You make it up in the description. There's a way to make that easy too. More later. You need to create this UDT and tag in every device so if the Micro doesn't allow UDT's this won't work. In message you should be able to move Stn101 to Stn101. Test it in one before you do a bunch of work in all of them UDT's are your friend (too). I'll try to send a better example later today.