Sign in to follow this  
Followers 0
Stupidav

FAL Differences

10 posts in this topic

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. Edited by Stupidav

Share this post


Link to post
Share on other sites
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 ...

Share this post


Link to post
Share on other sites
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.

Share this post


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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0