Firmware 1.19RC1 released - please help us with testing!
-
Thanks again for the videos. Is the +X direction to the left on your printer?
-
Still problem with RC3. I move X and U and it works (T0 is active tool after boot). I change to T1 (right tool) and when doing a X+1 (or was it X-1) it stats to move towards the right side. I managed to emergency stop before crash as lowered both max speed and current. This is unhomed so no tool change scrips should run but as you requested them I'll include them below, I only have tfree0.g and tfree1.g.
Homing worked better this time but first time I ran it the right (t1) carriage never move out to the end stop. I could not reproduce this but I believe I have seen it once before (in earlier betas), that time it was t0. Second homing worked as it should. I restarted the duet and homed again and it worked.
tfree0.g
G90 G1 X-33 F18000tfree1.g
G90 G1 X525 F18000config.g
; Communication and general M111 S0 ; Debug off M550 PDuetWiFi ; Machine name and Netbios name (can be anything you like) M551 Pxxxxx ; Machine password (used for FTP) ;*** If you have more than one Duet on your network, they must all have different MAC addresses, so change the last digits M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Address ;*** Wifi Networking M552 S1 ; Enable WiFi. Disabled for setup and testing. Enable once set up on your network. M555 P2 ; Set output to look like Marlin M575 P1 B57600 S1 ; Comms parameters for PanelDue G21 ; Work in millimetres G90 ; Send absolute coordinates... M83 ; ...but relative extruder moves ; Core xyu M669 K5 ; Select CoreXYU mode ; Axis and motor configuration M584 Y5 X7 U8 V6 E3:4 Z0:1:2 ; Set up steppers for x, y, u, v, z and e, use P4 once it works to hide V M671 X-60:560:250 Y-10:-10:560 S0.5 ; Set up lead screw positions for bed leveling M574 X1 Y1 U2 S1 ; set endstop configuration (all endstops at high end, active high) M574 Z0 S0 M208 X-38 Y-5 U-5 V-5 Z0 S1 ; Set axis minima M208 X495 Y500 U529.45 V500 Z700 S0 ; Set axis maxima U600 - 37 - 38 = 525 M569 P0 S0 ; Drive 0 goes forwards Z M569 P1 S0 ; Drive 1 goes forwards Z M569 P2 S0 ; Drive 2 goes forwards Z M569 P3 S0 ; Drive 3 goes forwards E0 M569 P4 S0 ; Drive 4 goes forwards E1 M569 P5 S1 ; Drive 5 goes forwards Y M569 P6 S1 ; Drive 6 goes forwards V M569 P7 S1 ; Drive 7 goes forwards X M569 P8 S1 ; Drive 8 goes forwards U M569 P9 S1 ; Drive 9 goes forwards M350 X16 Y16 U16 V16 Z16 E16:16 I1 ; Configure microstepping with interpolation M92 X160 Y160 U160 V160 Z1600 ; Set steps per mm M566 X800 Y800 U800 V800 Z24 E20:20 ; Set maximum instantaneous speed changes (mm/min) M203 X24000 Y24000 U24000 V24000 Z400 E1800:1800 ; Set maximum speeds (mm/min) M201 X1500 Y1500 U1500 V1500 Z250 E120:120 ; Set accelerations (mm/s^2) M906 X1700 Y1700 U1700 V1700 Z1700 E800:800 I30 ; Set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout ; Thermistors M305 P0 T100000 B3950 R4700 H30 L0 ; Put your own H and/or L values here to set the bed thermistor ADC correction M305 P1 X200 ; USE PT100 for heater 1 tool 0 M305 P2 X201 ; USE PT100 for heater 2 tool 1 M570 S180 ; Hot end may be a little slow to heat up so allow it 180 seconds ; Fans M106 P0 S0 H-1 ; Part cooling, disable thermostatic mode for fan 0 M106 P1 T50 H1 ; Set fan 1 to thermostatic mode for hotend 1 at 50deg M106 P2 T50 H2 ; Set fan 2 to thermostatic mode for hotend 2 at 50deg ; Tool definitions ; Tool 0 M563 P0 D0 H1 ; Define tool 0 G10 P0 S0 R0 ; Set tool 0 operating and standby temperatures ; Tool 1 M563 P1 D1 H2 X3 ; Define tool 1 and bind it to U-axis (X3) G10 P1 U0.15 Y-0.425 Z0.2 S0 R0 ; Set tool 1 operating and standby temperatures M92 E2650:2650 ; Set extruder steps per mm ; Z probe and compensation definition M558 P6 X0 Y0 Z0 ; Z probe is an BLTouch probe connected to E1-endstop (last) G31 T6 X-14 Y-26.765 Z2.70 P10 ; Set the zprobe height and threshold (put your own values here) M557 X30:470 Y30:470 S44 ; Probe grid M376 H5 ; Taper of bed compensation ;*** If you are using axis compensation, put the figures in the following command M556 S78 X0 Y0 Z0 ; Axis compensation here ; Heater model parameters M307 H0 A93.0 C167.8 D2.5 S1.00 B0 ; Bed M307 H1 A259.8 C120.8 D3.2 S1.00 B0 ; Tool 0 M307 H2 A356.8 C180.3 D3.9 S1.00 B0 ; Tool 1 ; BLTouch connected to PWM5/E6 M307 H7 A-1 C-1 D-1 M208 S1 Z-0.2 ; set minimum Z T0 ; select first hot end -
yes, +x is to the left in the videos
-
Any progress? - Eager to start testing
-
I really appreciate your help, because I need to resolve this today ready for the release tomorrow.
I'm puzzled because I just ran some more tests and I can't replicate your issue using RC3. Please can you try the following:
1. Home all axes. I homed X, Y and U in that order, and then sent G92 Z0 because I don't have a Z probe on my test rig.
2. Either send M302 P1 to enable cold extrusion or heat the hot ends up so that the tool change macros don't generate error messages.
3. Send the following sequence of commands:
T0
G1 X100 ; X carriage moves to 100
T1 ; X carriage moves to near home position
G1 X200 ; U carriage moves to 200
T0 ; U carriage moves to near home position
G1 X100 ; X carriage moves to 100If this goes wrong, please let me know where and/or post a video. If it doesn't go wrong, please try to find a simple sequence that does.
-
David, have you tried relative moves? I remember last time I tracked down this kind of problem (after beta 6?) it was related to relative moves… How does the web interface issue its moves, relative or absolute?
-
Your little test script runs perfectly.
The small script here makes some wierd movements, so I am trying to figure out when and why.
The documentation for M111 is a bit shallow, can you tell me how to get realtime echo of the command running? (Or better, extend the documentation, but I guess that's not today)
G90
M82
M140 S60
;From tool 0 gcode
G10 P0 R190 S190
G10 P1 R190 S190
G28
T1 ; To force the temperatures to be "activated"
T0
M116 P0
M116 P1
G92 E0
G1 E-3.0000 F600
G1 Z0.680 F9000
; process Tool 0
; layer 1, Z = 0.180
G1 z0.180
T0
; tool H0.200 W0.480
; skirt
G1 X109.566 Y102.382 F4500
G1 Z0.180 F9000
G1 E0.0000 F180 -
Here's the video of that gcode running:
-
Interesting, I did the test you asked for and it worked as expected. I then switched to T1, changed to relative G91 and did a G1 X-1.
This moved T1 from end pos (529.4) to 99…12:31:58 G1 X-1
12:31:43 G91
12:31:11 T1
12:30:59 G1 X100
12:30:46 T0
12:30:18 G1 X200
12:29:49 T1
12:29:41G1 X100
12:29:27 T0 -
I have mailed you the login for my workshop computer, you are welcome to teamviewer to it and have a go at it.
I am setting up a webcam, so you can see what you are doing
-
Webcam is up at: 212.237.97.81:8081
-
FYI, I am also using relative moves in my tool change gcode (tfree0.g)
-
Hi Kulitorum thanks for that. I've reproduced it and traced what is happening:
- After homing, the last requested X position is 30 (from homing Z)
- The T1 command leaves the last requested X position as 30 and changes the actual U position from 312.8 to 311.7and the actual X position to -27
- The T0 command changes the last requested X position to 311.7. This is wrong. It looks like it's worked out the actual X position before the tool change using the U axis mapping (which it does to avoid issues in the tool change files), but then it hasn't restored the last requested X position that was saved before the tool change started. I'll work out why.
- Then the G1 Z command uses the last requested X position, because the command doesn't include an X coordinate.
-
ok. I am going to a family thing now but I will leave my machine on, in case you want to test something.
-
Interesting, I did the test you asked for and it worked as expected. I then switched to T1, changed to relative G91 and did a G1 X-1.
This moved T1 from end pos (529.4) to 99…12:31:58 G1 X-1
12:31:43 G91
12:31:11 T1
12:30:59 G1 X100
12:30:46 T0
12:30:18 G1 X200
12:29:49 T1
12:29:41G1 X100
12:29:27 T0This is expected behaviour for the new firmware. The last requested X position was X=100. Then you change tool to T1. RRF doesn't try to move the head to the last requested X position at that point, because there is no guarantee that the last requested X position is reachable by the new tool. Similarly, it doesn't immediately adjust the Z height to account for the different Z offset of the new tool.
Now you do a move in which you specify the X coordinate but not the Y or Z coordinates. So the firmware moves the head to the last requested Y and Z coordinates, and the last requested X coordinate plus the relative movement you asked for.
The only time that the firmware sets the requested coordinates to actual machine coordinates is after you do a special move, which is normally during homing (G1 S1) or an individual motor move (G1 S2). Currently it also sets the requested coordinates to actual coordinates at the start of a tool change as well and in a few other situations, but IMO that is a bug.
The question is, this sensible behaviour or not? IOW, when you change tools and then you send a G1 command which either specifies relative coordinates or specifies only some of X, Y and Z, should the firmware assume that the unspecified coordinates should be the last values you asked for, or the current coordinates of the new tool? Taking the current coordinates of the new tool for the Z axis does not give desired behaviour, it leads to the print continuing with the new tool at the wrong height.
I think there are the following options for the behaviour when you do a tool change:
1. Set the requested coordinates to the actual coordinates of the new new tool. This is what RRF 1.19beta11 and previous firmware versions did. But if the old tool and the new tool have different Z offsets, and the new G1{XYZ} command in the file being printed doesn't specify Z, this results in the rest of the layer being printed at the wrong Z height.
2. Do what RRF 1.19RC3 does, but with the bug fixed. So any G1 command you specify immediately after a tool change will take the last requested coordinated before the tool change as the starting point for coordinates that you do not specify or that you specify in relative mode.
3. After a tool change, move the new tool the position last requested before you did the tool change. If the last requested position isn't reachable by the new tool, apply axis limits to the last requested position, and that becomes the new last requested position. This is likely to create unwanted movement. For example, if you home all axes and then do T1, it will try to move the U axis to X=minimum.
4. Treat the different axes differently, e.g. apply #1 to some axes and #2 to others.
My preference is #2 unless any other drawbacks of this approach become apparent. So I plan to release RC4 shortly, in which #2 is applied but the requested user positions are only updated to the actual machine position after a special move (which in practice means after a homing command).
-
ok. I am going to a family thing now but I will leave my machine on, in case you want to test something.
If you haven't already gone then I suggest you turn it off, for safety reasons - or at least disconnect the heaters. I can test that sequence on my bench setup.
-
Further to my previous response 2 posts up, I have now discovered a problem with specification #2 with the bug fix applied. If I select a tool and then select another tool without moving it first, there is unwanted movement because the commands in the tfree file assume a starting position that does not correspond to where the the head is. The unwanted movement is benign because it gets undone, but ugly.
So I'm reluctantly forced to treat different axes differently. I'll revert to specification #1 for all axes, except that after a tool change the requested user Z coordinate shall be restored to what it was before the tool change. I hope this will keep everyone happy. It should work provided that after issuing a tool change command, the slicer always specifies both X and Y coordinates (but not necessarily Z) in the next movement command.
-
A G1 Z without X coord should not change the X coordinate, But just leave X where it is, right?
-
But a G1 command with no Z coordinate does need to change the Z height, in the case that you have just done a tool change and the new tool has a different Z offset from the old one.
There is no single specification that, applied uniformly to all axes, results in the desired behaviour in all cases.
-
Tbh, this (#4) is what I would have preferred. #2 was confusing if you were using the Web interface to test movement. I guess if there was a good reason for going with #2 to get more compatibility with slicers you could have changed how the gui move worked and made it issue absolute moves.
Also in RC3 I some side effects (don’t know if it’s part of the know bug you are talking about).
If I move T0 to x 250, switch to T1 x-1 moves to 249 deselects T1 (both tools in standby now) and the activate T1 again it will move to min x (all the way next to T0).
If I activate T0 and move it to x 250. Deacitvate T0 (T0 moves to parking pos). Both tools are now on standby. U-1 will not move T1 but It moves T0 to 250.When I do x+0.1 a few times I could not make T0 go to 255.0.
x+0.1 254.8 x+0.1 254.8 x+0.1 254.9 x+0.1 254.9 x+0.1 255.1 x+0.1 255.2 x+0.1 255.3 x+0.1 255.3 x+0.1 255.4 x+0.1 255.6 ```I would guess this is a rounding issue in the presentation and the real position is something like 254.95 and next 255.05? The .05 for T 0 might somehow been picked up from T1 “G10 U0.15”. Anyways, these issues might not be a problem if you revert back to beta11 behavior for X and Y. Btw, maybe a G1 R2 command could be added that one could put in a tool change script to get the behaviour of #2 if it has any practical use…? (or the reverse if you decide to go with #2)
