Passing a value to a subroutine from a Spinbox

I have a plasma file that I might cut 1 part or 24 parts it just depends on the size of the material as I often use drops to cut the parts from. In the past I had a variable at the top of the file for the repeat section below. While this works fine, my fear is that I'll open the file and forget to set the number and it will try and cut more parts than I have material for.

With some suggestions from the IRC I came up with a way to pass the value of the pyvcp spinbox to my G code program. What I did was connect the output of the spinbox to analog in 00 then in my G code file I ran M66 E0 L0 which puts the value from the analog in pin into the #5399 variable. Then I use the #5399 variable in my o100 REPEAT [#5399] to set the number of repetitions of the code. The beauty of this is when I start LinuxCNC the spinbox is 0 so I can't hardly screw up.

JT

Neat idea John,

Rick G

If you can connect the spinbox to a HAL signal, you can also use #<_hal[hal_name]>
Maybe even directly the gladevcp.xxx name?

linuxcnc.org/docs/html/remap/structure.h..._referto_hal_items_a

When I tried that with a debug I got "######" instead of the float value of the signal.

JT

Did you also add:

[RS274NGC]
FEATURES =12

to your ini file?

( linuxcnc.org/docs/html/remap/structure.h...d_sub_ini_features_a )

Hmmm, no I assume.

JT

FEATURES = 8 seemed to do the trick...

JT

FEATURES=12 (8+4) also allows you to read INI file values.
I didn't find a use for that yet, but it might come in handy someday.

BigJohnT wrote: FEATURES = 8 seemed to do the trick.

This works nicely at the start of a file. But the values only update when a program is not running, so if you need "live" data the G-code analogue inputs are the way to go.

This was an mah addition, and he has decided it was a mistake. Personally I use it too much to agree, it just needs the limitations to be documented.

andypugh wrote: This was an mah addition, and he has decided it was a mistake. Personally I use it too much to agree, it just needs the limitations to be documented.

Why is this considered a mistake? It is a blessing to be able to interact with HAL in a much cleaner way than M-codes-calling-bash-scripts-that-in-turn-use-halcmd-to-interact-with-hal. Too bad you cannot set a signal from NGC except through the use of M6x

(probably I should just learn Python and use that instead of NGC code)