New experimental firmware 0.96c and web interface 1.07

Whoah, I'm very pleased to release version 0.96c of my firmware fork as I've improved a lot of things this time. Here is the complete changelog of my latest firmware release:

Quote

Updated Arduino toolkit to 1.5.8 (patches can be found in ArduinoCorePatches)
- Merged in more of RRP's dev firmware 0.94 to be able to build the firmware again (thanks Adrian)
Code queue items are allocated on start-up, dynamic allocation is no longer used in my firmware fork
Removed some redundant code (Platform:etZProbing, HEAD_OFFSETS)
Code checks for code queueing improved and added proper description for design principles
M0 only turns off all drives and heaters if the print is NOT paused, although current tool is deselected at all times
GCodes: Replaced Platform::Message calls with reply.copy where applicable
Requirement to specify all the extruders for M92, M201, M203, M566 and M906 no longer exists
Implemented M500 (Store parameters in EEPROM) and M502 (Reset parameters)
Implemented M501 (Load parameters from EEPROM) with "S" parameter to enable auto-save (for backward compatibility)
Firmware can be built without Flash support; requires only one line to be commented out
PIDs return ABS_ZERO as current temperature if heater faults occur (web interface v1.07 will then display "error")
Vastly improved networking, increased both performance and available RAM (now I get 13k of free RAM)
Added Diagnostics call to Network class and moved all parameters to the Network header file
Fixed issue where "Skipping zombie request" was occasionally written to the serial interface
Bug fix: Old-fashioned G32 (without macro file) resets current bed compensation automatically
Bug fix: G4 waits for all moves to finish (only related to my fork)

Note: Since Flash usage has become optional for my fork as per this release, it does no longer load parameters from the Flash storage on start-up. This means you MUST add "M501 S1" to the beginning of your config.g file if you want to use Flash support as known from dc42's or my older releases. I strongly advise you not to put it at the end of your config file, because it may then overwrite preset parameters with default firmware values.

If you've been using RRP's official or dc42's long-time proven firmware and want to give my firmware fork a try, please see here for a few things you must take care of when switching to my firmware fork.

Along with this firmware release, I've also improved the web interface quite a bit and pushed its version to 1.07. Here a list of the changes I made this time:

Quote

Rearranged tables on the Control page:
- Quick commands are now displayed in a vertical button group and changed button order
- Extruder control moved below "Move Head Position"
Removed second slider for extrusion factor; users can now switch through each extruder by clicking on the label
Print progress is only updated if print start time is known
Panic buttons now write messages to the log
Moved "show OK" checkbox to the settings
Ability to upload jpg and jpeg files to the img directory
Vastly improved message log, last G-Code is logged along with its output
Print control sliders are disabled on disconnect
Many default values are displayed in the HTML file
Rearranged parameters on the Settings tab
Added glyphicons to a few buttons
Refresh button on the Gcode files tab is displayed in line with SD Upload Drop
Replaced target link of "get help here" with Ormerod forum
Added links to iamburny's, dc42's and my GitHub sites
If a heater fault occurs, "error" will be displayed in the head temperature cell
Minor bug fixes

If you're upgrading from an older release of iamburny's web interface, you only need to replace these files:

Quote

reprap.htm
js/reprap.js
css/bootstrap-slider.min.css
css/main.css

Please note: Since I'm still running my Ormerod with only one nozzle, I haven't been able to test the new Extrusion Factor slider. Because the slider for Extruder 2 has been removed, you may now click on the "Extr" header to switch to the next available extruder. I'd appreciate if anyone with two (or more) nozzles could test this and give me some feedback here. You may also use my web interface fork with dc42's firmware, although I haven't tested it with that one. However, since we're both using nearly the same protocols, it should work just fine.

You can get the latest firmware binary here and my web interface fork here (click on "Download ZIP" and extract it to your /www directory).

As always I'd appreciate to see some feedback If you have any questions, concerns or bug reports, please report them here and I'll see how I can help.

