Some data I collected with the new logging features.
Run2:
In this run I redo the calibration. Interestingly there is noise in the current value of the top left motor before I run any commands.
Raw data logMaslow-serial Calibrate2.log (3.7 MB)
Cleaned Data csv M4 Data - RUN2.csv (1008.9 KB)
Run3:
This run is only me going to the apply tension step after a software crash. The noise still seems to be affecting the top left motor. In both of these runs the spindle and vacuum were off but plugged in.
Raw data log Maslow-serial ApplyTension(3).log (1.1 MB)
Cleaned Data csv M4 Data - RUN3.csv (302.8 KB)
I was thinking about making my output csv directly from the firmware vs rows of json data just to save space. How did you convert the json lines to csv?
We also should add the millis (timestamp) to the actual log messages so we can correlate the data.
Also @Bar, not to hijack this thread, but is this useful data? I think we can add a “debug on”, “debug off”, “debug dump” to the upper-right menu or somewhere out of the way to send these commands.
I copied the serial into vscode and then used the regex in the find and replace tool with this expression. [A-Za-z": {}] This removes all non numerical characters and then I just paste the output to a sheet with the titles prefilled.
I think that it’s very much useful data. We could probably prune down which variables we are recording and store more data which could be helpful, especially if we can get a dump of what was happening right before a crash
One more thing, could you make the json data print to the serial window in real time? This way I could look at the current readings as I try to test different solutions.
While I think that’s possible, I avoided that on purpose. By running the data gathering in binary form to the SD card on the second cpu, I take as little resource from operation of the machine as possible. The environment is pretty constrained, and I was thinking we may even take samples more often eventually and we will need this to not interfere with operations on the machine.
We could certainly also add a debug flag for logging values to the console (vs saving data, and printing it at the end)
100%. I just grabbed all the vars in maslow.cpp as a start. I think also grabbing position from fluid would be useful and probably a lot of the vars here are not useful.
Here is a build that still uses the stored data, but reports it as a CSV instead of lines of json. Should make it easier to digest from the log.
I’ve been thinking about the “as you go” reporting, I think this is likely to interfere with other output being used on the serial console (or have the possibility of it anway). I’m not 100% sure we want to do this without putting the lines in a format that will not be “raw” such that things reading the serial stream won’t choke on it. We had issues with other software such as openbuilds when the serial stream output raw data during operations.
I’ve run out of time for this weekend for this so unless I can sneak in some more time later, this will probably be it for now…
I swap the two pin power cables of the tl and tr motors and the noise is still present in the tl motor.
Could this be an issue with my board? I noticed this resistor sj2 is missing but I’m not sure if that’s intentional. Also any ideas on where this constant stray current would come from?
Is the noise that we’re looking at the readings of things like 0.1-0.5? I think that’s just going to be a small amount of noise on the ESP32’s ADC. The maximum value for that number is 4000 so I wouldn’t expect that small amount of noise to cause any issues.
When you have some time could you send a log of one of the machines that can’t reproduce this bug? Just a minute of it siting idle after startup should be fine. My concern is that the position seems to be constantly drifting by small amounts while there is no actual movement. I have to assume that this adds up over time until it passes the 15mm threshold. Also what values do you usually see for center point deviation?
Bottom right position starts drifting right from startup till I turn the machine off. This is while the belts are tightly wound after a retract all step.
Just wanted to leave an update for anyone who finds this thread. I managed to fix the problem by running a grounding wire through the shop vac hose (it was generating a tremendous amount of static).
Sadly the 15mm error has returned. I mange to now get a few hours into a cut before it shows up and I don’t think its ESD as I have this machine covered in conductive tape with a wire run to ground. All of my connections are glued into place. I am running the latest software. My anchors are very rigid and are not flexing. What is confusing is that the error seems to cause my belt to not spool correctly. The only other thing I can think of is grounding the floating pin on the encoder boards. . Any suggestions on what I should try next to kill this bug?
Last week, I had a spate of these ‘exceeded 15mm’ errors and also had a spooling excursion (on my lower right I think) when jogging the cutter to the left, didn’t think to conflate the two but now I wonder.
To fix this I ended up needing to extend all then $BRO enough times until I could take out the slack. I can see how it could get me in trouble but it sure was helpful in unforking this shirtshow.