Probe Basic - jog slider & status
29 Jan 2023 00:44 #263140
by spumco
Replied by spumco on topic 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 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
Please Log in or Create an account to join the conversation.
29 Jan 2023 05:45 #263152
by Lcvette
Replied by Lcvette on topic Probe Basic - jog slider & status
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
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
The following user(s) said Thank You: spumco
Please Log in or Create an account to join the conversation.
31 Jan 2023 17:37 #263376
by spumco
Replied by spumco on topic Probe Basic - jog slider & status
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?
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?
The following user(s) said Thank You: Lcvette
Please Log in or Create an account to join the conversation.
02 Feb 2023 02:31 #263486
by Lcvette
Replied by Lcvette on topic Probe Basic - jog slider & status
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!
Please Log in or Create an account to join the conversation.
02 Feb 2023 02:58 #263488
by spumco
Replied by spumco on topic Probe Basic - jog slider & status
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
-R
Please Log in or Create an account to join the conversation.
02 Feb 2023 19:31 #263543
by spumco
Replied by spumco on topic Probe Basic - jog slider & status
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.
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:
#TEST
net selected-jog-incr => qtpyvcp.hallabel.in
net JOG-SPEED-OUT => qtpyvcp.halbarindicator.in-f
setp qtpyvcp.halbarindicator.max-val 100
setp qtpyvcp.halbarindicator.min-val 0
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.
Attachments:
The following user(s) said Thank You: Unlogic
Please Log in or Create an account to join the conversation.
05 Feb 2023 16:21 #263755
by Lcvette
Replied by Lcvette on topic Probe Basic - jog slider & status
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?
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?
Please Log in or Create an account to join the conversation.
06 Feb 2023 14:18 #263834
by spumco
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.
Replied by spumco on topic Probe Basic - jog slider & status
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.
Please Log in or Create an account to join the conversation.
11 Feb 2023 14:40 #264289
by Lcvette
Replied by Lcvette on topic Probe Basic - jog slider & status
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.
The following user(s) said Thank You: spumco
Please Log in or Create an account to join the conversation.
16 Feb 2023 04:58 #264596
by spumco
Replied by spumco on topic Probe Basic - jog slider & status
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.
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.
Please Log in or Create an account to join the conversation.
Time to create page: 0.134 seconds