Fix heartbeats from task and motion

[BsAtHome]

The motion controller has a heartbeat that was apparently addressed in task, but that heartbeat counter was never updated or propagated. Task's status line, when LCNC exists, always printed task: 0 cycles, ... because of this. Using motion controller's heartbeat in task was wrong anyway because it is supposed to track task's main loop.

This PR fixes this by adding a taskbeat to task's main loop and that is used to print the status line at the end at exit. Additionally, the taskbeat is exported in the NML shared emcStatus in the task structure.

Secondly, the motion controller's heartbeat is now correctly exported in the NML shared emcStatus in the motion structure. Motion controller's heartbeat is necessary to track the RT loop (servo-thread) because status changes can be delayed by one or more RT loops, causing potential for races between RT and non-RT. Non-RT needs to be able to track RT's progression. Example: setting TELEOP mode automatically happens after homing all joints, but that takes one extra loop of the motion controller for it to become set. Sending the next command can therefore fail if you do no wait appropriately.

Also, the heartbeats are now 64-bit (which became possible after the NML update() fixes). That should leave time for about half a billion years of uptime at 1 kHz rates.

[snowgoer540]

Well done. I had some time to play with this evening. In order to use it, I needed to added heartbeat and taskbeat to emcmodule.cc. Were you planning to add it later? If not, do you want to update this pull request, or I am happy to add it later after this is merged..

Also, do you plan to update the documentation surrounding this?

[BsAtHome]

I guess that it would be alright if you make a PR after this has been committed, if you can solve the problem described below.
Anyhow, these heartbeat counters are only relevant (especially motion controller's) to prevent some specific RT vs. non-RT races afaics. Adding these to emcmodule.cc needs a use case. I guess you have a use case in mind?

With respect to the documentation,... is the rest of EMC_STAT documented?

The emcmodule.cc interface does expose the status. Whether this is a complete mapping of EMC_STAT, I doubt it. If you want to add it, then you must map it to an unsigned integer of exact 64-bit size in python. That you'll have to find out how to do in a portable way. Python does not expose T_* types for uint64_t explicitly afaik and uses a generic T_UINT and T_ULONG and is a bit vague about the actual size.
Note: We just changed NML to use only explicit size integers ([u]int{8,16,32,64}_t) in the update() routines and let the compiler sort it out how that maps because we had problems with 64-bit values.

[snowgoer540]

I guess that it would be alright if you make a PR after this has been committed, if you can solve the problem described below. Anyhow, these heartbeat counters are only relevant (especially motion controller's) to prevent some specific RT vs. non-RT races afaics. Adding these to emcmodule.cc needs a use case. I guess you have a use case in mind?

Speaking candidly, I am not sure I will get around to implementing anything, I was talking loosely with Phill about it, and the initial thoughts surrounded interactions that were influenced by a halui pin. Keeping track of the elapsed number of cycles for determining the exact position when an arc_ok signal was lost could be another use case. Rapid jog direction changes, state/mode changes, internal MDI commands with offset changes and motion, etc. Overall it seems like a pretty good tool to help with race conditions between rt and non-rt.

With respect to the documentation,... is the rest of EMC_STAT documented?

Sorry, I was speaking as if you were going to add it to emcmodule, I was thinking of the documentation surrounding the linuxcnc.stat attributes here: https://linuxcnc.org/docs/devel/html/config/python-interface.html#_linuxcnc_stat_attributes

That said, it would be up to me to add :)

The emcmodule.cc interface does expose the status. Whether this is a complete mapping of EMC_STAT, I doubt it. If you want to add it, then you must map it to an unsigned integer of exact 64-bit size in python. That you'll have to find out how to do in a portable way. Python does not expose T_* types for uint64_t explicitly afaik and uses a generic T_UINT and T_ULONG and is a bit vague about the actual size. Note: We just changed NML to use only explicit size integers ([u]int{8,16,32,64}_t) in the update() routines and let the compiler sort it out how that maps because we had problems with 64-bit values.

In my quick testing tonight I used T_ULONGLONG, but I will plan to use getter functions with PyLong_FromUnsignedLongLong() instead. Unless you object?