Duex5 Endstop Issue

fcwilt

@3DPrintingWorld said in Duex5 Endstop Issue:

Oh sorry I missed that somehow. I was running 3.2 but I had a lot of issues happen at around the time of install that I thought were related so I rolled back to 3.1.1 and recently completely erased and reinstalled 3.1.1.

Firmware 3.2.0 has some issues with endstop handling causing it to miss one on occasion.

Firmware 3.2.2 fixed that problem.

Frederick

3DPrintingWorld

@fcwilt Ok, I've had a few other issues as well when installing 3.2 but when I reverted the other issues are still there as well.

2/27/2021, 11:44:02 AM M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.1 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3SJ-6J1FA-3SN6J-1VYRG
Used output buffers: 3 of 24 (20 max)
=== RTOS ===
Static ram: 27980
Dynamic ram: 95828 of which 44 recycled
Exception stack ram used: 640
Never used ram: 6580
Tasks: NETWORK(ready,368) HEAT(blocked,1224) DUEX(suspended,160) MAIN(running,1640) IDLE(ready,80)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:46:17 ago, cause: software
Last software reset at 2021-02-27 10:57, reason: User, spinning module GCodes, available RAM 6660 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 38.5, current 39.8, max 40.3
Supply voltage: min 24.0, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/500
Driver 1: standstill, SG min/max 0/490
Driver 2: standstill, SG min/max 0/472
Driver 3: standstill, SG min/max 0/473
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max 0/429
Driver 6: standstill, SG min/max 0/428
Driver 7: standstill, SG min/max 0/397
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2021-02-27 11:44:01
Cache data hit count 4294967295
Slowest loop: 9.88ms; fastest: 0.13ms
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 4.5ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 163, MaxWait: 999248ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 75, completed moves: 75, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock 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 idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 140.13ms; fastest: 0.00ms
Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8

WiFi -
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 60:01:94:2e:09:23
WiFi Vcc 3.39, reset reason Unknown
WiFi flash size 4194304, free heap 20576
WiFi IP address 192.168.0.65
WiFi signal strength -62dBm, reconnections 0, sleep mode modem
Socket states: 0 4 0 0 0 0 0 0
=== DueX ===
Read count 1, 0.02 reads/min

fcwilt

Well the problem you describe was characteristic of firmware 3.2.0 - I never experienced it with 3.1.1 nor with 3.2.0.

I would suggest you upgrade to 3.2.2 and see if it makes a difference.

What is axis U used for?

Frederick

3DPrintingWorld

@fcwilt Its a IDEX so T1 is U axis and T0 is the X axis.

It homes X and U first then moves them away from the endstops. Next it homes Y to two different endstop switches to square up the gantry. There is a Y axis motor at each end of the gantry. If the U axis is not moved away from the endstop, while homing the Y it will pull the U axis towards the endstop because of the way the Dual markforged kinematics work.

It was hard to debug because it looked like a issue with the Y axis homing but it was actually the U axis, it just does not cause a Issue until it gets to the Y axis homing.

fcwilt

@3DPrintingWorld said in Duex5 Endstop Issue:
If the U axis is not moved away from the endstop, while homing the Y it will pull the U axis towards the endstop because of the way the Dual markforged kinematics work.

Well I don't know what sort of arrangement you have but having U axis motion as a "side effect" of homing Y does not sound right.

Can you post a diagram of the motion system as used on your printer?

Thanks.

Frederick

3DPrintingWorld

@fcwilt The Kinematics are correct, not really in question.

M669 K0 Y1:1:0:1.

Its a 0:1 or 1:0 arrangement depending on direction of travel of the Y axis.
MARKFORGED KINEMATICS.png

The issue is the U axis is not stopping at the endstop correctly when connected to the duex5. I dont think the type of kinematics plays a role. Perhaps I gave TMI.

Phaedrux

@3DPrintingWorld said in Duex5 Endstop Issue:

M350 X16 U16 Y16 Z16 E16:16 I1 ; configure microstepping with interpolation M92 X100.00 U100.00 Y100.00:100.00 Z1096 E415.00:655.00 ; set steps per mm (1760nimble) M566 X1000.00 U1000.00 Y1000.00:1000.00 Z100.00 E100.00:300.00 ; set maximum instantaneous speed changes (mm/min)(Nimble 40) M203 X12000.00 U12000.00 Y12000.00:12000.00 Z2000.00 E4200.00:4200.00 ; set maximum speeds (mm/min) M201 X800.00 U800.00 Y800.00:800.00 Z100.00 E600.00:600.00 ; set accelerations (mm/s^2)(500)(Nimble 120) M906 X700 U700 Y700:700 Z200:200:200 E600:600 I30 ; set motor currents (mA) and motor idle factor in per cent(Nimble 500) M84 S30

You only need singular values for linear axis in M350, M566, M201, M203, M906, etc. It's only extruders that require those values to be defined per drive. Once the driver has been assigned to an axis, you only need to define the settings per axis.

3.2.2 did fix some issues with endstops triggering very close together. So updating to 3.2.2 would be a good thing to test.

