New experimental firmware 1.09c-dc42

I've released version 1.09c of my firmware fork at [github.com]. Changes since 1.09b are:

Quote

Fixed two potential divide by zero errors in PrintMonitor
No longer reports an error if a tpre, tpost or tfree macro file is not found
Changed the way bed height errors are reporting after bed probing without calibration (i.e. with parameter S-1 on the final G30 command)
Final Z probing speed is now always 1/3 of the initial probing speed as set by M210 instead of the Z jerk speed
Bug fix: after Z probing, the Z height was set incorrectly by 1 motor microstep, which affected delta calibration
Updated homedelta.g file to use slower final homing and faster positioning after homing

The recommended web interface is still DuetWebControl 1.06.

---

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

Daft question ( i did try and search for an answer first) but as the feeds are all disabled on the web client how do I load filament?

Hi, you need to heat the hot end to 170C or above.
If you want to load with the hot end cold, issue M302 first.

Hope that helps

---

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

Hot end is above 170 *(195) and issued M302 P1, issued M302 and reports back that cold extrudes are on!

However the web control buttons remain grayed out. so do the buttons for LOAD FILAMENT

The only time they are NOT grayed out is when the printer is actually running a file.

You probably haven't selected the tool. Either click on it or send T0 so that it shows up as Active in the web interface. You may wish to add T0 to the end of your config.g file if you have only one extruder.

---

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

That was it!, Thanks I hoped it was something simple.

I have upgraded to the latest Firmware from a version that had the tool set to T1, Although I had changed my slicer settings to T0 (the reason why it worked while printing), the main Config file still said T1.

I have been away from this forum for quite some time, but have been following all the development from the sideline....way too little time for the fun stuff....

My Ormerod have been running incredibly stable with DC42 0.78 firmware and the corresponding web interface. Don't fix something that works :-)

After upgrading to firmware 1.09c and the latest 1.06 web-interface trouble started (tried web-interfaces from both ZPL's and DC42's GitHub accounts). Searching the forum and Googling hasn't clarified anything.

Everything is working fine, except that as soon as I command the Ormerod to do something, nothing happens and the web-interface freezes.

If I try to move an axis, I hear a click from the stepper-motor and the typical PWM-audio noise, but it doesn't move. Setting temperatures and using the "G1" command on the web-console also freezes everything.

I can use Pronterface to move motors and start a print, but the movements are jaggy as if it is delaying G-codes. If I pull out the USB-plug and put it in again (while printing), the Ormerod starts to print normally for some time.

I tried ZPL's firmware together with the web-interface from his GitHub account, and it works perfect.

Please note, that I am using my config.g file from 0.78 unedited. That's the next project :-)

What am I doing wrong here?

Thank you.

Best regards,

Carsten

Sorry, I don't know what would cause that. Zpl and I use the same networking code. If you have an Ormerod 1 then you need to add an M574 line to your config.g file to use my fork, but that wouldn't explain the problems you report. Perhaps you could compare your config.g file with the one in my Github repo.

---

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,

Thanks for the quick reply.

That was not the answer I had hoped for.....I had hoped to be called an amateur (or something worse) and just pointed to the posts, I _should_ have read before trying

I'll check my config.g and the M574 command - and let you know what happens.

:-) Carsten

Regarding loading (and unloading) filament - I find it easiest & quickest to turn off the motor and feed the filament by hand. This gives you feedback if there are any obstructions, and you can feel when the filament reaches the cold nozzle.

Dave

Excuse me but you feed up the filament the whole way to the Extruder that means roughly 400mm by hand? I do this only at the start or end but meanwhile I often use even for this task the Extruder motor.

---

