I have problems with the active tool TCP when mounting/dismounting a tool during the simulation.
So in the beginning of the robot program I want to mount a tool and I’m able to mount the tool succesfully. However, after that I should run a simple pick&place application but this isn’t workoing out as it should because after the mounting I lost the active TCP. This happening during the simulation.
So when I’m programming the robot program I’ll first create a subprogram to mount the tool. For this the active tool is null. After the mount I’ll define the active tool TCP, e.g. tool1, and create programs for the pick&place. I use the active tool TCP, e.g. tool1, which I defined in the prevoius phase. So everything works but when I launch the simulation I can mount the tool but then the defined active TCP, e.g. tool1, is lost (changed back to null) and poick&place operation isn’t working.
How to fix this? So how to keep the selected TCP active after mounting/dismounting the tool?
Are you using tool frames which are imported from the tool component?
One limitation in VC tool changing is that if you use imported tool frame from the tool component then when you dismount the tool the controller loses the reference to that tool frame. All robot motions using that tool frame get reset to NULL tool. Workaround for this is to use only controller’s inbuilt tool frame. Modify their position (and maybe parent node) to match the frame on the tool component and then only use those inbuilt tool frames on motions.
Why is direct recognition of Tool Frame Name not supported?
After changing the Tool, the Tool Frame with the same name will be matched in the program.
Older versions had this feature, for example VC4.1Pro, but instead it is not available after the update.
If the Tool Frame is attached to a joint link in the tool, the program will have to adjust the Null tool after each change to the tool.This will be waste time!
I’m pretty sure that motion statements have had base and tool frames as object references and not as string properties since the beginning of VC product and this problem has been there always. Are you maybe referring to some component library like Works which had their own robot controllers? Anyway the robot controller is quite old design and most of the problems in it are known to us. There’s work being done to overhaul the design of motion controllers and hopefully in time these problems get addressed.
Please check the attachement.
As the layout shown,two similar End Efftector both have a Tool Frame which is attached to their link.
There are two resault when mounting/dismounting a tool in VC 4.1 Pro and VC 4.6 Pro.
In VC 4.1 Pro, program will automatically identify the same tool frame name “Tool”.
mount the component Tool
dismount the component Tool,and mount the component Tool #2
In VC 4.6 Pro, tool frame get reset to NULL tool and must be selected again. It’s Inconvenient.
mount the component Tool
dismount the component Tool,and mount the component Tool #2
I installed older 4.1.0 build and tested again and on that the tool frame is found when you mount the new tool. So you were right and I was wrong. It seems this worked at early 4.X versions and something got changed to cause this regression. I don’t know what it may have been.
Yes,it works right on 4.1.0 as i say.
Actually,I think this is a good feature for optimizing the end effectors which have a bit difference with each other.Especially,being used for Grasping/Releasing function, the Tool Frame is attached to a joint link in the end effector.
At some point when the work on new motions controllers proceeds enough I think this feature should get into the product. But for the time being there’s no work done to the old controllers so next few releases will not have this feature.
I have the exact same problem with VC 4.8 Prem. I understand that this might come as an update in future versions, but for the time being is there a trick I can use to avoid making multiple simulations or having multiple robots.
I would appreciate if someone could help so I can avoid deviating from the real world all too much.
I solved it by just locating one of the 15 tool frames to each robot tool and in the program I then selected the right command for mounting/dismounting in regards to the tool frame I selected for the tool
It seems to be a bug where SetTool gets reset if you connect a tool component that imports tool frames to the robot controller. It happens both with Plug-n-Play tool and at runtime with signal actions. I reported this as bug item 34253 to devs.
I’d say the common workflow with tool changers would be to configure all the tool frames as static objects with different indices (parent node being the robot mountplate). So all tool frames exist in the controller at all times and then you just mount the correct tool component whenever you need it. This is close to how you would do things with real controller. This way you wouldn’t need to use SetTool statement at all.
If for some reason that approach is not suitable for your use case and you must use SetTool then as a workaround I suggest to deleted all the “ToolExport” fields on the tools components’ interfaces. It seems that when tool frames are not exported then the SetTools are not reset either. This does require access to modeling tab so I hope you have Professional or Premium available.
I honestly missed the conversation, because I thought I solved the issue with my specific problem. But indeed I ran into the same problem with the automatically resetting tool frames.
