I don't use the FAL instruction very much at all but I am currently working on an upgrade from a PLC5 to Control Logix and the standard program conversion rewites the expresion and destination and was hoping that some one could confirm that it is correct.

PLC5 writes it as (RSLogix5)
FAL R6:0 64 63 ALL #N7:154 #N7:90

Control Logix writes it as (RSLogix 5000)
FAL R6[0] 64 63 ALL N7[154]+R6[0].POS N7[90]+R6[0].POS

Any info is greatly appreciated. Thanks.

try posting this string into RSLogix5000 ... I think that it's a little bit closer to what you're looking for ...



FAL(R6[0],?,?,ALL,N7[154 + R6_0_POS],N7[90 + R6_0_POS]);



going further ... it looks like all that you want to do is copy a range of 64 memory locations from one place to another ... if that's true, then a simple COP instruction might be all that you need ...



usually I like to test these things before I post them, but I don't have a CLX system handy right now so I'm going out on a limb here ...



anyway, you get double your money back if it doesn't work right ...

Thanks, yea I typed it from memory, your correct.

Now after reading your post and seeing it on another coputer it is clear to me now, Thanks.
I could use the copy but in this case the program is making sure that all the data is copied over, because the next step is that it gets sent to a VB app.

You can still use a copy instruction. The CPS instruction (Copy Sychronous) will execute completely before moving on to the next rung.

You may want to read the fine print on the CPS instruction. I don't believe that execution of the next rung is prevented simply that the CPS protects the data structrues involved from change until the CPS is complete.

Actually, both the COP and CPS will complete fully before moving to the next rung. A simple test is to trigger an incremental copy (COP, Test[0], Test[1], 100) followed by a move (MOV, Test[99], Result) with a oneshot. If the copy doesn't completely finish first you will get variable results in Result.

The difference is that the CPS instruction protects the data source and result from being written to or read from anywhere but the instruction itself. The CPS is a required adder due to the asynchronous access that the CLX allows from just about anywhere. Actually, I think you could run into the same issue on the PLC5 with communications.

Keith

No you wouldn't have this issue on a PLC 5 because it's scan is as follows:
Input Image Update
Solve Ladder Logic
Output Image Update
Overhead Tasks
Repeat.

The communications cards would store new data to a comm buffer and only update the input image during the appropriate part of the scan.

In the CLX the Image Table updates are handled by a dedicated CPU seperate from the logic solver and therefore occur asynch.

I know this is true on the SLC series. I thought the PLC5 was built as a two processor system. The logic solver was separate from the communication processor. This tended to keep the overhead timeslice pretty short as all it needed to do was hand I/O data off to the comm processor and then move on. It's also why immediate I/O queries took such a toll on scan time. the logic slover needed to wait for new data before it could proceed. The same would be true of rack mounted comm cards. All the rack mounted stuff was buffered.

However, for serial or DH+ I thought the comm processor directly accessed memory as required. So you could get a change of data part way through the scan.

Keith

I am not an AB design engineer, but that is not how it has been explained to me in the past. I guess we will learn as we go.

I believe you're correct regarding DH+ being asynchronous - don't know about serial. In the 'classic' PLC5, remote I/O was also asynchronous, but I think they changed that on the 'new platform' PLC5.

The other thing to consider on CLX is other tasks - a higher priority task will interrupt a COP mid-stream but not a CPS. Regardless of the native DINT architecture, the COP moves data one byte at a time, making it easy for INT and DINT data to be corrupted. Incidentally, DH+ data transfer also moves one byte at a time.