Long integer from two consecutive 16 bit integers (Allen Bradley)

Ignition
1

I am creating a data type which is populated entirely from an “N” data file in a Micrologix. The contents of the data follows a pattern repeated for each of seven remote pump stations. All the data is collected into one Micrologix 1400 at the central office with the Ignition gateway PC.

I have all the scaling and conversion figured out with one exception. There are up to 3 pumps in each instance and I record the run time (in 0.01 hour increments) for each pump in a long integer that gets copied into two consecutive integers.

So at the remote pumps station, the long integer, for example is 567891 (meaning 5678.91 hours), that gets copied to two “N” integers and appears as -21933 and 8 when viewed in the decimal radix. I want to take those two consecutive integers into an ignition tag as a 32 bit integer and then scale it to a float to read as the original value of 5678.91

I have tried a lot of different methods to try to get Ignition to read two consecutive 16 bit integers as one 32 bit integer, but have not had any luck. If I have to, I can add PLC code and a Long integer data file to overcome this problem, but the results will be simpler and cleaner if I can avoid that.

2

Bring the 2 integer tags in as they are and make a 3rd expression tag that just shifts the high word left and ORs the low word in. Then you can figure out scaling as needed.

1 Like
3

Do you have any examples of what the expression syntax will look like for this? I am having a similar issue.

4

Something like ({High} << 16) | {Low} where High and Low are OPC tags with the high word and low word respectively.

5

What Kevin said, but force the low word to be handled as unsigned, like so:

({High} << 16) | ({Low} & 65535)
1 Like
6

Really late follow up but I ended up just doing the conversion in the PLC rather than an Ignition expression. Ignition reads from the Micrologix “L” file as a 32 bit integer just fine.

6 of one, half a dozen of the other, I guess, but I felt batter about having a distinct address that someone years down the road could easily track down at both ends and understand. That someone will probably be me.

I am a little bit spoiled on the flexibility of tags in my favorite HMI which will let you pick a starting address and read the bits (or arrays of bits, words, longs, etc.) and interpret the pattern about any way you can imagine. I was a little surprised that I can’t do that with Ignition, but it’s a minor inconvenience.

7

Not really. Assembling the 32-bit data type in the PLC protects you against wonky values if upper and lower halves are being read just as lower overflows into upper. A-B PLCs are really good at ensuring that core data types are atomic with respect to messaging, but only core types. Adjacent elements of an array or structure can be changed in the middle of a message read or write. AFAICT, L files in MicroLogix are atomic.

8

Good point. There is probably a microscopic chance that the Ignition driver reads those values right in the middle of the time that the MSG Read instruction is populating them with fresh data.

Doing the manipulation in the Micrologix of this particular PLC actually can result in the same problem since it happens to be a slave on the radio network and is not in control of when the source data arrives. So, the same microscopic chance of erroneous values being present for one PLC scan is still there. The odds that happens AND the Ignition driver reads it during that same scan greatly decrease the chance of logging or displaying bogus data on the Ignition system.

9

At any kind of scale beyond one person "microscopic" chances will happen... we see it all the time with customer reported race conditions or deadlocks when it comes to software development.

It might not happen to you, but it will happen to someone.

10

Yes, I have been that guy. I did a complex sorting algorithm in a SLC that used an STI routine to manipulate data in an array and could potentially affect the index of another instruction in the main routine that used indirect addressing. I didn’t notice the potential problem and it ran flawlessly for 6 months.

I made some other changes that added a few microseconds to the scan time of the PLC and the next day, BAM, CPU fault. I puzzled over it for an hour and still didn’t see the mistake, and bang, CPU fault again. Line down again: “illegal indirect address”. I spent that whole day stressed out not knowing what I broke, but finally did pick it apart and figure out it wasn’t my main code it was in the STI. So I fixed that routine to make a copy of that index and not write to the original just in case it triggered the STI routine right between the two instructions of the MAIN where it could break things.

One in a billion will happen to you if there are billions of PLC scans and you are responsible for them all.

3 Likes