Repeating a routine.

DFulkerson1rcp

We have a problem with our dual cell set up. We are running a 1400 and 6400 series for a welding and stacking process. The problem is the 1400 is repeating the routine that is called for some reason. The process is: The bots are started and they both run the routine for the product being made/welded. They are both welding on the same part till the end of the routine, the 6400 will go into a gripper routine to grab the the product and stack it, (only if the 1400 has completed its routine and has given the signal that it is done), then the 6400 will go into it's stacking routine, then it goes back to the main routine. The problem is happening at the end of the 1400's routine, it is not going to the main routine, it is staying in the same routine and repeats it, and the 6400 has the signal to pick up the product up while the 1400 is repeating the routine and it ends up in a big mess.

The 1400 is randomly doing this, and it only repeats it once. I checked the I/O's and there is nothing telling it to start again, I have searched the program for errors and found nothing.

For the bots to get the signal to start there has to be several I/O's made first.

I loaded a different prg. and haven't seen this problem since then. my question is what would cause it to repeat a routine on its own.

xerim

Is your run mode set to Single Cycle or Continuous? What happens when you add a Stop; to the end of the program? 

lemster68

I am going to guess that someone has set the PP to that routine and that Auto Condition Reset, AllDebugSettings, found in the system parameters for controller, is set to NO.  If this is the case, the controller, when switched into automatic, will keep the program pointer in that routine, rather than move it to the Main program.  You will see that warning when switching into auto.  Also, it will waarn if IO is simulated and speed is not 100%.

DFulkerson1rcp

The speed was on 100% and the run mode was set to continuous. i never received a error or warning, it was crazy, we loaded the prg. as before, did the weld mods and started to run the parts. it repeated several parts then it would  run normal for 20 to 30 parts then repeat the routine. once i replaced the prg. with a older copies it hasn't done it any.  
i never put a stop in it, but i did put a WaitTime 0.5 at the very end of the routine and still did it randomly. 

lemster68

What controls the cell/robots?  A PLC is telling them to select and run programs?  Or do you have some kind of simple control box to start/stop the robot?

DFulkerson1rcp

it uses an PLC to start, for it to start the jig/table has to be locked down then the start button pressed. Both bots send an output to the PLC and the PLC sends a input to the 6400 to continue with the stacking routine. When the 1400 would repeat the routine I looked at the I/Os and there was nothing telling it to start the routine. To me it was acting like there was no ENDPROC at the end of the routine. or like I had moved PP to routine and started it, causing it to repeat, but i cant understand why it would only do it once then not do it for 20 to 30 parts. I am beginning to believe that they have a mind of their own.   

lemster68

It is not possible for a routine to NOT have an ENDPROC, the controller would throw an error upon loading or PPtoMain, or Check program.  When you have time, PP to that routine, then put it into auto, note any warnings.  Let us know what it says.

DFulkerson1rcp

OK, will do. It might be a few days, we are running it now, I'll do it no my next setup. Thanks.

DFulkerson1rcp

OK I loaded the PRG. again, and no errors, warnings. Now i did have to do a cold start on this unit 9/21/20, due to a Internal log messages

1.  rlsup.c 2910 Not possible to free previously allocated PGM inter ¼0721 07:08.41 0721 07:08.41

rlsup.c 2910 Not possible to free previously allocated PGM interrupt no

Could that have any thing to do with it. 
If it will help, I do have the error log from when it started this repeating.

Danijel_Cro

OK, this is very interesting issue, can you share a little more info.

1. How exactly are you running the robots through the PLC, or better yet how your main routine looks like (do you use main routine at all), or you are loading routines according to the conditions?

2. Do you use handshake signals?

3. Which conditions needs to be meet to start the process routine in the first place?

4. Do you have more routines which are being called?

Small tips to check/implement:

- we had a situation where signal "Start at Main" on PLC side was triggered/flickered in certain conditions, which means that robot started from the first line, and if you don't have implemented double checking with PLC ( ie. handshake signal) would start the routine once again

- from my experience described issue lies on PLC side or PLC-Robot interface, and not in setting of Robot/Routine itself especially because this happens from time to time

