Rockwell - Convert Two INT to REAL

[Ken Roach]

I went off and got a haircut and missed most of the fun. Almost every time I write some indirect-addressing code I fault my controller at least once... and this time I didn't ! The FAL instruction is very powerful but often trips me up so I end up writing simple loops.

I should have shown the datatypes: the integer array was an INT[112] and the floating-point array was a REAL[56].

The FOR instruction is just a special kind of JSR loop: it increments that one specified tag every time it calls the subroutine, and it calls it X number of times all at once before the program continues.

Something you might not expect about FOR/NEXT is that when the instruction completes and the ladder routine continues to the next rung, the index value increments one last time. So the final value of that tag you may have used inside the subroutine for indirect addressing will often be one too high to be used in the same arrays afterwards.

If I was going to use that routine with a Prosoft card I would look to see if there's a scan counter or similar way to tell that the whole block of data I was working with was intact and complete. There's nothing quite like getting one half of a 32-bit REAL value's bits updated to make the result go wonky.

For related asynchronous-to-the-IO-update reasons, there's a Copy Synchronous (CPS) instruction that takes a teensy bit more time than an ordinary COP instruction because it locks the source and destination tags from being updated by I/O or Produced/Consumed or messaging functions until it finishes moving all the data in 32-bit chunks.

 

[Ken Roach]

The direct answer: if you have no pre-conditions on a JSR or FOR, it will execute every time that rung is scanned. I used a manually-set BOOL tag and a one-shot to make it execute just once for my experiment.

JSR executes the subroutine it's calling just once.

FOR executes it X/Step times.

I didn't put any limits around the indexed addressing instructions to protect myself from mistakes because I was just on a benchtop and not running a big honking power system.

 

[dalporto]

I know it's working in simulation right now, and I know that I need to retrieve that meter from the shop, hook the comm up, plug the test set on it and inject some values next week.

I'm not sure I understand everything you said, I'm getting the main idea but now my main idea is that I'm scared a bit. I know my way around a Modbus setup, but my learning curve with Rockwell isn't up to my standards right now, I'm getting too old.

But now I have possibilities, not just one;

1. Swap Words right from the ProSoft; hopefully I'll be able to use the array with COP right as it is;
2. Use your logic to swap the words;
3. Just manually swap each words and be done with it. I did it again, I could have done it by now but instead, I tried to find the easier way.

Anyway, thanks everyone here that helped with that, it's really appreciated!

 

[robertmee]

Ken brings up a good point...if the prosoft module updates its data table asynchronous to the scan, it's conceivable that your data changes during the FOR iteration. What he is suggesting is to use a CPS copy synchronous to copy the prosoft integer array into an intermediate array, and use the intermediate array in your FOR loop. That way the prosoft data if it changes, won't affect that scans calculations while running the FOR loop. Typically I always map IO and interface protocol modules (profibus is a common one), into Tags, and use these tags in logic...that enforces synchronization of sorts...never use direct IO tags in logic.

 

[drbitboy]

I know it's working in simulation right now, and I know that I need to retrieve that meter from the shop, hook the comm up, plug the test set on it and inject some values next week.

I'm not sure I understand everything you said, I'm getting the main idea but now my main idea is that I'm scared a bit. I know my way around a Modbus setup, but my learning curve with Rockwell isn't up to my standards right now, I'm getting too old.

But now I have possibilities, not just one;

1. Swap Words right from the ProSoft; hopefully I'll be able to use the array with COP right as it is;
2. Use your logic to swap the words;
3. Just manually swap each words and be done with it. I did it again, I could have done it by now but instead, I tried to find the easier way.

Anyway, thanks everyone here that helped with that, it's really appreciated!

Don't be intimidated; it's just ones and zeros. Once you get it working, however you do it*, it will work forever with those equipment (i.e. no one replaces the Logix or Modbus Slave with new hardware with a different CPU architecture).

The CPS is a necessary choice over COP for copying the bits of the polled data (dataarray; perhaps it will be MNETC.DATA.ReadData later?) into the array to be reordered (intarray), because asynchronous I/O is in the mix.

For the INT to REAL copy, CPS may not be necessary, because when that executes is under your control; that said, if there is an HMI (i.e. possibly asynchronous I/O) reading the REAL values), then you should go with CPS for that as well. Either way, pay particular attention to the Length parameter (cf. here).

