Firmware 1.18 released

dc42 · 12 Apr 2017, 04:24

are we implementing soon the Linear Advance Extrusion algo?

We've had an accurate pressure advance algorithm in RRF for more than two years. See https://duet3d.com/wiki/G-code#M572:_Set_or_report_extruder_pressure_advance.

weput · 12 Apr 2017, 13:13

@dc42:

@weput:

are we implementing soon the Linear Advance Extrusion algo?

We've had an accurate pressure advance algorithm in RRF for more than two years. See https://duet3d.com/wiki/G-code#M572:_Set_or_report_extruder_pressure_advance.

had no idea.

seem i'll have to read the whole thing.

bilsch · 21 Apr 2017, 19:47

Seeing something odd. Upgraded the firmware of a duet wifi board and the system is in a persistent reboot state.

RepRapFirmware for Duet WiFi Version 1.18.1 dated 2017-04-09

Executing config.g...RepRapFirmware for Duet WiFi Version 1.18.1 dated 2017-04-09

Executing config.g...RepRapFirmware for Duet WiFi Version 1.18.1 dated 2017-04-09

Executing config.g...

Any idea what could cause something like this?

dc42 · 21 Apr 2017, 19:55

Do you have a very old version of DuetWiFiServer installed? What happens if you remove the SD card? If it boots up without the SD card, try commenting out the M552 S1 command from config.g, then booting up with the SD card again. If that works, try upgrading DuetWiFiServer to the latest version (1.03-ch).

bilsch · 21 Apr 2017, 20:12

@dc42:

Do you have a very old version of DuetWiFiServer installed? What happens if you remove the SD card? If it boots up without the SD card, try commenting out the M552 S1 command from config.g, then booting up with the SD card again. If that works, try upgrading DuetWiFiServer to the latest version (1.03-ch).

Will do I'll give that a try.

The board boots up with:

< 4:11:23 PM: FIRMWARE_NAME: RepRapFirmware for Duet WiFi FIRMWARE_VERSION: 1.18.1 ELECTRONICS: Duet WiFi 1.0 FIRMWARE_DATE: 2017-04-09

I was in the process of upgrading the firmwares - wonder if I got out of order?

dc42 · 21 Apr 2017, 20:48

Yes, your firmwares are out of sync - the DuetWiFiServer version is very old.

Ottobawt · 17 Jun 2017, 01:23

@dc42:

The usual reason for the extruder moving incorrectly during printing is mixing up relative and absolute extruder coordinates. If you use relative extruder coordinates, make sure you include M83 in your start gcode. If you use absolute coordinates, make sure you have M82 in your start gcode.

Hello

I'm running a duet wifi, in an ultibots d300vs(delta); and just upgraded from 1.15.1 to 1.18.1.
Slicing on Simplify3D
I try printing one of my reliable prints/gcodes that worked flawlessly on 1.15, but the effector will move dangerously fast… Not the entire print, but in parts of the loop.

I am unsure if this is the same issue as related above. I put M82 into my "Starting script" section on S3D.. and didn't seem to help... I checked for any other settings in S3D that had to do with relative or absolute, and I didn't see any relatives checked on...

Please advise, I have a order I need done before fathers day.

elmoret · 17 Jun 2017, 02:17

Why not just roll back to 1.15.1 in the meantime to get the order done?

fcwilt · 17 Jun 2017, 03:39

How about changing the max speed settings.

Ottobawt · 17 Jun 2017, 04:15

@elmoret:

Why not just roll back to 1.15.1 in the meantime to get the order done?

It's a last resort, but like, 1.15.1 that shipped with my printer also had a different wiring configuration..
So I had to rewire some fans and LEDs… which isn;t a big deal... but put all together and there it's a chore... I might as well just get the new stuff to work I figure.

@fcwilt:

How about changing the max speed settings.

This is clearly a conflict/bug or something similar to what was going on with the user above. Adjusting max speeds might help… but I still don't think it's reading the print stably as it was...

I think I found a solution'/work around...

What was happening to be clear was the entire effector carriage would leap at lightning speeds from one position of the print to an other, not the entire layer, just sometimes through out the loop (i feel like at the end of every loop).

So for the heck of it, I found a option in S3D >G-Code> G-Code options > and ticked the box "Relative Extrusion Distances", and now it's printing with out the dangerously fast movements it would do every loop...

The tick box may be the same as M83?...

the only issue with this is... all my old gcode prints are not safe to use with this current firmware.

Is there away to update the old gcodes with out resclicing?

