New experimental firmware 0.78d-dc42 and web interface 0.98

I've released new firmware at [github.com] (follow the link to the version you want and press the Raw button), and new web interface software at [github.com]. The main purpose of these changes is better multi-tool support, but there are some other new features as well.

Changes in firmware 0.78d-dc42 since 0.78c-dc42:

Quote

* M116 command now accepts a P parameter to say which tool you want to wait for. Without the P parameter, it waits for everything as before.

* M220 and M221 can be used to get the override factors as well as set them.

* If the gcode file contains multiple 'filament used' comments (because it uses more than one extruder), all of them are returned to the web interface.

* The initial Z homing speed increased, because Z probing has for several versions been done in two stages. If you are using a switch instead of a probe for Z homing, you may wish to set the homing speed back to the old value using the M210 command.

* The active and standby temperatures for each heater are included in the status response for the web interface.

* Bug fix: the extruder positions got reset when running a macro file.

* Bug fix: if you specified a tool with no heaters or no drives, the tool was configured with a large number of random heaters or drives.

Changes in web interface 0.98 since 0.97:

Quote

* Filament calculations are now correct when more than one extruder is used by a print (needs firmware 0.78d-dc42)

* The active head is highlighted in the temperature control area

* You can select or deselect a head by clicking on it

* Setting the active temperature of a head no longer reselects the head if it is already active

* The SD card file list now includes info, print and trash icons by each filename. To print, click on the print icon, not the filename. Clicking on the info icon displays the file information.

I have included my homing files etc. at [github.com] because some people have asked for them. These files use the centre of the bed as the Z homing position. If you use a Z probe that needs white targets, then you will need to edit homex.g and homeall.g to home Z over one of the targets.

For the full list of differences between 0.78d-dc52 and RRP 0.78, see [github.com].

EDIT: after loading this firmware version, some users may need to send command M301 H1 W180 in order to get full hot end temperature. You need only send this once.

Edited 1 time(s). Last edit at 07/18/2014 05:31AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hi David

In Firmware 078c and 078d i have a temperature Bug.

In My gcode i Set the extruder Temp to 200 for the First Layer.

While starting the print and Heat up the extruder, it stops increase the Temp. By 195. it seems if there is an Offset


Also i have a Feature request for the web Interface. In the quick command section it will ne cool if you can add Buttons for custom gcodes
Like custom1.g and custom2.g

Hi David

Thank you for your work

I have updated to the new version 078d and web interface version 98.
In an older version, it was possible to add a new temperature for the bed, but it does not work for bed, works fine for head temperature.


/Per

---

#445

Quote
muggi
Hi David

In Firmware 078c and 078d i have a temperature Bug.

In My gcode i Set the extruder Temp to 200 for the First Layer.

While starting the print and Heat up the extruder, it stops increase the Temp. By 195. it seems if there is an Offset

Hi Muggi, I reduced the PID_MAX term from 180 to 100 at version 0.78c because I found that a value of 80 was more than enough to reach 250C on my system. But maybe you have a lower powered cartridge heater or low supply voltage. Try sending M301 P1 W180 to put that part of the behaviour back to the way it was in 0.78a. Let me know if that works, if so I'll change it back in 0.78e.

Quote
muggi
Also i have a Feature request for the web Interface. In the quick command section it will ne cool if you can add Buttons for custom gcodes
Like custom1.g and custom2.g

Yes, I agree.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
lehar
I have updated to the new version 078d and web interface version 98.
In an older version, it was possible to add a new temperature for the bed, but it does not work for bed, works fine for head temperature.

Hi Per, thanks for pointing this out. I have updated reprap.js to fix it. I haven't changed the version number, it's still 0.98.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Hi Muggi, I reduced the PID_MAX term from 180 to 100 at version 0.78c because I found that a value of 80 was more than enough to reach 250C on my system. But maybe you have a lower powered cartridge heater or low supply voltage. Try sending M301 P1 W180 to put that part of the behaviour back to the way it was in 0.78a. Let me know if that works, if so I'll change it back in 0.78e.

I'm not Muggi, but have the same problem.
M301 P1 W180 makes the temp overshoot by 6 degrees. M301 P1 W150 seems to be just fine in my case

Kind regards,
Leon

I'm very sorry, I got that command wrong. It should have been M301 H1 W180, not M301 P1 W180. I suggest you reset the Duet and start again because I'm not at my computer and I can't remember the default P value.

If you are getting overshoot, try reducing the P value or the I value with the M301 command. Send M301 H1 to find the current values.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

