RepRapFirmware 3.0 first official beta is out

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

smoki3

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

@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.

If I put a G92 X"xx.xx" in the homing scipt than it is working as it should

stewwy

@wilriker , any chance I can look at your duet2 config files for RRF3, your machine is close to mine and I'm just getting ready to try RRF3?

wilriker

@stewwy Yeah, no problem. I can provide it to you tomorrow. But be warned the post I link to in my signature is a bit outdated.

kinta

This post is deleted!

stewwy

Hi, could someone look at these, from my config.g and see if they are correct for RRF3?

; Endstops
M574 X1 S1 P"xstop" ; X home to min.
M574 Y2 S0 P"ystop" ; Y home to max. N0pen micro-switches.
M574 Z1 S2 P"zprobe.in" ; Define Z to use DC42 irProbe. Home to Min.

;ZProbe
M558 P1 C"zprobe.in" H3 F600 T6000 X0 Y0 Z1 ; Set Z probe type/mode 1. Not using on XY, but using it on Z. F400 dive speed T6000 travel speed
G31 P500 X15 Y-2 Z1.46 ; Z probe trigger value, offset in relation to nozzle. And trigger height adjustment
M671 X-50:325 Y110:110 S0.5 ; Leadscrew positions for bed tramming

Thanks in advance

Edit: I should mention I am using 2 motors for Z