(SOLVED) Max Velocity Selector Switch

can you post the relevent file please?

Sure, thanks for taking a look at it.

I'll probably want to add the mux16.N.suppress-no-input function and change in1 to 0 and so forth.  The selector has dead-spaces between the contacts and I think it'd be annoying to have the velocity change to 0 between contacts.

But that can wait until the fundamentals get worked out.

Here is the mux16 github that shows the logic for the selects to change inputs. It really needs to be added to the linuxcnc documents for those of us not so smart people.
github.com/robEllenberg/linuxcnc-mirror/...omponents/mux16.comp

Your HAL looks good to me. Thats how I though it would work. Maybe the slider wont change until it sees the counts change and then multiplies it by the scale. You can try setp the scale to like .1 and then use the mux to change the counts value but the mux out will need to be converted to an S32.

Did you try setting this to see if it makes a difference?    halui.max-velocity.count-enable

If you supress that value then you can only use 4 direct mux16 values and get the rest with an or2 statement.

Michael wrote:

Did you try setting this to see if it makes a difference?    halui.max-velocity.count-enable


 



 

No, duh.  That looks like what I need - I'll have a go right now.

EDIT - no joy.  Changing that and all the other pins didn't work.  The scale value changes just fine, but nothing affects the max velocity.

I would see use the mux16 to select count values that get modified by a scale value that was setp maybe. Not sure how the max velocity functions but maybe it only does the change when a new count value is introduced. The mux16 final value would need to be converted to an S32 value which basically means being a whole number.

You might be able to do a quick test of this with your current Hal by manually adding setp counts to 2 or 3 via halshow and see if that changes the on screen slider

setp max-velocity.counts doesn't change the max-velocity.output or the slider.   The only thing that changes the output value is setting the .increase or .decrease pin (and moving the slider as mentioned).  .decrease will immediately set .output to 0, and .increase will raise it to full value.

I tried reversing the scale and counts in hal, but that just threw a start-up error.  I poked around the probe basic screen in QT Designer, and the slider is connected to machine.max-velocity.set... some python function that I suspect is overriding any halui inputs.

I think I'm going to punt.  PCW's (and Rod's) recent guidance on connecting up 5v encoders to my particular mesa boards means I should be able to control my SRO and FRO with encoders without completely rewiring my whole panel... and I can do the same thing with the max-vel function.  I know that Probe Basic plays nicely with encoders and I still have an older hal backup somewhere with those connections I can re-use.

Thanks for the mux help.  If you get your setup working post it up as I'd like to see it.  I just think my particular GUI choice is limiting my options.

-Ralph

Ok I looked in the source - I was right to begin with you must connect mux output to the counts and set the scale to an appropriate setting.

halui only looks at the counts to see if anything has changed and needs update.

The error ehen switching will because .counts is an s32 type pin and you used mux's .out-f (flost type) use .out-s (s32 type)

I forgot mux16 can out s32. That makes it easier. Also makes sense that counts is the trigger.

Thanks gents, finally got it sorted out after working through the scaling

Here's the hal code for a 5-position selector switch:

setp halui.max-velocity.direct-value true
setp halui.max-velocity.scale [see below]
setp mux16.0.in00 [value] #triggered by switch position 1 (unconnected, no input)
setp mux16.0.in01 [value] #triggers mux16.sel0
setp mux16.0.in02 [value] #triggers mux16.sel1
setp mux16.0.in04 [value] #triggers mux16.sel2
setp mux16.0.in08 [value] #triggers mux16.sel3

# position 1 of the selector switch is left unconnected as a 'dead' position.  That will make the first switch position 'off'
net MAXVEL_1            <=  [HMOT](CARD0).7i84.0.1.input-23
net MAXVEL_1            =>  mux16.0.sel0
net MAXVEL_2            <=  [HMOT](CARD0).7i84.0.1.input-22
net MAXVEL_2            =>  mux16.0.sel1
net MAXVEL_3            <=  [HMOT](CARD0).7i84.0.1.input-21
net MAXVEL_3            =>  mux16.0.sel2
net MAXVEL_4            <=  [HMOT](CARD0).7i84.0.1.input-20
net MAXVEL_4            =>  mux16.0.sel3
net MAXVEL_IN           <=  mux16.0.out-s
net MAXVEL_IN           =>  halui.max-velocity.counts

GOTCHA'S:

• The mux16.N.inXX values must be edited if the MAX_VELOCITY value in the INI file is changed.
• The .in00-inXX pins only react to whole numbers.  This means it's hard to get exact desired max velocity numbers, but it's close enough for a global override.
• The max velocity briefly drops to zero during switch changes. This drop to zero speed may cause issues on particular machines.  Mux16.N.suppress-no-input pin eliminates the drop, but you lose the 'dead' position with zero output.  You will only have 4 effective positions (speeds) if you aren't multiplexing. Perhaps 0%, 5%, 25%, and 100% would be acceptable for most people.
• Not sure how this affects QtPyVcp GUI's (Probe Basic specifically), as the PB devs have added a MAX_LINEAR_VELOCITY and MAX_ANGULAR_VELOCITY setting. This scheme may need fine-tuning once I start moving my 4th axis around.

For an INI file MAX_VELOCITY = 1.5 (90ipm, my test speed) I wound up with the following values:

EXAMPLE 1 (mux16.N.suppress-no-input False):
halui.max-velocity.scale = 0.1
.in00 = 0 [0ipm]
.in01 = 1 [6ipm]
.in02 = 2 [12ipm]
.in04 = 7 [42ipm]
.in08 = 15 [90ipm]

EXAMPLE 2 (mux16.N.suppress-no-input True):
halui.max-velocity.scale = 0.1
.in01 = 0 [0ipm]
.in02 = 1 [6ipm]
.in04 = 4 [24ipm]
.in08 = 15 [90ipm]

Here my mpg.hal. I use encoder switches to select rapid feed, override, MPG increments, and axis select. But i must load this hal file over the postguit_call_list.hal. If not, was the position of feed override always 100%. Doesn't matter what show the switch.