@Phaedrux
Homeall.g

G91 G1 H2 Z2 F100 G1 H1 X-300 Y-300 F600 G1 H2 X5 Y5 F1000 G1 H1 X-300 Y-300 F200 G1 H2 Z-5 F100 G1 H1 Z304.1 F300 G1 H2 Z-2 F100 G1 H1 Z304.1 F100 G92 X0 Y0 G90 G92 Z304.1

homex.g

G91 G1 H2 Z2 F100 G1 H1 X-300 F600 G1 H2 X5 F600 G1 H1 X-300 F200 G1 H2 Z-2 F100 G92 X0 G90

homey.g

G91 G1 H2 Z2 F100 G1 H1 Y-300 F600 G1 H2 Y5 F600 G1 H1 Y-300 F200 G1 H2 Z-2 F100 G92 Y0 G90

homez.g

G91 G1 H2 Z2 F300 G1 H1 Z304.1 F360 G1 H2 Z-5 F240 G1 H1 Z304.1 F200 G90 G92 Z304.1

config.g

M552 S1 ;M552 S-1 M586 P0 S1 M586 P1 S0 M586 P2 S0 ; Drives M569 P0 S1 M569 P1 S1 M569 P2 S1 M569 P3 S1 M569 P4 S1 M569 P5 S1 M584 X0 Y1 Z2:3:4 E5 M350 X32 Y32 I0 M350 Z16 E16 I1 M92 X160.0 Y160.0 Z2133.33 E932.00 ;change as per machine M566 X720.00 Y720.00 Z300.00 E600.00 M203 X8400.00 Y8400.00 Z420.00 E8400.00 M201 X3000.00 Y3000.00 Z30.00 E250.00 ;M-curr M906 X1600 Y1600 Z1600 E800 I50 M84 S30 ; Axis Limits M208 X0 Y0 Z0 S1 M208 X300 Y300 Z304.1 S0 ; filament Sensor M591 D0 P7 C"exp.e3stop" R15:300 L7 E17 S1 ; Endstops M574 X1 S1 P"xstop" M574 Y1 S1 P"ystop" M574 Z1 S1 P"zstop+e0_stop+e1_stop" ; Z-Probe M950 S0 C"exp.heater3" M558 P9 C"^zprobe.in" H5 F120 T6000 G31 P500 X0 Y0 Z1.038 ; Auto level, coordinates as per motor order in M584 M671 X-17.66:297.34:140.00 Y-5.00:-5.00:327.61 S5.0 F1.2 ; define mesh grid M557 X30:300 Y30:300 S20 M376 H5 ; End Limits M950 J1 C"exp.e4stop" M581 P1 T2 R0 S1 M582 T2 M581 P-1 T2 M581 P1 T0 R0 S1 ;PA M572 D0 S0.045 ; Bed Heater M308 S0 P"bedtemp" Y"thermistor" T100000 B4138 M950 H0 C"bedheat" T0 M307 H0 B0 S1.00 M140 H0 M143 H0 S105 ; Extuder Heater M308 S1 P"e0temp" Y"pt1000" M950 H1 C"e0heat" T1 M307 H1 B0 S1.00 M143 H1 S320 ; cooling Fans M950 F0 C"fan0" Q500 M106 P0 S0 H-1 M950 F1 C"fan1" Q500 M106 P1 S0 H-1 ; Tools M563 P0 D0 H1 F0 G10 P0 X0 Y0 Z0 G10 P0 R0 S0 M575 P1 S1 B57600 M501 M911 S21 R22.5 P"M913 X0 Y0 G91 M83 G1 Z5 E-5 F1000" M929 S3 P"/macros/SERVICE/log/STPL_DEBUG.txt"

@flopo76 I have recently built the Mercury One zeroG Hydra 1.1 conversion of an Ender 5. I have RPI driving Duet mini 5+ and a HUVUD tool board running CAN from duet USB-Can bridge.

Everything has flashed fine but I am having intermittent issues. When I try to move the bed in large movement all three Z stepper get way out of sync. I am wondering if the USB speed from RPI to Duet is limited and causing communication issues. I really want to use this board but it has been one headache after another.

@droftarts

OK thanks for your reply