Also something to keep in mind with the duex is that it's usually a good idea to try and keep the Z axis motors and endstops together on the same board, probably the main board. So in your case you could have Y and Z on the mainboard and X U E on the duex. That may help avoid any timing issues.

This may also help with your other thread on independent Z leveling.

3DPrintingWorld

@Phaedrux said in Duex5 Endstop Issue:

You only need singular values for linear axis in M350, M566, M201, M203, M906, etc

This was pointed out in in the last thread. I made some large changes in experimentation and I must have reverted back to multiple values. I'll change it back but I have already confirmed that it will not have an effect. I'm assuming it defaults to the first value given.

It does seem like a good idea to put the endstops on the same board as the driver, but I was just trying to keep the X, Y, and U drivers on the same board. If that does not matter, I will move the U axis stepper and endstop back to the WIFI and then move both Y axis motors and endstops to the deux5.

Can you confirm that its ok to split drivers that work in conjunction to together on different boards? I would like to move the filament runout sensors to the deux5 but the documentation says it will not work. If its not suggested, then dual filament sensors would not be supported with my setup as I don't see a way around it.

I guess I will try 3.2.2 to see what happens.

Phaedrux

@3DPrintingWorld said in Duex5 Endstop Issue:

Can you confirm that its ok to split drivers that work in conjunction to together on different boards?

Better to split X Y U than to split the drivers between a single axis, no?

Personally I would use the probe for leveling and abandon multiple endstops entirely.

3DPrintingWorld

@Phaedrux I am only using the probe to level Z. The other stepper motors each have a endstop; X, U, Y(left), Y(right). Four in total. I do use two endstops for the Y, that is required to square the gantry to the frame.

I have considered sensorless homing for the Y, which would free up to two spots on the WIFI. Another user in our group has had good luck with it.

Phaedrux

Ah yes, sorry, for some reason I took your other thread about independent z leveling as the reason you were wanting to use multiple endstops.

Sensorless homing may be a good option. It might take some tuning though.

martin7404

Something that just came to me.
I think a year ago during setting duex5 with my dual lifting extruder experiment in the documentation was stated to take power for the duex from the duetwifi terminal , not directly from PSU. I forgot about that when wiring Muldex and the power for duex comes from PSU, i think others did the same as far the wiring on the github scheme is like that. I wonder if that could be the reason. I do not belive so.link text

The only reason for some troubles could be having bad GND conection between 2 boards

fcwilt

@martin7404

Hi,

This is how I connect power to Duet 2/Duex combos.

Duet WiFi Power Wiring.jpg

The two wires connecting the boards are solid, the two wires from the power supply are stranded.

The goal was to keep the length of wire from each board to the power supply the same so both boards see the same voltage.

Frederick

NexxCat

I had a very similar issue when building my IDEX printer. I seem to remember finding information from @dc42 that the end-stops on the Duex2/5 were polled differently from those on the main Duet2 board. I just moved mine back to the main board and the issue went away.

The issue I had was caused by the end-stop status not changing correctly or becoming stuck as triggered when it wasn't. This caused failed homing on the U axis, or failure to do a second more precise homing move after the coarse one. I verified that it was the Duex by manually triggering the end-stop and monitoring its status in DWC, where you could see it sticking. As soon as I moved it to the Duet2, it worked flawlessly.

martin7404

So with Muldex that can sol e the U problem, but with 3 Z motors on duex and Bltouch on duetwifi?

3DPrintingWorld

@martin7404 Good catch! I remember seeing that too, but I must have spaced it when I did the wiring. The wires are about 100mm long so it might be ok but I'll change it anyways.

3DPrintingWorld

@NexxCat This sounds like the issue. I updated to 3.2.2 and homed it maybe 10 times and no problem so far but it can be intermittent. I test it some more today.

I would move it back to the WIFI but I was hoping to use two filament runout sensors so I don't have the room on the board for both if I do.

3DPrintingWorld

@martin7404 said in Duex5 Endstop Issue:

So with Muldex that can sol e the U problem, but with 3 Z motors on duex and Bltouch on duetwifi?

I did try moving all three z axis motors to the wifi but my leveling was the same.

fcwilt

@3DPrintingWorld said in Duex5 Endstop Issue:

@martin7404 said in Duex5 Endstop Issue:

So with Muldex that can sol e the U problem, but with 3 Z motors on duex and Bltouch on duetwifi?

I did try moving all three z axis motors to the wifi but my leveling was the same.

Then what ever issue you are having is very likely related to the endstop sensors and/or the wiring.

I have my 3 Z steppers and Z endstop sensors connected to my Duex5 and they all work without problem now that I am running firmware 3.2.2.

Frederick

3DPrintingWorld

I have not seen this issue repeat since installing 3.2.2. Despite it being bad practice to have the endstop on a different board then the stepper. I will keep a eye on this should nozzle alignments not stay consistent as I often do multi material printing. The end goal is to move the y-axis to senseless homing which will make also room on the mainboard for the remaining endstop.