gladevcp "named" parameters in gcode
- h_munktell
- Offline
- Junior Member
-
Less
More
- Posts: 31
- Thank you received: 0
11 Dec 2012 05:57 #27542
by h_munktell
gladevcp "named" parameters in gcode was created by h_munktell
Hello
I'm having a gladevcp panel with some hal spinboxes. I want to use the value of the spinnbox (named "tool_change_pos_x") in the gcode, acoording to: this , I should be able to
But that just outputs "0.000000", but in HAL config that pin has the correct value (the one in the spinnbox). Any ideas why I can not do this? The example in the link works fine and outputs the correct value, but I'm not able to do it from gladevcp widgets.
And yes, I'm on master.
Best regards
Henrik
I'm having a gladevcp panel with some hal spinboxes. I want to use the value of the spinnbox (named "tool_change_pos_x") in the gcode, acoording to: this , I should be able to
(debug, #<_hal[gladevcp.tool_change_pos_x-f]>)
But that just outputs "0.000000", but in HAL config that pin has the correct value (the one in the spinnbox). Any ideas why I can not do this? The example in the link works fine and outputs the correct value, but I'm not able to do it from gladevcp widgets.
And yes, I'm on master.
Best regards
Henrik
Please Log in or Create an account to join the conversation.
11 Dec 2012 06:28 #27547
by mhaberler
Replied by mhaberler on topic gladevcp "named" parameters in gcode
you might have to turn on that feature explicitly, see www.linuxcnc.org/docs/devel/html/remap/s...d_sub_ini_features_a
[RS274NGC]
FEATURE=12
should turn on both _hal and _ini variables for the interpreter
- Michael
[RS274NGC]
FEATURE=12
should turn on both _hal and _ini variables for the interpreter
- Michael
Please Log in or Create an account to join the conversation.
- h_munktell
- Offline
- Junior Member
-
Less
More
- Posts: 31
- Thank you received: 0
11 Dec 2012 15:36 #27558
by h_munktell
Replied by h_munktell on topic gladevcp "named" parameters in gcode
At work right now, but I'm almost sure i have the features set to 30 as per "configs/sim/remap/manual-toolchange-with-tool-length-switch/". Checking a backup on my CNC machine from a few days ago, feature is set to 30. And I have not been poking around with it since.
Please Log in or Create an account to join the conversation.
11 Dec 2012 15:53 #27559
by mhaberler
Replied by mhaberler on topic gladevcp "named" parameters in gcode
sorry, I was wrong - it is 'FEATURES=1', not 'FEATURE=1'
I just tried running this : gladevcp -u spinbutton.py spinbutton.ui
(directory configs/gladevcp/by-widget/spinbutton)
in parallel with axis and executing
(debug, #<_hal[spinbutton.hal_spinbutton1-s]>)
in MDI and get a sensible result
- Michael
ps: this feature mask thing was a bad idea, I will replace this by concrete ini file options.
I just tried running this : gladevcp -u spinbutton.py spinbutton.ui
(directory configs/gladevcp/by-widget/spinbutton)
in parallel with axis and executing
(debug, #<_hal[spinbutton.hal_spinbutton1-s]>)
in MDI and get a sensible result
- Michael
ps: this feature mask thing was a bad idea, I will replace this by concrete ini file options.
Please Log in or Create an account to join the conversation.
- h_munktell
- Offline
- Junior Member
-
Less
More
- Posts: 31
- Thank you received: 0
12 Dec 2012 03:20 #27598
by h_munktell
Replied by h_munktell on topic gladevcp "named" parameters in gcode
Hi,
Checked the features, and it's on 30. Tried the spinnbutton as you did, but with the same result as before. In "Show HAL configuration", the values are correct, both for my gladevcp objects and for the spinnbutton values. But when I MDI a debug exactly like you did, (with -s) it prints out "12.000" regardless the value in the spinnbutton. A debug messega with the "spinbutton.hal_spinbutton1-f" results in "0.0000". Exactly like my gladevcp widgets/values when I DEBUG. -s prints "value 12", and -f prints "0".
Tried 1 and 31 on the features bitmask. with 1 it refused as expected and 31 was no different than 30 as expected.
I'm on 2.6.0-pre0-3567-gcb53192.
Any other ideas?
Checked the features, and it's on 30. Tried the spinnbutton as you did, but with the same result as before. In "Show HAL configuration", the values are correct, both for my gladevcp objects and for the spinnbutton values. But when I MDI a debug exactly like you did, (with -s) it prints out "12.000" regardless the value in the spinnbutton. A debug messega with the "spinbutton.hal_spinbutton1-f" results in "0.0000". Exactly like my gladevcp widgets/values when I DEBUG. -s prints "value 12", and -f prints "0".
Tried 1 and 31 on the features bitmask. with 1 it refused as expected and 31 was no different than 30 as expected.
I'm on 2.6.0-pre0-3567-gcb53192.
Any other ideas?
Please Log in or Create an account to join the conversation.
12 Dec 2012 17:12 #27613
by mhaberler
Replied by mhaberler on topic gladevcp "named" parameters in gcode
yes, my idea was to fix my own bug
this is corrected in master: git.linuxcnc.org/gitweb?p=linuxcnc.git;a...a08aa14aeb2eccba48ff
please pull, rebuild and it should work
- Michael
this is corrected in master: git.linuxcnc.org/gitweb?p=linuxcnc.git;a...a08aa14aeb2eccba48ff
please pull, rebuild and it should work
- Michael
The following user(s) said Thank You: h_munktell
Please Log in or Create an account to join the conversation.
- h_munktell
- Offline
- Junior Member
-
Less
More
- Posts: 31
- Thank you received: 0
13 Dec 2012 02:57 #27644
by h_munktell
Replied by h_munktell on topic gladevcp "named" parameters in gcode
It works!
Big thumbs up! I now have a decent semiautomatic tool changer.
1. A probe function to touch off Z with probeplate (all settings setable from gui/glade)
2. A button that sets tool change position from GUI (machine coordinates) Also editable in spinbox
3. A button that sets tool length probe position from GUI (machine coordinates) Also editable in spinbox
4. A remap on M6 to a sub routine that :
* Stores the position when M6 was called
* Move to tool change position
* Reacts on button from glade when tool is changed
* Moves to tool probe position
* Probes the reference or tool length offsets
* Sets the correct dynamic tool length offset
* Returns to the position where M6 was called to continue the program
5. All moves from different positions is made with traversiong to a safe Z (Z0 in my case) before XY, then correct Z
Now I just have to clean up the code, fix panel activation correctly depending on machine status etc etc.
![:woohoo: :woohoo:](/media/kunena/emoticons/w00t.png)
1. A probe function to touch off Z with probeplate (all settings setable from gui/glade)
2. A button that sets tool change position from GUI (machine coordinates) Also editable in spinbox
3. A button that sets tool length probe position from GUI (machine coordinates) Also editable in spinbox
4. A remap on M6 to a sub routine that :
* Stores the position when M6 was called
* Move to tool change position
* Reacts on button from glade when tool is changed
* Moves to tool probe position
* Probes the reference or tool length offsets
* Sets the correct dynamic tool length offset
* Returns to the position where M6 was called to continue the program
5. All moves from different positions is made with traversiong to a safe Z (Z0 in my case) before XY, then correct Z
Now I just have to clean up the code, fix panel activation correctly depending on machine status etc etc.
Please Log in or Create an account to join the conversation.
13 Dec 2012 03:09 #27646
by mhaberler
Replied by mhaberler on topic gladevcp "named" parameters in gcode
hi h_munktell,
good to hear
if you dont mind I'd appreciate a cleaned version so it can be added as an example - no urgency, let it shake out first
- Michael
good to hear
if you dont mind I'd appreciate a cleaned version so it can be added as an example - no urgency, let it shake out first
- Michael
Please Log in or Create an account to join the conversation.
- h_munktell
- Offline
- Junior Member
-
Less
More
- Posts: 31
- Thank you received: 0
13 Dec 2012 03:22 #27648
by h_munktell
Replied by h_munktell on topic gladevcp "named" parameters in gcode
Of course, that's the least I can do for the community.
One problem though (have not investigated so much, just run into it)
When starting linuxcnc and it tries to load the OPEN_FILE defined in .ini. There is M6 that will be "replaced" by the remapping. I get an error that my _hal[gladevcp.pin] doesent exist because the panel with those widgets is not loaded yet. No problem to run the program though after I have reloaded the file.
Can I somehow get all panels load before it loads the OPEN_FILE?
One problem though (have not investigated so much, just run into it)
When starting linuxcnc and it tries to load the OPEN_FILE defined in .ini. There is M6 that will be "replaced" by the remapping. I get an error that my _hal[gladevcp.pin] doesent exist because the panel with those widgets is not loaded yet. No problem to run the program though after I have reloaded the file.
Can I somehow get all panels load before it loads the OPEN_FILE?
Please Log in or Create an account to join the conversation.
13 Dec 2012 04:00 #27650
by mhaberler
o bwoy. I need to think about that one.. wasnt in my grand plans;)
As a temporary workaround, you can could test in the remap procedure with EXISTS(#<_hal[gladevcp.pin]>) if the HAL pin is is visible yet and loop with a delay
ugly but at least a fix for now
- Michael
Replied by mhaberler on topic gladevcp "named" parameters in gcode
Of course, that's the least I can do for the community.
One problem though (have not investigated so much, just run into it)
When starting linuxcnc and it tries to load the OPEN_FILE defined in .ini. There is M6 that will be "replaced" by the remapping. I get an error that my _hal[gladevcp.pin] doesent exist because the panel with those widgets is not loaded yet. No problem to run the program though after I have reloaded the file.
Can I somehow get all panels load before it loads the OPEN_FILE?
o bwoy. I need to think about that one.. wasnt in my grand plans;)
As a temporary workaround, you can could test in the remap procedure with EXISTS(#<_hal[gladevcp.pin]>) if the HAL pin is is visible yet and loop with a delay
ugly but at least a fix for now
- Michael
Please Log in or Create an account to join the conversation.
Moderators: HansU
Time to create page: 0.104 seconds