RepRapFirmware 3.01-RC7 available

tobias_munich

I made 2 print with 5 hours print time each, with the SBC connected.

the system is updated to the RC7 and the new DSF Framework, DWC

the system runs stable, no reconnects anymore.

looks good so far for me.

have to test some macros and other topics were i had issues...

gtj0

@dc42 I'm pretty sure this is an RRF issue and not DSF... I'm not getting the "Probe triggered at start of move" error message when running G29 S0 and the probe is in fact triggered at the start of a probe. The mesh probe just stops and the console returns "ok". I ran the G29 S0 from the Duet3 USB console to make sure. I forgot to capture the M122 but it showed no errors or abnormalities.

garyd9

Sometimes I watch my printer running and I just need to post a quick message to those involved in the development of RRF3 to say 'thank you.'

I don't think people can possibly realize everything that RRF3 does. The end result of a properly configured printer is just "magic."

(RC7 is working well for me on my delta with a standalone duet3.)

dc42

@gtj0 said in RepRapFirmware 3.01-RC7 available:

@dc42 I'm pretty sure this is an RRF issue and not DSF... I'm not getting the "Probe triggered at start of move" error message when running G29 S0 and the probe is in fact triggered at the start of a probe. The mesh probe just stops and the console returns "ok". I ran the G29 S0 from the Duet3 USB console to make sure. I forgot to capture the M122 but it showed no errors or abnormalities.

I'm sorry, I can't reproduce that. I inverted the Z probe input pin so that it was triggered at the very start, and ran G29 from DWC:

16/04/2020, 10:24:45 	g29
Error: Z probe already triggered before probing move started

I then tried from YAT/USB:

g28
ok
g29 s0
Error: Z probe already triggered before probing move started
ok

However, the code for handling this error changed in RC7, so there could well be a new issue. Are you doing anything differently? Does your probe use deploy/retract files?

EDIT: I just retested with deployprobe.g and retractprobe.g files present, and I have reproduced the problem.

ChrisP

@Danal said in RepRapFirmware 3.01-RC7 available:

For me, running a D3+Pi, this takes <25 seconds. For example, if I power cycle while everything is up and running, from the moment I hit power on to the moment the thermostatic fans kick in is less than 25. In fact, it is closer to 20.

How long does this take on your system?

So for me with a D3 and Pi4 it takes just over 24 seconds each time, which I appreciate isn't an age, but it's still not ideal.

Danal

@ChrisP said in RepRapFirmware 3.01-RC7 available:

@Danal said in RepRapFirmware 3.01-RC7 available:

For me, running a D3+Pi, this takes <25 seconds. For example, if I power cycle while everything is up and running, from the moment I hit power on to the moment the thermostatic fans kick in is less than 25. In fact, it is closer to 20.

How long does this take on your system?

So for me with a D3 and Pi4 it takes just over 24 seconds each time, which I appreciate isn't an age, but it's still not ideal.

Yeah, this is very much a judgement call on where to spend resources. A stand-alone board gets from power on to fans on in about 8 seconds, (not counting the little blip right at boot). So, collapsing out somewhere under 20 seconds, as vs some number of development hours (that I think are larger, not smaller, when I think about all the edge cases)... very much a judgement call.

ChrisP

@Danal said in RepRapFirmware 3.01-RC7 available:

@ChrisP said in RepRapFirmware 3.01-RC7 available:

@Danal said in RepRapFirmware 3.01-RC7 available:

For me, running a D3+Pi, this takes <25 seconds. For example, if I power cycle while everything is up and running, from the moment I hit power on to the moment the thermostatic fans kick in is less than 25. In fact, it is closer to 20.

How long does this take on your system?

So for me with a D3 and Pi4 it takes just over 24 seconds each time, which I appreciate isn't an age, but it's still not ideal.

Yeah, this is very much a judgement call on where to spend resources. A stand-alone board gets from power on to fans on in about 8 seconds, (not counting the little blip right at boot). So, collapsing out somewhere under 20 seconds, as vs some number of development hours (that I think are larger, not smaller, when I think about all the edge cases)... very much a judgement call.

Oh yeh, I 100% agree that there are bigger/more important issues and features to implement and fix first. However, I run a system where this delay is borderline unacceptable and in standalone on a D2, D3 or even the older boards, the fans start pretty much instantaneously. I'll admit I haven't time it (though I'm very tempted now.haha) but my gut feeling is that it 2 seconds or less.

Anyway, as I said initially, I'd like it to be added as a feature request if possible, because I can't imagine that one should be that hard to implement, but yeh the focus should be on other more important features first.

dc42

@gtj0 said in RepRapFirmware 3.01-RC7 available:

@dc42 I'm pretty sure this is an RRF issue and not DSF... I'm not getting the "Probe triggered at start of move" error message when running G29 S0 and the probe is in fact triggered at the start of a probe. The mesh probe just stops and the console returns "ok". I ran the G29 S0 from the Duet3 USB console to make sure. I forgot to capture the M122 but it showed no errors or abnormalities.

This is now fixed in the 3.01 source code and in the firmware binaries at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

gtj0

@dc42 said in RepRapFirmware 3.01-RC7 available:

@gtj0 said in RepRapFirmware 3.01-RC7 available:

@dc42 I'm pretty sure this is an RRF issue and not DSF... I'm not getting the "Probe triggered at start of move" error message when running G29 S0 and the probe is in fact triggered at the start of a probe. The mesh probe just stops and the console returns "ok". I ran the G29 S0 from the Duet3 USB console to make sure. I forgot to capture the M122 but it showed no errors or abnormalities.

This is now fixed in the 3.01 source code and in the firmware binaries at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

Fixed in RRF but not properly propagating through DCS. Will open new issue for that.

DaBit

I am quite happy with this DWC 2.1.2 + RRF 3.01-RC7 combo.

DWC somehow feels more responsive, and my phone loads DWC without issues now. It often happened that the loading of DWC froze with the 'blue bar' halfway, and I had to reload a few times.