Firmware 2.02 Release candidate 3 now available

BlueDust

@garyd9
I press the neagtive or positive buttons and the nozzle doesn't get any closer or further from the bed. I use this all thr time adjust the squish during the first layer.
I didn't reboot my printer a second time after installing the 3rd beta of the firmware. I will do that when I get home and see if that fixes it.

garyd9

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

@garyd9
I press the neagtive or positive buttons and the nozzle doesn't get any closer or further from the bed. I use this all thr time adjust the squish during the first layer.
I didn't reboot my printer a second time after installing the 3rd beta of the firmware. I will do that when I get home and see if that fixes it.

How big are your baby steps configured for? Does DWC claim that the baby steps are taking place? (It shows the current babystep.) On mine, I never actually measured the nozzle distance to ensure that the babysteps were happening, but I know that I'm about 0.04mm too high on my manual level, and if I don't babystep, everything curls up.

SupraGuy

I hadn't thought much about this, but I'm seeing something similar.

Baby steps are configured as 0.05mm, but I'm not seeing any effect on the machine. It changes the compensation factor on the DWC, (I had it showing up to a full 3mm of compensation at one point) but it didn't move the Z axis motors at all, so far as I could see.

My last few prints, I just stopped using it, because I thought that it might be something in my Z speed/acceleration settings not letting it get started for such a small move.

This started when I upgraded to 2.02RC2, still happening with RC3, however I also changed my Z lead screws when I upgraded to 2.02RC2 from 5mm/0.8mm lead to 8mm/8mm lead (4000 steps/mm to 400 steps/mm.) I had assumed that it had to do with the change in lead screws. I don't have those values from my config.g in front of me at the moment.

BlueDust

@garyd9
Default change is .05mm and it does say its changed. Usually I change this value from .25 to .35. After a 5 point calibration, start a print, change this Z level to around .25 / .35 to get a good squish going.
Usually stays pretty close to that initial adjustment after many 5 point calibrations until I power off/on again. And then I have to make this adjustment again.

Right now when I push the button - or + no changes are made, and as such, my prints don't always stick. This was working a 2 days ago. Appears like it stopped a day or two after I installed beta 3. I don't reboot the machine often so I may have rebooted it for the first time after installing the beta, but emergency stopping a print or something, that started this issue... Just saying that possible. Will reboot again when I get home. If that doesn't fix it will reinstall the current beta and if that doesn't help may reinstall beta 2 to confirm, as it was working for me.

Thanks

garyd9

@bluedust

WARNING: What follows is a WAG. Well, and educated WAG, but still a guess.

I wonder what the actual gcode DWC is sending - in particular if its actually sending a M290 R0 or M290 R1.

I wonder this because there's a commit that appears to be functionally different for R0. Previously, it would call PushBabyStepping(val - current). Now it's calling PushBabyStep(val)

I really don't understand the code I'm looking at, and my initial impression is that this change fixes a bug where the absolute mode (R0) was doing relative changes instead of absolute changes.

dc42

The only change made to baby stepping in RRF 2.03RC3 is to remove the limit of +/-1mm change when using absolute mode.

Old code:

const bool absolute = (gb.Seen('R') && gb.GetIValue() == 0);
float difference = (absolute) ? fval - currentBabyStepZOffset : fval;	
difference = constrain<float>(difference, -1.0, 1.0);
currentBabyStepZOffset += difference;

New code:

const bool absolute = (gb.Seen('R') && gb.GetIValue() == 0);
float difference;
if (absolute)
{
	difference = fval - currentBabyStepZOffset;
	currentBabyStepZOffset = fval;
}
else
{
	difference = constrain<float>(fval, -1.0, 1.0);
	currentBabyStepZOffset += difference;
}

garyd9

Like I said (typed...)

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

I really don't understand the code I'm looking at, and my initial impression is that this change fixes a bug where the absolute mode (R0) was doing relative changes instead of absolute changes.

For some reason when I was staring at the diff, it wasn't clicking in my head and I wanted to be clear about that when I posted. I had intended to followup when I got home, but I'm married with children. (I think that explains everything.)

I did see some weirdness with babystepping last night myself, but that was a case of the paneldue reporting an offset of 0.00 while DWC was reporting -0.02. I think DWC was correct, but it's very difficult to measure 0.02mm while the nozzle is moving.

tjb1

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

@bluedust

WARNING: What follows is a WAG. Well, and educated WAG, but still a guess.

I wonder what the actual gcode DWC is sending - in particular if its actually sending a M290 R0 or M290 R1.

I wonder this because there's a commit that appears to be functionally different for R0. Previously, it would call PushBabyStepping(val - current). Now it's calling PushBabyStep(val)

I really don't understand the code I'm looking at, and my initial impression is that this change fixes a bug where the absolute mode (R0) was doing relative changes instead of absolute changes.

You can see what DWC is sending the Duet by opening the Developer Tools for your browser (usually F12), select the Network tab and then click any of the buttons and you'll see something along the lines of http://ip_address/rr_gcode?gcode=

BlueDust

