Tool Calibration Form Problem

[Anonymous]

I've found what I think is a discrepancy in how Powermill handles a Spindle Calibration override.

We're running Powermill with Robot Plugin for a Kuka KR60 - L30 coupled with a rotary table for making a variety of sculptures in EPS and wood. We're using a spindle with a variety of endmills but also a large hotwire. I've created Spindle Calibrations for the spindle exactly per Powermill specifications and we get satisfactory results from this. However, creating a calibration using a long and short probe on the hotwire is considerably more challenging. I had created a TCP for the hotwire in the past using Kuka's XYZ 4-point method for one end of the wire that yields acceptable results when using the hotwire for rough cutting removal of large volumes of material before finishing with the spindle. However, we would also like to use the hotwire for more accurate finishing cutting in cases where the forms to be cut are simply much easier and faster to cut with the hotwire.

What I had wanted to do was to program the hotwire to come to a fixed known location where the wire should have a particular orientation (in this case, plumb to the rotary table top), then make adjustments to the TCP manually to get the desired accuracy. With that new TCP, I would then generate a Tool axis and Tool workplane X axis rotation matrix values and manually enter those into the Spindle information section of the Spindle calibration editor.

However, something odd happens when I try to switch back and forth between the spindle calibration using entered XYZ values for short and long probes and the Spindle information override.

The first 2 images show the TCP for a 15mm long hotwire tool when using the XYZ data. The second 2 images show the TCP for the same 15mm long hotwire when using the spindle information override - this override information was generated by the spindle calibration editor from the entered XYZ values; I did not create those numbers. Notice in the spindle override that the X value is 777.497. When using the entered data, the X value is decreased, when using the spindle override the X value is increased.

The first value is correct: 762.497. The second value is incorrect: 792.497. I have verified this with programs created with this tool. Although the difference may seem small for this particular tool, it becomes really problematic if I try to use longer tools.

Anyway, my question is why the difference? Should there be a difference? It seems like there should not be a difference at all.
Whatever the answer, is it possible to make a tool calibration override without this problem arising?

[alexandre.pintoAGNAU]

Hi John,

Can you export the calibration (steps below) and attach the  .Robsc  file?

This will help me understand this fully, after I  look into this I will report back to you.

Thanks.

[Anonymous]

Alex, files attached.

Thanks

[Anonymous]

Files

[Anonymous]

I created two files: one without using the Override spindle information and one with. When I look at the two saved files, I see that they're identical, which makes sense, because I didn't actually change anything in this case. But it's odd that 'no override' subtracts the length of the tool from the TCP X dimension (which I've verified is correct) and 'override' adds the tool length to the TCP X dimension.

[RAL6000]

Please note that the Angle C is changing from plus to minus.

Spindle override inactive: X 762 (777+15), C  180

Spindle override active:    X 792 (777-15),  C -180

In case you define the tools on the Kuka robot ($TOOL_DATA[]), did you changed the angle C too?

[Anonymous]

I did not change anything other than to check the Override spindle information box. Please note that +180 and -180 are exactly equivalent.

One of things that I had been doing to create a correct Kuka TCP, to get around the incorrect TCP from the override option was to use the Kuka 6th Workplane calculator through the Robot Configuration/Tool Database editor. This gives the correct X offset while also calculating the rest of the values correctly and had been giving me good results.

By contrast, from the image above, you can see the difference when trying to add a tool from the Robot configuration/Tool database editor when using the Tool calibration editor vs Workplane calculator. The workplane calculator will return the correct XYZ position (X offset in the correct direction along with its associated Y and Z coordinates). The Tool calibration editor returns the incorrect  XYZ position (X offset in the opposite direction with its associated Y/Zs). Again, the tool calibration is using the spindle information override in this case.

So this is my work around, which works. But it's annoying. There's clearly a bug associated with the spindle override in the tool calibration editor.

[alexandre.pintoAGNAU]

Hi John.

I have confirmed the issue you have reported, it is quite simple. Seems that when you select the "Override Spindle Information" the resulting X component of the tool coordinates are different. It must be an incorrect calculation in the background. I will report this to development.

The Tool orientation from both are correct though, both orientations result in the same Tool orientation.

One thing that is confusing me is that the X value is not the most important for your calibration (correct me if I am wrong) of the wire.

Looking at the image below, the X value is just moving the tool (wire in this case) up and down along the actual direction of the wire.

I would have thought that for you to replicate the correct position of the wire/tool the most important would be the Y Z position.

