Michael Lloyd

Can I print the cross reference for a specific tag array?

20 posts in this topic

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.

Share this post


Link to post
Share on other sites

For the SLC or the CLX?

Dumb question, it's the CLX.

Under Generate Report, I see Tag Listing for Routine.  Might not be all that helpful.

I'm not finding anything useful.

Edited by pcmccartney1
1 person likes this

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

About the only suggestion is to have both programs up and go one by one.

Checked to see if Rockwell had some other tools available, but nothing.

Take a look at KB ID #9760.  It talks about someone wanting to turn off cross-reference for printing.  Maybe generate a stripped down report with just the tag listing and cross-reference turned on?  Unfortunately, it will be every tag in the database.  But if you print it to a pdf, you might be able to search.

Edited by pcmccartney1

Share this post


Link to post
Share on other sites

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

Edited by Michael Lloyd
1 person likes this

Share this post


Link to post
Share on other sites

Brute force is sometimes the only way.

I like to sort (especially on arrays_, by BaseTag.

Alternate idea could be Find All or Find Next for both the SLC and CLX and verify the usage.  By the same token, I'm usually interested in the Destructive aspect of the tags.  Or even the lack of Destructive to try to figure out if it's an HMI based tag or via interface to third party device.

1 person likes this

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

One size fits all, doesn't always fit.  Betting the HMI application would reveal some clues.  You could probably "delete" tons of logic and tags and graphics, but that's on you to decide.

We have an "OEM" type application for one of our customers.  Using options for setup of the system on the HMI screens.  Selecting or Deselecting the option, hides or unhides various objects and turns on and off the scan of sections of ladder.  But understand that we've supplied around 150 of these systems while maintaining even the first installed system from 15 years ago through hardware migration of PLCs, IO, HMIs and comms types.

The funny part is that it was originally attempted in a MLX1100.  Then moved to L51s, then to L35E and now L33ER.  Started with original PVs on DNet, until today with PV+7 on ENet.  It's daunting, but fun.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Yes the brute force is sometimes the best and ugliest way. 

Would just redoing as OEM be faster? What HMI? That program could be a great help, with about 200 assumptions in it also.

 

Share this post


Link to post
Share on other sites
15 hours ago, a062549 said:

Yes the brute force is sometimes the best and ugliest way. 

Would just redoing as OEM be faster? What HMI? That program could be a great help, with about 200 assumptions in it also.

 

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

Share this post


Link to post
Share on other sites

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. 

p2655525065-4.jpg

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Looking at the Fx pdf.

Rung 0 is doing parameter passing into the subroutine (SBR).  A outside limit test (LIM) is performed, if FxNo is greater than 49 or less than 0, the CLR FxOutVal, latch and pass the now zero'ed value of FxOutVal and leave the routine.

If Rung 0 failed, then rest of the routine is executed, but each with it's own method (outside LIM) for parameter passing and jumping out of the subroutine.

Hope this helps, if not we can talk more. 

1 person likes this

Share this post


Link to post
Share on other sites

Just getting a look at this. Wow cool, complicated for the technicians, and me for that matter, to trouble shoot in the middle of the night too though.

 

Share this post


Link to post
Share on other sites
20 hours ago, pcmccartney1 said:

Looking at the Fx pdf.

Rung 0 is doing parameter passing into the subroutine (SBR).  A outside limit test (LIM) is performed, if FxNo is greater than 49 or less than 0, the CLR FxOutVal, latch and pass the now zero'ed value of FxOutVal and leave the routine.

If Rung 0 failed, then rest of the routine is executed, but each with it's own method (outside LIM) for parameter passing and jumping out of the subroutine.

Hope this helps, if not we can talk more. 

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

Share this post


Link to post
Share on other sites
4 hours ago, a062549 said:

Just getting a look at this. Wow cool, complicated for the technicians, and me for that matter, to trouble shoot in the middle of the night too though.

 

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.

Share this post


Link to post
Share on other sites

Indexed SBRs (SLC or MLX world) was a precursor to the AOI concept of CLX.  The problem is that with indexed SBRs, you can only debug using tag monitoring.  With the advent of AOIs, you could have multiple instances and actually debug the instance.  In your case, a series of valves.  While it would take some work, you could develop your own udt and AOI.

The draw back to AOIs is that if you need (made a logic mistake) to make a logic change, it requires a full download.  In otherwords, kill the process.  Not sure if that's particularly good in a process control environment.  Things tend to go boom.  You would have to be really confident in your coding.  Now, from a memory standpoint, there is overhead involved with AOIs, but most of the CLX have so much more memory, it's not really an issue.

AOIs are much more powerful in a manufacturing environment where the process (in this case, a machine) can be stopped, downloaded and restarted without much loss of production.

Developing AOIs for Motor Starters, VFDs, Solenoid Valves (we used to call these bang-bangs) and even Motor Operated Valves would or could be useful.  The next strength is a common interface to the HMI application.

I recently ran into an application where the programmer did indexed SBRs (in CLX) for PID control of Ozone Levels in various incubator rooms.  Of course, one zone acted up and it took three engineers a couple of days to figure it out.  The code was fine, the valve was stuck open and not responding to controls from PID.  But still a nightmare to come to that conclusion.

Share this post


Link to post
Share on other sites

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).

1 person likes this

Share this post


Link to post
Share on other sites

Happen to have the other boilers programs to compare?   Are they all using CLX? Dare I ask, but what are they, these boilers, doing? I assume oil stabilization?

Boilers and their testing is a long cantankerous process. Did a couple in a previous life, so I get your "What did you do?" fears. Never seem to be just right, get them pretty happy in the operation and be gone...

Yeah the techs would be happy with your additional rung comments. 

Edited by a062549

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now