New firmware 1.21RC4
-
Working well on the RailCore - haven't had any issues.
-
After updating to 1.21RC 4 my machine, again, has the issue of long pauses between executing commands. It seems that it is processing 2 commands at a time, pausing for 8 seconds or so, and then executing the next 2. This time, it did it at the beginning of a print though whereas before it did it at the end.
Which Duet is this?
Ethernet with X5. Upon finishing the print, I cannot connect via DWC but inputs from the Panel Due are executed properly and it does not appear to have entered the slow state.
Right now it is doing it very consistently. The machine automatically homes at start up. Then I can start a print at which point the start.g is executed properly but it seems that when it switches back to the regular gcode file is when things get slow. Sometimes, I can get it to print without this happening but I just had about 8 tries in a row where it got slow.
-
So it's a problem with out-of-order execution. I think the fix I need to do is to make the M116 wait until there are no queued moves left before it checks whether there is anything to wait for. Meanwhile, if you insert a M400 command anywhere between the G1 command and the M116 command, that should work around the problem.
I can confirm that adding a M400 command as directed does seem to correct the problem. If changing M116 to wait for the queue, the same change should probably be made for any other commands (if needed) that wait for a temperature (such as M109, M190, M191, etc.)
Alternatively, why not queue G10 (and M140, M141) commands instead of instant execution? I'd hope that the "retract" form of G10 already is placed in the movement queue and not executed out of order (otherwise it could really mess up prints.)
Thank you
Gary -
G10, M140 and 141 are already queued - that's part of the problem.
-
Welp! I tried to update from RC3 to RC4, and it detects that its a firmware upgrade, goes through the process, but when it 'restarts' it just states that there was an invalid password, in which once the password is entered, the 'firmware version' is still at RC3
-
Doesn't update via USB for me either. Just does the disconnect sound, says that it could not read from printer, then can not write to printer, then that the device did not recognize the command (M997, M997 S0/S1).
Just stays stuck at RC3 lol
-
Try the following:
1. Upload Duet2CombinedFirmware.bin through Settings->General in DWC.
2. In DWC go to System Editor and delete the old DuetWiFiFirmware.bin file.
3. Rename Duet2CombinedFirmware.bin to DuetWiFiFirmware.bin.
4. Send M997. -
This is relevant to RC3 but I didn't got to report this before the thread were closed. However, no mention of this quirk in the bug fix list. After upgrade to RC3 on my Core XY the bed compensation macro misbehaves. After the probing it just stops and does the homing procedure, not the fast move back to 0,0.
When I checked, it seemed the system went into relative coordinate mode (G91) after the two bed probes. These probes serve to compensate for dual Z leadscrews (each has independent motor). I inserted G90 after the probe commands and all is fine again. Maybe this issue already has been covered as I have not read the entire RC3 thread.Please can you try RC4 without the extra G90 and see if the problem persists.
The issue seems to be resolved. Thanks.
-
Try the following:
1. Upload Duet2CombinedFirmware.bin through Settings->General in DWC.
2. In DWC go to System Editor and delete the old DuetWiFiFirmware.bin file.
3. Rename Duet2CombinedFirmware.bin to DuetWiFiFirmware.bin.
4. Send M997.I'll give this a shot once the current print is over. (in about 15 hours x-x). Currently in the process of overhauling the printer with new parts in a slightly more stable design, so trying to utilize all the time I've got when I'm at work and sleeping.
-
Sorry, I'm a slow tester.
I have issues with RC3 regarding the H-parameter of G30. It seems to be ignored, or I made it wrong?!
Here's what I did:
Home the Delta
Delta calibration using bed.g and 6 factors
Use the same bed.g, but with S-1 to report the H-values
Replace the H-values in bed.g including +/- signs
Reset and calibrate again, but getting the same issues with inconsistent nozzle height
Revers the +/- signs of the H parameter, but again, no changes regarding nozzle height.I'd expect it would get worse ot better, when reversing the sign, but no changes???
Sorry, if that's already reported, but I don't have the time to read all the posts in the other thread.
edit: I used the new multiprobe-feature, maybe it's related?
-
dc42:
You mentioned in the RC3 thread that you wanted to change G30 for multi-probing and possible to move back to the dive height:
I am looking at this now. It would be easier if I change the behaviour of G30 with no P parameter so that after probing it moves the probe up to the dive height, just as it does when there is a P parameter. Can anyone see a reason why I shouldn't make this change?
As far as I can tell, after a simple [c]G30[/c] triggers, RRF now moves my bed down (by 7mm = dive height). Since my next command in homez.g is a [c]G1 Z3 F100[/c], the bed reverse direction and moves closer to the nozzle - at a faster speed, which is a bit nerve racking the first time
I have changed the code so that G30 by itself can do multi tap. Only G30 S-1 and S-2 now do single tap only.
[…]
Another possibility I have considered is to keep G30 behaving as now (but possibly with a speed override), but to make G30 P0 Z-9999 S1 do "1-factor calibration" on all machine architectures, i.e. set the Z height. Then in homez.g you would do G30 followed by G30 P0 Z-9999. The G30 with P parameter would support multi tap.The release notes didn't mention any of this, and neither does the gcode-wiki. Would you mind clarifying this please?
-
I have updated the release notes to include the changed G30 behaviour.
-
Hi all,
I updated from 1.2 to 1.2.1 RC4 (direct). Updated the Duet Wifi firmware, the web server and the web control interface.
Cartesian printer.I had issues with homing ('Error: G0/G1: insufficient axes homed') and found the answer in this thread - thought I'd read through all the 1.2.1 release notes but obviously not
Anyway after adding the S2 to my G1 commands I ran a home test.
X and Y worked as expected but Z tried its damnedest to smash through my glass bed! Have I missed something or is something else wrong?
[[language]] ; homex.g ; called to home the X axis ; ; generated by RepRapFirmware Configuration Tool on Wed Mar 07 2018 10:07:16 GMT+0000 (GMT) G91 ; relative positioning G1 S2 Z5 F6000 ; lift Z relative to current position G1 S1 X-205 F6000 ; move quickly to X axis endstop and stop there (first pass) G1 X5 F6000 ; go back a few mm G1 S1 X-205 F600 ; move slowly to X axis endstop once more (second pass) G1 S2 Z-5 F6000 ; lower Z again G90 ; absolute positioning[[language]] ; homey.g ; called to home the Y axis ; ; generated by RepRapFirmware Configuration Tool on Wed Mar 07 2018 10:07:16 GMT+0000 (GMT) G91 ; relative positioning G1 S2 Z5 F6000 ; lift Z relative to current position G1 S1 Y-205 F6000 ; move quickly to Y axis endstop and stop there (first pass) G1 Y5 F6000 ; go back a few mm G1 S1 Y-205 F600 ; move slowly to Y axis endstop once more (second pass) G1 S2 Z-5 F6000 ; lower Z again G90 ; absolute positioning[[language]] ; homez.g ; called to home the Z axis ; ; generated by RepRapFirmware Configuration Tool on Wed Mar 07 2018 10:07:16 GMT+0000 (GMT) G91 ; relative positioning G1 Z5 F6000 ; lift Z relative to current position G1 S1 Z-180 F6000 ; move Z down until the switch triggers G92 Z0 ; set Z position to trigger height ; Uncomment the following lines to lift Z after probing ;G91 ; relative positioning ;G1 Z5 F100 ; lift Z relative to current position ;G90 ; absolute positioning[[language]] ; homeall.g ; called to home all axes ; ; generated by RepRapFirmware Configuration Tool on Wed Mar 07 2018 10:07:16 GMT+0000 (GMT) G91 ; relative positioning G1 S2 Z5 F6000 ; lift Z relative to current position G1 S1 X-205 Y-205 F6000 ; move quickly to X and Y axis endstops and stop there (first pass) G1 X5 Y5 F6000 ; go back a few mm G1 S1 X-205 Y-205 F600 ; move slowly to X and Y axis endstops once more (second pass) G1 S2 Z-180 F6000 S1 ; move Z down stopping at the endstop G90 ; absolute positioning G92 Z0 ; set new Z position ;G1 Z5 F100 ; uncomment this line to lift the nozzle after homing -
1. What are you using to home Z: a homing switch, or a Z probe?
2. What M574 command or commands do you have in config.g?
-
1. What are you using to home Z: a homing switch, or a Z probe?
2. What M574 command or commands do you have in config.g?
I was just looking at this - I noticed in the 'Machine Properties' interface the Z switch seems be reversed..
1. A homing switch
2…
[[language]] ; Endstops M574 X1 Y1 Z1 S0 ; Set active low endstops M558 P0 H5 F120 T6000 ; Set Z probe type to switch and the dive height + speeds G31 P500 X0 Y0 Z0 ; Set Z probe trigger value, offset and trigger height -
If they are two-wire switches then it's safer to use the normally-closed contacts (the outer two on the microswitch) and set them to active high (S1) in M574. The problem with using active low is that if the wire becomes detached, the endstop will never show as triggered. This may be what has happened.
-
In the machine properties interface I can see endstop hit = 'yes'. If I then tap the switch it turns to 'no'
So the switch is functioning as expected but it appears that during the upgrade something has reversed..?
Or am I misunderstanding something?I've literally finished a print, done this upgrade and then applied the S2 changes to G1, that's all…
-
Strange, nothing has been intentionally changed in that area. How have you wired your switches - which contacts are you using? Do you definitely have only one M574 command in config.g?
-
They're two wire switches connected to the two left pins on the duet board header (with the wifi part bottom left). Is that not right then?
Here's my entire config.g. Its pretty much straight from the configurator as I'm new to all this so not comfortable changing much yet…
[[language]] ; Configuration file for Duet WiFi (firmware version 1.20 or newer) ; executed by the firmware on start-up ; ; generated by RepRapFirmware Configuration Tool on Wed Mar 07 2018 10:07:16 GMT+0000 (GMT) ; General preferences G90 ; Send absolute coordinates... M83 ; ...but relative extruder moves M555 P1 ; Set firmware compatibility to look like RepRapFirmare ; Network M550 Pxxxxxxxx ; Set machine name M551 Pxxxxxxxx ; Set password M552 S1 ; Enable network M587 S"xxxxxxxxxx" P"xxxxxxxxxx" I192.168.0.9 J192.168.0.9 K255.255.255.0 ; Configure access point and IP addresses. You can delete this line once connected M586 P0 S1 ; Enable HTTP M586 P1 S0 ; Disable FTP M586 P2 S0 ; Disable Telnet ; Drives M569 P0 S0 ; Drive 0 goes backwards M569 P1 S1 ; Drive 1 goes forwards M569 P2 S1 ; Drive 2 goes forwards M569 P3 S1 ; Drive 3 goes forwards M350 X16 Y16 Z16 E16 I1 ; Configure microstepping with interpolation M92 X80 Y80 Z400 E103 ; Set steps per mm M566 X480 Y480 Z12 E120 ; Set maximum instantaneous speed changes (mm/min) M203 X14400 Y14400 Z1200 E3000 ; Set maximum speeds (mm/min) M201 X800 Y800 Z100 E5000 ; Set accelerations (mm/s^2) M906 X855 Y855 Z855 E1125 I30 ; Set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout ; Axis Limits M208 X0 Y0 Z0 S1 ; Set axis minima M208 X200 Y200 Z175 S0 ; Set axis maxima ; Endstops M574 X1 Y1 Z1 S0 ; Set active low endstops M558 P0 H5 F120 T6000 ; Set Z probe type to switch and the dive height + speeds G31 P500 X0 Y0 Z0 ; Set Z probe trigger value, offset and trigger height M557 X25:175 Y25:175 S20 ; Define mesh grid ; 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 B3988 C0 R4700 ; Set thermistor + ADC parameters for heater 0 M143 H0 S120 ; Set temperature limit for heater 0 to 120C M305 P1 T100000 B4725 C0 R4700 ; Set thermistor + ADC parameters for heater 1 M143 H1 S280 ; Set temperature limit for heater 1 to 280C ; Fans M106 P0 S0 I0 F500 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off M106 P1 S1 I0 F500 H T45 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on M106 P2 S1 I0 F500 H T45 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned on ; 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 ; Automatic saving after power loss is not enabled ; Custom settings are not configured ; Miscellaneous T0 ; Select first tool -
Ok, so if I downgrade back to 1.2.0 everything works as expected and I can see the Endstops hit = No for all axes
Then I upgrade to 1.2.1 (rc4 or 5) and all axes show Endstops hit = yes.Should this be happening? Have I done something wrong?
EDIT: I'll move this into the RC5 discussions in case its relevant
