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

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

Deleted as second post now superfluous to requirements

Wireline wrote: ... 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.)

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

Wireline wrote: 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.