Michael Lloyd

Same here. There's so much going by while it's scanning that it's hard to dig out what I'm looking for. I'm definitely going to look at PLC Tools SIM-IPE IP Explorer

The PID routine is placed in a 1000 msec periodic task. Correct, you always want to call a loop with a periodic task. However, I've seen loops called every 10ms, and I think that's needlessly fast for most loops that I deal with. It eats up processor time but has no net benefit. I usually set the task at 250ms. 1s is slow. The time between calls affects how the loop parameters affect the output. There's a lot going on inside the equations that make up a PID loop. It calculates the rate of change between the PV and the SP for instance. The PID equation type is INDEPENDENT, as confirmed by .PE = 0. I don't see the .PE tag in list of loop tags. Mine says "PIC2001.DependIndepend" and the value for Dependant = 1. Are you sure that the program uses the PIDE loop? Scratch that, you never said it did and you are using the old PID loop. It works for most simple loops but I like the PIDE loop much more. To answer your question - Yes Independant is .PE = 0 …this means that KI is in repeats per minute rather than minutes per repeat…so the bigger the value the faster the integral  response…is this correct? Correct.  PD[].KP and PD[].KI are the proportional and integral tuning parameters, currently set at 0.25 and 0.05 respectively.  Gain (Proportional) = 25% and Integral = .05 repeats per min, which is slow. In simplest terms the integral term is adding or subtracting (depends on if SP-PV is positive or negative) a very small value to/from the output every minute. That's not necessarily bad. All Integral is doing is "integrating" the SP/PV difference and trying to bring them together by increasing or decreasing the output. You can literally set Integral to a very, very small number and effectively turn it off, creating a straight proportional controller. A Proportional or Gain only controller is almost always going to operate with an offset between SP and PV.  On the other hand, you can set Integral too fast and end up with I being the dominating portion of the equation. Some loops need that (I'm told, never seen it). I think integral is one of the most abused settings vs derivative being the most hated :) I prefer to put the integral term "out of the way" (as in low repeats or high time depending on which equation you chose), tune Gain such that the loop exhibits 1/4 wave damping when disturbed and then start bringing in Integral until it destabilizes the loop, then slow Integral down until you see 1/4 wave damping (or some version of that).

I did and correct. I think Independant is the default and I usually change it. There's no reason to change it if you don't mind the units

There are only two routines being used. I didn't print the blank routines. It's a Micrologix program. EMBOSSER1.pdf

Wireshark is a bit of overkill but it works.

Depending on how they implemented the PID block (ladder or Function Block) you can click the ellipsis (...) in the upper corner of the block to open the menu. I've changed it on the fly before but it may be best not to do that. 

Just FYI. RSS is for the Allen Bradley SLC500 series PLC. If it hasn't been posted by the time I get to work tomorrow I'll print it for you

Ki - integral,  It depends on which equation type you use. If you choose Dependent, my preferred Equation Type, then units are Minutes per Repeat (min/repeat) and a larger number is slower (longer time between repeats). If you choose Independent then the units are 1/min (old school repeats per minute which is the inverse of minutes per repeat) and a larger number is faster (less time between repeats). Personally I prefer to think of integral as minutes not 1/minutes) Kp - Gain. A larger number is faster. If you're used to the old school term of proportional band in %, where then a gain of 10 = 1/10 (the inverse of proportional band) or .10 = 10%. A gain of 1 = 1/2 = 1.00 = 100% proportional band  If you're tuning the old school way, choose Dependent, set Ki to 15 minutes (to get it out of the way). Set the gain at 2 (SWAG, set it where you want to), bump the process, observe the recovery. If all looks good but you want a faster response, try 4, bump, observe. If that's too fast, go 1/2 way back, in this example that would be 3, bump, observe. Once you see approximately 1/4 wave dampening then start to bring in Integral. May go from 15 to 7, bump, observe. Still too slow,  cut in half and test. Too fast, go back about 1/2 way (11). Ki interacts with Kp so you may find yourself tweaking the gain again.

Whatever answer you get here will be right. Ie it's just an opinion. Personally... I would have just installed a complete CLX box. BUT... I don't know anything about your system. Things like - how long can you be down for cutover? How much IO is there? - play into the discussion. If downtime is a problem then wiring in a new rack full of cards may be prohibitive. Relay output cards have a finite number of cycles, at some point individual points start to fail. Depending on the service of the card(s) (cyclic vs non-cyclic) that could be a factor in the decision to do the upgrade. If it's a low cycle installation then they are probably fine (or not :) ). One thing that nobody considers is the longevity of the components on individual cards. Electrolytic and Tantalum capacitor have a service lifespan specification (typically no more than 10,000 hours max but higher is sometimes available for a cost). 10,000 hours is not very long. If the equipment is in operation 24/7 10,000 hours is a little over a year. I think most people think of electronic devices as either disposable or eternal. I prefer think of them as repairable or about to fail :)   I'd have swapped the entire rack and card assembly...

