Studio 5000 reading analogue input low and high engineering values

Hopefully an easy one.
In my program I am reading my analogue input values, low engineering values and high engineering values.
My analogue input values read ok when i look at F8[64] to F8[79] but my low engineering values (F8[200] to F8[215]) and high engineering values (F8[232] to F8[247]) are incorrect apart from the first one for each.
Looking at the 2nd attachment, because the engineering low or high channel values aren't together (in order) this is causing problems. Do I somehow need to make it read the first value then skip 5 values read then skip 5 and so on.
I could do a separate CPS for each but this doesn't seem very efficient.
Any help would be much much appreciated. Thank you

Could you not just do a MOV for each one?

I was hoping there would be a move clever way of doing it

Just my opinion but the cleverest way is the easiest, quickest and one everyone will understand looking at the code.

haha point taken, thanks for your help

janner_10 said:

Just my opinion but the cleverest way is the easiest, quickest and one everyone will understand looking at the code.

Click to expand...

+1
I worked with an application where the original programmer used a FOR loop just for reading the I/O: clever but painful. Just another Rube Goldberg machine:


(from Wikipedia)

I don't see a word in which you have 16 Low Eng values and 16 Hi in consequence. So you are copying apples to pears. Except th first one of the array, which you are pointing correct.

You will need to use brute force....

MOV...Ethernet_3_IO:5:C.Ch0Config.LowEngineering F8[200]
MOV...Ethernet_3_IO:5:C.Ch1Config.LowEngineering F8[201]
...
MOV...Ethernet_3_IO:5:C.Ch15Config.LowEngineering F8[215]
(16 rungs)

and

MOV...Ethernet_3_IO:5:C.Ch0Config.HighEngineering F8[232]
MOV...Ethernet_3_IO:5:C.Ch1Config.HighEngineering F8[233]
...
MOV...Ethernet_3_IO:5:C.Ch15Config.HighEngineering F8[247]
(16 rungs)

A more detailed explanation, to help you understand why COP or CPS can't be used.....

COP or CPS instructions will not index through the "LowEngineering" members of the structure, so after the first element is copied to F8[200] (which it gets correct), the next data copied by CPS will be the HighEngineering structure member, which it will put into F8[201]. Then you will get "CalBias" into F8[202], and then it all goes pear-shaped, because the next data in the structure is a SINT, then an INT, followed by a REAL. The next data copied will be the SINT, the INT, and the first byte of the 4-byte REAL.

COP and CPS don't care about data-types, they are just byte-copiers, and quickly copy a set number of memory bytes from Source to Destination. The instructions determine how many bytes to copy from the specified Length, multiplied by the number of bytes of the destination data-type, in your case REAL. So the CPS copies 16 x 4 = 64 bytes from the source structure.

Now the question must be asked - why are you replicating data into the F8 file ??

Is it because you have a HMI or SCADA attached that gets the data from there ? If that's the case couldn't you just edit the Tag expressions in the HMI/SCADA to look directly at the structure members?

nhatsen said:

+1
I worked with an application where the original programmer used a FOR loop just for reading the I/O: clever but painful. Just another Rube Goldberg machine:

(from Wikipedia)

Click to expand...

I had to debug a program where the original coder used the SAME bits for a Panelview, populating them with different functions based on what screen the operator was on. So in the code B3/0 could mean 16 different things.

robertmee said:

I had to debug a program where the original coder used the SAME bits for a Panelview, populating them with different functions based on what screen the operator was on. So in the code B3/0 could mean 16 different things.

Click to expand...

Ran into that once too, this was an old Panelview connected via RIO, assumed it was programmed that way because block transfers had to be used to send data back-and-forth. It had dedicated block transfers and to minimize them they passed data into them based on what was required for the screen that was open rather than accounting for everything. Makes sense, however I now run far and fast from any PV with RIO!