Hi, I'm having the same problem, except I'm stuck in a reconnecting / /connected / disconnected loop. Refreshing or closing firefox , and deleting all sites data , doesn't work.
It happens after a somehow long operating time (~ 2 weeks)

Irecently upgraded everything to 3.5.3

@oliof We are mixing absolute and relative mode, as we produce a set of identic representations. So, for start of each representation we set the position absolute, but for producing the representation we switch to relative mode.

@MartinMV

a) probably best to keep to your own thread rather than re-opening three year old ones.
b) check the new docs site at https://docs.duet3d.com/en/User_manual/Troubleshooting/Duet_wont_respond

(Bonus tip, dont hit enter on the search bar there if you type search terms)

Have you tried the 3.6 beta release?

@Phaedrux
okay
Thank you

Running 3.6 beta5+1 and the normal test_A_wrap_closed.g, test_A_nowrap_closed.g I got these results:
36.png
I'm now just trying to find a middle ground speed/acceleration combo where the missed steps do not occur, yet isn't prohibitively slow. @dc42 Any ideas on a semi-sealed, magnet-style closed loop motor? Maybe some existing product I could retrofit the duet3d encoder to?

Best,
T

@R006 said in Duet3MB6HC with Duet3 scanning Z probe:

M558 P11 C"41.EXP1XD" F36000 T36000

This is incorrect. The SZP is a completely separate CAN board from the 1XD, so the C parameter should reference the SZP directly, not the 1XD. Your C parameter isn't even a real pin. The SZP should show up in the list of CAN boards in DWC > Settings > Machine-specific. Please show how you have wired it.

If you have another probe, eg BLTouch, you need to specify the SZP as another probe with the K parameter. So it should look like the documentation https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Duet_3_Scanning_Z_Probe#scanning-z-probe ie:

M558 K1 P11 C"120.i2c.ldc1612" F36000 T36000

Ian

@dc42
Okay,
but why print is paused after that information?

microsteps M350 X8 Y8 Z16 E16:16 I1

@R006 I would say first update the firmware from 3.5.2RC1 to the full release version of 3.5.2 There has been a lot of bug fixes since RC1

Fixed it . It was 2 years old SD card. Good quality card. Formated a new one and created new structure witht the current firmware and config. back to printing

@droftarts
Thanks for the hint with the H3
It was in the toolchange macro and probably a heatertuning with a M500 at the end brought it do the override...

Thanks a lot!

@dc42 On 3.5.2 I'm noticing some different behavior.
This time when the user presses pause while the move_x_macro.g is running, the x axis stops at X=300 and the machine enters a paused state. The macro does not seem to restart upon resuming.
The final line of the macro is G0 X400 which indicates the last movement command is being skipped? I tried adding a G0 X0 to the end of the macro and repeating with the pause, which made the machine stop at X=400. Repeating the G0 X0 did not help either.

EDIT:
I tried adding M400 or G4 P1 at the end of the file as workarounds for the last command issue, but this made the restart issue re-emerge.
Can provide logs again if need be.

Thanks,
T

@R006 it looks to me that you have a very old branch or version of WiFiSocketServerRTOS in your workspace. This is what mine looks like in Eclipse:

bc065b83-432b-45c2-b0e9-530ec4aea22b-image.png

The contents of MessageFormats.h in that project should be the same as at https://github.com/Duet3D/WiFiSocketServerRTOS/blob/main/src/include/MessageFormats.h.

@droftarts
I had never heard of such surges occurring at installation sites, so it was unexpected.
I plan to replace all the tool boards I use.

I think the firmware version of the 1LC was 3.4.4.
1LC should not have had 3.4.5.
sorry. I can't confirm it right away because I don't have the equipment at hand.

I think additional surge protection should be added to the AC circuit.
Is a protective component like a varistor necessary on the DC side as well?

@jay_s_uk Yup i'm aware. I've got a 1LC on the toolhead that i can connect a filament sensor to if i reeeally want one 😅

@gloomyandy

20240424_144735.jpg

Capture_gcode.PNG

also i am try to simulate same Gcode with RRF 3.5.0 rc4 in that only one gcode give the bad command error (2 time simulated and giving two different error which is attached in image)

20240425_105145.jpg 20240425_105222.jpg

also attached Gcode SS

Capture_gcode_1.PNG