Firmware 1.18 released

dc42

I've just released firmware 1.18. For the full details, and what you need to know when upgrading, see the release notes at https://github.com/dc42/RepRapFirmware/releases.

The maximum motor current for TMC2660 drivers is increased to 2.4A in this release. When running above 2.0A, you must always use a cooling fan to cool the Duet, and during testing you should run M122 at intervals to check for over-temperature warnings from the drivers.

Russ Gries

Thanks David! will give this an upgrade !

break

Update.:. its installed and working, will give feed back for any problems.

Question:

on the web interface, it took me a while to find where the view bed height was. now its an icon under system editor.
but now i cant edit it? so i have do download it-> edit it-> then re upload it? then send a some commands to get it to use those new values? is this correct?
i see now that there is a drop down for viewing and such … ok, nice!

but how to i edit it manually? download it-> edit it-> then re upload it?

you know i was thinking that because you can see and view each point on the map, why now just double click that point and then be able to edit that point? all with in the map high viewer? is that do able?

maybe its just me but i would think that the button for viewing the bed height would be on the main machine control page? then the edit button back on the System editor page… most average users would never find it... lol just my thoughts

also no edit buttons for gcode! Darn hehe ( i still really want that option!) good stuff tho, i know its a lot of hard work for this stuff!

Thanks again for all the hard work!

~Russ

GrodanB

Just flashed the firmware all went fine.

Tried the web interface, got a message that the file could not be renamed.

Removed the version part of the file so that the name is DuetWebControl.bin. And then it worked.

Will now re-level the bed and see if my weird mirroring still is needed…

Larzarus

Uh… So something weird is going on for me. I had been running 1.17rc3 for a couple months without issue. Updated for 1.18 yesterday (along with making a few other wiring changes to my fans) along with the 1.15a web interface and the web server to 1.03ch. Everything seemed great until I printed. My extruder was moving WAY WAY WAY too fast. I tried different gcode files, changing the steps per mm, microstepping, etc. and it is just crazy fast. The other axis are OK. I went back to 1.17rc3 and it's working fine again (left the server and web insterface at latest). I can't imagine this is happening to everyone, it's pretty obvious show stopper. But I'm baffled as to why it's happening to only the extruder and only with 1.18.

Here is my config.g section for the motors:

[[language]]
; Drives
M569 P0 S1 ; Drive 0 goes forwards
M569 P1 S0 ; Drive 1 goes backwards
M569 P2 S1 ; Drive 2 goes forwards
M569 P3 S0 ; Drive 3 goes backwards
M350 X16 Y16 Z16 E16 I1 ; Configure microstepping with interpolation
M92 X80 Y80 Z400 E152 ; Set steps per mm
M566 X900 Y900 Z24 E240 ; Set maximum instantaneous speed changes (mm/min)
M203 X15000 Y15000 Z2500 E3000 ; Set maximum speeds (mm/min)
M201 X2500 Y2500 Z050 E5000 ; Set accelerations (mm/s^2)
M906 X1300 Y1300 Z1100 E1800 I20 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout

Any ideas?

Thanks
Lars

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.

dc42

Due to a mistake I made with the USB VIDs and PIDs we have been allocated, I have withdrawn the release 1.18 firmware binaries and replaced them by 1.18.1. The Windows USB driver files are also replaced. There are no other changes between 1.18 and 1.18.1 apart from the displayed version number of course.

Larzarus

@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.

Yes, that was it, thanks. I use absolute extruder positioning in my gcode files, but I've got some relative extruder moves for retraction / priming in the config files resume.g, pause.g, etc. Never had an issue with 1.17rc3 but maybe something changed with when those files are called? Everything is working fine now by adding an explicit M82 in the header of the gcode.

dc42

What' i think changed is that there was a bug in the 1.17rc you were running whereby a M83 command in config.g was forgotten after config.g completed.

weput

are we implementing soon the Linear Advance Extrusion algo?

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.

weput

@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

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

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

@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

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

Ottobawt

@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

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

fcwilt

How about changing the max speed settings.

Ottobawt

@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

@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.