Loop to scale inputs - indirect addressing - SLC

[Lakee911]

I have a whole bunch of analog inputs that I need to scale to process values. Using JMP and LBL can I use indirect addressing to cycle through all inputs? This would save lots of rungs of logic.

Essentially I'll create two nested for loops to cycle between all input cards and each point and just read in the scale values from a table of registers. Any problem here?

I would need to use something like this for the SCP:

Input:       I:[N7:50].[N7:51]  
Input Min:   4000
Input Max:   20000
Scaled Min:  N13:[N7:52]
Scaled Max:  N13:[N7:53]
Output:      N14:[N7:54]

Assuming that the rest of the code was written properly, would this work?

For each value of N7:50 (which corresponds to the slot), I would cycle through 0 - 8 on N7:51 (which corresponds to the point). Each iteration would increment N7:52 and N7:53 by two and then throw the output into register N7:54 in file N14.

How would I limit the times it goes through the loop so my watchdog timer doesn't time out and fault the processor?

 

[widelto]

I think your approach is OK, and it´s going to work. Just wonder why you do not want to use SCP instead.

 

[Lakee911]

Because I would need about 50 SCPs ... why not just build a table and look up?

 

[widelto]

Because I would need about 50 SCPs ... why not just build a table and look up?

My only concern is watchdog, are you planning to jump to the same subroutine many times as needed in a single scan or you´re going to jump to the subroutine just once in a single scan and change parameters for the next scan ?

 

[Lakee911]

I *was* planning on cycling through the entire list with every scan ... do you think that will be a problem? How long is the watch dog timer set for?

 

[widelto]

I got to run right now, but try this, jump to the subroutine, let´s say 5 times, then 10 times and measure scan time each time, not sure what it´s the maximum value for watchdog, but this can give you what you max value is going to be. Do the same with SCP (no jump to subroutine) and compare scan times this can lead you to a conclusion.

 

[Lakee911]

I won't have access to run this for sometime, but I'll try that in the field. Thanks.

 

[val_99]

Great innovation, specially from job security stand point. But as an I&C guy with more then 20 years experience I would never do it. Think about poor maintenance or support tech. who will deal with your stuff soon or later. The simple the better !!!

 

[Lakee911]

Too late ... already done. It will be well documented though.

Added value is I can pull the scaling inputs right into my HMI if I wanted to.

 

[TConnolly]

Using a loop that long is going to add a huge amount of overhead to your program. You can create those 50 rungs in a matter of seconds in Excel. Excel autofill automatically increments AB memory addresses as you drag down. Then cut/paste to notepad and remove the carriage returns, and then paste it into RSLogix500.

 

[TConnolly]

It took only about ten minutes to do all this. I entered the 56 rungs in Excel, one instruction per column by creating the first rung. I copied to create the second rung and edited the addresses so that Excel knows how much to skip each the memory address of each column by. Then highlighted the first two rows and drug down to autofill all the rest. Then I edited the input address column for module breaks, again using autofill to make the changes fast. Then cut/paste as text to MSWord, used find and replace to remove carriage returns, and saved as a text file. Then I configured a new program with IO, and pasted text in using mnemonic editor.

edit to add: Least I be misunderstood, I'm not trying to show off, but rather show how you can create a very large series of similar rungs very quickly using Excel. The cool thing about doing this is that whether you are creating 20 rungs or 200 rungs the amount of time involved is about the same. Loops have their place, and I use them often. But there is no need to pay the overhead penalty here. I stuck the Excel file, text file, and PLC file into the attached zip file so you can see how its done.

 

[Dua Anjing]

Got to say I'm on Lakee's side on this one. I'm a firm believer in the KISS system. Write the code as if you have to fault find it at 2:30 in the morning with 38 angry managers breathing down your neck..

 

[TConnolly]

At 2:30 in the morning Bubba on the night shift maintenance crew is not going to understand a loop and indirect addressing, he probably can't even find where in the program a particular input is even being scaled. He cant search for it because the module and IO point is obfuscated by indirect addressing. If he searches for I:8.0 he won't find it. He will be scratching his head and the programmer will get a phone call.

If someone comes along a few years from now and needs to upload the program without comments he then has to try and figure out the not so obvious. Even with comments he might wonder, and keep in mind, it could be the very same person who wrote the program who is trying to figure out what he was doing originally. (Dont ask me how I know that ).

 

[Ron Beaufort]

I just KNEW that Alaric was going to beat me to it ...

well, he might have fewer rungs – but the approach is nowhere near what many experienced programmers would call "simple" ...

consider a poor maintenance guy who's trying to track down a "problem" with a particular field transmitter ... instead of following the mathematical trail through one particular "scaling" rung (even one out of 50), he's going to be faced with a constantly flickering number on the screen which will be changing much too fast to be read ...

over the years, I've been called upon to "uncomplicate" several elegant looping structures like this which have been designed by other programmers ... usually they're MSG (Message) operations - but the same concepts apply ...

the biggest problem is that when ONE part of the system quits working, you can't get the REST of the system to "hold still" long enough to track down what's causing the problem ... besides that:

(1) rungs are cheap ...

(2) troubleshooting time is expensive ...

and ...

(3) the processor still has to do JUST AS MANY math operations when you "loop" through the sequence – PLUS – it also has to do MORE operations in order to interpret the indirect addressing, increment the pointer, jump to the label, and test the loop conditions for completion ...

the processing time might not be an issue in most systems, but analyzing and understanding the signal flow quite often becomes a problem – regardless of how much documentation is provided ... again, the signal values won't "hold still" while you're trying to track them down ...

so the BIG question is this: what have you really gained by using this approach? ...

to each his own – but personally I'm not really a fan of this type of programming ...

 

[Paul T]

Awesome response, Ron. That sums up the reasons not to get too cute perfectly.

Only thing I'll add is that this type of task is why subroutines were invented. Scaling fifty analog inputs is just the thing to do in a sub, debug once, then never have to look at again except maybe at oh-dark-thirty. And then, it's perfectly clear what's going on.

And, along the way I'd buffer them all so that I could write my logic cleanly while the real IO could be arranged in whatever way was most convenient to wire.