Nice work, ZPL! I've forwarded a link to Adrian.

Ian
RepRapPro tech support

Thanks. I gave this a go.

I compiled from source under 1.5.8 and it loads and runs fine with 1.0.7 web interface.

I get a significantly smaller bin (~200k) so I think my compile options must be different. I was using -O2 with 1.5.6 and that used to give me about 260k so maybe the options are different with 1.5.8 and it is optimising for small.

The 1.0.7 browser window works fine maximised with a 1280 x 1024 screen but if I have it shrunk even slightly then the elements start overlapping with quite a lot of left hand margin left clear. I'll have a look to see what the CSS is doing on my system.

Yes, you probably get a smaller binary because I build my firmware binaries with -O3 optimization enabled. Nice to hear it compiles well on different machines though, so thanks for your feedback!

I've been using Chrome to access my machine and I haven't had any problems resizing the web interface - may I ask which browser you're using? I intend to further improve the web interface for mobile devices, but IMO there were more important things to do first.

Quote
zombiepantslol
Yes, you probably get a smaller binary because I build my firmware binaries with -O3 optimization enabled. Nice to hear it compiles well on different machines though, so thanks for your feedback!

I've been using Chrome to access my machine and I haven't had any problems resizing the web interface - may I ask which browser you're using? I intend to further improve the web interface for mobile devices, but IMO there were more important things to do first.

Compiled on Ubuntu 12.04, Eclipse Luna, Arduino 1.5.8 compiler.

Compiled with -O3 gives 249K so that is closer.

Browser is latest Chrome on Ubuntu.
Maximised all looks OK


Non maximised but close in size. Now buttons go to the right and overlap, Graph goes wrong and extruder controls spill over.

Quote
bobtidey
Compiled on Ubuntu 12.04, Eclipse Luna, Arduino 1.5.8 compiler.

Compiled with -O3 gives 249K so that is closer.

I've been using nearly the same setup here, except I've been running Arch Linux natively. Your binary size sounds right though, in fact my firmware binary should be just as big.

Quote
bobtidey
Non maximised but close in size. Now buttons go to the right and overlap, Graph goes wrong and extruder controls spill over.

I see, now I get what you mean. I'm surprised the chart auto-resizes itself though, I didn't expect that. The reason the extruder buttons start overlapping is because I had to move the labels into their own table cells to get them vertically centered. I'm no HTML professional and have been trying to improve my HTML/Bootstrap knowledge by customizing the web interface, so if you come up with a better solution, I'd appreciate to see it

I checked browsing from a different PC with a widescreen monitor and as I sort of suspected this is more to do with window width rather than when it is maximised.

