`Have you ever tried teh M80/M81 routines that record teh Gcode status and then restore the Gcode status back to the recorded values ??
Just a thought(;-) TP
`Have you ever tried teh M80/M81 routines that record teh Gcode status and then restore the Gcode status back to the recorded values ??
Just a thought(;-) TP
I had never heard of those M codes before; they are not documented by Tormach, and a cursory Web search turns up some unrelated uses of them in some gCode implementations. Should we rely on Tormach to support them for save & restore?
Being able to save and restore gCode settings would be nice, but most of what I perceive as missing is access to engine status (speed range, slider positions, etc) that by nature can't be set by gCode, but now can't even be read by gCode.
Perhaps not exactly what you are asking for but there may be alternatives that don't require Tormach to make changes. I haven't tried it but supposedly you can call Python from gcode. (See https://forum.linuxcnc.org/20-g-code...python-example for some details.) You could use python code to read or set any HAL pin from your gcode. For example, HAL pins 'tormach.spindle-range' and 'tormachspindle.belt-position' reflect the current belt settings (I did try that).
Please keep us informed if you try this!
To be rude, "the documentation is in the code"! More politely, go to the MDI and enter "admin halcmd show". PP will dump zillions of lines containing the names of all pins and signals and components into the log file . Many of the names are somewhat self-explanatory. If there is any doubt, change the value what seems the obvious meaning and enter "admin halcmd show pin i_do_not_fully_understand" and play until you understand. If you haven't yet found it, the logfile is called gcode/logfiles/pathpilotlog.txt and is probably most easily examined from notepad++ on a PC connected to your gcode share.
Look at Creating Userspace Python Components for some details of the interface and what you can accomplish.
The M80/M81 routines are used in the PP ATC functions so I dought they are going anywhere soon. (;-) Use them or not up to you. But they work great here. EVERY DIY controller I have worked with in the past has special " things" they do not tell you about.
(;-) TP
response to #25
I'm still missing something. Among the lines generated by admin halcmd show there are a few whose interpretation would seem to be straightforward. For example, there are lines that seem to show the current minimum and maximum spindle speeds, so I could write Python code that would let HAL know what speed range the machine was in. I found some other interpretable lines (the current tool's number, OD, and offset; the radio button for jog size; the slider (I think) of feed rate) too.
What I'm missing is this: I haven't noticed any means of having HAL share what it knows with running gCode. I'll be happy to write a bunch of Python to poll various machine state, but I don't want to bother with that until I could write some gCode like
Code:o 1234 if [something] (msg, low speed range) o 1234 else (msg, high speed range) o 1234 end if
Earlier I wrote "I haven't tried it but supposedly you can call Python from gcode. (See https://forum.linuxcnc.org/20-g-code...python-example for some details.)" Have you tried the material in that link? It is one of the dozens of things on my to try list!
Just a note there is a void between the Python side and the Gcode side where some data cannot pass either way. You have to route the data to an outside program then to the otherside. Been there tried that. I was working on having PathPilot to send text about the Gcode side conditions to the enduser which was controlled on teh Python side. Doing either side was trivial but transferring data across teh void was very complicated as I found out .
Just a thought , (;-) TP
I looked through that link and found nothing useful. Someone in one comment said he thought that Python-to-gCode communication wasn't actually possible, but all I take from that comment is that it isn't trivial.
The whole business of going into HAL & Python is, at best, an unattractive workaround. As you noted, there are zillions of data maintained by HAL. That is a conservative estimate.
By contrast, there are no more than one or two dozen simple items that are
- already used by the PP engine,
- individually communicable as numerical (and often boolean) values, and
- of potential value in gCode programs.
If Tormach's rule of thumb were that whenever such an item is identified, it is linked to a new #54xx parameter, then this might add about 2 person-hours per year to their workload, and it would protect users from getting trapped in irredundant, semi-maintainable innard-hacking.
As I understand it, there is some code that is more-or-less "real time" that resides in the kernel and handles interpreting the gcode and sending motion commands to the hardware. This code is very much "heads down" doing time critical things and has some strong limits on how long it can take to do what it needs to do. It can't reach "out" of the kernel to the other code which runs the user interface due to timing limits and security limits.
The other piece of code keeps the user interface working. This is where the python code is. It can send information into a queue of commands that get sent to the code in the kernel, but it gets very little information back from the code in the kernel (some status info, mostly, I think). The user interface isn't "real time" or in the kernel, so it has fewer restrictions on what it can do. That's what allows it to run the user interface.
So when the gcode is executed, it is in code that can't get back to the python code to a very large extent. The user interface code is pretty much limited to issuing commands and listening for some very limited status, but doesn't really "look at" the gcode, it just hands it down to the code in the kernel.
After I had struggled with it for about a full week I broke down and asked Tormach if it was possible. Here is teh responce.
Hi Terry –
You’ve discovered that “you can’t get there from here” with regard to the Python user interface and the state of G code interpreter data.
It can be done via use of a LinuxCNC feature called “remap” for M and G codes but use of remap is very complex and has various non-obvious side effects.
You might try another approach to get the data you want somewhere that the UI can find it.
Look into using the magic comments that start with “LOG” to lay a trail of bread crumbs for your M00/M01 break handler in the UI.
Open the file, log your data, close the file, and let the UI code look for the file and do something with the contents.
You would include this sequence just before the M00/M01 break in the gcode program.
LOG understands named and numbered G code variables.
Note: the default directory for the LOG file is ~/gcode – i.e. /home/operator/gcode. This is the folder that shows up as the root of the File tab in PathPilot.
G Code Overview
(LOGOPEN,filename.txt) - opens the named log file. If the file already exists, it is truncated.
(LOGAPPEND,filename) - opens the named log file. If the file already exists, the data is appended.
(LOGCLOSE) - closes an open log file.
(LOG,) - everything past the , is written to the log file if it is open. Supports expansion of parameters as described below.
The amount of work involved just was NOT worth the effort as it still was not know IF it could be done dependably. Yep just one of those just can't get there from here deals. OR close but no cigar (;-).
There was also a deal where you write teh data out to a holding program outside of PathPilot. It ran in Linux . the the Python side could read into that program and grab teh data . It too was not worth the effort to impliment and maintain over updates.
The idea was simple take error data from teh gcode side and send it to the user cell phone from teh Python side. (;-)
(;-) TP
Another thig I am working opn is to be able to send user messages to the Status line at teh bottom of teh main page. That way the operator gets a direct view of any incoming messages without having to change screens or mouse over the status tab. You simply look at teh status line for any new message. Many times in probing routines or measurement routines using teh probe you need to see teh actual data as it is collected . This always worked well in other controllers where you had teh staus line on teh main page.
There is a message line there PP uses it on startup to post teh mode name. But after that I do not ever see it used for anything PP.
SO if when you used debug and it sends teh message to the status PAGE it would be great to also send it to the Status line on teh main page. It would only contain 1 line then be overwritten on teh next message.
I got close but it was one of those close but no cigar deals.
(;-) TP
Something like this (check the status line below the DRO's)?
https://youtu.be/thZDQ-kUahA
I personally don't think a single line is much use for monitoring measurement values but...
Step
It may be worthwhile to expand on this:
- Values that gCode can set, but cannot read. These can't therefore be saved, temporarily changed (say, in a subroutine), and then restored. The M80/M81 codes touted by @vmax549 might do the trick, but the trouble with unreadable values is that there's no way to know if they have actually been restored. The only values in this group that I've come across so far are the P and Q parameters of G64, but there may be others.
- Values known to PathPilot because it knows what machine it's on. These include
- absolute maximum X
- absolute minimum Y
- absolute minimum Z
- maximum feed rate
- Values known to PP once the machine has been referenced, and in a given workspace. These include the minimum and maximum possible values of X, Y, and Z.
- Values that a user can set in the UI. These include the high/low spindle-speed range and the positions of the various sliders. The jog slider is interesting because PathPilot ignores it while a program is running, but -- if it could be read by gCode -- it could allow live manipulation of a running program in various ways.
- Values derived from some of the above. These include
- the maximum and minimum spindle speeds at this high/low setting,
- the actual feed rate and spindle speed (modified by the pertinent sliders and constrained by the maxima; these are the values shown in the DROs of the UI)
I think that's it; as I estimated, it is fewer than 2 dozen items.
HI Step I had found the name for the status line and was able to write to it as well. BUT I know that Debug sends the text to the status PAGE but how are you redirecting teh debug output to the status line on teh main page ??
(;-) TP
Hi Step the important question would be did you hand edit the screenset to add teh C axis dro or were you able to get Glade to work with PP ??? So far I have not been able to get Glade to work with PP. I would love to be able to add a couple of DROs and a couple of buttons to teh screenset.
There are also Text lines embeded in teh toolpath window. That would be better than teh status line as it is more visable to teh operator.
(;-) TP
Fenichel , If you look in the remap for the M80/M81 I think you can see exactly what values they are saving and restoring.
(;-) TP