Reading Parameters / Return Values from Python

I'm working on some extensions to the GMOCCAPY GUI and I'm running into a road block reading parameters and returning values to Python from O-Code or mdi commands? Is there a way to do this? I can't seem to find much in the way of documentation for the _hal and _ini parameters and their usage in G-Code / O-Code.

Reading Parameters
For example, if I want to read the work coordinate system for a non-active work coordinate, in G-code, I can read the (x,y,z) values from the parameters: 5221 + WCS_Offset, 5222 + WCS_Offset, 5223 + WCS_Offset

However, since I haven't found a way to read the parameters directly from Python itself, I have to do one of the alternative methods below.

Alternative 1 - The status channel will return the active work coordinate system, but that requires changing the active work coordinate system, reading the values, and restoring the previous work coordinate system which seems clunky and it only works for the WCS values and not general parameters.
Alternative 2 - Another alternative is to save the values to a temp file -- this works great and allows me to read all parameters, but it is very hacky IMHO.
Alternative 3 - Using Signals - I tried to create a new HAL pin and this works great for reading from G-Code, but I can't get writing from G-Code to work.
A direct approach would be much nicer -- maybe I'm missing something obvious?

O-Code Return Values
Another use case that I seem to be missing is for retrieving the return values from o-code. The return code is saved into parameter #<_value> - is there any way to read this from Python after calling a subroutine?

self.command.mdi("O<probe_z> call")
# How can I read the return code from the probe_z subroutine or do I just have to always use the raw probe value?

Any help or guidance (or pointers to the appropriate C/C++ code to look at) would be greatly appreciated.

Thanks,
Eric

Hi Andy,

Thanks for the reply. The code you linked to is for remapping various G-Codes which does help to some extent, but from what I understand, it would mean that I would have to override a few G-Codes to get the information that I'm looking for which doesn't seem to be much better than the current file approach. At least it is another option in case a run into any issues.

In reading through the remap documentation again, I did find out that the HAL references are read-only since they are read during read-ahead, so that explains the issue with alternative 3: linuxcnc.org/docs/html/remap/remap.html#remap:referto-hal-items

Thanks,
Eric

No, that was not my suggestion, I was just using that code as an example of parameter access from Python.

The stdglue.py, self.params, and other topics on the remap.html page refer to the embedded Python interpreter, so that still doesn't provide a data path back to the Python GUI code.

I believe that the same approach would work with "self.params["5121"]

Out of curiosity, I gave this a try and it worked for name parameters but not ordinal parameters. Taking a look at the parameter code in src/emc/rs274ngc/pyparamclass.cc, it turns out that named parameters are referred to by string and numbered parameters are referred to using their ordinal. So the named parameter self.params["_x"] is referred to as self.params[5420] or self.params[5212] for the WCS example.

Anyway, interesting side diversion and I'm sure the knowledge will be useful in the future.

Regardless, this approach doesn't open up any easy way to pass data back to the Python GUI code. No big deal, though, since using alternative 2 (temporary files) works fine.

Cheers,
Eric