Is it necessary to recompile genserkins.h when you change DH parameters?

More
09 May 2018 18:57 - 09 May 2018 19:15 #110443 by Wireline
Hi

I can't remember where I saw it suggested, but I have been recompiling genserkins each time I need to update the DH parameters. I did this by editing the defaults in genserkins.h (as well as ofc changing them in the HAL file).

Is it possible to pass new DH params via some other source, say the HAL file or a command line parameter, without having to recompile each time? I am trying to troubleshoot some aspects of the tool coordinate frame and came across this old post ...

forum.linuxcnc.org/10-advanced-configura...f-robot?limitstart=0

... and now I am wondering if there is an easier way to pass the tool frame in as a 7th joint, as suggested in the post?

Cheers

Wire
Last edit: 09 May 2018 19:15 by Wireline. Reason: info

Please Log in or Create an account to join the conversation.

More
09 May 2018 20:33 - 09 May 2018 22:04 #110449 by Wireline
Deleted as second post now superfluous to requirements
Last edit: 09 May 2018 22:04 by Wireline.

Please Log in or Create an account to join the conversation.

More
10 May 2018 00:01 #110474 by andypugh

... and now I am wondering if there is an easier way to pass the tool frame in as a 7th joint, as suggested in the post?


I think that you can use "setp" in the HAL file.

You might even be able to use "halcmd setp" from the command-line and change things on a live system.

(You can save typing by starting with halcmd -kf to link to the running HAL, and then you don't need to use "halcmd" any more in that terminal session until you quit halrun. This also gives you tab-completion of pin names.)

Please Log in or Create an account to join the conversation.

More
10 May 2018 14:19 - 10 May 2018 14:21 #110515 by Wireline
Thanks Andy I will give that a go. I went with custom recompiled genserkins in the end, but having that as another option when passing in different tooling configs might be useful, if I can't get the method in the post quoted above to work.

I have the 7th joint in and running, but the next challenge will be getting the motion.tooloffset.z parameter passed in as well, to take account of tooling offsets. At the moment when I input a tool offset in the tool table, the robot carries out its gocde as before, but the tool trace is at the offset point. For example if the gcode z value is 400mm, with no tool offset the robot will draw at 400mm z. But with an offset of say 40mm, the trace is drawn at 440m z. Hopefully this is what "the 7th joint method" will resolve.

Is there a huge difference between what you can simulate in vismach / run in place build and the real robot, i.e. is the pin data simply sent from linuxcnc to the controller? I am learning as I go with this one and IRL is the next big challenge. We have a new controller built from custom components after the original staubli one packed up. I have a lot to learn about that one too ...

Cheers
Last edit: 10 May 2018 14:21 by Wireline.

Please Log in or Create an account to join the conversation.

More
11 May 2018 00:13 #110555 by andypugh

I have the 7th joint in and running, but the next challenge will be getting the motion.tooloffset.z parameter passed in as well, to take account of tooling offsets. At the moment when I input a tool offset in the tool table, the robot carries out its gocde as before, but the tool trace is at the offset point. For example if the gcode z value is 400mm, with no tool offset the robot will draw at 400mm z. But with an offset of say 40mm, the trace is drawn at 440m z. Hopefully this is what "the 7th joint method" will resolve.

I have a feeling that that is a limitation of the Axis / Gremlin preview. I think it just applies an offset in cartesian space.

Is there a huge difference between what you can simulate in vismach / run in place build and the real robot, i.e. is the pin data simply sent from linuxcnc to the controller? I am learning as I go with this one and IRL is the next big challenge. We have a new controller built from custom components after the original staubli one packed up.

If the Vismach model is set up right then it should exactly represent the real robot. Things like accurately logging the tool point are something that I haven't really figured out how to do in Vismach (but some of the sims do it well).
I am peripherally involved in a Staubli conversion using STMBL servo drives. I think that is working quite well.

Please Log in or Create an account to join the conversation.

Time to create page: 0.088 seconds
Powered by Kunena Forum