Firmware 2.02 Release candidate 3 now available

kuhnikuehnast

@dc42 said in Firmware 2.02 Release candidate 3 now available:

@kuhnikuehnast said in Firmware 2.02 Release candidate 3 now available:
@dc42 said in Firmware 2.02 Release candidate 3 now available:

@kuhnikuehnast said in Firmware 2.02 Release candidate 3 now available:

About the strange notice that a motor not seems to be connected properly... As I did some tests yesterday, the message only popped up during the G32 command...? Maybe this could be a hint to find a possible problem / solution?

Did you get this message when running 2.02RC3, or only with 2.02RC2 ? You don't appear to have mentioned it before in this thread.

oh, sorry. I got on RC2 as a "red window- alert". On RC3 I now get a "yellow window" that disappears after a few seconds:
Warning: motor phase A may be disconnected reported by driver(s) 0
Warning: motor phase B may be disconnected reported by driver(s) 0
But the print and anything else works fine...?
Thanks.

Is this on a Duet WiFi, Ethernet, or Maestro?

Are you able to identify which command in your bed.g file provokes it?

Is driver 0 driving the X motor as usual, or have you used M584 to re-map another axis or extruder to driver 0?

What current do you have that motor set to?

It is a Duet Wifi (1.03), it is the X motor, current is set to 800 (same motor as on y). I just tried to figure out what exactly is causing the message but it is really strange! It only pops up sometimes. But if, then it almost always pops up if I start a print. Then after the G32 command and somewhere around the G29. If I don't print, I can move all axis, home all axis etc... (I can even execute my S3D- start-script...?)
As slicer I use S3D, here is the start-script:

G21 		; metric values
G90 		; absolute positioning
M82 		; set extruder to absolute mode
G28 		; home axis
G32 		; auto bed compensation
; G28 Z		; home z
M98 PClean_Nozzle.g 	;
G29 		; mesh bed levelling
M98 PClean_Nozzle.g 	;
G92 E0 		; zero the extruded length
G1 X20.0 Y20.0 Z0.2 F7800 	; start point for starting line
G1 X140.0 Y20.0 E10 F800 	; extrude 8mm filament along 110mm movement in x
G1 X150.0 Y20.0 Z0 F7800 	; separation move Z0 to keep up nozzle preasure
G92 E0 		; zero the extruded length again

and here the Clean_Nozzle.g file:

; go to start point
G0 X225 Y68 Z10 F9000		; Z not yet to prevent crash
M564 S0				; allow negative Z-value
G0 Z4.5				; start point reached

G91 				; relative positioning

; start X0 Y0 front left

G0 X15  Y13 F6000 		; 1. move
G0 X-15 Y14 F6000 		; 2. move
G0 X15  Y13 F6000 		; 3. move
G0 X-15 Y0 F7000 		; end back left

M564 S1				; denie negative Z
G1 Z5				; lift Z at the end
G90				; absolute positioning

dc42

Perhaps it's the nozzle cleaning script? Can you try running it a few times?

You can ignore the message, because the firmware doesn't do anything apart form warn you when the drivers report open circuit motors - but obviously it's annoying.

paulowisk

@k3lag uncheck "always show info area and main menu" option in user interface in DWC.

k3lag

@paulowisk said in Firmware 2.02 Release candidate 3 now available:

@k3lag uncheck "always show info area and main menu" option in user interface in DWC.

Problem was stray '.' at end of the URL for my printer. I finally found the stray '.', it was in bookmark for the printer. Not sure how it got there but problem solved.

3DOeste

@dc42 Hi, it turns out I had an M558 on both my homeall and homez. I simply add the correct values at the end of the macro and problem solved.

One thing I noticed by accident is that the bed levelling, after homing all axes, crush in Y. Since I never used it, the coordinates are wrong, but anyway is it normal to go beyond the limits established?

dc42

@3doeste said in Firmware 2.02 Release candidate 3 now available:

One thing I noticed by accident is that the bed levelling, after homing all axes, crush in Y. Since I never used it, the coordinates are wrong, but anyway is it normal to go beyond the limits established?

The firmware intentionally allows you to use G30 commands that probe beyond the normal bed limits, because there are situations in which this is desirable.

garyd9

I had another freeze with M600 last night. Same filament-change.g file as posted earlier, same symptoms. I don't know if the problem is something in my .g file or if M600 (which is new in this RC) has an issue. So far, M600 has worked 0 of 2 attempts. I've quoted my previous message on the issue below:

@garyd9 said in Firmware 2.02 Release candidate 3 now available:

Are there any restrictions on the commands usable in M600 macro? (filament-change.g ) I tried it tonight and when it hit the M600 macro, everything froze. The macro contained the following commands:

M83
G1 E-4 F2500
G91
G1 Z20 F5000
G90
G1 X0 Y85 F5000
M291 P"Change Filament"
M300 P5000

