What is the sort of information everyone likes to bake into their equipment standards for new Kawasaki robotic systems, specifically for material handling? I've seen everything spelled out down to program names and functions/ip addresses/IO mapping/communication types to the opposite end of the spectrum where maybe one would ask for a specific controller/robot model and that's it. Also those with integration experience what is something you like/dislike to see when reviewing the customers request for new projects?
Developing a Equipment Standard for New installations of Kawasaki Robots
-
ericwiz7923 -
April 9, 2021 at 7:29 PM -
Thread is Unresolved
-
I do not have a whole lot to offer up. But you mentioned material handling, so one thing comes to my mind. That the bolts holding the end effectors onto the robot are safety lock wired such that they cannot back out from vibration and such. I went to one installation that had been running and a maintenance person needed help to position the robots so that they could check/tighten any loose bolts. I was like, "what? Who does not lock wire their bolts?" Well they didn't specify it, and I suppose others don't either. Big hazard to have an end effector come loose at high speeds.
-
I do not have a whole lot to offer up. But you mentioned material handling, so one thing comes to my mind. That the bolts holding the end effectors onto the robot are safety lock wired such that they cannot back out from vibration and such. I went to one installation that had been running and a maintenance person needed help to position the robots so that they could check/tighten any loose bolts. I was like, "what? Who does not lock wire their bolts?" Well they didn't specify it, and I suppose others don't either. Big hazard to have an end effector come loose at high speeds.
That’s a good suggestion. Never seen a Tool go flying, lots of parts though lol. Best one was I told a rookie tech not to blindly run the robot homing program because the clamps holding that large metal car part would open sending the part flying in the process. He looked me square in the eye said “No it won’t” then proceeded to yeet that part out of the cell.
-
I'm not sure about your specific application. One thing i really dislike is when people change base and tool coordinates without considering the consequences.
For instance as a rule we always leave our robots with a null base. That way everyone knows the base coordinates instinctively when looking at the robot and where the plugs come out the back of the robot and apply the left hand rule.
And since the new guys don't know any better and don't double check things before making changes it avoids the chance of mistakes happening.
For example, years ago someone change the base coordinates on a robot by 90 degrees so they could work in the positive quadrant because they thought they knew better. One of our other service technicians went to make changes and didn't realise. They ended up damaging the tool and surrounding conveyors as a result.
So having a standard and enforcing a standard is another challenge in it's own.
The only other thing i would say is that the less things you change from default the less thing can go wrong or forget to change when replacing existing equipment with new equipment or copying it for a future system.
For example. Say you have a VSD/VFD and the default setting is for the motor to run forward. but when you install it you see the motor runs in the opposite direction. You could change it in software thus changing it from default. When the VSD fails and gets replaced the person doing it might not realise they need to change the direction setting from default and potentially cause damage as they will usually wire it the same as the drive they are replacing.
But if they installed the VSD correctly and swapped any of the 2 phases so that the motor went the correct way in the default setting this wouldn't have been an issue.
-
Interesting topic and something I could spend hours on for sure based on my experience with end users and integrators.
But to some things up generally:
- Fundamental product knowledge is key - even if you are an operator.
- How this fundamental knowledge is then applied.
- Anything programmed can be changed unless access is prevented.
- Just because it works, does not mean the pixies are not queuing up waiting for some fun.
I completely concur with ShAdOwDrAgOnS
Base and Tool go hand in hand as they are the 2 fundamental coordinate systems used.
Whether you use BLOCK or AS, Base and Tool are fundamental to the robot and intended application.
They need to be considered for ANY intended application and applied accordingly.
Fundamental to ANY Robot is:
- Correct zeroing.
- Correct working envelope parameters (hard stops, limit switches and joint limits).
- Correct EOAT values (Tool)
- Correct internal working areas of the envelope (Base).
Not setting these or applying them incorrectly is going to lead to a charity event for the pixies.
You now have the added bonus of Cubic S to 'Police' the settings and stop the robot in the event of 'external influences', but Cubic S can only police the fundamental settings, if these are incorrect, the policing of them will also be incorrect.
All OEM's provide training for their products, anyone dealing with robots should at least attend some fundamental product training.
In house training often circumvents fundamentals for application training.
-
Display More
Interesting topic and something I could spend hours on for sure based on my experience with end users and integrators.
But to some things up generally:
- Fundamental product knowledge is key - even if you are an operator.
- How this fundamental knowledge is then applied.
- Anything programmed can be changed unless access is prevented.
- Just because it works, does not mean the pixies are not queuing up waiting for some fun.
I completely concur with ShAdOwDrAgOnS
Base and Tool go hand in hand as they are the 2 fundamental coordinate systems used.
Whether you use BLOCK or AS, Base and Tool are fundamental to the robot and intended application.
They need to be considered for ANY intended application and applied accordingly.
Fundamental to ANY Robot is:
- Correct zeroing.
- Correct working envelope parameters (hard stops, limit switches and joint limits).
- Correct EOAT values (Tool)
- Correct internal working areas of the envelope (Base).
Not setting these or applying them incorrectly is going to lead to a charity event for the pixies.
You now have the added bonus of Cubic S to 'Police' the settings and stop the robot in the event of 'external influences', but Cubic S can only police the fundamental settings, if these are incorrect, the policing of them will also be incorrect.
All OEM's provide training for their products, anyone dealing with robots should at least attend some fundamental product training.
In house training often circumvents fundamentals for application training.
I understand completely. I based most of my listed specs off of our existing equipment for modularity so that it will be easier for my technicians to repair in the future (ie. controller model, AS Program exclusivity, Cubic-s version). As far as the use of base and tool coordinates (or lack there off) and the AS Programing exclusivity, that was how the equipment was originally designed and sold by the integrator. Our applications do not change tool or base values. One part of your comment that just hit me like a bolt of lightening though, that may make my revised spec, is your comment on correct eroing and correct working envelopes. That would most certainly save a lot of heart burn down the road. All great information everyone!
-
I would add that payloads be setup correctly, including whatever these robots call equivalent of ABB "Armload".
-
As far as the use of base and tool coordinates (or lack there off) and the AS Programing exclusivity, that was how the equipment was originally designed and sold by the integrator.
I did not want to come out and say this as it steers away from your topic, but this is kind of my point.
Kawasaki Systems certainly allow them to be very bespoke indeed, and as an end user, should problems occur, then the supporting OEM documentation or training you have received may not support your cells and you are totally reliant on the integrator should you experience errors, faults or strange occurrences.
To be clear, I am not making any kind of statement towards your integrator in saying what they have delivered and setup is wrong.
The point I am making is that where possible, always follow fundamentals as the OEM documentation will be relative to them.
If these fundamentals are not followed, there must be a reason why.
For instance, an integrator may re-zero JT4 (on a 6 axis robot) 180 degrees from mechanical zero to accommodate a service pack/harness installed.
As an end user, unless you are aware of this and you needed to re-zero JT4 (ie motor failure/change), then it is very likely you will use OEM procedures and the result could tear the harness afterwards.
If you come across a cell that doesn't follow fundamentals, then be aware/in agreement of them before hand between integrator and client and have it documented/pencilled into any in house training you are likely to offer so you can fully support it.
Yes, Lemster68 has also suggested payload.....
Kawasaki uses AS Weight command or Tool coordinate aux function to apply payload, COG and moment of inertia values that will certainly allow for a more optimized system.
-
Display More
I did not want to come out and say this as it steers away from your topic, but this is kind of my point.
Kawasaki Systems certainly allow them to be very bespoke indeed, and as an end user, should problems occur, then the supporting OEM documentation or training you have received may not support your cells and you are totally reliant on the integrator should you experience errors, faults or strange occurrences.
To be clear, I am not making any kind of statement towards your integrator in saying what they have delivered and setup is wrong.
The point I am making is that where possible, always follow fundamentals as the OEM documentation will be relative to them.
If these fundamentals are not followed, there must be a reason why.
For instance, an integrator may re-zero JT4 (on a 6 axis robot) 180 degrees from mechanical zero to accommodate a service pack/harness installed.
As an end user, unless you are aware of this and you needed to re-zero JT4 (ie motor failure/change), then it is very likely you will use OEM procedures and the result could tear the harness afterwards.
If you come across a cell that doesn't follow fundamentals, then be aware/in agreement of them before hand between integrator and client and have it documented/pencilled into any in house training you are likely to offer so you can fully support it.
Yes, Lemster68 has also suggested payload.....
Kawasaki uses AS Weight command or Tool coordinate aux function to apply payload, COG and moment of inertia values that will certainly allow for a more optimized system.
I agree 100%, hence the desire to develop a company spec.
Advertising from our partners