@garyd9
I would expect it to be impossible (or close to) to measure those small changes. I just print and change it during that first layer and see the difference. But even changing it 1mm + or - doesn't do anything anymore. And that should make big obvious changes to the print.
I am back to recalibrating Z with every power on (before I discovered the baby stepping button). Not a big deal, just takes more time.

Thanks for looking into this.

3DOeste

Hi, I have a problem when running G29 to probe the bed. For some reason the moving speed between probe point it's extremely slow. I have M558 P9 H3 F100 T2000, but no matter what T value I put, it always moves at 1.7mm/s.

It was working fine last time I used it, and I sincerely don't remember to have modified anything else (but perhaps I did...)

Any clue?

Phaedrux

@3doeste do you have the max speed limited in your config?

3DOeste

@phaedrux Hi, this is my config.g, Don't mind the comments, I never change them.

; General preferences
M111 S0 ; Debugging off
G21 ; Work in millimetres
G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves
M555 P0 ; Set firmware compatibility to look like RRF
M564 S1 H1 ; limit movement within axis boundaries, forbid movement of axes that have not been homed

; Automatic saving after power loss is not enabled

M667 S1 ; Select CoreXY mode
M208 X0 Y0 Z0 S1 ; Set axis minima
M208 X284 Y289 Z296 S0 ; Set axis maxima

; Endstops
M574 X1 Y1 S0 ; Set active low endstops
; M574 Z0
; M558 P0

; BL Touch
M307 H3 A-1 C-1 D-1
M557 X0:284 Y0:289 S20
M558 P9 H3 F100 T2000
G31 X-51.13 Y37.24 Z1.4 P25
M376 H5

; Drives
M569 P0 S0 ; Drive 0 goes forwards
M569 P1 S0 ; Drive 1 goes forwards
M569 P2 S1 ; Drive 2 goes forwards
M569 P3 S0 ; Drive 3 goes forwards
M350 X16 Y16 Z16 E16 I1 ; Configure microstepping with interpolation
M92 X100 Y100 Z800 E801,81 ; Set steps per mm
M566 X600 Y600 Z12 E250 ; Set maximum instantaneous speed changes (mm/min)
M203 X18000 Y18000 Z1200 E1200 ; Set maximum speeds (mm/min)
M201 X3000 Y3000 Z250 E250 ; Set accelerations (mm/s^2)
M906 X1500 Y1500 Z1500 E1400 I30 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout

; Heaters
M301 H0 S1.00 P10 I0.1 D200 T0.4 W180 B30 ; Use PID on bed heater (may require further tuning)
M305 P0 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 0
M143 H0 S120 ; Set temperature limit for heater 0 to 120C
M305 P1 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 1
M143 H1 S280 ; Set temperature limit for heater 1 to 280C

; Tools
M563 P0 D0 H1 ; 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
M572 D0 S0.05 ; Set pressure advance

; Network
M550 PIDITEC 3DPro ; Set machine name
M540 PBE:EF:DE:AD:FE:ED ; Set MAC address
M552 P192.168.5.111 S1 ; Enable network and set IP address
M553 P255.255.255.0 ; Set netmask
M554 P192.168.5.1 ; Set gateway
M586 P0 S1 ; Enable HTTP
M586 P1 S0 ; Disable FTP
M586 P2 S0 ; Disable Telnet

; CPU Temp
M912 P0 S-3

; Fans
M106 P0 S0 I0 F500 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
M106 P1 S0.7 I0 F500 H1 T45 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on
M106 P2 S0.7 I0 F500 H1 T45 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned on

dc42

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

Hi, I have a problem when running G29 to probe the bed. For some reason the moving speed between probe point it's extremely slow. I have M558 P9 H3 F100 T2000, but no matter what T value I put, it always moves at 1.7mm/s.
It was working fine last time I used it, and I sincerely don't remember to have modified anything else (but perhaps I did...)
Any clue?

Run M558 without parameters, to check that the T2000 value in config.g has been read properly.

garyd9

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

BlueDust

Fyi
I just installed a previous version of the firmware and the baby steps are working.

3DOeste

@dc42 I just done that and it’s not reading it, it shows the dame value as F, but even then it moves at 1.7mm/s.

M558
Z Probe type 9, input 0, invert no, dive height 3.0mm, probe speed 100mm/min, travel speed 100mm/min, recovery time 0.00 sec, heaters normal, max taps 10, max diff 0.01�

kuhnikuehnast

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?

dc42

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

@dc42 I just done that and it’s not reading it, it shows the dame value as F, but even then it moves at 1.7mm/s.

M558
Z Probe type 9, input 0, invert no, dive height 3.0mm, probe speed 100mm/min, travel speed 100mm/min, recovery time 0.00 sec, heaters normal, max taps 10, max diff 0.01�

1.7mm/sec is about 100mm/min, so that explains it. The question is, why does it have the travel speed set to 100 instead of 2000. Do you have any M558 commands in any other files, for example homing files? If you reboot the Duet and run M558 before you home the printer or run any other commands, does it report 100 or 2000 ?

dc42

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

kuhnikuehnast

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