New firmware 0.89i and web interface 1.03

I've just released version 0.89i of my firmware and version 1.03 of my web interface fork. Apart from a few other changes, this updated firmware is now able to queue non-moving G-Codes and to execute them just-in-time. This enables users to utilize the full potential of filament cooling using M106/M107 and should generally resolve a bug where non-printing G-Codes were executed too early. These changes were quite tricky, but I think I've got it all working now.

Here is the complete changelog for this firmware version:

Quote

Merged in more changes from dc42's latest firmware 0.78r (thanks dc42!)
Implemented cold retracts (minimum temperature is 90°C)
G28 and M1 reset homed axes
M0 does no longer disable any drives, M1 still does
Implemented internal G-Code queue to execute codes in-time
When prints are paused, moves stop right after the current move completes
Other minor changes
Firmware binary built with O3 optimization enabled
Updated Arduino libraries to 1.5.6_r2, core patches are on my repo

It is not mandatory to update the web interface if you're using version 1.00 or later, but it is definitely recommended, because the pause/reset code has changed from M1 to M0 in my fork. All other changes include:

Quote

Rebase from dc42's latest web interface fork (thanks again, dc42!)
Message log can now display line breaks properly
Fan RPM heading is displayed in one line only
Added G32 (automatic bed compensation) to the quick commands

You can download this firmware binary here and my updated web interface fork here.

If you decide to give it a try and encounter any issues, please report them. Feedback is welcome!

Edited 1 time(s). Last edit at 09/09/2014 01:22PM by zombiepantslol.

when i print thing stop working when temp for extruder is met. temp going down after temp is met and it wont print after that.

M111 S0 ; Debug off
M550 PAnthony's Ormerod 3D Printer ; Machine name (can be anything you like)
M551 Preprap ; Machine password (currently not used)
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Address
M552 P192.168.1.14 ; IP address
M553 P255.255.255.0 ; Netmask
M554 P192.168.1.1 ; Gateway
M555 P2 ; Set output to look like Marlin
G21 ; Work in millimetres
G90 ; Send absolute corrdinates...
M83 ; ...but relative extruder moves
M906 X800 Y1000 Z800 E800 ; Set motor currents (mA)
M563 P1 D0 H1 ; Define tool 1
G10 P1 S0 R0 ; Set tool 1 operating and standby temperatures
M92 E433 ; Set extruder steps per mm
M558 P1 ; Use an unmodulated Z probe
G31 Z1.22 P656 ; Set the probe height and threshold
M557 P0 X65 Y10 ; Four...
M557 P1 X65 Y160 ; ...probe points...
M557 P2 X200 Y160 ; ...for bed...
M557 P3 X200 Y10 ; ...levelling
M556 S78 X0 Y0 Z0 ; Put your axis compensation here
M201 X800 Y800 Z15 E1000 ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z60 E3600 ; Maximum speeds (mm/min)
M566 X800 Y800 Z30 E20 ; Minimum speeds mm/minute

Your config file looks good, so I figure it has something to do with your start G-code. Can you please attach the complete G-code file you were trying to print?

G21 ; set units to millimeters
M107
M190 S60 ; wait for bed temperature to be reached
M104 S195 ; set temperature
T1
M107
G28
M109 S195 ; wait for temperature to be reached
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
G1 F1800.000 E-2.40000
G1 Z0.200 F7800.000
G1 X80.791 Y84.693 F7800.000
G1 E2.40000 F1800.000

Hi zombiepantslol

Does your firmware include the dc42 changes to G10 for the nozzle offset? they are in RepRapFirmware-078s-alpha-dc42.bin

Thanks for your hard work
Paul

Edited 1 time(s). Last edit at 09/15/2014 08:41AM by appjaws1.

---

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

antlvk, that sounds like a temperature fault to me. Can you see anything unusual in the message log? I suggest you check your wiring again and upgrade to 0.89j.

Paul, I've just released 0.89j on GitHub. This binary contains most of dc42's changes for 0.78s, including his modifications for G10 offsets, but I haven't merged in his new LCD code yet. If you give it a try, please let me know if it's all working

Quote
zombiepantslol
Paul, I've just released 0.89j on GitHub. This binary contains most of dc42's changes for 0.78s, including his modifications for G10 offsets, but I haven't merged in his new LCD code yet. If you give it a try, please let me know if it's all working

Just thought I would let you know, the firmware and web interface seems to be working fine. I am just completing a 2 colour test item, so the G10 codes are definitely working well and as far as I can tell everything else is working. More testing in the morning.

Thank you for your efforts.

---

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

Thanks for your feedback!

