@adalton5683 probably best to start a new thread with details of your full issue.

@dc42 gotcha, I wanted to make sure because I’m using about 3 feet of ribbon cable for the CAN signal. I was concerned that since it’s not twisted pair, it may cause problems. Seemed to print well. No lost packets over an 8 hour print.

B26145A6-58B0-4D8C-BBBD-AA3E2B52D0F8.jpeg

@peirof no, it's a probe. Either use the object model or the box top left on the DWC dashboard

Thank you for the tips.

I was finally able to locate the problem after days. It seems to be related to the "Cutting corners" function of the "SuperSlicer". I deactivated it and now the oscillations are back where they should be: approx. 46 Hz.
But now all screws are really, really tight 🙄

Now the

M593 p "zvd" F46 ; input shaping

is sufficient again.

I also lowered the instantaneous speed change and acceleration values a bit. Here is still missing some fine tuning.

@dc42 The shame was for my comment of "M558", I noted already "speeds" and did not see it so I asked here. 😞

4fc8bbe9-b0f4-4bb7-b30d-ce7f3b5061a5-image.png

Cheers, Chriss

@wayneosdias I'm sorry, my first suggestion should have been:

echo sensors.analog[0].lastReading

; homez.g ; called to home the Z axis ; do nothing if XY is not homed yet if !move.axes[0].homed || !move.axes[1].homed echo "XY are not homed yet. Aborting!" abort ;end if M98 P"/macros/magprobe_get_status.g" if global.magprobe_status = "docked" M98 P"/macros/goto_z_switch.g" ; Goes over the Z-Switch PIN !!!! CHECK COORDINATES CAREFULLY !!!! G30 K1 Z-99999 ; Probe the Z pin at the back G90 G1 Z10 F9000 elif global.magprobe_status = "attached" M98 P"/macros/magprobe_dock.g" M98 P"/macros/goto_z_switch.g" ; Goes over the Z-Switch PIN !!!! CHECK COORDINATES CAREFULLY !!!! G30 K1 Z-99999 ; Probe the Z pin at the back G90 G1 Z10 F9000 else echo "Magprobe-status not detected. Aborting!" abort

This is my homez.g... I mentioned G31 for a better understanding. I guess, the trigger point of the probe will be set to the z-parameter in G31. In my case to 0 or to an offset...

@owend thx

Can you send. M122 and share the results?

@queevix I'm glad you solved it. Some USB cables are intended for charging devices only, so they have the power wires but not the data wires.

So you have two duet wifi boards? One will connect, but the other won't?

Can you show a photo of the hotend so we can see the hot block configuration?

Have you tried tuning it as a tool with M303 T0 S240?

@peirof Maybe as this is in general discussions I can comment a bit.

Unless the driver chip itself was totally backwards compatible hardware wise It seems very unlikely even if you could manage do desolder and replace the chip itself.

I could only imagine the support situation if the Duet3D boards would support step sticks with not only different manufacturers Watterot, Fysetc, BTT etc but also all the different variants TMC2209, TMC5160 etc some using USART, others SPI and so on, that people would manage to insert.

@fcwilt yes

@phaedrux
Thanks for the 1st layer test, it worked wonderfully.

Screenshot_80.jpg

Where it says about a pg down
https://duet3d.dozuki.com/Wiki/Gcode#Section_Replies_from_the_RepRap_machine_to_the_host_computer

"On the latest version of Pronterface and Octoprint (1.2.0+) a special comment of the form:
// action:command
is allowed to be sent from the firmware, the command can currently be pause, resume or disconnect which will execute those commands on the host."

Is this referring to a release candidate or beta version?
I'm on the latest stable version and either I don't know how to trigger one or it is not in this version.

@mintytrebor Sure. flows.json

@phaedrux ok... Thx