Slicer: Simplify3D 4.0; sometimes CraftWare 1.14 or Cura 2.7
Delta with Duet-WiFi, FW: 1.20.1RC2; mini-sensor board by dc42 for auto-leveling
Ormerod common modifications: Mini-sensor board by dc42, aluminum X-arm, 0.4 mm nozzle E3D like, 2nd fan, Z stepper nut M5 x 15, Herringbone gears, Z-axis bearing at top, spring loaded extruder with pneumatic fitting, Y belt axis tensioner
Ormerod 2: FW: 1.19-dc42 on Duet-WiFi. own build, modifications: GT2-belts, silicone heat-bed, different motors and so on. Printed parts: bed support, (PSU holder) and Y-feet.
Ormerod 1: FW: 1.15c-dc42 on 1k Duet-Board. Modifications: Aluminium bed-support, (nearly) all parts reprinted in PLA/ ABS, and so on.

Quote
Treito
Excuse me but you feed up the filament the whole way to the Extruder that means roughly 400mm by hand? I do this only at the start or end but meanwhile I often use even for this task the Extruder motor.

By hand is faster, and is very easy. Try it.

Dave

I am not able to reach 100mm/s by hand. I am happy to have this function in the WI. If I would transport the filament slowly I may have a chance.

---

Slicer: Simplify3D 4.0; sometimes CraftWare 1.14 or Cura 2.7
Delta with Duet-WiFi, FW: 1.20.1RC2; mini-sensor board by dc42 for auto-leveling
Ormerod common modifications: Mini-sensor board by dc42, aluminum X-arm, 0.4 mm nozzle E3D like, 2nd fan, Z stepper nut M5 x 15, Herringbone gears, Z-axis bearing at top, spring loaded extruder with pneumatic fitting, Y belt axis tensioner
Ormerod 2: FW: 1.19-dc42 on Duet-WiFi. own build, modifications: GT2-belts, silicone heat-bed, different motors and so on. Printed parts: bed support, (PSU holder) and Y-feet.
Ormerod 1: FW: 1.15c-dc42 on 1k Duet-Board. Modifications: Aluminium bed-support, (nearly) all parts reprinted in PLA/ ABS, and so on.

I found my error by comparing my config.g file with your's, David (DC42) and testing back and forth.

I had an "M111 S1" in the top of my config. It turned out, that switching off debug-output made the difference - not the M574, although I was missing that command.

Somehow it makes sense since the connecting and disconnecting USB had an impact.

:-) Carsten

I'm glad you got it working. Sounds like I may have some extra debug in my fork.

---

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
I've released version 1.09c of my firmware fork at [github.com]. Changes since 1.09b are:

Quote

Fixed two potential divide by zero errors in PrintMonitor
No longer reports an error if a tpre, tpost or tfree macro file is not found
Changed the way bed height errors are reporting after bed probing without calibration (i.e. with parameter S-1 on the final G30 command)
Final Z probing speed is now always 1/3 of the initial probing speed as set by M210 instead of the Z jerk speed
Bug fix: after Z probing, the Z height was set incorrectly by 1 motor microstep, which affected delta calibration
Updated homedelta.g file to use slower final homing and faster positioning after homing

The recommended web interface is still DuetWebControl 1.06.

Dave

Another daft Question but where does the M210 command go and what is the format of it Please?

Just about to flash mine with new FW and would like to get it correct.

Doug

The official purpose of M210 is to set the homing speeds in mm per minute, e.g. M210 X1000 Y1000 Z100. But RepRapFirmware defines the homing speeds in the homing files instead. So the only value that matters is the Z value. This is used as the Z probing speed.

The order of commands in config.g mostly doesn't matter, except that the M563 tool definition commands must come before any commands that manipulate tools such as G10 and T0.

---

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
The official purpose of M210 is to set the homing speeds in mm per minute, e.g. M210 X1000 Y1000 Z100. But RepRapFirmware defines the homing speeds in the homing files instead. So the only value that matters is the Z value. This is used as the Z probing speed.

The order of commands in config.g mostly doesn't matter, except that the M563 tool definition commands must come before any commands that manipulate tools such as G10 and T0.

In that case is something like M210 Z100 about right then for the Delta (Which I seem to have got going acceptably now).

Sorry to ask this in the Ormerod section.

Doug

