[Karl]

I calibrated our cell but have a huge error. With the "follow tracker" option unchecked, the laser was exactly where it needed to be on 65 out of 70 points. Am I missing something obvious, or is there a huge outlier that's throwing me off?

We have a rotary axis but I deleted it from the station so I could do the arm calibration.

See files attached, thanks!
-Karl

---

才意识到我可以点击看看埃罗rs. I remeasured point 26 (error was 64mm), now the error is 0.372mm. Updated report attached.

Now to add the rotary axis, do I just model mechanism to add it to the cell, then define the mechanism, and I'm good to go? Or do I need some kind of handshake with the calibrated arm?

-Karl

[Albert]

Great, thank you for your status update.

你可以转台作为一个简单的1轴mec模型hanism, however, you should properly calibrate the axis by properly placing the coordinate system the mechanism is attached to. You should follow these steps:

1. Right click the coordinate system where you'll place the turntable
   
2. SelectDefine Reference Frame
   
3. Select method:Turntable Calibration (1 axis)
   
4. Make sure to use a calibrated tool (pay attention to theUsing TCPnote)
   
5. Collect some points by moving the turntable and teaching the same point on the turntable as you move it. The first point should be right on axis X+ and moving the turtnable towards the positive sense. A minimum of 3 points is required (6-10 recommended). More points is better as it will give you a better understanding of errors.
   

It is assumed that the turntable turns around the calibrated Z axis.

[Karl]

Thanks for the response Albert, we got the mechanism set up the next day using the laser. For some reason it rotated 176deg around Z, I don't know how to make it align X to world X other than changing that to zero and making the (other two of RPW) to negatives.

Two other problems I have:

1) we're using the Base=EK{} method, but the robot is rotating its TCP around the rotary axis with the rotary frame, rather than staying stationary and letting the rotary frame rotate (like a lathe). Same behavior as this thread:External axis hijacks references (www.sinclairbody.com)but I'm not importing an APT file, which is where the Auto Comp setting shows up..

2) I can't get the station to use the correct tool! Changing the inputted code to have TOOL=TOOL_DATA[2] just uses tool 1 anyway. I tried the TOOL 2 method (setting the post line to "True") with the same behavior.

[Karl]

I got the rotation corrected, the $AXIS_DIR was 1 rather than -1 in the machine.dat file on the robot. Still having the weird problem with the Tool data though.

[Sergei]

Maybe adding an "Set Tool Frame" instruction will solve your problem.

1. Add instruction



2. Link the tool

[Karl]

Isn't that what the SetTool(n) is supposed to do? From post #8 here://www.sinclairbody.com/forum/Thread-Machinin...03#pid7003

[Albert]

Automatically linking to your Tool 2 requires a line like this one:

Code:

$TOOL=TOOL_DATA[2]

Note the dollar sign was missing on the SRC file you provided. With the correct syntax you should see a summary stating what tool is being used.

On the other hand, I noticed RoboDK won't link to your numbered tools or frames for KUKA SRC files. We'll improve RoboDK to support importing numbered tools and frames that exist on the station. For the time being it requires the workaround provided by Sergei by manually adding the Tool change instruction.

The instruction call SetTool allows integrating a tool change routine. Not all controllers quire working with Tool IDs but but most robot machining programs require using IDs. This can also be customized in the post processor.

[Karl]

Automatically linking to your Tool 2 requires a line like this one:

Code:

$TOOL=TOOL_DATA[2]

Note the dollar sign was missing on the SRC file you provided. With the correct syntax you should see a summary stating what tool is being used.

I'm forced to do it without the dollar sign, otherwise it won't link the tool. see screenshot:


I tried changing the post option TOOL_INDEX = False / True options but that doesn't have an effect; it just uses the default tool.


Right now I'm saving the programs as SRC files from sprutcam, then I open them in notepad++, delete the $, "filter only" in RoboDK, then open them again and add the $'s back. Sergei's method sounds fine but it's more work than what I'm doing, ideally I would skip any extra editing altogether.

[Albert]

The TOOL and BASE that is used when you load the program is exactly the same in both scenarios (with the dollar sign and without). The warning message you see is because RoboDK does not know the definition of the TOOL and BASE with the index. Therefore, the currently active tool and reference frames are used.

[Karl]

The TOOL and BASE that is used when you load the program is exactly the same in both scenarios

That wasn't a great example then, here's a program with a few tool changes, using the $ signs:


and here's the same filtering result when I remove the $ signs:



It doesn't say it's using the correct tool so maybe the filtering isn't correct for tool2?

Another possible solution would be to edit the post so it automatically replaces "TOOL=" with "$TOOL=". I couldn't figure out how to make that change in roboDK, but I can make sprutcam's post export without the $.