[Duet3 6HC] Gcode inside accelerometer results

[pkos]

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.

[OwenD]

@pkos
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.

[dc42]

@pkos and @OwenD, are your accelerometers connected to the main board via SPI, or via I2C and CAN?

[OwenD]

@dc42
Mine is SPI, but mine is duet2 wifi

[dc42]

@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]

@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?

[OwenD]

@dc42
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.