Firmware 1.18 released
-
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.
-
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.
-
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.
-
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.
-
are we implementing soon the Linear Advance Extrusion algo?
-
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.
-
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.
-
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?
-
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).
-
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?
-
Yes, your firmwares are out of sync - the DuetWiFiServer version is very old.
-
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.
-
Why not just roll back to 1.15.1 in the meantime to get the order done?
-
How about changing the max speed settings.
-
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.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
-
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.
-
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 -
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.
-
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 -
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.
