# Robot Automation



## IMM_Doctor (Mar 24, 2009)

*Injection Molding Press Robot?*

You weren't specific about what material is being handled, but when you reference Whittman, I speculate Injection Molding Machine.

I may also speculate that your robot is a hybrid (combination) of servo driven (encoder) monitored axis, and also pneumatic (proximity switch) end-of-travel monitored axis. 

If your problem lies solely with the "C-Flop" pneumatic axis, I suspect intermittent proximity switch overlap. It is common to have simple reed or magnetic sensors on the flop cylinder and if during the rotational flop that the end-travel of one end comes on before the the opposite end of travel goes off. By the time you arrive after the fault you don't see the overlap. It is common for software enginners to program a hard fault when both ends of an axis are seen on at the same time. 

To prove, or isolate overlap as a possible culprit, temporarily abandon one of the sensors that is at or near the central rotational axis which is easily ovelapped, and install a new discrete digital prox at the circuference of the axis that will guarantee that it will only make at the far end of travel.


----------



## RIVETER (Sep 26, 2009)

jjlogue3 said:


> Does anyone in here have any robotic automation experience? I am currently trouble shooting a Whittmann 8 series robot with a cnc 6.2 controller. The robot is a single dimensional robot currently performing multiple maneuvers as well as a simple stacking program. The program starts by going down on the y-axis to pick the part then back up to 0 position on the y then traverses on the z to a cage and x out to a printer y down to print the bar code x in away from the printer c flips to 90 degs and y down to stack in 2 piles of 5 then triggers the conveyor for 3 seconds. Our current problem lies in the area of the program that flips the c to 90 degs. At this point the robot stops (sometimes after hours of operation and others about every 20 mins) and will throw up a c axis illegal operation fault. The c axis isn't monitored by a transducer it is simply monitored by proximity sensors 1 at 0 degs (home) and 1 at 90 degs. The fault hints towards an over travel fault but this is impossible due to the sensors. I personally as well as many others have stared at the proxs at the exact time the alarm occurs and haven't seen so much as a hiccup. I recently programmed a 2 second delay before and after the c axis makes its flip and has seemed to produce longer run times but the problems still happen from time to time. Any ideas? We have ruled out the contractors and a servo overheating would throw up an alarm all on its own. My next step is to make a less complex stacking program to see if that helps. But I am open to any and all ideas. Sorry for the long post just wanted to get all the appropriate info out.:thumbup:
> 
> Thanks
> Jeremy


That is a lot of information to digest. I am not an expert but maybe you could insert two steps...one before the problem step, and one after the problem step. Just use a very small xyz shift on each new step and maybe it's computation errors will go away.


----------



## jjlogue3 (Mar 5, 2011)

IMM_Doctor said:


> You weren't specific about what material is being handled, but when you reference Whittman, I speculate Injection Molding Machine.
> 
> I may also speculate that your robot is a hybrid (combination) of servo driven (encoder) monitored axis, and also pneumatic (proximity switch) end-of-travel monitored axis.
> 
> ...



You are correct in your assumptions 230T Hpm toggle to be exact producing 1 part every 50 seconds. You are also correct with a combo of encoder and prox with the only prox being on the c flip axis and the xyz being encoders. It seems to me that we ruled that out by triggering both proxs at the same time during the flip but just to make sure I will try it again tomorrow. Also I forgot to mention that we ruled out the injection molding machine (kinda ruled out its self due to it finishing out the cycle and finally alarming for cycle time).


----------



## jjlogue3 (Mar 5, 2011)

RIVETER said:


> That is a lot of information to digest. I am not an expert but maybe you could insert two steps...one before the problem step, and one after the problem step. Just use a very small xyz shift on each new step and maybe it's computation errors will go away.


I did this with the 2 second pause before and after the c flip and since this is a 1d robot we are trying to get our moves to a minimum. I could be wrong but I don't think adding moves will help my problem. Thanks for the reply none the less. And for that matter sometimes a non expert looking in can point out something that the ones of us that deal with it every day will miss!


----------



## IMM_Doctor (Mar 24, 2009)

jjlogue3 said:


> Does anyone in here have any robotic automation experience? I am currently trouble shooting a Whittmann 8 series robot with a cnc 6.2 controller. The robot is a single dimensional robot currently performing multiple maneuvers as well as a simple stacking program. The program starts by going down on the y-axis to pick the part then back up to 0 position on the y then traverses on the z to a cage and x out to a printer y down to print the bar code x in away from the printer c flips to 90 degs and y down to stack in 2 piles of 5 then triggers the conveyor for 3 seconds. Our current problem lies in the area of the program that flips the c to 90 degs. At this point the robot stops (sometimes after hours of operation and others about every 20 mins) and will throw up a c axis illegal operation fault. The c axis isn't monitored by a transducer it is simply monitored by proximity sensors 1 at 0 degs (home) and 1 at 90 degs. The fault hints towards an over travel fault but this is impossible due to the sensors. I personally as well as many others have stared at the proxs at the exact time the alarm occurs and haven't seen so much as a hiccup. I recently programmed a 2 second delay before and after the c axis makes its flip and has seemed to produce longer run times but the problems still happen from time to time. Any ideas? We have ruled out the contractors and a servo overheating would throw up an alarm all on its own. My next step is to make a less complex stacking program to see if that helps. But I am open to any and all ideas. Sorry for the long post just wanted to get all the appropriate info out.:thumbup:
> 
> Thanks
> Jeremy


Next time the alarm happens. Write down the alarm text EXACTLY as it appears on the robot HMI. Be succicnt and exact in caps and punctuation.

Then go to Google, and enter the exact alarm text surrounded by quotes. You may get lucky, and find another Whitman user that already solved this. Or go to the Whitman Web-site and enter the same alarm text in quotations, and you may get a hit from one of the Wittman troubleshooting manuals.


----------



## jjlogue3 (Mar 5, 2011)

IMM_Doctor said:


> Next time the alarm happens. Write down the alarm text EXACTLY as it appears on the robot HMI. Be succicnt and exact in caps and punctuation.
> 
> Then go to Google, and enter the exact alarm text surrounded by quotes. You may get lucky, and find another Whitman user that already solved this. Or go to the Whitman Web-site and enter the same alarm text in quotations, and you may get a hit from one of the Wittman troubleshooting manuals.


I have not googled it but we have been in contact with the whittmann techs actually a whittmann came to our facility and wrote the program in question for us to train me and the other electrician how to program the stacking portion. The whittmann techs suggested changing out the contactors and beyond that "they can send a tech out" which it really isn't that much of a problem for us as of yet. Did you get my PM?


----------

