gladevcp / remapping gcode / python questions

Hi,
I wrote a geometric chuck simulator for generating patterns.
Now I would like to create a glade front end to allow users to add/ remove wheels and change their 3 parameter values. Also ultimately I would like to take the path generation component and attach that to a remapped gcode in order to greatly simplify the program. Assuming the code to remap was G65 I would envisage passing one parameter which would be an angle so the core of the resulting program would be something quite simple such as

#<_depth> = -1
#<angle> = 0
( goto safe height )
o<wheels>) while [#<angle> lt 360 ]
g65 [#<angle>]
#<angle> = [#<angle> + 1]
o<wheels> endwhile
(got safe height )

I envisage that the python script attached to g65 would move the current position to the values generated by the wheels pattern generator possibly using global variables such as #<_depth> declared above in the program text.

This is all new to me (including writing python but have experience of c,c++,c#) so I have several questions.
1) Is it possible that the ui code could control the data used by the python script attached to the remapped gcode? How would I hook them up together ?
2) Which version of python does the gladevcp and also the embedded interpreter use ? I think I am assuming 2.7 but hoping for 3.3 as I am using 3.3 at present to write a small path visualizer for my wheels program but with qt5 ui generator.
3) Could the embedded python interpreter access global variables such as #<_depth> above and use them ?

Not sure where to send this query but hoping someone may have the answers and a possible hint as to how to get started.
Thanks
Alan

Hi Alan,

you'd pass the parameter through a unused word, like Q, so that'd be:

g65 Q#<angle>

That Q would become part of the 'argspec', see the remapping docs.

(note G codes do require some axes).

I envisage that the python script attached to g65 would move the current position to the values generated by the wheels pattern generator possibly using global variables such as #<_depth> declared above in the program text.

Most people just use NGC subroutines; certain operations are a bit hard to do in Python because the interface is rather lowlevel and primarily used to feed parameters to, and result values from NGC procedures. It is possible in principle though.

1) Is it possible that the ui code could control the data used by the python script attached to the remapped gcode? How would I hook them up together ?

Note the Python interpreter used during remapping is part of the milltask process, not the UI. Those are different processes. It is possible to pass parameters from UI's - the easiest being through HAL. Some hints can be found in the Remapping docs.

2) Which version of python does the gladevcp and also the embedded interpreter use ? I think I am assuming 2.7 but hoping for 3.3 as I am using 3.3 at present to write a small path visualizer for my wheels program but with qt5 ui generator.

2.7 (or 2.6), depending on platform.

3) Could the embedded python interpreter access global variables such as #<_depth> above and use them ?

yes it can, all named parameters are visible.

Some examples how Python can introspect interpreter state can be found under tests/remap, for instance:

git.mah.priv.at/gitweb?p=emc2-dev.git;a=...62b7ef9e13371a2d8124

- Michael

Thanks Michael for the information.

When originally thinking about this I sort of discounted NGCGUI because I assumed that it would only access values passed as parameters to a subroutine. As the number of wheels used could vary I thought that it would not apply. The best I could do was to pass into the subroutine the base address of the data block (currently #200 and was not sure what I could do about the profile data) I assumed that NGCGUI would have no mechanism for unpacking this data. I was counting on writing python event handlers attached to the glade interface to unpack the data and update it as necessary. This was before I considered gcode remapping. So my original scenario was
1) wheels data + profile data held sequentially from known addresses (#200 onward wheels data and #1000 onwards profile data),
2) data editing using gladevcp accessing this data
3) path generation by my current subroutine wholly in program so keeping large chunks of my preexisting code

With gcode-remapping I could have roughly the same but with python g65 handler accessing gcode variable data OR I could hold the data in python variables within the python memory space itself. (I have written a non linuxcnc python program to generate the path that does this).

The second option is very attractive to me because it is a means of removing the reliance on linuxcnc variable memory whoose size is limited. The wheels data is trivially small but the profile data can get stupidly large. Consider cutting a path over a rectangular profile 100mm square with the profile heights being defined every 0.1 mm.

So ideally I would ultimately like to hold all data in python variables within the resize-script space but access it for editing using gladevcp, this would mean some inter-process communication between the two python processes. Is this a pipe dream?

I shall start with the first code-remapping option but hope that its possible to do the second option. The problem with the size of profile data is quite common so perhaps someone has solved it in a general way (I know about but have not yet tried the probekins solution). Any suggestions on this would be welcome

Alan

Alan,

The second option is very attractive to me because it is a means of removing the reliance on linuxcnc variable memory whoose size is limited. The wheels data is trivially small but the profile data can get stupidly large. Consider cutting a path over a rectangular profile 100mm square with the profile heights being defined every 0.1 mm.

So ideally I would ultimately like to hold all data in python variables within the resize-script space but access it for editing using gladevcp, this would mean some inter-process communication between the two python processes. Is this a pipe dream?

I would think it is possible in principle, but keep in mind this is the G-code interpreter in control, and only calling onto Python at certain points - you could view this embedded interpreter as a Python extension of interpreter C++ methods. So you dont have your standard read-eval-print loop; a command to tell embedded Python to re-read some file necessarily must come from gcode. So this could become inelegant quite fast

- Michael