- yes the described issue is happening like it would if you have continuous mode activated, but continuous mode repeats the routine where the PP was set, and ENDPROC command returns PP to routine which called subroutine.

So if you use MainRoutine, then calling production subroutine, from your description, you reach end, return to MainRoutine, and then for some reason call the routine again. If this is the case, its up to the PLC/PLC-Robot interface.

DFulkerson1rcp

OK i have attached the prg with notes and the flow on it. The bots gets its start signal from a PLC but there has to be several inputs made before it will start. Look over these, and let me know if you need any thing else.

lemster68

Do not use PulseDO, set that output and wait for a bit from PLC acknowledging that the routine is complete.  Then, turn the output off and wait for acknowledge complete bit to turn back off.

DFulkerson1rcp

I'm not understanding you completely. Do you want me to see how long it takes the PLC to see the output. or the bot to see the output.

lemster68

No, it is an acknowledgement, a handshake.  Robot says I am done, PLC says, I see you are done.  PLC won't tell the robot to do that routine again until it is the right time to do it.

DFulkerson1rcp

Im not 100% on what the PLC prg looks like i haven't been in it yet, i only have a little knowledge about the prg. I do know that on the I/O's on the pendent it changes the  START_LEFT=1 to a 0 when it does PulseDO LEFT_DONE; thats on both bots. after this only on the 6400 it has the L_Grip_ready,1; and the output PulseDO L_Grip_done; (LINE 998 on 6400 prg) changes it to 0. Those I/O's do come from the PLC.

lemster68

PulseDO is not good, especially as in your program.  It does not specify to pulse high, which is an optional argument.  If the signal is already is already high, it will happily pulse it low.  Not only that, but also you can get stuck when the cell stops, like e-stop, before the PLC can act on the signal, then you go back into auto, signal will be low, and things will go wrong.  That is why I suggest the handshaking, turn a bit on, wait for acknowledge, turn the bit back off, wait for ack to turn off, proceed.

DFulkerson1rcp

OK I wasn't the one that wrote the PRG. its the product of 6 people. We have been running it this way for 10+ years. What command would you recommend to use. Also do you think that is why it repeated. 
and i was just thinking about it that signal only tells the PLC that it is done, and the table/jig is ready for start again. the only one command that stays active is  START_LEFT=1, unless the PulseDO LEFT_DONE; is what changes it out, but not knowing how the PLC Prg. is setup im not sure. but why would that only do it on this copy of the prg. and randomly, because as soon as is loaded another copy  it hasn't done is sense.

lemster68

I have had to fix cells that used PulseDo before, they just get stuck and no one knows why.  If I force the output that the PLC is expecting, then things get back into sync.  I replace the PulseDo with a Set and Reset with some time in between, or you handshake it like I described.

Danijel_Cro

It is hard to say what is exactly happening without checking PLC program, but is it possible that you will not get signal for Dowel_16, until the Dowel_15 is recognized from PLC as done, as an precaution for PLC that all jobs before are finished?

DFulkerson1rcp

Sorry its taken so long for me to respond. Thanks for all your help. 

lemster68

So have you resolved the problem?

DFulkerson1rcp

Yes i believe so. Knock on wood it has been running great, for now. I haven't changed that PulseDO yet, I need to look at the PLC first to make sure it doesn't need to be changed in there also. 

Danijel_Cro

Ok, but can I ask what did you change and what was the issue?

Or, for now you didn't had this problem anymore?

Feedback for us is also important as for you is the answer for your question.

DFulkerson1rcp

I just changed the Program. I used an older copy of the same Program. Once I did that It has never done it again. Could that PRG, or file have been corrupted for some reason? I pulled it off a flash drive, and it hadn't been used for a while. I didn't have the PRG on the ram because I had to do a cold start on it due to the (rlsup.c 2910) error. 
Or could the contacts stick in the PLC modules, I understand that they either are good or bad, but I have seen relays contacts stick randomly. And with the PulseDo command being a short burst, it is not be enough time to release the contact?
We have been running it for a while now and no problems with it. My concern was Keeping it from doing it again, one for safety and to keep from breaking it.