@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