Closed ronlawrence3 closed 1 week ago
BarbourSmith
commented
2 weeks ago I think that this is an absolutely fantastic feature that would make debugging tricky issues so much easier.
Is this data preserved through crashes? I know that it would be on the SD card, but probably not otherwise?
ronlawrence3
commented
2 weeks ago Is this data preserved through crashes? I know that it would be on the SD card, but probably not otherwise?
Yes and no. Up to whenever the last buffer gets written, the file captured will be current. I think we'll have to strike a balance between size of buffer and writes to the SD card which are by far the slowest part of this. If the flash was not so full already that would be an option for the buffer but I'm afraid to take too much space there. I can experiment with it a little and see... maybe buffer to that and write from there to SD periodically.
BarbourSmith
commented
1 week ago I did some weird things to the Maslow-Main branch (basically switched where that name points to a different branch) because I was having a really hard time getting the changes from the original FluidNC project to merge in without breaking things, but that change is going to mess up this pull request's target and I'm sorry about that. Maslow-Main is still the correct branch to target with these changes
@BarbourSmith - This is not intended to merge (yet), but to give you a heads up of what I've been up to.
This starts a task on the second core that we can use to gather telemetry data as the machine operates. It creates a (right now 5k) buffer that it stores data into and when its full appends it to a file on the SD card.
By default this is turned off, but a new $TELEM command has been added that toggles it(I was thinking I'll have it take an argument y/n that will let you specifically turn it on or off). When its on, the telemetry loop will execute every half-second to grab what I thought might be good values and store them in the buffer.
Another new command $TELEMDUMP will load the file and dump it to the serial in json-ish format for every measurement.
I also need to add more of a header than just structure size (e.g. firmware version, other?) so we can change the data structure and be able to detect that its not compatible with the dump feature. Also configuration for how often to collect, etc. there are many possibilities. Also not sure about the thread safety concerns. As I'm mostly reading primitive values, I think we probably won't end up with half an int or anything like that, but the structure values might not be a true snapshot given values can change under it as the dump runs. I'd like to see how that goes before going to any mutex protection of the variables as a whole.
My thoughts on this are to be able to add a debugging feature to the UI to start recording telemetry, kick off an operation (calibration, cutting, whatever), then stop and dump the telemetry where it can be analyzed.
I have not yet tested this thoroughly but will start putting it through its paces over the next few weeks.
Is there anything you think would be useful to gather that I can add to this? Do you think it is even a useful feature for any of the issues you've seen happening?