Shouldn't be wires. Cause everytime the extruder will heat perfectly and fast. just as the temp met the head become on active and temp goes down. i try out the new firmware first. thanks

ok it works with your new firmware but having problem with web control


extruder control what ever setting i use also only load by 1mm i cant load 400mm, it will take ages to load my filament, lol

Quote
antlvk
ok it works with your new firmware but having problem with web control


extruder control what ever setting i use also only load by 1mm i cant load 400mm, it will take ages to load my filament, lol

I think the Head needs to be active and up to temperature for the extruder control to work.

---

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

There appears to be a problem when changing which head is the active one.
1, From cold it take a long time for the selection to be recognised and actioned.
2. When the selection is actioned the head moves in the X direction.

I think one of the problems is that to change from head 1 active to head 2, the system seems to wait for the working temperature to be reached on head 1 before it will switch to standby.
e.g.

Switching from Head 1 to Head 2 will only take place when Head 1 has reached temperature and then the head moves in the X direction, towards X0
Switching from Head 2 to Head 1 will only take place when Head 2 has reached temperature and then the head moves in the X direction, away from X0

Manually switching heads should not wait for any temperature to be reached and their should be no movement in the X direction.

Hope the above is clear
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

When you select a head, the previously selected head (if any) is deselected and the corresponding tfree file is run. Then the tpre file for the new head is run, the head is selected, and the tpost file is run. So any pauses and head movement you are seeing are probably caused by commands in those 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].

Quote
appjaws1

Quote
antlvk
ok it works with your new firmware but having problem with web control


extruder control what ever setting i use also only load by 1mm i cant load 400mm, it will take ages to load my filament, lol

I think the Head needs to be active and up to temperature for the extruder control to work.

Yes, that is correct, My firmware fork has cold extrudes disabled by default, however you can enable them again using "M302 P1". The minimum extrusion temperature is 160°C and for cold retracts you'll need at least 90°C.

Paul, as far as I can see, dc42's tpost macros contain M116. That's probably the reason you have to wait quite a while before the new tool is actually selected - assuming you have an active temperature set at this point. Also, the tfree macros contain a single move (G1 X1 Y5 F6000) and these seem to be executed whenever a tool is deselected, so I guess this is explains why you experience moves on each tool change. I don't have a 2-nozzle Ormerod here, so can you please tell me how the firmware is intended to react to those commands? Does dc42's fork do anything differently at this point? Or does it make sense to prevent these G1 codes from being executed if G10 offsets were already specified?

As promised I've just released version 0.89k with S3D support on [github.com]

Thanks to dc42 and zombiepantslol ,

I think the problem, if it is a problem, is the head position in tfree is needed during normal operations but of course the actual head position takes into account the offset. So on change of head the head is being moved by the offset amount.

I don't think we need to change any firmware I will just apply the offset manually in the tfree files so that the net movement of the heads is zero.

I'm in the middle of a print at the moment so will confirm this solves the problem later.
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

Quote
zombiepantslol
As promised I've just released version 0.89k with S3D support on [github.com]

Fantastic - thank you so much @zombiepantslol

Thanks for your feedback I just had to update the firmware binary of 0.89k though, because the extrude buttons (in particular due to a problem with M121) caused moves to be executed twice with wrong feedrates.

Quote
zombiepantslol
As promised I've just released version 0.89k with S3D support on [github.com]

Thank you very much indeed, it is greatly appreciated. What web files does that firmware use? I also assume that the X motor is reversed (compared to firmware of a couple of months ago) - or have you kept the RRP original direction?

Dave

Dave, my web interface is basically identical to dc42's fork (version 1.02). There are just a few minor modifications, e.g. M0 is executed on Pause/Reset, so the stepper motors aren't disabled whenever a print is cancelled. If anything goes wrong at the first layer, you won't have to home all axes again.

The default X axis direction is still inverted (as of RRP's dev firmware 0.86), but you can add

M569 P0 S1

to your config.g file if you don't want to turn around that connector on the Duet.

Paul, you could try moving the G1 command from the tfree files to the tpre files, then I don't think they should be affected by the nozzle offsets because no tool is selected at that point.

---

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
Paul, you could try moving the G1 command from the tfree files to the tpre files, then I don't think they should be affected by the nozzle offsets because no tool is selected at that point.

Thank you David, I have made the change but can't test until later.

Quote
zombiepantslol
As promised I've just released version 0.89k with S3D support on [github.com]

Thank you, the filament and layer details are working great.

---

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

I've just released version 0.89l on GitHub. The changes in this release are:

Quote

M18 and M84 (disable drives) can disable specified axes and extruders only
More diagnostics code added
Improved file info detection
Other minor changes