How am I going to get the original values or the values it had before?
When I send M301 H1 I seem to get the last values set, even after resetting the Duet. It seems to store the last value in flash memory or so.

Kind regards,
Leon

M301 H2 (not in use and probably not affected) returns P5.00 W100
So reverse engineering it seems to be P5.00 W180. Ok, that seems to work without substantial overshoot.
Do I have to include the M301 in config.g or will submitting the command once do?

Kind regrds,
Leon

Good thinking Leon, yes the PID parameters are saved in flash but you've read the defaults from heater 2. The values you've set will be preserved until you next flash the firmware, so no need to put them in config.g. I'll set the initial value of W back to 180 in the next version.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hi David,

This may be a silly question which I have been meaning to ask for sometime. If I have updated a file, say setbed.g, how do I transfer that file without taking the card out?
If I send it to the config button, it ends up in the sys directory and not the gcodes directory. If I send it to Upload & Print Drop/Click it just actions, when I might not want it to.

If I then run setbed.g, the old version in the gcode directory gets actioned.

Am I missing something?

Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Hi Paul, you need to select the Gcode Files tab, then use the SD Upload Drop button.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Hi Paul, you need to select the Gcode Files tab, then use the SD Upload Drop button.

See I told you it was a stupid question, how many times have I looked at that page and not seen the button.

Thanks
Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

very cool, On my printer its showing two Extrude rs. In fact i plane to have two shortly, but down t have the extender board for my Doet controller yet. is there sum-thing in the Config.g file that it looks for to determine the number of extrude-rs?

At present my version of the web interface always shows two heads in the heaters section, and two extruder sliders on the print status tab. However, the number of extruder positions shown in the head position section should match the number of tools you define in config.g. When I have time, I will change it to support more than two hot ends and extruders and to show only those present.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

David,

I must have missed the explanations on the usage of the Print Controls.

If I increase the speed to 120%, I can see that the speed of the head increases, does the amount extruded also increase by to 120%?

If that is the case what was the thinking behind the extruder controls? Under what circumstances would you alter the extruder percentage?

Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

If you increase the print speed by 20% then the extrusion speed also goes up by 20%. The total amount extruded remains the same.

Moving the extruder sliders is like changing tge extrusion factor in slic3r. I find it useful because during a print, sometimes I can see that it is over or under extruding.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Finally came out of the stone age and upgraded to 0.78d. When I was using 0.59, with the nozzle at 1mm from the bed the z-probe (unmodulated) read around 930. Now in the same position it reads around 500. I have moved the probe pin so it's not that. I have M558 P1 set in my config.g, which I believe is correct for this probe type. Should probably mention that I have a 2mm spacer on the nozzle mount as I was having clearance issues between prints and the probe a while ago. Any ideas?

I tend to set the trigger level a bit high and then bring the nozzle down the last 0.2/0.3mm manually to get around ambient light issues etc so it's not really a problem for me, but it seems like a massive change in value!

It's currently printing so (to my surprise) I set up everything correctly, including slic3r. Excellent work on the firmware! Many thanks.

Edited 1 time(s). Last edit at 07/19/2014 01:54PM by static65.

Did you move the blue wire from the z probe to its new position on the expansion connector?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Ran cupple of prints and Tried some Different config.g Files using:

FIRMWARE_NAME:RepRapFirmware
FIRMWARE_VERSION:0.78d-dc42
ELECTRONICSuet + Extension
DATE:2014-07-16

Not-est sum-thing interesting When i try to Set the Axis compensation in the attached config.g file. When i un-comment this line:

; M556 S76.5 X1.5 Y0.0 Z1.5 Set Axis compensation
To
M556 S76.5 X1.5 Y0.0 Z1.5 ; Set Axis compensation

My Z axes starts to lose steps

Anyway, just a pit of testing

oww, When a print is finished i notes that the Extruder drive T1 is stuck in reverse till i power off the printer. hear is my Start and End GCODE:

Start:
G21; set units to millimeters
G90; use absolute coordinates
M83; use relative distances for extrusion
G10 P1 X-20.0 Y-10.0 Z0.0 R0 S195
G1 Z5 F200; lift nozzle
G1 X185 Y15 F2000; Go to wait for warm position
T1
M116 P1 ; Wait for all temperatures
G1 X200 Y200 F9000
G1 E15 F200
G1 Z0.4 F200 ; Put nozzle down for Cleaning
G1 X200 Y15 E20 F900


END:
M140 S0 ; turn bed temperature
G91 ;relative positioning
G1 Z5.00 E-5 F275 ;retract the filament a bit wall lifting the nozzle, to release some of the pressure
G90 ;absolute positioning
G28 X0 ; home X axis
G1 E-10 F275
T0
M84

