I figured out the issue. The cables I was using were crap. Replaced them with a higher quality cable (I bought these from amazon: https://www.amazon.com/dp/B07GD2PHX9?ref=ppx_yo2ov_dt_b_product_details&th=1) and it's working without issues with default sampling rate, resolution, and SPI clock frequency:

M955 P0
Accelerometer 0 type LIS3DH with orientation 50 samples at 1344Hz with 10-bit resolution, SPI frequency 2000000

Ok, so the probe was faulty. New probe just came in and it works flawlessly.

@owend This is super cool! I didn't know RRF supported conditional GCode. Now I need to learn how to program in this language.

Thanks a bunch!

I followed your advice and I am now getting consistent readings within 0.005mm which is well within the margin of error for the probe. The key was the probing speed and the dive height (Set to 5mm/s and set to 5mm). Once I slowed the probe down and also didn't raise the Z height above 5 mm, the readings were consistent.

Thanks for the advice!

@phaedrux It does seem like an Ethernet controller problem. The SD card from the problem board works just fine on my spare Duet 2 Ethernet.

I tried resoldering the ethernet module pins to the board, but to no avail. When the board is first powered through USB, the module lights up. When I issue an M552 S0 to turn off networking, the module lights go out. When I enter M552 S1 to enable the network, the lights don't come back on. At this point I can't be certain if it's the main board or the ethernet module. Guess I'm going to have to switch it back to WiFi to confirm.

I will use my spare board in the meantime.

Thanks!

That's what I think as well. I just downgraded to firmware 2.05.1 and am having the same issue. I'll get a replacement ethernet module for this board and try it out. I do have a Duet Ethernet board in the mail, so that will be for my second printer

Ok, so I received my new Duet 2 Ethernet board today and the first thing I did was flashed firmware 3.2.2 on it. It is working without a glitch so far (fingers crossed). I guess the ethernet module on the other board was bad. I have ordered a replacement for it, so hopefully that fixes my problem.

In any case, after fixing the sensor, and getting a new ethernet module, I am running a test on the printer now and it's working great. Here are some before and after videos of the printer (Before using the stock Melzi Creality board, and after upgrading to the duet 2 Ethernet)

Before:

• Creality Melzi CR-10S board running TH3D Unified firmware: https://photos.app.goo.gl/4C3ot65njb7UHMkw5
  After:
• Printing fan shroud in shitty PETG - https://photos.app.goo.gl/MHW1buUSXjcr9uBu6
• Printing fan shroud in fresh dehydrated PLA using the shitty fan mount: https://photos.app.goo.gl/adq6ZPjeLS47jGB58

I figured out the issue. The cables I was using were crap. Replaced them with a higher quality cable (I bought these from amazon: https://www.amazon.com/dp/B07GD2PHX9?ref=ppx_yo2ov_dt_b_product_details&th=1) and it's working without issues with default sampling rate, resolution, and SPI clock frequency:

M955 P0
Accelerometer 0 type LIS3DH with orientation 50 samples at 1344Hz with 10-bit resolution, SPI frequency 2000000

@phaedrux I had the SDO and SDA pins reversed on the main board. I did a bit more testing and here are the list of symptoms:

1. When the printer is first powered on, the basic G-Code macro (which moves X from 0 to 50 and captures accelerometer data) works as expected
2. If I run a second macro to capture accelerometer data when moving Y from position 40 to 270 right after the X-move macro, then no data is collected.
3. If I physically restart the printer (power off and power on) and run the Y-move macro first followed by the X-move macro, then both macros capture accelerometer data
4. If I try to create an input shaping motion profile after step 3, the process (which first moves X from 75 to 225, centers the print head, and then moves Y from 75 to 225) only completes the X movement and I get an error message: "Error: M956: Failed to start accelerometer data collection: INT1 error"
5. If I physically restart the printer, home all axes, and go directly to the input shaping motion profile capture, it completes the X motion, and then stops partway through the Y motion capture, and the motors start to idle, with no error messages and the window on the screen still shows the following. Any macros executed after I cancel out of this step show that no data is being collected:
   

The definition of my accelerometer is as follows (in config-override.g):
; Accelerometer
M955 P0 C"spi.cs4+spi.cs3" I50 S1000 R10 Q2000000

The X-move macro:
G1 X-50
G4 S2
G1 X50 F20000
M400
M956 P0 S1000 A0

The Y-Move Macro:
G28 Y
G1 Y40
G4 S2
G1 Y270 F20000
M400
M956 P0 Y S1000 A0

The parameters for the input shaping motion profile capture are shown below:

I rechecked the connections and seemed to made a mistake with the wiring. However, now the accelerometer moves in the X direction when I start the input shaping motion profile, but doesn't do the Y motion. It stops, the motors go idle, and that's it. Even the basic accelerometer data gathering macro now says "Sample,X,Y,Z
Failed to collect data from accelerometer"

I have a Duet 2 Ethernet + Duex 5 on a CoreXY machine running RRF v 3.4.0. The LIS3DH accelerometer is mounted on the heat sink fan shroud with orientation 50 (Z facing -Y and X facing +X). I tested the accelerometer using a simple set of GCode commands (as outlined on the Duet3d Documentation site) and the CSV file captured the data with no issues. I then installed the input shaping plugin and followed the instructions on the Duet 3D Documentation website. However, when I went to create a motion profile, the connection to my printer is reset and the board basically restarts. I've added some screenshots showing what happens. Any ideas as to what the issue could be?

@phaedrux It does seem like an Ethernet controller problem. The SD card from the problem board works just fine on my spare Duet 2 Ethernet.

I tried resoldering the ethernet module pins to the board, but to no avail. When the board is first powered through USB, the module lights up. When I issue an M552 S0 to turn off networking, the module lights go out. When I enter M552 S1 to enable the network, the lights don't come back on. At this point I can't be certain if it's the main board or the ethernet module. Guess I'm going to have to switch it back to WiFi to confirm.

I will use my spare board in the meantime.

Thanks!

@phaedrux Yes, it lights up (Yellow light is solid and green light blinks randomly). I have a spare Duet 2 Ethernet and am testing with the SD card from the problem board into the spare board to see if the issue repeats itself.

I'm using a Duet2 Ethernet with a Duex5 Expansion board for one of my new builds and am having trouble with the ethernet connection. The configuration is set to acquire a dynamic IP, but it is not getting an IP assigned. I connected to the board through YAT and get the following message:

Network is enabled, configured IP address: 0.0.0.0, actual IP address: 0.0.0.0

I then issue an M552 S0 to turn off the network and restart it using command M552 S1, but the ethernet module doesn't seem to turn on. I have to disconnect and reconnect the USB for it to restart the ethernet module.

FYI - This is a Duet Wifi board that I converted to ethernet. During initial testing automatic IP assignment seemed to work fine, but after installation on the printer, I can't get it to work. I have restarted my router, even tried a manual IP assignment in the config file as well as on the DHCP list on my router, but to no avail.

When I assign a static IP in the config.g file and connect via USB on YAT, I get the following message repeatedly on my screen:

Network is enabled, configured IP address: 192.168.1.188, actual IP address: 192.168.1.188 (This message keeps repeating with no end).

Even with the message repeating, when I try to launch DWC, it doesn't connect. Any ideas as to what the issue may be? Do I need to format the SD, and rebuild the configuration files?

@owend quick question. I'm assuming move.axes(2) refers to motor driver 2 which is usually mapped to the Z axis. What if I have multiple independent Z (my printer has drives 5, 6, and 7 mapped to z on a Duex 5)? Can I use any one of those drive numbers?

@owend This is super cool! I didn't know RRF supported conditional GCode. Now I need to learn how to program in this language.

Thanks a bunch!

I was wondering if the microcontrollers on the Duet 2 or Duet 3 have enough memory so that the max Z height from the last print is stored in memory before the print is finished. This way, when a new print is started and the printer has to home on Z, it can recall that saved height and start from a potentially known position (not as an accurate height, but a starting point of reference to assist with homing). This can avoid overtravel since most homing moves require the Z axis to move away from the print head (usually 5 or 10 mm) and if the prior print used the printer's full Z capacity, then there would be no more Z travel left and it puts unnecessary strain on the motors.

If this value can be stored, is there a way it can be stored using ending G-Code?