Fix command.c debug messages

[hdiethelm]

While working on #3839, I activated debug and found that the output had random newlines.

The reason is that at the end of emcmotCommandHandler_locked(), a newline is printed and not every command had a rtapi_print_msg().

ABORT doesn't use joint_num, so I see no reason to print it.

To test, I added rtapi_set_msg_level(RTAPI_MSG_ALL); in control.c emcmotController(). This is temporary, not in this PR. Is there any other way to activate debug per module?

Alternative: Remove the rtapi_print_msg(RTAPI_MSG_DBG, "\n"); at the end and add a newline to all other rtapi_print_msg(); Advantage: Less issues in the future. Disadvantage: You don't see if someone forgot to add prints and there will be more changed lines.

[BsAtHome]

Is there any other way to activate debug per module?

Unfortunately, no. The print message/debug interface is an all-or-nothing proposition. For real module/component/level differentiating debug messages we need to build a different interface. Maybe using a "channels" idea to select what kind of debug is enabled. And, IMO, we should be able to switch debug off and not being build/included at all to see what that does in performance (instead of executing the many if(level >...) statements).

[andypugh]

You can change the debug level in the HAL file. This is something that I added, and I am not sure how well it works.
It doesn't really address your question, except possibly allowing you to selectively debug the loading of a particular module at a different level.

Prior to adding the HAL command the way to change debug level on the fly was "echo 7 > /proc/rtapi/debug". But that had stopped working by the time I added the HAL command. Possibly it only ever worked in RTAI?

[hdiethelm]

You can change the debug level in the HAL file. This is something that I added, and I am not sure how well it works. It doesn't really address your question, except possibly allowing you to selectively debug the loading of a particular module at a different level.

Like halcmd debug 5? For me it doesn't work but I am also not using rtlinux on my dev machine due to ZFS is incompatible it seams. Might be a simulated RT issue.

[hdiethelm]

I just did a bit digging: At least without rtlinux, do_set_debug_cmd() can not work because it is called in the halcmd process and sets the msg_level of this process. So not inside the rtapi_app process where it would have an effect.
The command should be sent to rtapi_app and executed in there to have an effect.

I hacked something together which seams to work. I will make it nicer and create yet an other PR in a few days.

[BsAtHome]

In uspace, there is a UNIX socket linking the master and slave rtapi_app program. The first to start becomes the master and all other instantiations of rtapi_app will become a slave.

The slave will send a command down the socket for the RT part to execute (like load an RT component). This command simply seems to be the argv[1...argc-1] list of the program. Changing the message level needs to be done in the master that should receive it automatically from the slave. But, there does not seem to be a "debug" command recognized in the handle_command() function. That is why the level is never changed in uspace.

[hdiethelm]

Yes, i figured that already out and it is already working well. I just have to remove my debug code and then I will create a PR.

[hdiethelm]

BsAtHome: Thanks, anyway. I think while you where writing, I already figured that out by adding some debug prints and reading the code.

PR is ready: #3870