Hey everyone,
I am working on a post-processor for Kawasaki robots and would love to see an example of a touch sensing program in the .AS format if anyone can provide one. Thank you in advance for your help with this!
Hey everyone,
I am working on a post-processor for Kawasaki robots and would love to see an example of a touch sensing program in the .AS format if anyone can provide one. Thank you in advance for your help with this!
Check out the Arc Weld AS Language Manual, there is an example in there which is very complexed and searches by touch sense and frames to generate a weld path.
I have put this into a KRoset video example here on my youtube channel:
KRoset (Licensed Version) - Arc touch sense example from Arc AS manual - YouTube
I have a more basic version too for X/Y adjustment which displays some basic touch sense code:
KRoset (Licensed Version) - Basic AS Touch Sensing for XY directional offset - YouTube
Good luck with it as the Kawasaki touch sense command invokes several parameters in a single instruction.
Display MoreCheck out the Arc Weld AS Language Manual, there is an example in there which is very complexed and searches by touch sense and frames to generate a weld path.
I have put this into a KRoset video example here on my youtube channel:
KRoset (Licensed Version) - Arc touch sense example from Arc AS manual - YouTube
I have a more basic version too for X/Y adjustment which displays some basic touch sense code:
KRoset (Licensed Version) - Basic AS Touch Sensing for XY directional offset - YouTube
Good luck with it as the Kawasaki touch sense command invokes several parameters in a single instruction.
Hey kwakisaki,
This is great info, I actually have the manual and it has been very useful, but I need to see an entire program for reference to ensure I am not missing anything. Do you have a program you could share?
Both examples I have linked to are programs...........
The 1st is out of the manual and the 2nd is as you can see on the video.
Any chance I can get a text version of the files? Thanks!
Sadly not.
Unless I am paid for my work and my discretion (I operate my own business) , I only provide example code publicly as functionality for training, liability and plagiarising prevention purposes.
The 2nd example from my youtube channel is attached though.
Sadly not.
Unless I am paid for my work and my discretion (I operate my own business) , I only provide example code publicly as functionality for training, liability and plagiarising prevention purposes.
The 2nd example from my youtube channel is attached though.
Thank you!
Thank you for sharing the code. This is very interesting implementation to find the start point for a weld kwakisaki. Considering that the SSENSING option exists and is intended to achieve the same thing. However, as I understand things (so far), SSENSING doesn't shift the weld end-point (to preserve the weld trajectory), and SSENSE also doesn't have the ability to record the amount that the target point differs from the new detected start point.
Therefore, I deduce that without TRPM, SSENSE is not as powerful as the example that you provided above. Have I missed anything in the logic?
I don't have the RTPM board, but would like to shift the entire weld seam by the shift in the start point. I suppose the safest option would be to shift the start point using an adaptation of your example (XAC rather then SSENSE) , and then measure and shift the end-point of the weld seam (with XAC as well). Based on how much difference there is between the start-point shift and the end-point shift, I can decide if using the start-point shift alone is sufficient to shift the end-point and have a successful weld.
Pretty similar yes, but both have merit over the other in given situations.
Any weld path the SSENS can be applied to, but is intended for groove and is pretty much a 'fixed' start sense detection based on the pattern used and parameters for the groove as opposed to XAC which is primarily for work correction as you can see in both of my examples.
The more complex example is directly from the Arc AS manual (with some corrections I have done) which dynamically touch senses and creates frames to locate the start point of the weld and the end point of the weld is just a mm distance from the start point.
Something you would have to have a play around with, but IMHO if you are welding standard parts that fit in with the built in patterns, then SSENSE is easier to implement, but XAC has a little more 'power and flexibility' around bespoke parts.
Thanks for the feedback.
Perhaps this should be the start of a new thread, but the context of this query is that I am hoping I can use touch sensing to overcome a small challenge. The robot zero plates seem to have been tampered with in the past, and the TCP doesn't stay fixed when rotated about tool TCP. The implication is that I cannot change the tool angle without changing the TCP position.
The BA series robots don't have an available zero kit like the RS series.
This is a video of the TCP shift during angular change
The paint lines on the bolts don't match up anymore, I suspect they were removed and replaced when the robot was painted. Kawasaki told me that some of the blue robots were painted on the production line and others were done after the fact. I think this is an after-the-fact one.
I got the factory zero settings for the encoders, but that doesn't improve the situation. It actually makes the TCP stability worse. I have double-checked the Tool definition, and I tried the automatic tool definition process (repeatedly), but it gave many errors and didn't result in a satisfactory result.
I am going to add a smaller tool to the robot flange (calibration spike) with measurable offsets and then double-check the TCP stability again. The welding tool offsets are very difficult to measure accurately.
As plan B, if I am unable to re-zero the robot, is to try and get around the x,y,z position error by adding an offset to each weld position, into free space, then using SSENS or XAC to detect the exact position of each weld start and end before it is executed. I big cycle time hit for the process.
The paint lines on the bolts don't match up anymore, I suspect they were removed and replaced when the robot was painted.
That doesn't help.
I got the factory zero settings for the encoders, but that doesn't improve the situation.
Factory values are useless if any mechanical disconnect, motor changes, gear box changes have been made since.
Teaching TCP's accurately should really utilize dial gauges, DTI's and if any back lash is present that would have an impact on accuracy.
People have many methods of TCP teaching, but mainly using auto function requires patience and understanding of the process especially when OAT is required and if during auto tool errors occur, it is because you are not applying enough orientation differences between taught points usually.
Personally I have no issues with teaching TCP using the auto function or direct entry using OEM values or even using the A+B method (unknown tool in the AS manual).
But like what you are referring to, if you use a central spike to the flange and can refine your technique based on that, you could identify if it is the technique or possible mech issues within the arm.
You've got the option of getting an inclinometer and making some reference mounting plates to attach to certain positions on the arm segments to assist in more accurately zeroing each joint.