Setting up independent axis

I am attempting to setup 2 axis as independent axis using the limit3 component. I am hoping that someone out there has done this before and can point me in the right direction in terms of linking up limit3 within hal. I have added two instances of the limit3 component to the servo thread and am in the process of linking the maxV maxA and position limits.

Can you please elaborate on what exactly are you trying to get.
Same axis with motors on both sides? That is already implemented in 2.8pre and easy to set up.
All the axis in linuxcnc are independent as such to a certain extent.

I have 5 axis under machine control. I have a transfer system that can and will operate two additional axis indepedent of the main machine. I am trying to implement such that a separate uspace process can drive the indpendent axis.

here is my current hal file that I am attempting to use for testing. I am using a setp command and sending in a position. Currently I get a joint following error which I am guessing is related to how the feedback is configured. Just not sure how to get it to work using the limit3 component.

#*******************
# AXIS U
#*******************

setp pid.u.Pgain [AXIS_6]P
setp pid.u.Igain [AXIS_6]I
setp pid.u.Dgain [AXIS_6]D
setp pid.u.bias [AXIS_6]BIAS
setp pid.u.FF0 [AXIS_6]FF0
setp pid.u.FF1 [AXIS_6]FF1
setp pid.u.FF2 [AXIS_6]FF2
setp pid.u.deadband [AXIS_6]DEADBAND
setp pid.u.maxoutput [AXIS_6]MAX_OUTPUT
setp pid.u.error-previous-target true
setp pid.u.maxerror .5

net u-index-enable <=> pid.u.index-enable
net u-enable => pid.u.enable
net u-output => pid.u.output
net u-pos-cmd => pid.u.command
net u-vel-cmd => pid.u.command-deriv
net u-pos-fb => pid.u.feedback

# Step Gen signals/setup

setp hm2_7i76e.0.stepgen.05.dirsetup [AXIS_6]DIRSETUP
setp hm2_7i76e.0.stepgen.05.dirhold [AXIS_6]DIRHOLD
setp hm2_7i76e.0.stepgen.05.steplen [AXIS_6]STEPLEN
setp hm2_7i76e.0.stepgen.05.stepspace [AXIS_6]STEPSPACE
setp hm2_7i76e.0.stepgen.05.position-scale [AXIS_6]STEP_SCALE
setp hm2_7i76e.0.stepgen.05.step_type 0
setp hm2_7i76e.0.stepgen.05.control-type 1
setp hm2_7i76e.0.stepgen.05.maxaccel [AXIS_6]STEPGEN_MAXACCEL
setp hm2_7i76e.0.stepgen.05.maxvel [AXIS_6]STEPGEN_MAXVEL
setp hm2_7i76e.0.encoder.04.scale [AXIS_6]ENCODER_SCALE

# ---- limit3 position, velocity, accel limits

---

setp txfr.y.min 0.00
setp txfr.y.max 20.00
setp txfr.y.maxv 13.33
setp txfr.y.maxa 20.00


# ---closedloop stepper signals---

net u-pos-cmd <= txfr.y.out
net u-vel-cmd <= axis.6.joint-vel-cmd
net u-output <= hm2_7i76e.0.stepgen.05.velocity-cmd
net u-pos-fb <= hm2_7i76e.0.encoder.04.position
#net u-pos-fb <= hm2_7i76e.0.stepgen.05.position-fb
net u-pos-fb => axis.6.motor-pos-fb
net u-enable <= axis.6.amp-enable-out
net u-enable => hm2_7i76e.0.stepgen.05.enable

# ---setup home / limit switch signals---


net u-home-sw => axis.6.home-sw-in => hm2_7i76e.0.7i84.0.2.input-03
net u-neg-limit => axis.6.neg-lim-sw-in => hm2_7i76e.0.7i84.0.2.input-01
net u-pos-limit => axis.6.pos-lim-sw-in => hm2_7i76e.0.7i84.0.2.input-02
net u-index-enable => axis.6.index-enable => hm2_7i76e.0.encoder.04.index-enable


Thanks for the reply.

If they are independently controlled and don't need to be axis letters, you can just have your uspace process directly to the stepgen a component, and not bother with setting it up as a joint or axis.

You can make this _much_ simpler.
The Mesa Stepgen will conform to the programmed accel and velocity limits. You can skip the PID in this case, and you probably don't need the limit3 either.

Just send a value to the stepgen.05.pos-cmd pin and the stepper will go there.

You might need to re-invent homing for these motors.

You might like to consider the possibility of deriving the position commands from G-code "analog" outputs. A G-code subroutine can run a sequence and send the position (or velocity) data straight to HAL. This is an example using M64, M66, M68 etc.

Couple of quick questions.

1) What is the best way to set the parameter to the stepgen from a userspace python process? The only way I know of is to use a shell script that would execute halcmd.
2) How do I determine when the move is complete without having access to motion.in-position?

Thanks for the response.

I am not a good programmer and can't explain it well, but for #1 you can create halpins from python and twiddle their values directly from your program. I've done this a little, hacking away and copying examples from GladeVCP examples, and do it yourself Gui tutorials.
linuxcnc.org/docs/html/gui/gladevcp.html...evcp:adding-hal-pins

For #2, I think I would use a near component to compare the value you command to the stepgen, with the feedback position of the stepgen. When they are the same (or mostly the same) it has arrived. and the near output bit would go true

wn007 wrote: 1) What is the best way to set the parameter to the stepgen from a userspace python process? The only way I know of is to use a shell script that would execute halcmd.

create HAL pins in the component and set the positions form there.

2) How do I determine when the move is complete without having access to motion.in-position?.

Use another HAL pin to receive the stepgen.N.position-fb and compare the values inside the HAL component.

linuxcnc.org/docs/2.7/html/hal/halmodule.html

Is there a way to control the speed (feed rate) when using stepgen directly? I think I can handle the homing without much trouble just need to control the homing speed. Thanks for the responses.

wn007 wrote: Is there a way to control the speed (feed rate) when using stepgen directly?

Yes, the stepgen will run at the value of the maxvel pin.

linuxcnc.org/docs/2.7/html/man/man9/stepgen.9.html indicates that in the case of the software stepgen this is a parameter rather than a pin so it can't be driven directly via (for example) a G-code analogoue output, it would need to be set by a user M-code using halcmd.

For the Mesa stepgen it is a bidirectional HAL pin: linuxcnc.org/docs/2.7/html/man/man9/hostmot2.9.html#stepgen
This is also not 100% convenient. Because it is bidirectional it would need to be connected via a tristate-float HAL component but could then be driven relatively easily with M68