Topics created by too

@cncmodeller That's a good tip, I have actually resorted to something similar!
I created a "M2001.g" file in the sys folder and added a M2001 command on each layer change...

The issue is that I am using a custom slicer that I can't easily change myself and that doesn't have this capability (that at least adds ";LAYER: ##" markers at the beginning of a new layer). I was hoping to not have to manually change the gcode file, but thank god for the "change all occurrences" function in VSCode 🙂

@too said in Z probe Trigger value has no effect:

M558 P5 C"^io4.in" F1500 T12000

You're calling the full M558 line here in homez. I'm not sure, but I think this may be resetting your g31 to default values. If you only want to have two speeds for the G30 it would be easier to simply use two values for F in your M558 in config.g.

Ex: M558 P5 C"^io4.in" F1500:120 T12000

Otherwise, if you just want to alter a value in M558, just call it with the parameter you want to change.

Ex M558 F1500

The other thing that I notice is that your Z motors appear to be spread across the mainboard and expansion.

M584 X0.3 Y0.4 Z0.0:0.1:0.2:1.1

This may run into a limitation in RRF and it would be better to have all Z axis motors on the mainboard where the z probe connects.

https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations#Section_Temporary_limitations

Due to CAN latency the motors connected to expansion boards may slightly overshoot the position at which the endstop or Z probe was triggered. This would not usually matter for an endstop switch, but it does mean that if the Z motor(s) is/are connected to an expansion board then repeated probing with a Z probe (e.g. for mesh bed compensation) is not advisable. This will be fixed in a future release

@too I'm sorry this has taken so long to resolve and I am glad you found a workaround. I am implementing a fix for M571 when the extruder is driven from a CAN-connected board in RRF 3.5beta2.

hi @Kulitorum @too I have had a look at the gcode and config and done some calculations on max step rate. the values are quite reasonable so surprised you are seeing hiccups. It would be good to discuss in person further, I will email you tomorrow morning.

In the mean time, at what point in the print are you seeing the weird outputs? Also do you see that with RRF 3.2?

@droftarts thanks for the tip!

Yes, the boards work fine. I can control the axes that are connected to the individual boards even with this error coming up.

I did in fact not have any termination resistor in the boards - I added them on the last one and would you look at that, the error is gone, thanks!

@jay_s_uk okay thank you

@Danal said in RRF3 / Duet3 with Pi: execute bash through M code:

@dc42 said in RRF3 / Duet3 with Pi: execute bash through M code:

It would be perfectly possible (and probably straightforward) to take a Telnet client and have it talk to the API provided by DSF. But Telnet is horribly insecure, so it would be much better to implement SSH or another secure alternative.

Completely agreed. But there it is on D2. Hmm....

And it's disabled by default. And we tell users not to make a Duet accessible to the Internet without using a VPN.

Thanks, I'll fix it in the next DSF version. If you encounter more issues with DSF, please report them at GitHub.

@too said in M28 not working in RRF3:

@dc42 did you get any further on the DSF M28 issue?

I'm waiting for @chrishamm to look into it.

M32 will be fixed for this use case in the next DSF version.

Thanks, that does indeed look like it could help. I'll try that!

@too, please test again with release 3.0 stable.