Firmware 1.19RC1 released - please help us with testing!
-
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.
-
Ok, it seems RC4 works for me too. I have not done a full test with pausing etc, but for just normal printing it seems to work.
And the "tool Z offsets not working" bug was reported by me, so you can strike that off your list.
Thank you
-
Ok, it seems RC4 works for me too. I have not done a full test with pausing etc, but for just normal printing it seems to work.
And the "tool Z offsets not working" bug was reported by me, so you can strike that off your list.
Thank you
Thanks for the feedback! Got there in the end.
Unless I receive any more problem reports, I intend to release RC4 as the 1.19 release. It's now very similar to 1.19beta11 apart from the tool change Z offset fix and refactored homing code to support SCARA.
-
Yep, looks like basic printing works now, have not tested to change offsets. I'm out of time now…
I'll let the cura developers know of your hatred of absolute extrusion at first opportunity I get!
The following start code should prime and reset both tools..?
G1 Z15.0 F6000 ;Move the platform down 15mm T1 M83 G1 E2 M82 G92 E0 T0 M83 G1 E2 M82 G92 E0 -
Yes, that looks good.
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.
-
I have made some contributions to Cura and one of the recent changes is that it now really does differentiate between Marlin and RepRap flavour gcodes. Until recently it had RepRap(Marlin) flavour that has to conform to various Marlinisms and so wasn't really that well matched to RepRap. It now has separate Marlin and RepRap flavours and so there's no obvious reason why the RepRap flavour gcode could not support relative extrusion. I shall investigate and will keep you posted.
-
Thanks, that would be great!
Another good feature would be to write T0 to the Gcode file before any temperature-setting commands, if no T commands would otherwise be written.
-
Another good feature would be to write T0 to the Gcode file before any temperature-setting commands, if no T commands would otherwise be written.
OK, I'll look at doing that as well.
-
Lars and Kulitorum, please can you each post about 20 lines from the gcode files you are printing around the point where your slicer generates a tool change. I may be able to simplify the absolute extrusion distance tracking a little, but I need to know what Cura is doing with the extrusion distance when it changes tools.
-
Lars and Kulitorum, please can you each post about 20 lines from the gcode files you are printing around the point where your slicer generates a tool change. I may be able to simplify the absolute extrusion distance tracking a little, but I need to know what Cura is doing with the extrusion distance when it changes tools.
Just checked the current Cura code and it resets the distance to zero on extruder change.
-
Hmmm, homeing takes forever in RC4…. Maybe it's just me, but in my latest tests, the printer would home X, then just sit there for maybe 30 secs before homeing Y. This is when sending a G28 command. Pattern repeats for other axies.
Anybody else see this?
-
After playing around, it seems that the command
G1 X-355 F6000 S1
Will keep going (counting, not actually moving the head) after the endstop has been hit, until the X-355 has virtually been reached. I would assume the wanted behavior would be for that G1 move to exit once the endstop has been hit? This may be the source of the delays.
-
Also, my U axis with this command:
G1 U370 F600 S1
Moves at max allowable speed (42000 in my case) and not F600 as requested. The other axes does not display this behavior
-
Lars and Kulitorum, please can you each post about 20 lines from the gcode files you are printing around the point where your slicer generates a tool change. I may be able to simplify the absolute extrusion distance tracking a little, but I need to know what Cura is doing with the extrusion distance when it changes tools.
G1 X217.984 Y238.175 E143.27576 G1 X218.406 Y237.387 E143.28697 G1 X218.897 Y236.64 E143.29818 G1 X219.453 Y235.939 E143.3094 G1 X220.069 Y235.291 E143.32061 G1 F1200 E127.32061 G92 E0 ; Start tool change script in cura G91 G1 Z0.5 F1800 ; move bed down G90 ; End tool change script in cura T1 G92 E0 M109 S200 M104 T0 S180 G1 F1200 E14 G0 F18000 X220.069 Y235.291 Z4.3 G0 X227.6 Y241.835 G0 X227.6 Y243.1 M104 S210 ;TYPE:WALL-INNER G1 F1800 E16 G1 F4800 X246.4 Y243.1 E16.23576 -
Just checked the current Cura code and it resets the distance to zero on extruder change.
A initial G92 E0 would be nice as it starts printing without resetting the extruder.
-
Just checked the current Cura code and it resets the distance to zero on extruder change.
A initial G92 E0 would be nice as it starts printing without resetting the extruder.
You could put that in the start gcode.
-
Hmmm, homeing takes forever in RC4…. Maybe it's just me, but in my latest tests, the printer would home X, then just sit there for maybe 30 secs before homeing Y. This is when sending a G28 command. Pattern repeats for other axies.
Anybody else see this?
...
After playing around, it seems that the command
G1 X-355 F6000 S1
Will keep going (counting, not actually moving the head) after the endstop has been hit, until the X-355 has virtually been reached. I would assume the wanted behavior would be for that G1 move to exit once the endstop has been hit? This may be the source of the delays.
I can't reproduce that. I'm using the same config and homing files as you are except that my Z homing file is just G92 Z0. When I press Home All, as soon as I trigger the X homing switch it homes Y.
Also, my U axis with this command:
G1 U370 F600 S1
Moves at max allowable speed (42000 in my case) and not F600 as requested. The other axes does not display this behavior
I can't reproduce that either. Perhaps it depends on which tool (if any) is selected. EDIT: I've tried it with T0, T1 and with no tool selected.
Can you run a few more tests and come up with a command sequence that demonstrates these issues immediately after a reset?
-
You could put that in the start gcode.
Yep, did that. It was not needed pre RC1. Once you know you need it it's simple to put it in the start gcode.
I have made some contributions to Cura and one of the recent changes is that it now really does differentiate between Marlin and RepRap flavour gcodes. Until recently it had RepRap(Marlin) flavour that has to conform to various Marlinisms and so wasn't really that well matched to RepRap. It now has separate Marlin and RepRap flavours and so there's no obvious reason why the RepRap flavour gcode could not support relative extrusion. I shall investigate and will keep you posted.
What version is this? Don't remember seeing it in 2.6.2?
-
What version is this? Don't remember seeing it in 2.6.2?
Hi, not it's not in a release yet, I think that 2.7 will probably have it.
I am just working on a PR that makes Cura use relative extrusion when it outputs RepRap flavour gcode.
A question: when using relative extrusion, is G92 E0 required at all, and if not required, if it is present, does it cause any problems?
-
G92 E0 is not required at all when doing relative extrusion. But it doesn't cause any problems.
When using relative extrusion, it's best to include M83 near the beginning of the gcode somewhere before the first extrusion command, to tell the firmware that relative extrusion is in use.
