RepRapFirmware 3.0 first official beta is out

kraegar

Updated, then had the thought to check M122. Once again it's showing I'm running 1.0.3.3 even though the pi reflects 1.0.3.5.

apt list 2>/dev/null | grep duet | awk -F'[/ ]' '{print $1" "$3 }'
duetcontrolserver 1.0.3.5
duetruntime 1.0.3.5
duetsd 1.0.2
duetsoftwareframework 1.0.3.5
duettools 1.0.3.5
duetwebcontrol 2.0.0-4
duetwebserver 1.1.0.0

=== Duet Control Server ===
Duet Control Server v1.0.3.3
Code buffer space: 2048
Configured SPI speed: 1000000 Hz
Full transfers per second: 220.03

I'll force the full update.

T3P3Tony

@kraegar stupid question but you are stopping the service and then restarting it?

kraegar

I did not stop the service manually when I updated. If that's in the instructions I apologize, I winged it since I recall you'd said you were adding stopping the services to the apt scripts.

kraegar

For clarification, I'm doing an sudo apt-get update; sudo apt get upgrade

Perhaps something odd is happening that's preventing it from upgrading for me?

kraegar

Just checked, doesn't look like that's in the instructions, so I didn't skip it

I can provide more info on my pi, but literally the only thing I've installed has been the duet software. I've left it completely "stock" other than that. It's a pi4 running the "lite" install of Buster.

gtj0

@kraegar This should do it...

sudo systemctl restart duetcontrolserver
sudo systemctl restart duetwebserver

T3P3Tony

yes its not in the instructions - fair one.

kraegar

@gtj0 Sure. But using apt-get that shouldn't be necessary. Upgrade scripts should stop services if required. I have no problem doing it manually, either.

kraegar

Very strangely reprinting the same file today as failed yesterday, while it's running and looks like it will complete, has plummeted in print quality. The only change at all was to update the duetsoftware framework on the pi. Same spool of filament, etc.

I'll test some other slices, but that was unexpected.

smoki3

Does it matter on RRF3 if I connect my Z Probe to Duet2Wifi or Duex5? I know on RRF2 there was a difference in the latency.

Is this still the same here?

kraegar

No changes other than updating the duet software and restarting the printer. The one from 1.0.3.3 on the right (that failed part way through), 1.0.3.5 on the left. I was tuning a new slicer (PrusaSlicer), so the first had some cooling issues, but the new one is something else entirely. I don't use pressure advance or firmware retracts, nothing like that.

smoki3

Seems there is a bug with the endstops on the duet2.

My Z probe (normal micro switch) is randomly not working.
On the one hand sometimes it is showing in DWC Z-Probe status 1000 even when then probe is not triggered. Without touching the printer I do a emergency stop than the probe status is 0.
On the other hand sometimes it is not detected if the probe is triggered and my printer is crashing.

The microswitch is connected to my duex5.

Its defined with this code:

; Z-Probe
M574 Z0 C"nil" 		                       ; no Z endstop switch, free up Z endstop input
M558 P5 C"!duex.e2stop" H3 F180 T25000 	       ; Z probe connected to Z endstop input
G31 X-14 Y0 Z0.00 P500          	       ; Set Z probe offset + naher ran - weiter weg
M557 X0:300 Y0:190 S50:47.5                    ; Define mesh grid

UPDATE: seems like it make a huge difference if I take the pins directly on the duet instead of the duex5.

smoki3

I also have another wire behavior with stall detection on my corexy machine with the duet2.

If I start homing the machine executes the homey.g (also happens for X axis) as it should. But the randomly I get the massage homing failed. But no crash or something else. Everything is as it should just the message homing failed and the axis is not marked es homes.

I tried so many stall parameters but I don't this it has something to do with this, because the stall is working fine and the home is done fine. Just the axis get not marked as home then I get homing failed.

Is there a way to debug?

dc42

The Homing Failed message means that the homing switch was not triggered before the move completed. If using stall detection, it means no stall was detected.

smoki3

@dc42 said in RepRapFirmware 3.0 first official beta is out:

The Homing Failed message means that the homing switch was not triggered before the move completed. If using stall detection, it means no stall was detected.

But it is detected because it move to the end position and then it do the rest of the script (move a bit away from the end position end so on). Otherwise the printer should crash normally because it have to go another 400mm if the stall is not detected

T3P3Tony

@kraegar please try 1.0.4.0 @chrishamm believes this is fixed

kraegar

@T3P3Tony Will do, thanks for the quick update @chrishamm!

kraegar

Looking much better so far!

smoki3

@dc42

As you can see here the drivers are detecting the stall very well.

https://photos.app.goo.gl/DMTiBbvibGsSs42Y7

But it looks like the signal get not processed correctly.

kraegar

Testing yesterday and today has so far shown 1.0.4.0 to be stable, and fixed the quality issue that cropped up in 1.0.3.5