As I shrink the width down the internal layout remains fixed and centralised within the overall frame (both left and right margins reduce. Then at about 1210 pixel window width the left and right margins are down to about 25 pixels with the central region remaining fixed at about 1160. Going below this the CSS positioning flips and repositions stuff.

So the issue with my second screenshot is really that the width of the browser frame can't accommodate the fixed elements of this particular screen layout.

Not a huge issue providing one has the window large on at least a 1280 wide screen. It is not helped in my case by Ubuntu putting the launcher bar in a fixed position down the side of the screen. It is a bit irritating when trying to do file drags.

One might be able to save a little bit of real estate in the layout whilst still keeping it a fixed size. E.g. the move control buttons are generously sized, and the extruder feeds could be relabelled as feed is a bit redundant. For the upper half either the graph could be shrunk a bit horizontally or the connect, stop, pause repositioned.

I might have a little go at seeing how much could be saved while still keeping it looking nice.

Quote
bobtidey

One might be able to save a little bit of real estate in the layout whilst still keeping it a fixed size. E.g. the move control buttons are generously sized, and the extruder feeds could be relabelled as feed is a bit redundant. For the upper half either the graph could be shrunk a bit horizontally or the connect, stop, pause repositioned.

I might have a little go at seeing how much could be saved while still keeping it looking nice.

I always thought that the design of a web page should be able to accommodate most if not all screen sizes and that key fields would automatically adjust to accommodate the screen pixel count, this would include changing the font size etc. Perhaps I'm wrong, it has been a very long time since I had a dabble with web design.

---

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
appjaws1

I always thought that the design of a web page should be able to accommodate most if not all screen sizes and that key fields would automatically adjust to accommodate the screen pixel count, this would include changing the font size etc. Perhaps I'm wrong, it has been a very long time since I had a dabble with web design.

Web design for desktop seems to fit into two camps; resizable, fixed. Many modern web sites particularly commercial ones belong to the fixed camp. They want to control the exact look and feel, and ensure everything works correctly. Changing browser width just changes margins, just like the iamburny-ormerod. Dynamic ones are often of the forum / blog variety where table columns widths are varied.

Where I think this ormerod layout differs is that a lot of fixed width sites assume a minimum 1024 width whereas this layout needs more like 1200.

Relaying to fit a 1024 might be nice, but is complicated a bit by the tabbed lower half so a lot of stuff needs tweaking.

@zombiepantslol Loaded your firmware and web interface.

I needed to stop a print so I pressed Pause and the print stopped but I could not raise the head, none of the controls worked.
I then pressed reset and again nothing worked and all this time I had the hot end in contact with the print.
The only way I could move the Z axis was to switch off and on the ormerod.

I thought that if the Pause was pressed you should be able to move any of the axis and either resume the print or reset. If reset, the current job should be cleared and the printer returned to the wait state with the bed temp and the home positions maintained, waiting for the next print.

You say in your release that Flash usage has become optional for my fork. Could you explain the pros and cons of using this please
Could this be the reason that I could not get any head movement after a pause? Do I really need to add M501 S1" to the beginning of my config.g file ?

As always thanks 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

bobtidey: I'm aiming to get the page scale down properly to 720px, but I need to touch the whole layout again to achieve this. My motivation for this change is my tablet, since I want to use it to monitor my prints sooner or later. I don't know when I get time for this again, but as I said, I want to implement it on a long-term view.

Quote
appjaws1
I needed to stop a print so I pressed Pause and the print stopped but I could not raise the head, none of the controls worked.
...
I thought that if the Pause was pressed you should be able to move any of the axis and either resume the print or reset.

Yes Paul, this behaviour is intended, at least partially. The issue is when you pause a running print with my firmware fork, the movement will stop as soon as the current move finishes. But because the firmware doesn't know whether you want to resume your print or not, it doesn't allow any move-related codes to be executed as long as it's still paused. The reason for this is because it still has ~29 cached moves left to be executed at that time, and it's nearly impossible to "inject" another move at that state. At the moment this is the price to pay if you want to be able to pause the print almost instantly, but I want to improve it as soon as the Move code has become more "mature", i.e. when it provides smoother accelerations/decelerations, possibly a working bowden-tube elasticity compensation and refined drive stepping routines. Either way, this behaviour isn't new to my fork; in fact I changed the firmware to behave this way back in my 0.89 release.

Quote
appjaws1
I then pressed reset and again nothing worked and all this time I had the hot end in contact with the print.
The only way I could move the Z axis was to switch off and on the ormerod.

That sounds odd. I just tried to reproduce this problem, but without success. I paused a running print, pressed Pause, then Reset and my print stopped just as I expected. If this happens to you again, can you please post the output of M122 while it's paused and after you try to reset the print? That may help me figure out what went wrong on your machine.

Quote
appjaws1
You say in your release that Flash usage has become optional for my fork. Could you explain the pros and cons of using this please
Could this be the reason that I could not get any head movement after a pause? Do I really need to add M501 S1" to the beginning of my config.g file ?

The main reason Flash usage has become optional is because RRP wants their machines to start up in a neutral and identical state, which means all the settings should be set within the config.g file. I can understand this argument to some extend, because I wouldn't want to start troubleshooting end-user problems if I didn't exactly know what their actual configuration looks like. If some parameters (e.g. PID values) were modified earlier and saved to Flash-EEPROM, it can become quite difficult to find out why a machine isn't working the way it's supposed to. But this has absolutely nothing to do with the pause issue you mentioned. If you want to utilise Flash usage as known from dc42's or my older releases, you must add the command I mentioned to your config file. Otherwise your changes will be lost when you turn off your printer unless you set up those parameters anyway in your config.g file.

Edited 1 time(s). Last edit at 11/12/2014 01:05PM by zombiepantslol.

Quote
zombiepantslol
bobtidey: I'm aiming to get the page scale down properly to 720px, but I need to touch the whole layout again to achieve this. My motivation for this change is my tablet, since I want to use it to monitor my prints sooner or later. I don't know when I get time for this again, but as I said, I want to implement it on a long-term view.

This is a great idea and will be very useful for anybody who wants to control their Ormerod using other web devices, like a RPi, tablet or phones.

Quote
zombiepantslol
Yes Paul, this behaviour is intended, at least partially. The issue is when you pause a running print with my firmware fork, the movement will stop as soon as the current move finishes. But because the firmware doesn't know whether you want to resume your print or not, it doesn't allow any move-related codes to be executed as long as it's still paused. The reason for this is because it still has ~29 cached moves left to be executed at that time, and it's nearly impossible to "inject" another move at that state. At the moment this is the price to pay if you want to be able to pause the print almost instantly, but I want to improve it as soon as the Move code has become more "mature", i.e. when it provides smoother accelerations/decelerations, possibly a working bowden-tube elasticity compensation and refined drive stepping routines. Either way, this behaviour isn't new to my fork; in fact I changed the firmware to behave this way back in my 0.89 release.

Thank you for the explanation. What is the point of pausing a print if you can't do anything and the hot end is in contact with and melting, the printed object ? I would have thought that as a minimum the hot end should be raised and then returned if the print is resumed. I know this would be difficult but could you not have an over-ride queue that would be actioned on the pressing of pause?

Quote
zombiepantslol
That sounds odd. I just tried to reproduce this problem, but without success. I paused a running print, pressed Pause, then Reset and my print stopped just as I expected. If this happens to you again, can you please post the output of M122 while it's paused and after you try to reset the print? That may help me figure out what went wrong on your machine.

.

I'll check again in the morning and send the results.

Quote
zombiepantslol
The main reason Flash usage has become optional is because RRP wants their machines to start up in a neutral and identical state, which means all the settings should be set within the config.g file. I can understand this argument to some extend, because I wouldn't want to start troubleshooting end-user problems if I didn't exactly know what their actual configuration looks like. If some parameters (e.g. PID values) were modified earlier and saved to Flash-EEPROM, it can become quite difficult to find out why a machine isn't working the way it's supposed to. But this has absolutely nothing to do with the pause issue you mentioned. If you want to utilise Flash usage as known from dc42's or my older releases, you must add the command I mentioned to your config file. Otherwise your changes will be lost when you turn off your printer unless you set up those parameters anyway in your config.g file.

Great explanation, now I understand I have added "M501 S1" to the beginning of my config.g file.

---

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

That sounds odd. I just tried to reproduce this problem, but without success. I paused a running print, pressed Pause, then Reset and my print stopped just as I expected. If this happens to you again, can you please post the output of M122 while it's paused and after you try to reset the print? That may help me figure out what went wrong on your machine.

I paused a print and the print stopped immediately and no movement controls worked as you explained.
I then pressed reset and the movement controls went from dim to fully displayed but the buttons had no response. If I try and set the Head1 temp to zero, the box changed to zero and then displayed the last print temperature, in my case 193.
If I press "STOP" then the controls work and I can move the head but I have lost all of the bed compensation and homing settings.
The result of this is that I will need to go through the whole start up routine again for a new print.
I issued M122 and the following is a copy of the message log, I hope that is correct.

; RepRapPro Ltd
M111 S0 ; Debug off
M501 S1 ; use flash
M550 Pappjaws-Ormerod ; 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
M208 X200 Y200 Z180 ; Set axis travel
M208 X5 S1 ; Set axis minimum
M906 X950 Y950 Z950 E850 ; Set motor currents (mA)
M305 P0 H-5
M305 P1 H50
;M305 P2 H-55
M563 P1 D0 H1 ; Define tool 1
G10 P1 X0 Y0 Z0 S0 R0 ; Set tool 1 offset, operating and standby temperatures
;M563 P2 D1 H2 ; Define tool 2
;G10 P2 X-6 Y0 Z0 S0 R0 ; Set tool 2 offset, operating and standby temperatures
M92 E420 ; Set extruder steps per mm
M558 P1 ; Use an unmodulated Z probe
G31 Z1.0 P500 ; Set the probe height and threshold
M557 P0 X35 Y35 ; Five...
M557 P1 X35 Y180 ; ...probe points...
M557 P2 X185 Y180 ; ...for bed...
M557 P3 X185 Y35 ; ............
M557 P4 X100 Y105 ; ...levelling
M556 S74.5 X-0.56 Y0.18 Z0.267 ; Put your axis compensation here
M201 X800 Y800 Z15 E1000 ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z100 E3600 ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E20 ; Minimum speeds mm/minute
M140 R45 ; set bed standby temperature to 30C
M106 S0 ; set extra fans off
11:22:07Print cancelled!
11:21:58M25
Error: Cannot pause print, because no file is being printed!
11:21:57Print paused!
11:21:24File [tempWebPrint.gcode] sent to print
11:18:05File [setman.g] sent to print
11:16:16M503
; Configuration file for RepRap Ormerod

; RepRapPro Ltd
M111 S0 ; Debug off
M501 S1 ; use flash
M550 Pappjaws-Ormerod ; 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
M208 X200 Y200 Z180 ; Set axis travel
M208 X5 S1 ; Set axis minimum
M906 X950 Y950 Z950 E850 ; Set motor currents (mA)
M305 P0 H-5
M305 P1 H50
;M305 P2 H-55
M563 P1 D0 H1 ; Define tool 1
G10 P1 X0 Y0 Z0 S0 R0 ; Set tool 1 offset, operating and standby temperatures
;M563 P2 D1 H2 ; Define tool 2
;G10 P2 X-6 Y0 Z0 S0 R0 ; Set tool 2 offset, operating and standby temperatures
M92 E420 ; Set extruder steps per mm
M558 P1 ; Use an unmodulated Z probe
G31 Z1.0 P500 ; Set the probe height and threshold
M557 P0 X35 Y35 ; Five...
M557 P1 X35 Y180 ; ...probe points...
M557 P2 X185 Y180 ; ...for bed...
M557 P3 X185 Y35 ; ............
M557 P4 X100 Y105 ; ...levelling
M556 S74.5 X-0.56 Y0.18 Z0.267 ; Put your axis compensation here
M201 X800 Y800 Z15 E1000 ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z100 E3600 ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E20 ; Minimum speeds mm/minute
M140 R45 ; set bed standby temperature to 30C
M106 S0 ; set extra fans off
11:16:15config.g Upload Complete in 00s
11:16:15File Upload of config.g to sys/config.g started
11:16:09M503
; Configuration file for RepRap Ormerod


; RepRapPro Ltd
M111 S0 ; Debug off
M501 S1 ; use flash
M550 Pappjaws-Ormerod ; 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
M208 X200 Y200 Z180 ; Set axis travel
M208 X5 S1 ; Set axis minimum
M906 X950 Y950 Z950 E850 ; Set motor currents (mA)
;M106 S35 ; set fan PWM to 35%
M563 P1 D0 H1 ; Define tool 1
G10 P1 X0 Y0 Z0 S0 R0 ; Set tool 1 offset, operating and standby temperatures
;M563 P2 D1 H2 ; Define tool 2
;G10 P2 X-6 Y0 Z0 S0 R0 ; Set tool 2 offset, operating and standby temperatures
M92 E420 ; Set extruder steps per mm
M558 P1 ; Use an unmodulated Z probe
G31 Z1.0 P500 ; Set the probe height and threshold
M557 P0 X35 Y35 ; Five...
M557 P1 X35 Y180 ; ...probe points...
M557 P2 X185 Y180 ; ...for bed...
M557 P3 X185 Y35 ; ............
M557 P4 X100 Y100 ; ...levelling
M556 S74.5 X-0.56 Y0.18 Z0.267 ; Put your axis compensation here
M201 X800 Y800 Z15 E1000 ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z100 E3600 ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E20 ; Minimum speeds mm/minute
M140 R45 ; set bed standby temperature to 30C
M106 S0 ; set extra fans off
11:00:07M503
; Configuration file for RepRap Ormerod

; RepRapPro Ltd
M111 S0 ; Debug off
M501 S1 ; use flash
M550 Pappjaws-Ormerod ; 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
M208 X200 Y200 Z180 ; Set axis travel
M208 X5 S1 ; Set axis minimum
M906 X950 Y950 Z950 E850 ; Set motor currents (mA)
;M106 S35 ; set fan PWM to 35%
M563 P1 D0 H1 ; Define tool 1
G10 P1 X0 Y0 Z0 S0 R0 ; Set tool 1 offset, operating and standby temperatures
;M563 P2 D1 H2 ; Define tool 2
;G10 P2 X-6 Y0 Z0 S0 R0 ; Set tool 2 offset, operating and standby temperatures
M92 E420 ; Set extruder steps per mm
M558 P1 ; Use an unmodulated Z probe
G31 Z1.0 P500 ; Set the probe height and threshold
M557 P0 X35 Y35 ; Five...
M557 P1 X35 Y180 ; ...probe points...
M557 P2 X185 Y180 ; ...for bed...
M557 P3 X185 Y35 ; ............
M557 P4 X100 Y100 ; ...levelling
M556 S74.5 X-0.56 Y0.18 Z0.267 ; Put your axis compensation here
M201 X800 Y800 Z15 E1000 ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z100 E3600 ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E20 ; Minimum speeds mm/minute
M140 R45 ; set bed standby temperature to 30C
M106 S0 ; set extra fans off
10:59:55M115
FIRMWARE_NAME:RepRapFirmware FIRMWARE_VERSION:0.96c-zpl ELECTRONICSuet (+ Extension) DATE:2014-11-09
10:59:51Page Load Complete

---

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 noticed something else, the Head 1 temperature is set at 193 for the print but the displayed temperature is showing 189.4 when the print started, on layer 6 the current temperature has reached 192.2, 5m into the print. The correct temp of 193 was reached after 6m 13 sec of the print start.

I have never had this problem before. The hot end always reached temperature quickly, all-be-it with a slight overshoot.
After 8mins the temperature is being maintained to what has been set +- 0.4.

---

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
appjaws1
What is the point of pausing a print if you can't do anything and the hwholeot end is in contact with and melting, the printed object ? I would have thought that as a minimum the hot end should be raised and then returned if the print is resumed. I know this would be difficult but could you not have an over-ride queue that would be actioned on the pressing of pause?

At the present time the whole purpose of the Pause button is to simply make movements stop, so you can either resume or reset the current print. I personally don't see any real advantages in allowing moves while a print is paused when using the current firmware, e.g. because the nozzle will start oozing very quickly. If it were possible to set up custom macro files to define exactly what should happen when a print is either being paused or resumed, we could define extra retractions (and feed moves, respectively), tool (de)selection and custom moves to be executed just-in-time. This may be implemented eventually in the firmware though, which is why I haven't replaced the Pause button with "Reset Print", but I won't change this behavior in my firmware fork until I see a good reason to do so.

Regarding your diagnostics output: Sorry, but I can't see any M122 call in there - are you sure you ran M122 and not M503? Your config.g file is quite useless to obtain the necessary debug information in this case. FYI, a typical M122 output looks like this:

Quote

M122
Platform Diagnostics:
Memory usage:
Program static ram used: 47172
Dynamic ram used: 35068
Recycled dynamic ram: 3776
Current stack ram used: 1616
Maximum stack ram used: 3880
Never used ram: 8408
Last reset 00:00:34 ago, cause: power up
Last software reset code & available RAM: 0x0000, 13192
Error status: 0
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
Free file entries: 10
Longest block write time: 0.0ms
Slowest main loop (seconds): 0.011175; fastest: 0.000053
Move Diagnostics:
State: running
Heat Diagnostics:
Heater 1: I-accumulator = 0.0
GCodes Diagnostics:
Internal code queue is empty.
Network diagnostics:
Free connections: 15 of 16
Free transactions: 23 of 24
Free send buffers: 19 of 20
Webserver Diagnostics:

Oh, and the heater code hasn't changed in my latest releases, so I suggest you increase your heater "S" value a bit. See dc42's 0.78e firmware release on how to adjust this particular parameter using M301. I bet dc42 could give you better advice on this, I must admit I'm not too familiar with PID controllers (yet).

Quote
zombiepantslol
At the present time the whole purpose of the Pause button is to simply make movements stop, so you can either resume or reset the current print. I personally don't see any real advantages in allowing moves while a print is paused when using the current firmware, e.g. because the nozzle will start oozing very quickly. If it were possible to set up custom macro files to define exactly what should happen when a print is either being paused or resumed, we could define extra retractions (and feed moves, respectively), tool (de)selection and custom moves to be executed just-in-time. This may be implemented eventually in the firmware though, which is why I haven't replaced the Pause button with "Reset Print", but I won't change this behavior in my firmware fork until I see a good reason to do so.

One potential use of the pause button is to allow you to insert a captive nut that is going to be buried inside the part. In that case you may need to move the head out of the way, insert the nut and move the nozzle back before resuming.

Dave

Quote
dmould
One potential use of the pause button is to allow you to insert a captive nut that is going to be buried inside the part. In that case you may need to move the head out of the way, insert the nut and move the nozzle back before resuming.

Yes that's true, but when using my fork, moves will stop as soon as the current move has finished. Especially because you don't have to wait for the next ~29 moves to complete, I think it should be well possible to estimate when to pause the print to insert custom parts like nuts or so.

Quote
zombiepantslol

At the present time the whole purpose of the Pause button is to simply make movements stop, so you can either resume or reset the current print. I personally don't see any real advantages in allowing moves while a print is paused when using the current firmware, e.g. because the nozzle will start oozing very quickly. If it were possible to set up custom macro files to define exactly what should happen when a print is either being paused or resumed, we could define extra retractions (and feed moves, respectively), tool (de)selection and custom moves to be executed just-in-time. This may be implemented eventually in the firmware though, which is why I haven't replaced the Pause button with "Reset Print", but I won't change this behavior in my firmware fork until I see a good reason to do so.

If I want to pause a print to remove a bit of plastic or insert a nut for example I don't want the hot end causing damage to the print before I resume printing and I need room to get at the printed item.

Quote
zombiepantslol
Regarding your diagnostics output: Sorry, but I can't see any M122 call in there :

I thought that the output didn't contain what you wanted, I don't think the command worked, but probably finger trouble on my part.
Here is the correct output.

M122
Platform Diagnostics:
Memory usage:
Program static ram used: 47172
Dynamic ram used: 35164
Recycled dynamic ram: 3680
Current stack ram used: 1616
Maximum stack ram used: 5288
Never used ram: 7000
Last reset 00:03:07 ago, cause: power up
Last software reset code & available RAM: 0x0000, 12960
Error status: 1
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
Free file entries: 9
Longest block write time: 0.0ms
Slowest main loop (seconds): 0.009964; fastest: 0.000046
Move Diagnostics:
State: paused
Heat Diagnostics:
Heater 0: I-accumulator = 0.0
Heater 1: I-accumulator = 0.0
GCodes Diagnostics:
Internal code queue is empty.
Network diagnostics:
Free connections: 15 of 16
Free transactions: 23 of 24
Free send buffers: 19 of 20
Webserver Diagnostics:

Hope that helps.

Quote
zombiepantslol
Oh, and the heater code hasn't changed in my latest releases, so I suggest you increase your heater "S" value a bit. See dc42's 0.78e firmware release on how to adjust this particular parameter using M301. I bet dc42 could give you better advice on this, I must admit I'm not too familiar with PID controllers (yet).

This is strange because I've never had this problem before, I will check dc42's release notes to see how to do this. Thank you for your help.

---

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 think the suggestion of macros files for pause print and resume print is a good idea, so I will consider adding it to my fork in the next release. I'll have to check first whether it would interact badly with zpl's command queue and instant-pause changes.

---

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
zombiepantslol

Quote
dmould
One potential use of the pause button is to allow you to insert a captive nut that is going to be buried inside the part. In that case you may need to move the head out of the way, insert the nut and move the nozzle back before resuming.

Yes that's true, but when using my fork, moves will stop as soon as the current move has finished. Especially because you don't have to wait for the next ~29 moves to complete, I think it should be well possible to estimate when to pause the print to insert custom parts like nuts or so.

That depends how large the layer that you are pausing is. If it is a small layer the hotend will be in the way no matter where you pause.

Having said that however, a far more sensible way to insert embedded objects is to edit the print file and insert suitable commends just after the relevant layer change. With that in mind, is there any command that can be inserted that will result in a file-initiated pause? If not it would make a useful addition.

That way G-code could be inserted in the print file that moves the head away, turns off the extruder heater and enters an indefinite pause state. You could then hit the "resume" button any time afterwards, and the code following the "pause" command could wait for the hotend to get back to its working temperature, move the head back to where it was before the pause and resume printing.

I can think of many uses for a G-file commanded pause. It could, as another example, be used to allow the filament to be changed to different colours at preset layer heights in the print. Ideally you would want to have manual control of the printer while it is paused to be able to effect any changes you may require. While not as versatile as a true multi-colour printer it would suit quite a few situations - allowing the traffic cone to be printed on a single nozzle printer, for example, or allowing raised lettering to be a different colour.

Dave

Paul, thanks for your report, I could reproduce the problem you are experiencing.

A quick status update: I've got the pause feature fully working with my latest changes, but I haven't finished paused/isolated moves yet. I intend to make M24 (Resume) go to the position where the print was interrupted, but this turns out to be more difficult than I expected. When I have everything working, I'll make the firmware run pause.g and resume.g when a print is either paused or resumed. I think this will improve quality when a paused print is resumed.

Quote
zombiepantslol
Paul, thanks for your report, I could reproduce the problem you are experiencing.

A quick status update: I've got the pause feature fully working with my latest changes, but I haven't finished paused/isolated moves yet. I intend to make M24 (Resume) go to the position where the print was interrupted, but this turns out to be more difficult than I expected. When I have everything working, I'll make the firmware run pause.g and resume.g when a print is either paused or resumed. I think this will improve quality when a paused print is resumed.

Thank you for the update, this will be of great benefit to all users, can't wait to try it.

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

Strange, during a print the hot end temperature reduced from 193 to 168 and even though I increased the set temp to 200 the temperature remained at 168-170.
I've never noticed this before, so I am not sure if it is a firmware or a connection problem. This is my first big print since upgrading the firmware.
I wonder if this is tied in to the other temperature problem of the temperature not reaching the set temp. I did set the S parameter according to dc42's 0.78e instructions, but I'm not convinced that that is the problem.

I think I will revert to an earlier firmware and see if the problem persists.

edit.--The printer is still printing and extruding even though the hot end is 169. I wonder if it is just a temperature reporting issue., I've got no way to ctually measure the temperature of the got end accurately.

edit

It's definitely NOT the firmware - see new thread

Edited 2 time(s). Last edit at 11/18/2014 09: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