Dead in the water on 7i92 config

I was using the jog wheel on the XHC to try to move it. I've found this super-valuable because it's easy to set the zero and X/Y work coords while walking around a big router, far from the PC. Has an LCD coordinate readout, too.

In Joint mode, I could set the XHC's dial to X, Y, or Z and turn the handwheel and X, Y, or Z moved. It was a very slow move and the "Step ++" button to change the step speed did nothing.

Honestly I'm not clear on what "Incremental" jog is. A jog wheel, however, is going to mean moving the commanded position +0.1", +0.2", +0.3", +0.4", +0.5"... incrementally. As opposed to "G91 G0 X0.5" = move X +0.5 from wherever it is now. Or "right arrow", being "keep moving as long as this arrow is held, then decelerate when released" which is not a specific destination.

I did see that G91- which I know as "relative mode", is referred to as "incremental mode". But all 3 examples above are all relative to the current position.

Is "incremental jogging" the fact that you've got incremental step, step, step off the jog wheel? But even if it didn't handle it as I'd like, it'd be basically implemented as a string of "G91 G0 X0.1" commands, which is awkward because that would seem to require fullstop after each one.

dannym wrote:

Honestly I'm not clear on what "Incremental" jog is. A jog wheel, however, is going to mean moving the commanded position +0.1", +0.2", +0.3", +0.4", +0.5"... incrementally. As opposed to "G91 G0 X0.5" = move X +0.5 from wherever it is now. Or "right arrow", being "keep moving as long as this arrow is held, then decelerate when released" which is not a specific destination.

I did see that G91- which I know as "relative mode", is referred to as "incremental mode". But all 3 examples above are all relative to the current position.

Is "incremental jogging" the fact that you've got incremental step, step, step off the jog wheel? But even if it didn't handle it as I'd like, it'd be basically implemented as a string of "G91 G0 X0.1" commands, which is awkward because that would seem to require fullstop after each one.

A jog wheel move is essentially a series of incremental jogs, hence why it doesn't work. Listen to Andy, he is one of the smarter, most helpful people on the forum.

So I'd like to do trivkins, but I'm unclear on this. With gantrykins, I just did "loadrt gantrykins" and made the axis associations in the HAL file.

I need Joint 0 and Joint 3 tied together as the X axis, with the ability to home each side to resolve racking.

"loadrt trivkins" works. It appears I need to find the source code for trivkins somewhere, alter it, and recompile somehow?

linuxcnc.org/docs/2.5/html/man/man9/kins.9.html

I don't quite follow, I don't see anything about a "gantry" component. Where would a sample config be?

It has nothing to do with kinimatics, (other than being used with trivkins). It is a hal component, Andy posted a link to the man page a few posts up.
linuxcnc.org/docs/2.7/html/man/man9/gantry.9.html
It was just added in version 2.7.4 and I don't think there is any mention of it in the regular documentation. But I think there may be an example config somewhere.
That said the man page makes it look like setting it up shouldn't be too hard even without an example.

This is rough for me too here... but I still don't get it. I just need to link Joint 0 and Joint 3 under the X axis. The homing needs to be worked out, but later. The "personality" part is baffling.

The example I found is wiki.linuxcnc.org/cgi-bin/wiki.pl?GantryPlasmaMachine

It uses 2x steppers on Y, and trivkins, but there's no gantry.anything going on here. What I did see was:

#Y2 signal setup:
#Mod to slave Y(1) and Y2:
net Y2.pos-fb hm2_7i43.0.encoder.03.position => pid.3.feedback
net Y2.pos-out pid.3.output => hm2_7i43.0.stepgen.03.velocity-cmd

# Add an offset to the position command to remove racking.
# No offset when homing, but apply after homing to adjust the homed error
net Y.pos-cmd axis.1.motor-pos-cmd => sum2.6.in0
setp sum2.6.gain0 1
setp sum2.6.gain1 1
setp sum2.6.offset 0
net home-status mux2.8.sel
setp mux2.8.in0 [AXIS_3]ANTI_RACK_POSITION_OFFSET
setp mux2.8.in1 0
net Y2Offset mux2.8.out sum2.6.in1
net Y2.pos-cmd sum2.6.out pid.3.command

And I don't know if that's some off-label hack or the way it's done or what. The pos-fb and pos-out are just the pid.3 and stepgen.03, not tied to the Y1's pid/stepgen 01 instance. So the "net Y.pos-cmd axis.1.motor-pos-cmd => sum2.6.in0" seems to be where the magic happens.

But the way that summing and anti-racking works is still unclear to me. It's got me concerned about just copying in something where I don't understand most of the code and I don't need the anti-racking homing just yet- but will eventually.

Current .hal file enclosed, just because.

Well I made a best-effort (attached) to integrate what was done in comet.hal into this 7i92 config. Still kinda guessing, the [PRUCONF](DRIVER) part I changed to the hm2_[HOSTMOT2](BOARD) I'm using.

What I get is that the pin hm2_[HOSTMOT2](BOARD).stepgen.00.position-cmd isn't found. I've looked through all that and yeah stepgen uses position-fb and velocity-cmd. Not sure where to go from here. Pretty suspicious I've screwed up more things than that.