I also use Allen Bradley Ethernet IP.
For starting I pulse an abort for 250 msec, wait 250, then pulse prod start for 250.
Then I have a handshake where the PLC waits for the robot to be ready and finish any initialization or home routine, then the PLC acknowledges with a 250 msec pulsed DI.
To stop the robot, hold the stop signal on with the PLC until UO[program running] is off to confirm the robot has ended its program.
When the fence circuit is closed and power on reset, I wait 500 msec then pulse the robot reset. If you don't have the delay it will not reset always.
I found these to be very reliable timings. You may be able to shorten the times and still be ok, just test it.
Sent from my VS985 4G using Tapatalk
I use cstopi for an immediate abort in the start up sequence.
But I also have a DI cycle stop for the operator to stop the program with a push button. After every cycle and during waiting periods the robot checks for the cycle stop push button and will go home then end the program if pressed. This allows me to have a controlled customized end cycle routine. The PLC will hold the end cycle DI on until the robot stops, allowing it to finish it's current task.
Sent from my VS985 4G using Tapatalk
In the system configuration, are the UI signals enabled and the control set to Remote?
Are you using the CSTOPI for Abort. or are you using the actual about DI. That helps a lot, I have been looking for a chart that shows the timing for reset, start, stop of a robot but have not found anything yet.
Thanks,
Steve
I'm only speaking from experience with a RJ3 controller, but there should be a UOP signal timing chart in the manual.
For this kind of signals, always do a handshake between PLC and robot. It's safer and easier to check if there any problems.
There is a timing chart in the manual, but it does not have actual times, it just shows when signals need to overlap, etc. Depending on scan times and RPI setting in the PLC, the actual timings could vary from system to system. The timings I have are fairly conservative, you could shorten them if there was a need to, but you would need to test it on your specific system to make sure it still works consistently.
There is a timing chart in the manual, but it does not have actual times, it just shows when signals need to overlap, etc. Depending on scan times and RPI setting in the PLC, the actual timings could vary from system to system. The timings I have are fairly conservative, you could shorten them if there was a need to, but you would need to test it on your specific system to make sure it still works consistently.
Correct.
The chart just shows the rising/falling edge overlap.
Looking back at OP and the original question, I would just try pulsing your signals a little longer.
After every cycle and during waiting periods the robot checks for the cycle stop push button and will go home then end the program if pressed.
Hi, sorry for refreshing an old topic.. (this is my first post btw) but I have a question the Cycle Stop check. I already implemented a Cycle Stop request check with every loop of the Main program. The problem I see is that when the robot is in a WAIT instruction (e.g. waiting for a new job) it won't stop the cycle. I could add it after a WAIT timeout but lets say it has to be the default 30s. That is a waste of time. HawkME you say you check this "during a waiting period" and I completely understand but could specify how you do this?
Add the cycle stop to every wait by using the "or" operator. For example:
: WAIT DI[x] OR DI[y] Timout LBL XXX
: IF DI[y], call cycle_stop
DI[x] is your normal wait condition, and DI[y] is your cycle stop input. Now a cycle stop request will also break the wait condition.
Oh man.. I was completely overthinking this that I'm embarrassed the solution is this simple. I forgot you can add operators in WAIT instructions.. (maybe was thinking about WHEN conditions).
Anyway thank you so much for your help! (hides head in sand)
No problem. If you don't often use waits this way then it's easy to forget. I always use them this way so I have more responsive program control.
