Open the-snowwhite opened 4 years ago
It looks like rtapi_print treats the message as an error (which is ultimately what is getting called by hm2, see here and here). In addition, that error is then passed through to the linuxcnc.error_channel in Python, which axis is picking up. I've seen similar non errors pop up as well, such as in the lutn component. I believe at some point machinekit-hal started exposing additional error messages through to the NML error_channel, but I'm not sure when. Before, the various components that were printing debugging messages as errors were silently ignored or simply logged to some file rather than being exposed to the error_channel. I imagine the fix is going through and changing debugging messages to a more appropriate log level, such as INFO or DEBUG.
This is definitely about https://github.com/machinekit/machinekit-hal/issues/318 bullet # 3. At some point, the EMC error channel was hijacked and all logs funneled through it, but that was originally meant only for carrying EMC-related application messages. A look through the LinuxCNC code will show the original intent. That behavior should be restored, and a separate ∅MQ channel between rtapi_app
and rtapi_msgd
should be established for ordinary HAL logging. Altering log levels artificially makes the Axis messages look normal, but hides a lot of important information that used to be logged to console or log file.
I took a crack at it a year or so ago, but after an enormous amount of work I still couldn't quite get it all straight and mothballed the project.
Every time I have run any hm2_soc based axis configuration I have been able to come up with in EmcApp it initially looks like this:
Exactly 11 messages I have to close each time I test on a physical hm2 setup.
The console looks like this:
And the config I have been able to come up with so far is here:
Hal log: (from DE0_Nano_soc)