This to me seems like a firmware bug, or at least unexpected behaviour.

Looking at the firmware source code (GCodes.cpp lines 1745-1753 and 1884-1901 in current dc42 dev branch), it seems that while M82/M83 controls relative/absolute movement for only "E axis", G90/G91 does that for everything, XYZ as well as E. That causes that last move (after doing G90 and X homing) to go to absolute E position -10, which basically means "unwind as much filament as was used during the whole print, and then another 10 mm".

Even if you removed the G90 command, the X homing move probably would include some G90/G91 as well. In any case, since the X axis is already homed in (and is so during the whole print assuming the belt/motor didn't skip), you should be able to accomplish the exact same result with this end gcode:

M140 S0 ; turn bed temperature
G91 ;relative positioning
G1 Z5.00 E-5 F275 ;retract the filament a bit wall lifting the nozzle, to release some of the pressure
G1 X0 E-10 F275
T0
M84

It will move to X0 with a regular move (not homing), and combine it together with the E move for good measure. Personally though, I'm not sure if any retraction after the first 5mm will make much of a difference.

An alternative would be to do an M83 before the last G1 command.


More importantly, firmware gurus: Is it expected/reasonable behaviour that G90/G91 controls relative/absolute coordinates for any other axes than XYZ? You usually do G90/G91 for a different reason (homing and such) than you do M82/M83 (essentially gcode compatibility). If it were to affect E as well, it should probably reset the "current E coordinate" just as M82/M83 does.

I would be happy to write a patch for this, but the code change is pretty trivial and it's more important to define what is the appropriate behaviour in this case.

Edit: Just to be clear, until very recently I was assuming that G90/G91 affected only XYZ, and M82/M83 affected only E, and that is what I personally think is the most reasonable behaviour.

Edited 1 time(s). Last edit at 07/20/2014 05:24AM by jstck.

I think this behaviour is expected, see [reprap.org]. But IMHO this could be used for relative XYZ moves only, I don't really see a reason why it should set extruder moves relative.

gdwinslow: To fix this unwinding bug in your end g-code, you can simply put "G91" before your retraction move.

I'm still looking into the firmware in order to fix another movement bug, at least in my fork I have a problem where extruder feed moves are sometimes not executed properly after a retraction move. I figure this is a problem in the Move code, but this will take me some time to investigate since I'm not too familiar with the DDA/LookAhead code (yet). dc42 could probably explain what may be causing this, and unfortunately RRP's fix in FW 0.89 doesn't seem to help either, but I understand he's still busy with his multi-extruder so I'll definitely have a look at this. Either way I'll report if I find anything.

I didn't realise that G90/G91 sets extruders as well as drives. I don't think this is sensible behaviour, given that we have M82/M83 to set the extruder behaviour. So I'm minded to change it so that G90/G91 doesn't affect extruders in my forthcoming 0.78e-dc42 release. Comments, anyone?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

dc42, I think that makes sense. I will change the behaviour of G90/G91 in my next firmware version as well. Oh, and have a look at M82, you probably don't want to reset the extruder positions if absolute moves are already set.

makes good sense.

I had an issue this morning whilst testing automatic bed levelling and Z homing.

If I repeated the setbed.g then the Z values were all wrong, it was almost like the old set and new set were added together.

I the only way I could get it to work was switching the ormerod off and on.

I thought there was a M code to reset bed compensation but I couldn't find it listed.

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Quote
dc42
Did you move the blue wire from the z probe to its new position on the expansion connector?

Yep sorry, thats what I meant by "I have moved the probe pin" but I wasn't being very clear. If I stick my finger right under the probe it still reads up in the 900's, just seemed odd that the reading changed between firmware versions. Calculated in a different way perhaps?

The z probe reading is calculated in exactly the same way as in previous versions of my fork of the firmware. I know it is working properly because my differential IR z-probe/hot end board generates 4 preset readings, and they all read correctly.

Static65, are you sure that the XY coordinates where z homing is done are the same as the ones you used before? They are defined in the homex.g and homeall.g files.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Yep, same coordinates. I'm using the same homing files as I was in 0.59. As it's only myself that's experienced this it's probably a one-off, or some kind of configuration error on my part, probably when I was running 0.59. It hasn't stopped me printing as I have a manually levelled bed and I home manually anyway.

Sorry, comment on the G90/G91 affecting extrude-rs. All good comments and questions. I think i am to Now to this feald to comment on right way to handle though. I will change my END code for now. Thanks all