Probe Basic - jog slider & status

Lcvette - Bit of an update.

I posted a feature request in LCNC, but cmorley explained (if I understand it) that unlike FRO/SRO/RRO, LCNC doesn't store any jog speed values.  Any value is actually 'stored' (of that's the reight term) in halui or some other GUI and sent to LCNC with each jog command.

And it looks like he did something similar to what I'm proposing in qtvcp a couple years ago:

github.com/LinuxCNC/linuxcnc/commit/da89...38fde4003786d6e475bd

Mind taking a look at his commit and seeing if it's maybe an option for qtpyvcp?

Thx,
R

I briefly looked it over but I don't see anything like you were describing. Those halpins he's defining appear to be the existing lcnc exported python connections. I can store the slider value because it's a vcp settings slider. Storing it is more of a command store, not a synchronous setting. Think of it as a offset being stored, requires a reload to access it, like the Tool table, offset table etc. The issue is getting the signal in from your physical analog dial to the ui and synchronizing the slider. There may be a way to do it, but I'm not sure how. You have two outputs competing. And trying to make them sender and receiver but there's no channel existing to make it a receiver. If that makes sense. Getting a static value such as used in macros etc is fairly easy, but without a lcnc channel that supplies and updates that data, I'm out of ideas on how to accomplish it.

You'll have to dig a bit deeper and see if you can find a solution. Or maybe someone reading this has some ideas. I'm happy to try things, just not sure what to try..lol

Been thinking about this a bit more but haven't had a chance to test (mill is electrically torn up during 4th axis install).

Forgive me if I'm using incorrect terms, and please correct me where I've made assumptions that don't work.

Objective is to display the current jog-speed, which is a percentage of INI [AXIS/JOINT] MIN/MAX_LIMIT

Problem is that jog-speed is not stored by LCNC internally.  It is always sent from an external source - the GUI, whether that's halui or some other UI like qtpyvcp.

As it doesn't exist, there is no python integration for jog-speed - thus the value cannot be passed to qtpyvcp (Probe Basic) for display.

However, what's important isn't the jog-speed value.  It's the value itself - regardless of what it does.  Which got me thinking: can a value be sent (float in this case) to qtpyvcp via a hal pin even though it isn't "jog-speed"?

There's a qtpyvcp HAL widget called HAL LCD Number which appears to create two input pins (s32 and a float).  Specifically qtpyvcp.lcd.in-f appears to be created.

Once created, can this new pin - tied to a display box/window - accept values from any HAL signal?

If so, the HAL signal from my jog-speed scale.N.out pin could supply the value and the LCD display widget could simply be labeled "external jog-speed" or similar.

The value gets sent to qtpyvcp as simply a number to display, and also to halui as the jog-speed value.  A bit wonky as the qtpyvcp 'internal' jog-speed slider wouldn't reflect the external jog-speed value... but that's what I've got right now anyway.  I can set the GUI slider to 0% and the external MPG jog-speed value to halui still functions.

Or am I missing some key part of the puzzle?

Yeah give it a try, I was looking at some of the other hal widgets, but I've not been in a position to test anything, but try it out and see if it does what you're looking for, and please report back, may be that's the beginnings of a better solution if it works out!

WIll do.  Waiting on some servo cable connectors for my 4th, but when those are in and I can power it up again I'll have a go at it.

-R

Success!

In QtDesigner I found HalLabel and HalBarIndicator widgets.  Pretty easy to set up, and they both create HAL pins.  Important part is that they are float-in pins.  Took longer to fiddle with the layout and style stuff to get them looking decent than it was to connect in HAL.

I've not experimented with multiple copies so I don't know how the hal pin naming works when you add more than one of each type.

Restarted PB and opened HALshow... and the new pins showed up as I'd hoped.  Basically the same process as adding an LED indicator on the screen.

Connected up in my postgui hal file:

And everything worked.  Twiddling the MPG wheel results in the bar indicator displaying the jog-speed.  The value is also sent to halui - which seems to have a higher priority than the qtpyvcp jog-speed value. The GUI slider only controls the GUI jog buttons.

Also had a go at displaying the MPG-controlled jog increments.  I can read them from my MPG selector, but it's nice to have an on-screen confirmation.

 

Next step is getting rid of the on-screen jog buttons and replacing them with indicators or other status labels.  Ultimate intention is to remove anything from the main screen that can cause machine movement (other than the probing tab).

Thanks for the encouragement.

Great work! I sure it will help many folks out with similar setup!

Just glanced at your screen grab, noticed it isn't synching with the on screen sliders? I thought this was what you were after? I'm confused. It appears from your last statement that your just wanting full external control? And just wanting readouts to show physical states?

Lcvette wrote:

Great work! I sure it will help many folks out with similar setup!

Just glanced at your screen grab, noticed it isn't synching with the on screen sliders? I thought this was what you were after? I'm confused. It appears from your last statement that your just wanting full external control? And just wanting readouts to show physical states?

You're correct - I had the GUI sliders set different than the external-pin slider specifically to show the fact that LCNC can deal with jog-speed values from two unconnected sources.

I don't know if there's any way to link the external value to the GUI slider value.  Perhaps that can be done with widget rules, but I haven't played with that yet.  Would be nice to do this because the external jog-speed pin isn't linked to angular-jog-speed and my 4th axis is really slow during external-button jogging.

If you've got an idea how to connect the value going in to the HalBarIndicator to the existing jog-speed sliders, I'm all ears.

And yes, my ultimate desire is to have 'full external control' - more or less.  I realize this seems silly as PB is based around touchscreens - what's the point of undoing all the hard work you all put in to having a comprehensive touch-friendly GUI?  As I've written elsewhere, I don't like touchscreens for critical/safety controls as there's no tactile feedback.  I don't trust them (or mice or keyboards) not to trigger something unexpectedly - especially non-resistive screens.

If KCJ had continued work on the Hazzy screen (i.e. compatible with python3) I'd probably be exploring that GUI as well.  I think his philosophy was to remove all on-screen jogging...

I prefer touchscreens for data entry and menu selection/navigation, but not for direct machine control.  Frankly, I don't even like how LCNC inputs are configured in general... typing something in MDI and pressing the 'enter' key results in immediate execution of the MDI command.  I prefer - like on some commercial controls - to type something, hit 'enter' or 'insert' and the command goes in to a holding area of sorts but doesn't get executed until cycle start is pressed.  On three of the commercial machines I own (or use), the only way to get movement is cycle start (other than jogging or axis homing).

Just a personal preference.

that was the conundrum i was facing before that i could not find a good solution to. will dabble with it next time I have some dev time for ui work.

Lcvette -

I think you can abandon the jog-slider branch if you want to clean up orphan github branches.  As we found out I can't (probably) connect the halui value to the jog-sliders you cooked up.  I'm using a halbar indicator and statuslabel to display the values - but there's no connection between the halui stuff and probe basic widgets.