I'm (slowly) working thru a large program that is a SLC conversion to a CLX program. There are no docs (probably were but they are long gone) so I'm back-documenting via the IO / electrical drawings. As in, document the IO, cross reference the IO, then cross reference where it ends up, then cross reference that. There are 58 total routines, of that 31 are actually used but the rest show up in the cross reference. The rest are for a different kind of fuel (oil vs gas for instance), a different type of steam drum level control. Flue Gas Recirculation vs not. Various forced draft fan arrangements. For the record - I despise one size fits all programs, because they DON'T. There, I feel better. I will say this, whoever wrote the original SLC program was very good, even if he or she did write a one size fits all program... whoever it was probably knew the program well enough that it was not hard to adjust parameters to fit the situation. Once it went through the SLC conversion grinder all bets were off. To the point:  I have a Tag called StatBits of the type INT[256]. I'd really like to know where all of those live. I've been trying to figure out how to print the XREF vs writing the locations down. So far I'm stumped.

Boilers make me nervous. The amount of stored energy available when it's online warrants extreme caution. The boiler that the program that we've been discussing is installed on is currently down. Changing it now would be easy enough. However, just as soon as I get the thing loaded but not tested something will happen to one of the other two boilers and I'll make the morning report for having broken Boiler 5. :o) The three ring binder that has all of my notes, prints, etc for boiler 5 has a photo of Johnny Five on the cover. https://robotics.fandom.com/wiki/Johnny_5 I've gone from "I'm going to rewrite that thing" to "maybe I should figure out what's in it first" to "Even though I hate programs that are SLC based but imported into CLX, the original programmer was pretty good. I wish I had documentation". My goal is always to write and document the program such that the tech that has to live with it never uses an expletive before my name (again lol). I have UDT's for motors and valves but chose to use ladder logic for the program. Techs can follow and edit ten or fifteen rungs of ladder easier than they can AOI's (I thought, I'm not so sure that's the case now). I have a number of AOI's, mostly engineering calc based, that I use in plants and pipelines. Back when I was working with S7's (200, 300, and 400) a friend and coworker decided "he" was going to write his own PID loop function block. My first question - WHY? Then I got dragged into. We both left that company before we got too far in. I think it was doable but the S7 PID loop was fine, well tested, and liability free (for us).

