adccommunitymod (AutomationDirect) asked a question.
RS485 Modbus Communications Interrupted During Run-Time Transfer
Created Date: February 14,2011
Created By: jjsjeff
**** This post has been imported from our legacy forum. Information in this post may be outdated and links contained in the post may no longer work.****
On my latest project I was doing run-time transfers to force logic on and off while a process was running during checkout. I noticed everytime I did this all of my Schneider Electric Altivar 312 drives would get a modbus error because communication was interrupted. Is this something that will be fixed in future releases of the 550? Software/Hardware info: Productivity 3000: v1.4.0 (29) P3-550 f/w: v1.0.9.23 RS-485 Network: 9 Altivar 312 and 1 AC-Tech MC1000 series
Created Date: February 14,2011
Created by: bcarlton
I don't think the P3000 has true online programming. Therefore an interruption is expected during a transfer. Is there something you read about the P3000 which made you believe this wouldn't happen? It's just a side effect of the nature of the P3000. Unless they really change the whole method of operation this probably won't go away. Work out a way to test your logic other than re-downloading code or be prepared for the interruptions.
Created Date: February 15,2011
Created by: jjsjeff
This is what it says on page 6-12 in the P3 user manual:
Run Time transfers allow the user to transfer edits to a project back into the CPU without
stopping the CPU scan, therefore not stopping the process. Be aware that a Run Time
transfer will affect the length of your scan time, which should be considered if your process is
susceptible to varying or lengthy scan times. The download time is longer compared to a
Stop Mode transfer.
During a Run Time transfer, the current project file continues running until the entire
project file is transferred to the CPU. Once downloaded, the ladder logic files swap and
begin executing the new file. The Tag Database is shared between the two project files during
a Run Time transfer, therefore current operating values will not be effected.
Because the Tag database is shared, any edits to the Tag database will force a Stop Mode
transfer.
Maybe I'll have to do some testing to see if it was a problem with taking too long to download causing the drives to fault. I believe the manual for the ATV312 VFDs mentioned that they like to be talked to at least every 5 seconds or they throw the modbus comm fault.
I 've since commissioned the project and probably won't see it ever again, but I will do more like it in the future most likely.
P.S. The job was in Connell, WA and the weather was great last week (compared to what I would have endured in KS).
Created Date: February 15,2011
Created by: bcarlton
I stand corrected. It does seem to imply that communications will continue given that the scan will continue. Do you think the lengthened scan would be at fault?
I have no idea if these drives have a similar feature but Allen Bradley drives allow a 'continue last ' operation if communications stop. I assume there are hard wired stop methods.
Created Date: February 15,2011
Created by: Do-more PE
I tested this here and the communications does indeed continue during a run time transfer. I would suspect that the lengthened scan time during the swap is the culprit.
Created Date: February 15,2011
Created by: jjsjeff
Thanks for checking on that. ;)
It's good to hear that it does indeed work the way I thought it did and that I just need to fix the other problems.
Created Date: February 14,2011
Created by: jjsjeff
On my latest project I was doing run-time transfers to force logic on and off while a process was running during checkout. I noticed everytime I did this all of my Schneider Electric Altivar 312 drives would get a modbus error because communication was interrupted.
Is this something that will be fixed in future releases of the 550?
Software/Hardware info:
Productivity 3000: v1.4.0 (29)
P3-550 f/w: v1.0.9.23
RS-485 Network: 9 Altivar 312 and 1 AC-Tech MC1000 series