None of the moves in the filament-change.g were run as far as I could tell. It appeared to just freeze when it hit the M600. The paneldue and DWC showed a paused state, but the movement buttons and resume buttons (on both UI's) didn't do anything. The only thing I was able to do was "emergency stop" (which did work.)

dc42

I confirm that there is a problem with M600 in the 2.02RC firmware. I will fix it in 2.02RC4.

zerspaner_gerd

M116 now accepts an optional S parameter to specify the acceptable temperature difference

Thank you for the implementation!
Is working!

Veti

I just set up my new Maestro

Firmware Name: RepRapFirmware for Duet 2 Maestro
Firmware Electronics: Duet Maestro 1.0
Firmware Version: 2.02RC3(RTOS) (2018-10-17b2)
Web Interface Version: 1.22.4-b1

Everything works nicely except the 12864 LCD.

I need to press reset on the Display for it to display something. On initial boot it shows nothing.
But the display text is garbled:

This is my menu.
text R1 C1 F0 T"CoreXY"
text R15 C1 F0 T"Bed temp "
value N180 W30
text T" actual "
value N80 W30
text R30 C1 F0 T"E temp "
value N200 W30
text T" actual "
value N100 W30

Veti

also i just noticed the firmware configurator does not produce the M350 line for maestro.

dc42

Most 12864 displays reset automatically when they are powered up, but it looks like your display doesn't, or takes too long. You could try having just a single button on the mein menu, that loads the real menu you want, then press the encoder to get that menu.

For 2.02RC4 I will look at making the M918 command reset the display, if it doesn't already. That would give you the opportunity to use a G4 delay command in config.g before the M918 command, to give your display extra time to be ready.

tjb1

Now that 12864 support is in the firmware does that mean it will work on a Duet WIFI/Ethernet?

Veti

@tjb1 said in Firmware 2.02 Release candidate 3 now available:

Now that 12864 support is in the firmware does that mean it will work on a Duet WIFI/Ethernet?

no. the duet wifi/ethernet does not have the communication ics required for the communication.

frafa

Hi David,

I test firmware 2.02RC3 on my Scara and DuetWifi
I do not have a Z end stop just your IR Probe
and G28 error on G30
G30 S-1
G30 P0 X0 Y0 Z-99999

Return:
G28
Error: Z probe was not triggered during probing move
Error: G0/G1: insufficient axes homed

My homeall.g (ok on 1.21RC3):

M18 ; Disable all stepper motors (pour desactiver le second bras IMPORTANT !)
G91 ; relative movement
G1 S2 Z4 F250 ; ensure head is clear of the bed

;Move by security to the case or already home !
G1 S2 X10
G1 S2 Y-10

; Home proximal joint
G91
G1 S1 X-200 F2000 ; move proximal joint clockwise by up to 200 degrees until the endstop switch is triggered
G1 S2 X5 ; move proximal joint anticlockwise by 10 degrees
G1 S1 X-20 F300 ; move proximal joint slowly to the endstop switch again
G90 ; absolute movement

; Home distal joint
G91 ; relative movement
G1 S1 Y200 F2000 ; move distal joint clockwise by up to 200 degrees until the endstop switch is triggered
G1 S2 Y-5 ; move distal joint anticlockwise by 10 degrees
G1 S1 Y20 F300 ; move distal joint slowly to the endstop switch again
G90 ; absolute movement

;Home Z
G90 ; absolute movement
G30 ; Single Z-Probe

My ZProbe on config.g:

; Z probe
M558 P1 I0 X0 Y0 Z1
G31 Z2.2 P500
M557 X25:265 Y25:265 S80

Googliola

@dc42 @claustro
M557 X15:325 Y-15:270 P3 (in config.g)
resulting in
Error: M557: Error: M557 P parameter is no longer supported. Use a bed.g file instead.

Seems like a bug to me. Or what am I missing? (It worked just fine with S parameter, but defining the number of probing points is so much handier...)

zerspaner_gerd

I accidentally pressed the tool 0_1541612956596_PanelDue Tool.jpg over the PanelDue instead of the temperature. After that, my 4 hours printing was broken because in the middle of printing the tool T1 with offset and temperature was deselected.

Error message in DWC:
Error: Attempting to extrude with no tool selected.

Such inputs should not be executed in print!!

garyd9

@zerspaner_gerd said in Firmware 2.02 Release candidate 3 now available:

I accidentally pressed the tool !(...) over the PanelDue instead of the temperature. After that, my 4 hours printing was broken because in the middle of printing the tool T1 with offset and temperature was deselected.

Ouch.

I completely agree with you that the attempt to change tools should be blocked. However, I think it'd be more appropriate for it to be blocked by DWC and the PanelDue (and not by the duet firmware itself.) Gcode that changes tools in mid-print is completely reasonable for multiple tool machines. For Paneldue, I think this would be a fairly simple change to just check the 'status' before reacting to the tool button.

Edit:

I just submitted pull request #42 for panelduefirmware to address this. I can't help with DWC (but I think it's not quite as easy to deactivate a tool with DWC.)

dc42

When an SD card print is in progress and not paused, I think it might make more sense to disable many GCode commands that come from other sources. Not just tool selection but also G32, G29, and all movement commands except baby stepping. This would be done in the main firmware so that it applies to all input streams except the SD card.

Comments?

Phaedrux

@dc42 I think that would be a good safe default. I've ruined a few prints myself by accidentally touching the PanelDue during a print.

I still think there is a place for a screen lockout function for the Panel due in addition.