Ravioli
Member
I have read several posts where Ken Roach warns of using not-start, as your stop condition, and how asynchronous IO updates may result in a failed start. The recommendation is to assert a start until the drive is active, and assert a stop until the drive is not active.
I have two issues with this approach:
Bad practice
Best practice
My suggestion
My thinking with this method is when the PLC wants to run the drive (CMD_FWD/ CMD_REV), the first scan stops asserting the stop, second scan will enable the forward/reverse bits, and the third scan will enable the start command. Would this be sufficient to keep the race condition from happening? If I moved the start rung below the forward/reverse rungs it should execute it in two scans (drop the stop in the first scan, then send start and direction in the second scan)
Bonus question: Has anyone heard or seen a missed start phenomenon on PF700 on RIO on PLC-5? I'm trying to track down an issue where once every few months the drive doesn't seem to start. Although the RIO outputs are updated synchronously, is it possible that they are asynchronous between the 20-COMM-R and the Drive? I was thinking of trying to change the logic to something similar to the above.
I have two issues with this approach:
- If the PLC logic commands the drive to start while it is in the middle of ramping to a stop, the drive will first come to a stop, before starting again, rather than accelerating back up from whatever speed it's at.
- If the drive is configured for ramp and hold, the active bit stays high when the drive is sitting at DC injection, meaning the drive won't get a start command.
Bad practice
Best practice
My suggestion
My thinking with this method is when the PLC wants to run the drive (CMD_FWD/ CMD_REV), the first scan stops asserting the stop, second scan will enable the forward/reverse bits, and the third scan will enable the start command. Would this be sufficient to keep the race condition from happening? If I moved the start rung below the forward/reverse rungs it should execute it in two scans (drop the stop in the first scan, then send start and direction in the second scan)
Bonus question: Has anyone heard or seen a missed start phenomenon on PF700 on RIO on PLC-5? I'm trying to track down an issue where once every few months the drive doesn't seem to start. Although the RIO outputs are updated synchronously, is it possible that they are asynchronous between the 20-COMM-R and the Drive? I was thinking of trying to change the logic to something similar to the above.