[Albert]

Did you mean to attach your SRC program file for the KUKA controller?

I believe the $ sign is needed for the tool change to take effect in the KUKA controller. This is why RoboDK ignores any tool change or frame change if you don't provide the $ sign.

[Karl]

Yes I attached it for reference. The $ sign is needed in the Kuka controller, correct, but I need to remove it to be able to filter in RoboDK. Then I have to open the filtered program, and type the $ signs back in.

The point I was trying to make was that with or without $ signs, RoboDK doesn't allow a tool change during filtering. Whatever tool is first, is used throughout the entire program. The result is that any programs I want to run that use multiple tools need to be filtered in batches, grouped by tool.

It would be much better if RoboDK could update the active tool if TOOL=[] changes at any point in the program. I have a working tool change on the Kuka controller that is called by SetTool(n) but the calibration profile in RoboDK doesn't update.

[Albert]

RoboDK uses the active tool for filtering if the tool data is not recognized when filtering a KUKA SRC program file.

Therefore, one option is to first setup your tool in RoboDK and then filter your program.

[Karl]

Right, and I have 5 or 6 tools set up in RoboDK. They're set in order, Tool1 is the same across my cam software and robodk, and is also TOOL_DATA[1] in the robot. The only disconnect is that if my code calls for Tool1 for the first half of the code, then switches to Tool2, RoboDK will just stick with Tool1.

That's what my first screenshot from post#10 is about, see the red rectangled areas here; in summary it's saying "can't import tool2, just using tool 1 instead" so inherently the calibration filter will not be correct

---

removing the $ sign is the only way to get robodk to import the tool frame, but it won't switch to a different tool partway through.