Firmware 1.19RC1 released - please help us with testing!

lars

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

lars

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.

burtoogle

@lars:

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.

dc42

@Kulitorum:

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.

@Kulitorum:

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?

lars

@burtoogle:

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.

@burtoogle:

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?

burtoogle

@lars:

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?

dc42

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.

burtoogle

@dc42:

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.

Understood, thanks.

dintid

Issues I've found so far:

Getting following error at each restart/reboot: Can't open 0:/sys/oem.json to read, error code 4
Can't edit Macros
Can't delete Macros
When using M200 D1.75 in order to run in Volumetric mode the lenght of manual extrusion is around 4/10 the expected length
Filaments - can add one with name, but no properties/can't edit

Using

Firmware Electronics: Duet WiFi 1.0 + DueX5
Firmware Version: 1.19RC3 (2017-08-05)
WiFi Server Version: 1.19beta10
Web Interface Version: 1.17+2

burtoogle

I have created CuraEngine PRs that always using relative extrusion and output an initial T0 before any temperature setting commands when generating RepRap flavour firmware. Hopefully, they (or a variant) will get accepted and then become available in the 2.8 release.

lars

@burtoogle:

I have created CuraEngine PRs that always using relative extrusion and output an initial T0 before any temperature setting commands when generating RepRap flavour firmware. Hopefully, they (or a variant) will get accepted and then become available in the 2.8 release.

Nice!

dc42

@dintid:

Issues I've found so far:

Getting following error at each restart/reboot: Can't open 0:/sys/oem.json to read, error code 4

Can't edit Macros

Can't delete Macros

When using M200 D1.75 in order to run in Volumetric mode the lenght of manual extrusion is around 4/10 the expected length

Filaments - can add one with name, but no properties/can't edit

Using

Firmware Electronics: Duet WiFi 1.0 + DueX5
Firmware Version: 1.19RC3 (2017-08-05)
WiFi Server Version: 1.19beta10
Web Interface Version: 1.17+2

Thanks for your report.

Regarding #1, it's normal for that message will be generated if you have Platform debugging enabled. It's not usual to run a printer with debugging enabled. Perhaps you have a M111 command in config.g left over?

Regarding #s 2, 3 and 5, those functions are working properly for me. However, I am running a pre-release copy of DWC 1.19. I've asked chrishamm if he is happy to release that version yet. I don't plan to release RRF 1.19 until DWC 1.19 is also available.

I will investigate #4.

EDIT: regarding #4, I see what is happening. You enable volumetric extrusion, and the firmware then assumes that all extrusion commands received are in volumetric units - including values received from DWC. Looks like we I should make volumetric extrusion work on a per input source basis, and turn it off when starting to print a new gcode file.

dc42

Here is a question for those of you who use Cura with multiple tools. If you select volumetric extrusion in Cura, what M200 commands does it generate? I see the following possibilities:

1. A single M200 command at the start, with a single D parameter. This would constrain you to use the same filament diameter on all extruders.

2. A single M200 command with multiple D parameters, one per extruder (or perhaps one per tool).

3. One M200 command shortly after each tool change.

dc42

Firmware 1.19RC5 is now released. Please post any remaining issues in the thread I have created for that release.

BagelOrb

Hi dc42,

Cura developer here ^^

Relative extrusion can have rounding problems.
Nevertheless we now have a PR for relative extrusion, and I am willing to merge.

I don't see any use in making the E-values relative by default for RepRap firmware, though. If users have already been printing with Cura then there's no need for relative extrusion any more.
Instead I would like to make the E-values absolute by default, unless a users changes the setting for Relative E-steps by hand.

What do you think?

dc42

Please explain why you think relative extrusion can have rounding problems. Are you talking about rounding in the slicer, or in the firmware, and where does the rounding you are referring to occur?

Way back in the mists of time, before we had the M221 command or mixing extruders, the step count of the extruder motor bore a direct relationship to the E value in the G1 command, until the slicer sent G92 E0. But that simple relationship has long since ceased to exist. So it is no longer the case that the only rounding that the firmware does is from the absolute extrusion commanded to the nearest motor step, plus any rounding when G92 E0 is processed.