RepRapFirmware 3.01-RC7 available
-
@Feb said in RepRapFirmware 3.01-RC7 available:
Updated to RC7 hoping this would fix my issue. Running 1 6HC (XY), 1 3HC (Z), and a tool board. The z probe has been moved from the toolboard directly to an IO on the 3HC hoping it would fix my issue. It seems as if I'm having a compounding z error when probing. Can slap this probe on any other printer and its fine, on this one it refuses to repetitively trigger the switch. You can hear the trigger of the switch become slightly fainter with each successive probe.
Its in SBC mode, I cant currently run standalone, there isnt a ethernet port anywhere near the printer
Youtube video of issue: https://www.youtube.com/watch?v=zmMMtDluAHQ
Config Below:
; Configuration file for Duet 3 - K2 Alpha Printer - Programmed by Feb ; General preferences G90 ; send absolute coordinates... M83 ; ...but relative extruder moves M550 P"k2printer1" ; set printer name ; Drives M569 P1.0 S0 ; Z1 (Front Left), physical drive 1.0 goes backwards (3HC, Expansion 1) M569 P1.1 S0 ; Z2 (Rear Left), physical drive 1.1 goes backwards (3HC, Expansion 1) M569 P1.2 S0 ; Z3 (Right Center), physical drive 1.2 goes backwards (3HC, Expansion 1) M569 P0.3 S1 ; X1, physical drive 0.3 goes forwards (6HC, Main Board) M569 P0.4 S0 ; X2, physical drive 0.4 goes backwards (6HC, Main Board) M569 P0.1 S0 ; Y1, physical drive 0.1 goes backwards (6HC, Main Board) M569 P0.2 S1 ; Y2, physical drive 0.2 goes forwards (6HC, Main Board) M569 P20.0 S1 ; E1, physical drive 20.1 goes forwards (Toolboard 1) M584 X0.3:0.4 ; X-axis, set drive mapping M584 Y0.1:0.2 ; Y-axis, set drive mapping M584 Z1.0:1.1:1.2 ; Z-axis, set drive mapping M584 E20.0 ; E-axis, set drive mapping ;Leadscrew locations M671 X-73.82:-73.82:476.58 Y-23.32:426.68:176.68 S10.0 ;Front left, Rear Left, Right S30.0 is the max correction - measure your own offsets, to the bolt for the yoke of each leadscrew M350 X16 Y16 Z16 E16 I1 ; configure microstepping with interpolation M92 X160.00 Y160.00 Z800.00 E830.00 ; set steps per mm M203 X18000.00 Y18000.00 Z1800.00 E3600.00 ; set maximum speeds (mm/min) M201 X3000.00 Y3000.00 Z150.00 E1500.00 ; set accelerations (mm/s^2) M566 X500.00 Y500.00 Z100.00 E1500.00 ; set maximum instantaneous speed changes (mm/min) M906 X1000 Y1000 Z1000 E800 I50 ; set motor currents (mA) and motor idle factor in per cent M84 S600 ; Set idle timeout ; Axis Limits M208 X0 Y0 Z0 S1 ; set axis minima M208 X360 Y360 Z300 S0 ; set axis maxima ; Endstops M574 X2 S1 P"io1.in" ;set X endstop connected to pin io1.in (6HC, Mainboard) active high, home to max M574 Y1 S1 P"io2.in" ;set Y endstop connected to pin io2.in (6HC, Mainboard) active high, home to min M574 Z1 S1 P"1.io1.in" ;set Z endstop connected to pin 1.io1.in (3HC, Expansion 1) active high, home to min ; Filament Out Switches M574 P2 C"1.io2.in" ;set filament out switch 1, connected to pin 1.io2.in (3HC, Expansion 1) active low M581 P"1.io2.in" S1 T1 C0 ;invoke trigger 1 when a rising edge is detected on the 1.io2.in (3HC, Expansion 1) ; Z-Probe M558 P8 H5 A5 F900 C"1.io3.in" T12000 ; Z probe connected to pin io0.in (Toolboard 1) M557 X30:320 Y30:320 S58 ; define mesh grid G31 X21.3 Y21.3 Z10 P1000 K0 ; define magnetic z probe offsets ; Bed Heater M308 S0 P"temp0" Y"thermistor" T100000 B4100 H0 L0 ; configure sensor 0 as thermistor on pin temp0 M950 H0 C"out1" T0 ; create bed heater output on out0 and map it to sensor 0 M143 H0 S120 ; set temperature limit for heater 0 to 120C M307 H0 A150.8 C1427.7 D0.6 V24.0 B0 S0.8 ; Heater 0 model: gain 150.8, time constant 1427.7, dead time 0.6, max PWM 0.60, calibration voltage 24.0, mode PID M140 H0 ; map heated bed to heater 0 ; Hotend Heater M308 S1 P"20.temp0" Y"thermistor" T100000 B4138 ; configure sensor 1 as thermistor on pin temp0 (Toolboard 1) - E3D Thermistor ;M308 S1 P"20.temp0" Y"thermistor" T100000 B3950 ; configure sensor 1 as thermistor on pin temp0 (Toolboard 1) - Beta 3950k M950 H1 C"20.out0" T1 ; create nozzle heater output on out0 (Toolboard 1) and map it to sensor 1 M143 H1 S340 ; set temperature limit for heater 1 to 340C M307 H1 A533.5 C198.5 D8.4 S1.00 V24.0 B0 ; disable bang-bang mode for heater and set PWM limit M570 S360 ; Hot end may be a little slow to heat up so allow it 180 seconds ; Part Cooling Fan M950 F0 C"20.out1" ; create fan 0 on pin out1 (Toolboard 1) M106 P0 S0 H-1 ; set fan 0 value. Thermostatic control is turned off ; Hotend Cooling Fan M950 F1 C"20.out2" ; create fan 1 on pin out2 (Toolboard 1) M106 P1 S0 H1 T65 ; set fan 1 value. Thermostatic control is turned on ; Electronics Cooling Fans M950 F2 C"out3" ; create fan 2 on pin out3 (6HC, Main Board) M106 P2 S255 H-1 ; set fan 2 value. Thermostatic control is turned off M950 F3 C"out4" ; create fan 3 on pin out4 (6HC, Main Board) M106 P3 S255 H-1 ; set fan 3 value. Thermostatic control is turned off ; Tools M563 P0 D0 H1 F0 ; define tool 0 G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C ; LED Lighting Control M950 P0 C"out2" ; assign pin out2 (6HC, Main Board) to GPIO 0 M564 H0 ; Allow Movement without Homing T0 ; select first hot end M302 P1 ; allow cold extrusionPlease explain what the "compounding problem" is and what you mean by "it refuses to repetitively trigger the switch", because I can't tell from your video. The only sound I can hear in the video is the sound of the Z axis moving. Please post the GCode you are running to demonstrate the problem, what should happen if everything is working as you expect it to, and what actually happens.
Also, please check using M115, M115 B1 and M115 B20 that all 3 boards really are running firmware 3.01-RC7.
I would not expect a Z probe to behave any differently when connected to the 3HC instead of a tool board, because both boards run very similar firmware, and in both cases the probe trigger signal arrives at the main board via the CAN bus.
-
@ChrisP said in RepRapFirmware 3.01-RC7 available:
I guess this is more of a feature request than a bug, but I've noticed that if using a Duet3 with SBC,it is possible that the system can sit in a potentially unsafe state while the SBC boots. I first noticed the issue when power cycling before the nozzle had fully cooled and therefore before the thermostatic fan on the heatsink had stopped. During this period between power up and DCS being fully started, the Duet sits there being dumb and not knowing that the fan should be on.
I realise that there's an argument for not resetting while thermostatic fans are on etc., but it's a thing I do relatively regularly on many of my Duet based systems running Duet2s etc and it's not an issues. Sometimes it's not by choice either if DCS crashes and the only way I have to hand to restart is a power cycle.
Therefore, would it be possible to implement a means of having an SD in the Duet3 too with just some very basic config so that this can be run immediately to initialise heaters/fans/guards etc., but then still wait to connect to the SBC?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?
Delta / Kossel printer fanatic
-
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...
thanks to @dc42 , @chrishamm
-
@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 S0and the probe is in fact triggered at the start of a probe. The mesh probe just stops and the console returns "ok". I ran theG29 S0from the Duet3 USB console to make sure. I forgot to capture the M122 but it showed no errors or abnormalities. -
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.)
-
@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 S0and the probe is in fact triggered at the start of a probe. The mesh probe just stops and the console returns "ok". I ran theG29 S0from 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 startedI then tried from YAT/USB:
g28 ok g29 s0 Error: Z probe already triggered before probing move started okHowever, 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.
-
@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.
-
@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.
-
@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.
-
@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 S0and the probe is in fact triggered at the start of a probe. The mesh probe just stops and the console returns "ok". I ran theG29 S0from 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.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@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 S0and the probe is in fact triggered at the start of a probe. The mesh probe just stops and the console returns "ok". I ran theG29 S0from 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.
-
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.
