Python Userspace Interface Rapid Speed value?

First and foremost - I'm not sure this is the right category for this topic - please advise or move if required - it's kind of a user interface?

I'm making good progress on the Python Interface manualmatic pendant[1] - but there are a couple of machine values that I can't seem to access. The first relates to jog values - I can sorta understand that because jogging is always UI driven.

But the second is rapid speed. I can get feed speed from linuxcnc.stat().settings[1] (from the Python Interface docs [2]) but settings[2] gives me spindle speed - which I can already get from spindle[0]["speed"].

Is there a rapid speed value? Am I missing something obvious? If not, can I please request it is included in 2.9 (as settings[3] perhaps])? I'd like to be able to contribute to the interface if that would help, but I have not yet found in the github source... (all hints or links welcome!)

Many thanks in advance.

[1] forum.linuxcnc.org/18-computer/44682-a-t...ualmatic-mpg-pendant

[2] www.linuxcnc.org/docs/html/config/python-interface.html
 

It's not totally clear to me exactly what you're doing but it looks like rapid is exposed to
halui.rapid-override.value
as an output pin

i'm playing with the halui.rapid-override pins in hal_show.
it looks like you can manipulate the .value like this
1. set the .scale to the |absolute| amount you want to change the rapid .value
2. set .increase or .decrease to change the rapid .value by the .scale amount

or

1. set .count-enable to true
2. change .counts to change .value by .counts * .scale ?? I'm thinking this intended for encoders?

...I'm new to all this myself.

Hi Kyle - thanks for your reply - I'm trying to take advantage of the userspace Python Interface to create an almost plug and play pendant for Arduino/Teensy - that only requires one file (maybe two) and a single line in the custom.hal but will work for all UIs without any changes or net pin configuration.
I'm more confident it will work now than when I posted the proof of concept earlier (link [1] in the first post) - I have the manual mode sorted and making good progress on the auto mode - even though I'd like the rapid speed to display on the pendant, I'd rather lose it than have end users have to create custom pins (although there is likely a way I could build it into the component).

In the Python Interface the command().rapidrate() sets the scale (1 = 100%) but I need the base speed to calculate the overriden speed, as per feed speed and spindle speed. I don't think I have the option to set count-enable.

I'm new to it too - this was (is) my 2021 Christmas project but I think using the Python Interface has great potential. Hoping there will be more exposed in v2.9.

Fwiw you could put your hal connections in a separate file and the user need only have to put

source my_hal_file.hal

In their hal file.

(Edit) Ah okay now I see, your not making a userspace module?

Jog speed is produced by what ever ui you are using. Linuxcnc has no global setting of jog speed.

Rapid rate is not a setting the operator can set directly - only modify - the 0-100% is pretty standard indicator.
I suppose you could read the INI and figure out the exact speed if you really wanted to.

Hi Chris - Thank you for confirming my understanding of jog setings - it's still a bit of a learning curve!
I guess the same applies to rapid rate as G00 doesn't specify a velocity.
The Python Interface appears to offer me a range of options to dig into:

• max_velocity - from [TRAJ]MAX_VELOCITY
• motion_type - possibly MOTION_TYPE_TRAVERSE - rapid move happening?
• command - look for G00 to detect rapid move happening?
• gcodes - although I'm not sure what "Active G-codes for each modal group." means!
  
  Thank you for pushing me in (hopefully) the right direction.
  

Aha! Logging this for anyone interested.

max_velocity - from [TRAJ]MAX_VELOCITY was a big disappointment - ini files now appear to set MAX_LINEAR_VELOCITY so max_velocity always returns 0.

However, I somehow missed stat().current_vel which in combination with motion_type (value of which changes when running a program) should give me both the actual feed rate ( MOTION_TYPE_FEED) and the actual rapid rate (MOTION_TYPE_TRAVERSE).

We shall see - and I still have to work out what to do with the other motion types (esp arc).
 

Well. That seems to work! I was unsure for a bit (still am) but it matches the gmocapy display...