Firmware 1.19RC1 released - please help us with testing!
-
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) -
I've just released RC4. Please try it.
I did consider whether instead of restoring the initial user-requested Z coordinate after the tool change is complete I should actually have the Z axis move; but I thought of some problems with doing that, so I didn't.
G1 R2 is already implemented. However, it needs to be tested on an IDEX machine. The complication is that after changing from T0 to T1 or vice versa, where does the U axis end up? If we switched T0->T1 then we want the new U position to be the mapped X coordinate, not the old U position. If we switched T1->T0 then we want the new U position not to be restored at all but to be left nas it was after execution of the tool change files. I suspect it isn't accounting for this. And then are the other 4 cases of switching between no tool (T-1) and T0 or T1, in either direction.
-
You could make variables to use in Gcode. This way it could be the responsibility of the free.g to:
- Store current position to user-named variables.
- move the head to park position
and post.g
- move the head back to user-stored position
This would be much more flexible and support different configurations and be the responsibility of the user to support the functions he needs.
I think if you make the following variables available, we would come a long way:
TnX TnY TnZ En where n is the extruder or head number.
For starters the user variables could be just an array of 30 floats that are indexed like data[n] and the user can keep track. - that should be relativly easy to implement and very flexible.
-
True, but explaining how to use them to novices would be complicated. I prefer to get as close to an "it just works" solution as possible for the majority of users.
-
Just to give you some quick feedback on RC4, my initial move x/y/u tests worked!
I'll recompile it with my modification to get it to work with cura and do a test print and report back when its done. -
Thanks for the feedback. I think I've cracked this one at last - provided that the user (can't remember who) who reported tool Z offsets not working is happy with it.
-
Hmm.. something is going wrong after I pause and stop a job. I do a few extrudes on both tools (maybe up to 10mm) to prime the tools. When I do "print another" it moves to where it should start and do a huge retract! Is there some code that tries restores the e0 and e1?
M190 S63 M104 S210 M104 T1 S210 M109 S210 M109 T1 S210 ; G28 ;Home G1 Z15.0 F6000 ;Move the platform down 15mm M83 T1 G1 E2 T0 G1 E2 M82 ;LAYER_COUNT:420 ;LAYER:0 M107 M104 T1 S180 G0 F6000 X221.18 Y236.445 Z0.3 ;TYPE:SKIRT G1 F1800 X220.667 Y236.983 E0.01398 G1 X220.193 Y237.581 E0.02834Edit: retract was on T0
Edit 2: I get retract on T1 too -
Ok, Ill put that in the start g-code… Are you planing to go back to old behaviour (where it worked without G92 E0) for this (pre RC) or keep it this way?
Edit: Plenty of G92 E0 just to be sure it works
G1 Z15.0 F6000 ;Move the platform down 15mm M83 T1 G92 E0 G1 E2 G92 E0 T0 G92 E0 G1 E2 G92 E0 M82 -
Absolute extrusion in 3D printers must rank as one of the worst ideas ever. Whoever thought it was a good idea was a moron. It causes problems with supporting pause/resume, resume after power fail, mixing extruders, and filament change support. Please nag the Cura developers to add support for generating relative extruder coordinates.
You and the Cura developers between you have fallen into one of the traps of using absolute extrusion. The first extrusion command generated by Cura (G1 F1800 X220.667 Y236.983 E0.01398) does not have a G92 E0 command before it to define the datum for that extrusion command. You should insert a G92 E0 command in your start gcode after the M82 command.
EDIT: your post crossed with mine.
-
You should insert a G92 E0 command in your start gcode after the M82 command.
Will that reset it for both tools?
-
No, only for the current tool. RRF maintains separate cumulative extrusion amounts for each tool. AFAIK nobody has ever defined whether this is what 3D printers are supposed to do, or whether a single value should be maintained. Yet another problem caused by using absolute extruder coordinates. Relative extruder coordinates make things so much simpler.
Your question and my response would not have been needed had your slicer generated code that used relative extruder coordinates. Please nag the Cura developers to add support for relative extruder coordinates.