As you not interested in the position of the wire with respect to the X axis of the 6th axis workplane. What defines your position are actually the Y and Z coordinates, and these seem to be correct, these values are good. The issue is only on the X value.

Seems that the calculation with override is adding the Tool length from the Calibration surface, whereas the NoOverride is subtracting the length. It is not doing the math correctly.

Grateful for you reporting this, let me know if you need anything else.

Alex

[Anonymous]

Thanks for the update, Alex.

You are correct in that Y and Z ultimately are what produce the "correctness" of the actual cut, whereas the X determines the location of the hotwire bow around the part to be cut. This is ultimately what is causing me the problem. You can imagine that if I wanted to make a tool 200MM long to center the bow around a narrower piece of stock, if this tool is offset in the opposite direction the hotwire may not intersect at all with the actual material. Indeed if the X is not where it's supposed to be, PM simply won't execute the toolpath correctly or correctly and collision-free.

[alexandre.pintoAGNAU]

John.

I did not ask before, but why are you overriding?

What issue did you have with the default calibration data that made you use that option?

I am curious about this.

I noticed that on your calibration that:

A -  the length of the short spike, is 0

B - the ABC values perfect [0 -90 180/0 -90 -180]

A - would make more sense to have a spike length other than zero, it would actually calculate a vector/orientation of the tool/wire.

B - this indicates that the calculations are not 100% correct (due to A), or you managed to get a wire completely parallel to the X axis of the 6th axis workplane. ANy tool will have a slight angle as it is quite hard to mount a end effector on a robot and keep it aligned.

Do you recall the data I gave you as an example ?( I attach it here again, just import in the calibration form)

I created these points by adjusting a line in the CAD, i basically tried to replicate a calibration process.

I created a line that was my tool, and adjusted the length to simulate the long and short spike.

I also made sure the line was NOT parallel to the X axis, so that it has "real" looking values. The perfect rotation values of ABC to me indicate you are not replicating the wire with these values.

I hope this makes sense and helps you get a more accurate setup.

Keep me posted.

[RAL6000]

You are absolutely right. C is rotating around X. My fault^^

I also checked the manuals and there is nowhere detailed information about the function to override. I checked my tool calibrations, i have never used it and even when i now activate it i don´t get that kind of miss-calculation.

[Anonymous · Accepted solution]

Alex,

That calibration that I sent was just an example to illustrate that there is a problem with the override spindle information.

The reason for the override is because I don't have a hotwire setup for use with spikes at either end of the hotwire bow.

So instead, I want to use the TCP that I originally measured at one end of the hotwire as a starting point. I use the  XYZ position of this TCP as the tool attach point. I then use the Transformation converter to get rotation matrix values from the Euler angle values of the TCP. I entered the IJK values of that rotation matrix into the Tool axis vector and Tool workplane X axis IJK vector fields in such a way to produce a Spindle calibration with +Z pointing to the floor and +X pointing in line with the hotwire bow's arm and away from the robot. This is meant to establish a correct working PM calibration. I then created a 0.2 mm long x 1.5875mm (1/16th") diameter tool. (The short length is to keep it close to the value of the tool attach point.)

I then built a hotwire calibration box that I mounted to the rotary table with 4 corners that are very nearly perfectly plumb to the surface of the table. I programmed toolpaths that terminate at the 4 corners of this calibration box to observe the discrepancy between the current calibration of the hotwire and the actual position relative to each corner. I then determined a method for making adjustments to each value of the tool's TCP manually in the calibration program on the KCP. When I modified the TCP such that the hotwire is nearly perfectly aligned with the corners of the box, I then used this newly adjusted TCP to create another new PM calibration using the previous method with the calibration spindle override. Because the tool was so short, I reasoned that it's position and orientation can be taken to be the new tool attach point. 

When I output the same programs using this new calibration, I can observe that the wire is very closely aligned with the corners of the calibration box. Further, when I program wholly new parts, their dimensions within 1/16" error to my programmed model.

The only problem, is that I must output these TCPs using the 6th axis workplane calculator instead of simply relying on the spindle calibration as when not using the spindle information override.

I hope I wrote all of this without causing too much confusion. Regardless this process does work to my satisfaction.

However, at this point I can certainly recognize having gone through all of this that it may be easier to just redesign my hotwire bow to accept spikes at either end and just use the normal calibration process.

[Anonymous]

Just making a note here that this backend calculation problem has never been fixed. The override Spindle calibration still adds the tool length to the X value instead of subtracting it.