topic_unsolved [Duet3 6HC] Gcode inside accelerometer results
pkos last edited by
I've been having some interesting time playing with the accelerometer on two of my printers.
I got it to run perfectly on a Duet3 Mini 5+, reads all data nice and easy.
Using the same wire and same accelerometer, I moved the sensor to my 6HC board on a second printer and tried the same. Only difference was a different IO port (8 on the 6HC, 3 on 3 mini 5+).
The accelerometer would get discovered, but I was unable to change orientation. Each time, firmware reported the same orientation of 20 (I was trying to force it to 10).
But the weirdest thing happened when running the actual test. Instead of providing actual results (like I got on the mini 5+), I would get parts of gcode in there. The gcode looks like it was sliced by me, but how it got into the csv file is beyong me
A part of the CSV below from the top.
Sample,X,Y,Z Failed to collect data from accelerometer G1 X56.644 Y228.606 E0.02609 G1 X57.391 Y229.083 E0.028 G1 X57.995 Y229.709 E0.02747 G1 X58.445 Y230.466 E0.02785 G1 X58.698 Y231.266 E0.0265 G1 X58.767 Y232.114 E0.0269 G1 X58.651 Y232.94 E0.02633 G1 X58.374 Y233.681 E0.025 G1 X57.927 Y234.379 E0.02619 G1 X57.309 Y234.98 E0.02726 G1 X56.898 Y235.229 E0.01516 G1 X56.652 Y235.378 E0.0091 G1 X56.569 Y235.427 E0.00304
Is there anything I can do to figure out why this happens? Like a debug mode? I know there's a different thread about debugging, but there, the accelerometer doesn't get discovered, whereas mine works on mini, but not on 6HC.
One more note - I didn't find a way to reproduce it reliably, but sometimes, when running the code to move and start readings - the printer would reboot on it's own. Not always though.
I just had the same thing happening.
It was picking up parts of a macro, parts of a print file and all sorts of weird things.
I went back and checked all the terminals were seated correctly and it seemed to fix it.
Also when I tried initially I was testing using a macro
When I did it later I just used the console.
Not sure if that might make a difference.
Mine is SPI, but mine is duet2 wifi
@owend, I think I see what is happening. Because it's not always possible to write data to the SD card as fast as it is generated, and there isn't enough RAM on Duet WiFi to buffer more than 8kb of it at a time, I pre-allocate space for the file in order to speed up writing. If RRF fails to retrieve accelerometer data at all (e.g. because the INT line isn't connected), then you are seeing the old data in the preallocated SD card sectors.
I will change the code to delete or truncate the file if retrieving accelerometer data fails.
pkos last edited by
@dc42 I tried both. Same behavior. Just to be sure, this is on the 6HC.
I’m going to give it another go, but I am curious if there is any way we can as users try to figure out why data collection failed?
Each time it happened I saw a line that said it didn't collect any accelerometer data.
However in some cases there was some data, but also a heap of random code.
Your theory on picking up previous data sounds entirely feasible.
As I said, when I re-seated all the connectors on the headers it stopped.