Posts made by TheIndianDude

I have tried to manually update the DWC Files as mentioned in the guide by deleting the www folder from the SD Card and unzipping the DWC files from Github into a new www folder, but this has not helped.

I'm using a Duet 2 Wifi on the latest version of RRF (3.5.4), and for some reason, DWC just won't open on any browser on my PC or my phone (I've tried Chrome, Edge, Opera, and FireFox to no avail). The diagnostics show an IP address and I'm able to ping it with no issues, so I'm not sure what's going on. This has been an issue with earlier versions of RRF for me as well and only with the WiFi boards, which is why I've switched to using the Duet Ethernet on my other printers (When connected via ethernet, DWC opens without issues). However, I would like to get the WiFi connection working. M122, M39, and M552 results and a few other screenshots shown below:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.4 (2024-11-24 10:43:42) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DLM-996RU-N85S4-7JTD8-3SN6J-9V97R
Used output buffers: 1 of 26 (13 max)
=== RTOS ===
Static ram: 23488
Dynamic ram: 73720 of which 208 recycled
Never used RAM 16060, free system stack 186 words
Tasks: NETWORK(1,ready,13.1%,141) HEAT(3,nWait 5,0.0%,330) Move(4,nWait 5,0.0%,361) DUEX(5,nWait 5,0.0%,23) MAIN(1,running,86.9%,368) IDLE(0,ready,0.1%,29), total 100.0%
Owned mutexes: USB(MAIN)
=== Platform ===
Last reset 00:09:31 ago, cause: software
Last software reset at 2025-01-15 14:10, reason: User, Gcodes spinning, available RAM 12508, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 28.7, current 29.4, max 29.6
Supply voltage: min 1.6, current 1.8, max 1.9, under voltage events: 0, over voltage events: 0, power good: no
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 1 queued, 1 completed
Driver 0: ok, SG min n/a
Driver 1: ok, SG min n/a
Driver 2: ok, SG min n/a
Driver 3: ok, SG min n/a
Driver 4: ok, SG min n/a
Driver 5: ok, SG min n/a
Driver 6: ok, SG min n/a
Driver 7: ok, SG min n/a
Driver 8: ok, SG min n/a
Driver 9: ok, SG min n/a
Driver 10: 
Driver 11: 
Date/time: 1970-01-01 00:00:00
Cache data hit count 4294967295
Slowest loop: 7.15ms; fastest: 0.15ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 1.7ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is ready with "M122" in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Q0 segments left 0
Code queue 0 is empty
=== DueX ===
Read count 0, 0.00 reads/min
=== Network ===
Slowest loop: 21.24ms; fastest: 0.07ms
Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 0 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.2.0
MAC address e0:98:06:a4:5e:7c
Module reset reason: Turned on by main processor, Vcc 3.36, flash size 4194304, free heap 43844
WiFi IP address 192.168.1.166
Signal strength -48dBm, channel 1, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0
ok
M39
SD card in slot 0: capacity 3.98GB, partition size 3.98GB, free space 3.71GB, speed 20.00MBytes/sec, cluster size 64kB
ok
M552 S-1
WiFi module stopped
ok
M552 S0
ok
WiFi module started
M552 S1
ok
WiFi module is connected to access point BeastWifi, IP address 192.168.1.166

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?

@deckingman thanks for the info! This is certainly a step in the right direction for me. However, instead of an emergency stop when the max limits are triggered, I want the axis that triggered the max limit to just stop moving and continue with the rest of the Gcode. The only situation where this will be a concern for me is while homing the axes. So if Z max is triggered, the Z axis should stop, the printer should continue homing X and Y and then home Z. My X and Y axes don't have the issue of max limits being triggered because the frame is designed in a way that encapsulates the end of the linear rails for these axes and the carriage blocks cannot dislodge from them.

I'll look into the different trigger config options on the M581 command and experiment with them.

Thanks a bunch!

I am using a Duet 2 Wifi + Duex 5 on a CoreXY printer from SecKit Designs (The SecKit SK-Tank) and I noticed that the linear rail positioning and frame size make it so that carriage block reaches the end of the rail at the max range of the Z axis. Normally, I would program the max coordinates in RRF configuration to prevent the axes from going over, but when the printer is shut down and started up with the bed at a random position, the homing sequence moves the Z axis before homing the X and Y. This can cause the carriage blocks to dislodge from the rail if the Z axis is close to max position before the homing sequence starts.

In order to mitigate this, I was wondering if we could program and set up an endstop for Z max as well so that motion on the Z axis stops if the Z max end stop is triggered. I have extra endstop channels in the Duex 5, so was wondering how I would set up my config file for this.

Any help would be appreciated.

Thank you.

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!

@SupraGuy Hmmm....I do have HTP Stove paint...

@Phaedrux Thanks for the tips. I'm using the BuildTak flexplate with a black coating on the sheet steel, so I don't think it's related to transparency/translucency of the bed material, but the surface is rough (to enable better adhesion I suppose), so I will use a piece of matte paper to see if that changes anything.

My standard Z homing is based on the center (updated in homez.g and homeall.g to make sure probe is at bed center). I will move to the bed center and try tuning the trigger height.

My dive speed is set to 10mm/s. I'll try slowing it to half that (been meaning to do that anyway, so now's as good a time as any)

I like the idea of throwing out the outliers and taking an average or modal value.

Thanks for the tips! Will update the thread based on the results.

Hi,

I'm following the "Test and Calibrate a Z probe" tutorial on the Duet Wiki (https://duet3d.dozuki.com/Wiki/Test_and_calibrate_the_Z_probe) and I'm running into minor inconsistencies with the trigger height. The wiki says that after we bring the nozzle down to touch the build plate or just grab a piece of paper (I'm using a sheet of printer paper), to reset z to 0 (G92 Z0) , move z up 5 to 10 mm (G1 Z5) and run a G30 S-1 to get the trigger height and to repeat these series of steps 4 or 5 times.

I'm trying to get my Z trigger height near the bed 0,0 position (sensor is 5mm in from both X and Y edges) as I want to see the height map relative to the bed origin. After I get the nozzle to the right height, I send G92 Z0, move Z up 5mm, run the G30 S-1 and get a trigger height value. I then move Z down by the trigger height value to make sure it doesn't over travel and that there isn't excess pressure on the paper, re-zero Z, and repeat. The second time, the trigger height is completely different. Here are the values I'm getting:

1st try: Trigger height 0.855mm
2nd try: Trigger height 0.840mm
3rd try: Trigger height 0.837mm
4th try: Trigger height 0.848mm
5th try: Trigger height 0.795mm
6th try: Trigger height 0.822mm

Would these values be considered within margin of error for the IR probe? The website for the probe (https://miscsolutions.wordpress.com/mini-height-sensor-board/) states that the repeatability should be approximately 0.01mm, but I'm getting a variance between 0.003mm and 0.06mm which I think is a massive swing.

Any ideas how I can bring the numbers closer together? Also, what should I use as the trigger value? The last obtained trigger height?

@droftarts Honestly, Kapton on glass is pretty awesome since all you need is a bit of glue stick and stuff just sticks to it.