Especially with no rung comments (I don't usually do those but this one warrants it) and nothing in the tag description unless I add it.

I'm pretty sure the first rung is designed for a False result if everything is good. The _Fx routine is called from 25 different routines. The Fx Map tab in the spreadsheet that I attached below (It's got the same name as the one that I attached earlier but I've been adding to it) has an Fx Map tab that shows how the function is being loaded. The routine is a busy little bee. Sometimes it returns one parameter. Sometimes it returns a floating point array (like MiscData[36] for instance). I believe these arrays to be valve or flow rate characterization values but I'm not certain that is true. The programmer used indirect addressing, using FxTblStart,0,0 as the pointer in the copy commands starting at Rung 2, Destination is FxX00 (real variable with the value 25 in it right now). Rung 1 seems to be how it increments FxTblStart. The further down the routine I go the more "interesting" it gets.  I don't get to work on this as much as I would like. This kind of programming is not within the realm of understanding for most of our techs but if I can get my head around it then I can pass the info on to them. Boiler 5 BCP IO Sheet Rev 0.xlsx

If you have the panel drawings you can start with documenting the IO and "sometimes" figure out what is going on.

Neither are documented     S4PROCE.RSS S4PROCE.pdf ML1500.pdf

One of the things that's keeping me from deciphering one of the routines in the program is my relative lack of SLC 500 time. I have written quite a few SLC programs, all fairly simple, but once I was up to speed on the Logix 5000 I didn't purposely choose the SLC unless the project was low budget or very low IO count. I didn't do much with arrays in SLC 500. The _Fx routine (attached) looks like it's for loading data from lookup tables (sometimes it's just one parameter, sometimes it's a table of values used to characterize a valve). The IO sheet is saved such that a tab that is used to cross reference all of the calls for the Function Fx. I'm working on understanding the Fx routine but if someone could shortcut that process with an explanation of the first two or three rungs that would help I also included FxEdit which, I assume, is how the arrays are built. Input is probably from the HMI. I hope to have the software for that loaded and licensed by tomorrow. Boiler 5 _Fx Routine.pdf Boiler 5 _FxEdit Routine.pdf Boiler 5 BCP IO Sheet Rev 0.xlsx

I think I found the HMI panel .mer file. It was saved in 2015. I'm not sure what version of software it'll take to open it. 

That was my original thought but I wanted to know what the OEM was doing before I rebuilt from scratch. Supposedly the boiler master (total of 3 boilers on site that are in service) is in the program for what we call Boiler #5. It might be but they don't use it. It might be but they don't use it. A boiler trip basically shuts the facility down and its not pretty. Speaking of #5, there are only 3 active. They shut a 2 boiler cogen plant down before we bought the facility. The HMI is an Allen Bradley Panelview (I think, I know it's an Allen Bradley touch panel). The guys at the plant have looked for the program but so far no luck. I'm happy to share the joy. I'll even toss in the IO sheet I started on. The end goal is to have it fleshed out completely. From there it won't be much of a stretch to write the program. I'm working on knocking the rust off of my air/fuel ratio with cross limiting control design skills. And the steam drum control logic has some nuances that I need to brush up on. I have some pretty good articles on boiler control. I can add those if there's any interest.  Don't tell anyone but for all of my whining I like digging into other peoples programs. This one is testing me but it's interesting. Boiler 5 BCP IO Sheet Rev 0.xlsx Boiler_5_CCS_nsp.ACD AiPct Cross Reference.pdf

1st - I'm not a PlantPax person. BAD 32 = Signal failure (out-of-range, NaN, invalid combination)   Found on Page 14 Here: https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/syslib-rm042_-en-p.pdf SrcQ - I/O Signal Source Quality   Page 18 has a programming example. Page 19 says that you should have a bad quality indicator if the error code is 32  

I've been trying to get my hands on the HMI program but so far I'm not having any luck. That would clear up a lot of things and speed up the task of documenting tags. Since it's a boiler I'm taking this one real slow. I go back and forth between doing a total rewrite and trying to trim out the fluff. The problem is that if I take the time to figure out what is and what isn't fluff I'll know the program well enough to leave it alone. If I change the wrong thing the HMI could lose data AND the data that goes to the Foxboro DCS could disappear. Neither of those things is very attractive. It sounds like I am but I'm not against an OEM type application. I'm against it in boilers, fired heaters, high speed rotating equipment, like turboexpanders. Turbine / compressor applications are typically cookie cutter (Solar Turbotronics for instance). In some ways the "standard" UDT's that I use could be considered "sort of" OEM.

The thing that makes this daunting is the huge number of undocumented addresses. So far I'm seeing each of the IO points moved at least 3 more times before it lands on a tag that seems to be used in the "control portion" of the program. To give you an idea of the task ahead- Not counting IO, there are 5,701 tags and aliases and only 43 used IO points. 7 DI, 4 DO, 16 AI, 9 AO, and 7 Thermocouple. That doesn't count the tags for 15 PID (not PIDE) loops, most of which aren't used (because they are built for fuels that we will never use, like coal and oil).

That could very well be the case. It didn't happen at every site, only 2, maybe 3 out of 55 total. And, it just occurred to me that it was the Compact Logix PLC not the Micrologix that had issues with glitches. The Micrologix PLC's were tanks. I even had an electrician run a sawzall blade through one :/ but it didn't survive :) It would've made a great commercial for AB if it had.

Mostly true but, unless AB fixed it, if the power glitches it can clear the program in a Micrologix. It's not an "everytime thing" but I've seen it happen more than once. On the other hand (and I think this is just as bad), if you use the memory card and "auto reload" the program on powerup that has it's own issues. (1) If a tech makes a change and doesn't update the program on the memory card, the PLC will reload the old program when power cycled and you lose the change. That could have safety an/or operations implications (2) Updating the card will require interrupting the process. For these reasons, we stopped using the cards, installed and maintained small UPS systems to mitigate power blips, and as far as I know we don't have "program dump" issue anymore.

Brute force for the win. (1) Use free program called Greenshot to screenshot sections of the Cross reference, 5 in this case. Save as JPG (2) Use Adobe to make the 5 images a PDF file (3) Save PDF file and Print. Results attached It's kind of sad that something that could be useful isn't part of the software. People that write software apparently don't have to use it. PS - If the description is documented (by me) the tag is used in the program (specifically it's used in OUR version of the program. There's a lot of trash in this thing), otherwise it's wasted space. PSS - this is a different tag array, it's "only" 80 REAL values. I experimented with something 1/3 the size of the discrete arrays and still had 5 pages. The cut / paste method left a lot of blank space top and bottom.  The real values are moved from the Analog Point (Local:X:I.ChxData for instance) to the AiPct (Analog Percent)[x] tag. They converted everything to percent (which is normal, for the most part, in boiler control) except all of the transmitter inputs are scaled 0-100% on the analog card, so scaling is done on the card and then dumped into a SLC 500 scaling routine that is modified to use a MOV instead of CPT. The thermocouple cards are scaled full range and then calculated in the same SLC 500 scaling routine. <insert rant here> AiPct Cross Reference.pdf

Bummer. I was hoping I was just missing it. The group of "bits" are in 50 - 100 different locations in different routines. I didn't actually count how many there were. The tears of agony were blinding me lol