Using an IR probe you can go for a higher because of the reduction to 1/3 speed when it gets close. I am away from my computer, but from memory I think I use Z300 or Z600 on my delta.

---

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

Thank's Dave

is there a Way to Set the 'TEMPERATURE_LOW_SO_DONT_CARE' in the 'config.g' ?

I need to set to 30.0 for my powere off Command

There isn't a gcode to set that value. The problem with reducing it is that if the printer is used in a hot climate then the temperature might never drop enough, e.g. if you select 30C and ambient is 33C. For your power off sequence, I suggest you first set 41C and wait until it is reached. Then set 0C but don't wait. Then use e.g. G4 P60000 to wait 1 minute. Then power off.

---

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

Ok, Thanks

I am trying to update to this firmware. The first post indicates that it needs me to update the web interface to 1.06 but I cannot seem to download the web files to put on the SD card. After a bit of searching I found [github.com] which seems to have the files I need, but I cannot see how to download them. If I go down the "WWW" path I can eventually view each file separately, but if I click on "raw" as I do for the firmware, it just shows the contents as text rather than prompting to save. Must I create all the files manually and copy and paste the contents?

Dave

Hi dmould,

You either need to download the entire firmware repository and or grab the web interface directly from my repository here: [github.com] Once you are at the root of the repo you want to get, click on "Download ZIP" on the right side. This should give you a ZIP file with the whole directory structure. Also keep in mind you can upload all files via FTP, that's probably easier than copying each file one by one (just be aware the firmware can only handle one concurrent upload, so limit the number of concurrent connections to 1 in the server settings before you start).

Thanks - seems that David's github branch does not have the "download zip" option. For me, transferring the www folder to the SD card is still easiest carried out by removing the card.

I quite like the new (for me) web design in 1.06. The only very slight niggle is that it no longer shows "last layer time" - that appears to have been replaced by "first layer time". It was occasionally handy to know how long the last layer had taken to print, but I don't have a use for knowing how long the first layer took - but no big deal, I can get an approximation from the graph when I need it.

Dave

Quote
dmould
Thanks - seems that David's github branch does not have the "download zip" option. For me, transferring the www folder to the SD card is still easiest carried out by removing the card.

I quite like the new (for me) web design in 1.06. The only very slight niggle is that it no longer shows "last layer time" - that appears to have been replaced by "first layer time". It was occasionally handy to know how long the last layer had taken to print, but I don't have a use for knowing how long the first layer took - but no big deal, I can get an approximation from the graph when I need it.

Dave

Actually David's Github does have the Download Zip option you just have to go up one level to the Whole of it (IE DC42 Github complete listing which is the same as ZPL's Firmware repository.

ZPL has just made the WWW available in a separate Github as well

Doug

Quote
dmould
I quite like the new (for me) web design in 1.06. The only very slight niggle is that it no longer shows "last layer time" - that appears to have been replaced by "first layer time". It was occasionally handy to know how long the last layer had taken to print, but I don't have a use for knowing how long the first layer took - but no big deal, I can get an approximation from the graph when I need it.

Thanks Dave, I'm glad to hear you like it. It's right that the last layer time is not displayed in a table cell, but as you already said you can read it more or less from the layer time chart. I'm considering to add an animation to the "current layer time" cell though, so the layer time is highlighted and stops counting for 2 seconds whenever a layer change occurs. I still have a lot of other things to do first, but I think I'll get back to this in my next webif release.

If you are changing the web interface, one suggestion is to get rid of the multiple print time estimations (which take up space and can be confusing), and just have one based on the most accurate parameter available. The most accurate is filament length, the next is layer time, and the least accurate is file percentage. So if you can get total filament from the G-code file, use only that, otherwise layer time unless Z height is unavailable, and file percentage as the last resort.

Dave

I like having multiple print times. I use absolute extrusion and Cura zeroes the extruder roughly every 10000mm, so estimates on filament usage get knocked out of whack.

What I would like though, in the vein of time to completion, is if we could automatically store the time it took to print a file