I might have got the prints to print safely... but I am not sure if it's printing as well as it used to at this point

dc42 · 17 Jun 2017, 06:16

@Ottobawt:

So for the heck of it, I found a option in S3D >G-Code> G-Code options > and ticked the box "Relative Extrusion Distances", and now it's printing with out the dangerously fast movements it would do every loop…

The tick box may be the same as M83?...

the only issue with this is... all my old gcode prints are not safe to use with this current firmware.

Is there away to update the old gcodes with out resclicing?

If you slice using relative extrusion (which we recommend if your slicer supports it), include M83 in your slicer start gcode. If you slice using absolute extrusion, include M82 in your slicer start gcode. Some slicers do this automatically, others do not.

If you have old gcode files that don't have the M83 or M82 command in them, you can use a text editor (e.g. Notepad++) to insert that line.

gratefulfrog · 18 Jun 2017, 20:04

I just upgraded from a very old version 1.0 from RepRapPro and I got a rather poor first print.. The linked photo shows the object printed previously with the old firmware and the new.

https://goo.gl/photos/7DXMoQSvDybQYKcD8

I used the same gcode file.

Any thoughts as to what could be wrong?

Thanks,
Bob

dc42 · 18 Jun 2017, 21:04

Assuming you allowed the print to complete, it looks to me that your Z acceleration and/or Z feed rate and/or Z jerk are set too high in config,g.

gratefulfrog · 18 Jun 2017, 21:40

Sorry, I should have mentionef that I stopped the print because the filament jammed. So it never got to the full height.

I was thinking that the nozzle temp might be too high? But there's no reason why it would have changed, is there?

Thanks for your help!
Ciao,
Bob

dc42 · 19 Jun 2017, 05:24

It looks to me that the temperature is too high or the print is too fast or the print cooling is inadequate. Does your printer have a good print cooling fan? If not then you need to use a much lower print speed when printing tall thin towers like that, or e!se print 2 of those parts at once so that each layer gets time to cool while the corresponding layer on the other part is being printed.

gratefulfrog · 19 Jun 2017, 09:16

Yes, I feel that the temp is too high, also. The print speed doesn't seem fast and the cooling fan is running.

The printer is a RepRapPro Huxely Duo, with a single head and a 0.3mm nozzle.

But what has changed because of the firmware update? Previously this same gcode file printed perfectly. I have done another test with the same result.

In your pm, you said that when I upgraded the firmware I should "Tune the bed and extruder heaters". What exactly does that mean? Could that be the problem?

gratefulfrog · 19 Jun 2017, 10:01

I tried a new print of just a rectangular column 10x10mm.

It is PLA nozzle temp 195C, bed 57C. These are the settings I've been using for years.

As you can see in the image, at first it printed ok, but after about 15mm vertical, the glops start appearing and then finally the nozzle jammed.

Could it be that the extruder is extruding too much filament?

I am really at a loss as to how to debug this.

https://goo.gl/photos/UQt9gpSKS8P2gV2F9

Cheers,
Bob

dc42 · 19 Jun 2017, 10:47

Printing small rectangular columns is problematic on many 3D printers because a layer may not have time to cool properly before the next layer is printed on top of it. Things which help include:

Using a good print cooling fan. Make sure it to directed at the print just below and around the nozzle, not at the heater block.
Reducing print speed. Some slicers have a "Minimum layer time" parameter to facilitate this.
Printing 2 or more of them together, so that after a layer is printed on one of them it gets a chance ot cool while a layer is being printed on the other(s).

gratefulfrog · 19 Jun 2017, 11:05

Thanks, I understand that but why did it work in the past with the previous firmware (V1.1) ?

Also, would that explain the nozzle jamming up ?

I had set the slic3r as:

enable fan if layer print time is below: 60 seconds
slow down if layer print time is below: 20 seconds
min print speed: 10mm/s

I don't see a "minimum layer time" setting in Slic3r.

Thanks for your help! I'll keep trying…
Ciao,
Bob

dc42 · 19 Jun 2017, 11:54

I can't think of any firmware change that would account for the difference, assuming that you are using basically the same config.g file with just the changes needed by the new firmware. Other possible reasons for the difference` include:

A change in the quality of the filament part way through the reel
Higher ambient temperature now than when you printed it before
Fan slowing down during the print, due to bearing wear and/or power supply voltage dropping
Z axis has developed a problem. I remember getting a print similar to yours where the print went wrong above a certain height. It turned out that the Z axis was binding and the print head was no longer moving up the full amount commanded.