Has it been running stable now for long enough that you're sure it's related?
If you get the time out of whack on purpose, can you recreate the issue?
What firmware and DWC versions?
Has it been running stable now for long enough that you're sure it's related?
If you get the time out of whack on purpose, can you recreate the issue?
What firmware and DWC versions?
Please try configuring your Duet in Access point mode where the Duet creates a network SSID that you connect your device to.
https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m589-configure-access-point-parameters
This will help isolate whether the problem is with the Duet side or your routers side.
Can you test the BLTouch directly connected to the Duet? Reconfiguring the servo pin, etc.
@jonathanbrent can you convert it to an int instead of a string. They the files will be sequential, with the right number of seconds between names. Just not easily human readable without converting the int back to a datetime.
Being able to use datetime in a filename is a feature I would like as well. There is a feature request tracking something similar here:
https://github.com/Duet3D/RepRapFirmware/issues/787
@marioys97 set the error trigger level a bit higher to start with as well (E value in M569.1)
@o_lampe said in [3.4.6] Odd behaviour of rotary axis:
put M350 before M92, it uses the microstepping value to calculate the real steps per unit.
Are you saying that this does not work in 3.4.6?
For the OM field this was fixed recently:
The values of the fields of move.rotation in the object model were incorrect, typically zero even if G68 had been used
https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC
@usinjin running the calibration for multiple motors at the same time is on the feature request list:
https://github.com/Duet3D/RepRapFirmware/issues/758
Best regards
@Joel it is possible to redefine M208 in the homing macro before and after homing AFAIK. This is untested but basically:
Set M208 Y350 in config.g
In your homey.g.macro
See if that works
@CarlBosson there is no downside other than possibly slightly higher energy use to having the pump running constantly. Depending on the size of your reservoir, and the amount of heat you need to pull out the titan, along with ambient temp you may not need the fan, but once again it's not doing any harm really running constantly. (Possibly slight noise aside).
You can chuck a spare thermistor into the reservoir and monitor the temperature there if you fancy it and have a spare temperature input.
@BDPrinters if you have a free endstop and it's just the probe.in pin that's not functioning you can use the e1.stop for example.