The FAL executes its loop only when it "sees" a rising edge** on its input rung; the OTU ctrl.EN was my way of getting around that restriction so it would instead execute on every scan cycle; you may want to replace that OTU with one-shot logic that indicates the Modbus data have just been transferred.

* I still think Ken's is clearer, but beauty is in the eye of the beholder; it would be well worth putting extensive comments on these rungs for future diagnosis
** Cf. here, look for the diamond with "Is .EN bit set to True?" in the top-center of that page.

 

[Ken Moore]

Did not read the whole thread, but the ProSoft module will do word or byte swapping for you.

 

[dalporto]

Yeah, I know it should.

But with the Pass-Through Mode enabled (to accommodate for read/write) now I'm still unsure of the behavior it will have in the end. It's already doing some weird things that the ProSoft crew in Bakersfield finds a little odd. So I'm planning a B and a C.

A Belden guy answered me first when I asked questions to ProSoft couple weeks ago. The first time I heard of ProSoft it was a dude in its garage somewhere in Canadian Prairies 15 years ago, so I'm guessing he sold it to Belden lately?

....


I'm going to read about CPS to try to wrap my head around it, it's still very abstract to me.

 

[drbitboy]

I'm going to read about CPS to try to wrap my head around it, it's still very abstract to me.

From a data perspective, CPS is functionally identical to COP i.e. it copies the bits from one area of PLC data memory to the another area of PLC data memory.

The difference is that CPS prevents the I/O and networking subsystems from writing any bit to PLC data memory.

TL;DR

For example, say the PLC is merrily evaluating your program during one scan cycle, and the instruction COP dataarray[0] intarray[0] 56 is what is actually executing at instant T_uh-oh, and it has only copied the bits of element dataarray[0] to the bits of element intarray[0], and is about to copy the bits of element dataarray[1] to the bits of element intarray[1], but, at T_uh-oh just before that second element copy, the communication subsystem receives a Modbus packet.

Since communication is a higher priority than program evaluation, the PLC interrupts the scan cycle program evaluation at instant T_uh-oh to handle the incoming Modbus packet, which packet changes every element of dataarray. When the communication task is done, the PLC returns control to the scan cycle program evaluation, and the COPy instruction would complete by copying elements dataarray[1] through dataarray[111] to elements intarray[1] through intarray[111], but not dataarray[0] to intarray[0], because it has already done that before the interrupt.

So half (16-bits) of realdata[0] are from the previous Modbus packet before the interrupt, and half are from the latest Modbus packet. Yeehaw!

PLC programming, for all but the most basic applications, is primarily about time; when something happens is more important than what happens.

 

[Ken Roach]

I'm guessing he sold it to Belden lately?

Almost ten years ago now !

I know there's a tendency to romanticize how smaller companies were able to give more attention to their customers back in the day. Prosoft certainly grew up in the oil and gas specialty business and was a small company with a tight focus. Doug Sharratt was one of those guys who was personally important to the industrial comms business back in the day, in the same way as Jerry Miille, Lynn A. Linse, and Ron Monday. When Doug was killed crash-landing Prosoft's Cessna twin at Sunriver back in 2008, it was a blow.

Doug would have loved drbitboy's explanation of T-uhoh block data interrupts and enthusiastically launched into an explanation of the backplane API's block handling counters.

 

[BachPhi]

SWPB can swap byte AND word. This should be a direct answer to what he is asking for.

 

[drbitboy]

SWPB can swap byte AND word. This should be a direct answer to what he is asking for.

According to Logix, SWPB swaps words IFF* the source and destination parameters are DINTs. So the 112 INTs would need to be COPied to 56 DINTs, then word=swapped (by individual DINT i.e. in a loop), then those DINTs need to be COPied to the REAL array.

* See the Order Mode table here.

 

[drbitboy]

I realized this is a cleaner, more understandable way to do the FAL approach:

CPS dataarray[0] intarray[1] 112    ;;; intarray is ARRAY[0..112] of INT (113 elements), this fills elements 1-112.
OTU ctrl.EN
FAL ctrl 56 0 ALL intarray[2*ctrl.pos] intarray[[(2*ctrl.pos)+2]    ;;; shifts INT element 2 to 0, 4 to 2, ... 112 to 110; leaves odd elements in place
CPS intarray[0] realarray[0] 56

N.B. I am pretty sure those instructions could all be on one rung.