New firmware 0.96f-zpl

I've just released version 0.96f of my firmware fork on GitHub. Here's what I changed this time:

Quote

- Modified code queue to store only a few codes and reduced its memory usage
- Implemented M226 (GCode initiated Pause)
- Rewrote most of the Move Spin code and implemented split moves for 5-point bed compensation
- Improved Pause/Resume/Reset feature and parts of the networking code
- Removed some more redundant code
- Last message is now stored in Flash (may be useful for debugging)
- M0 runs "reset.g" whenever a paused print is reset
- M81 disables drives before ATX power is turned off
- Increased Z lift in homeall files from 2mm to 3mm
- Adjusted center probe position in homeall and homez files
- Rearranged SD-image directories to look equal to the ones in dc42's firmware fork
- Bug fix: M120+M121 now save and restore the last-known extruder positions
- Bug fix: Possible endless loop in the Network code
- Bug fix: FileStore:eek didn't set internal bytesRead property
- Other minor changes

Thanks to dc42 for the following:
- Initializing arrays using ARRAY_INIT macro
- Fixed issue where the active aux GCodeBuffer could become overwritten
- Implemented PrintingAFile interface again in the GCodes class
- Implemented M305 'X' parameter to swap ADC channels on demand
- Added support for M20 S2 and M36

If you want to give it a try, you can get the firmware binary here. The compatible web interface version is still version 1.08. For a short summary about the differences between RRP's original firmware and mine, see this thread.

If you have any questions or problems, feel free to post them here. Feedback is appreciated as usual!

Thank you very much for all of the changes and including dc42's latest.

I have now tested on a 2 nozzle machine and everything is working well but I wonder if we can change the order of things for "resume".
It would make more sense to have the head return to the correct position before lowering to the correct height, at the moment the head lowers and then the head is moved into position with the potential problem of catching on a stray bit of plastic.


I have another problem
In my config file I have both nozzles set with
G10 P1 X6 Y0 Z0 S195 R155
G10 P2 X-6 Y0 Z0 S195 R155

Initially the web interface shows the correct set temperatures but after a Head change the Head 1 standby shows 160 instead of 155. I just don't know where this is coming from, it's not the custom G-code in slic3r. Any ideas of where to look?

I've just added a new post to 2 nozzle printing setup concerning a few issues.

Paul

Edited 1 time(s). Last edit at 11/30/2014 12:31PM 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

Quote
appjaws1
Initially the web interface shows the correct set temperatures but after a Head change the Head 1 standby shows 160 instead of 155. I just don't know where this is coming from, it's not the custom G-code in slic3r. Any ideas of where to look?

What do you have in your tool change macro 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].

Found it, It was the last place I expected. my manual set bed file "setman" which I run after switch on.. I have now corrected this so the only outstanding issue in this thread is the resume movement issue.

---

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, thanks once more for your feedback!

Quote
appjaws1
It would make more sense to have the head return to the correct position before lowering to the correct height, at the moment the head lowers and then the head is moved into position with the potential problem of catching on a stray bit of plastic.

Sorry, but I definitely won't change the order of my resume code. The additional move you described is only performed if the current coordinates don't already match the ones at which the print was initially paused, so it's actually some kind of backup facility. But I consider adding a new 'R' parameter to G1, so one can go back to the correct position within the macro files. For the moment it's a good idea to only use the "Move Head" controls while a print is paused, that way you can easily go back to the right XY coordinates before you decide to resume a paused print.

Hi zombiepantslol,

Thanks so much for all the great work you are doing! I am an newbie on 3d printing and Ormerod but an avid tinkerer...! I decided to stray from the RRP firmware mainly because the web interface was giving me a really hard time so I tried your latest version. Everything works great but My extruder motor is not responding at all! On RRP it works just fine! This is Ormerod 1 and 0.96f-zpl. I created and modified config.g and triple checked it. The extruder doesn't move either from ponterface or the wonderful web interface. Any ideas? Did I miss something?

P.S. I now have tried dc42's latest version and it works so I am baffled...

Thanks,
Achilles

Hi Spaceskater,

thanks for your feedback! I guess you didn't heat the hotend to more than 160C before you tried to perform extrusion moves. My firmware fork needs at least 90C to retract and 160C to extrude filament, but you can override this safety feature by sending "M302 P1" to your printer.

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

Quote
zombiepantslol
Hi Paul, thanks once more for your feedback!

Quote
appjaws1
It would make more sense to have the head return to the correct position before lowering to the correct height, at the moment the head lowers and then the head is moved into position with the potential problem of catching on a stray bit of plastic.

Sorry, but I definitely won't change the order of my resume code. The additional move you described is only performed if the current coordinates don't already match the ones at which the print was initially paused, so it's actually some kind of backup facility. But I consider adding a new 'R' parameter to G1, so one can go back to the correct position within the macro files. For the moment it's a good idea to only use the "Move Head" controls while a print is paused, that way you can easily go back to the right XY coordinates before you decide to resume a paused print.

I understand, thanks. In the pause.g file I have added a line that moves the head out of the way and goes to position X10 Y200 and when I want to resume the head lowers first and then the move back to the stored position in your code. It is very difficult to read the exact position of the head as you press pause so I would not know where to position the head prior to resume.

Perhaps I need to remove the code that moves the head away from the object and do everything by the X and Y move buttons. Such a shame because the concept of the pause and moving out of the way so you could get at the print was really good and once set up didn't need any intervention besides pressing the button and doing whatever needed to be done to the print or change filament etc.

Would your "R" parameter achieve what I have described? If so YES PLEASE.

I have had a message pop up in chrome saying that 192.168.1.14 (my ormerod) has reported that this page has no drag and drop. Chrome has not changed and it has only happened since 096f-zpl firmware

regarding Spaceskater post about the extruder not working. I had the same problem on 01-11-2014, not sure which zpl firmware version and tried everything to resolve it and ended up using my spare extruder motor so that I had a one nozzle system working. 3 weeks later on returning from holiday and updating firmware and web interface, I tried that extruder motor again and it worked. Don't know why or what cured it but something in the firmware must have gone awry. The extruder actually stopped in the middle of a print. This has not happened again, so whatever caused it must be very intermittent and under specific set of circumstances.

Thanks again for the hard work
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

Thanks zombiepantslol! I will test this this evening. Even though I did test temperatures and the speed they heat up, I can't remember if when I tried to load filament the tip was hot or not. The interesting part that threw me off is that the total filament length on the web interface did increase every time I clicked to extrude. And the printer didn't accept any other commands for the time it was theoretically extruding, even though the motor was not moving.

Thanks once again!
Achilles

To move away from the part & back again with G code macro files, just switch to relative moves before moving away, then reverse the directions to move back, and finally switch back to absolute moves. You just need to pause in a position where you are sure that the relative moves won't try to take the head outside the print area.

Dave

Quote
dmould
To move away from the part & back again with G code macro files, just switch to relative moves before moving away, then reverse the directions to move back, and finally switch back to absolute moves. You just need to pause in a position where you are sure that the relative moves won't try to take the head outside the print area.

Dave thank you for that. I did try that initially but soon discovered that the head went outside of the print area, depending on size of object and position when pause is pressed. This is why I used absolute to move the head to the park position and on resume zpl's firmware returns the head to the correct XY and Z position. all I wanted to accomplish was to actually reverse what the pause had done by moving XY first and then Z but I guess it is easier said than done.

This is my pause.g file

M83 ; extruder relative position
G1 E-10 F3600 ; retract filament
G91 ; relative positioning
G1 Z+10 F200 ; raise the head
G90 ; absolute positioning
G1 X10 Y200 ; move the head out of the way
G91 ; relative positioning

This is my resume.g

G91 ; relative positioning
G1 Z-10 F200 ; lower the head
M83 ; extruder relative position
G1 E10 F3600 ; feed filament
G1 F6000

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
appjaws1

Quote
dmould
To move away from the part & back again with G code macro files, just switch to relative moves before moving away, then reverse the directions to move back, and finally switch back to absolute moves. You just need to pause in a position where you are sure that the relative moves won't try to take the head outside the print area.

Dave thank you for that. I did try that initially but soon discovered that the head went outside of the print area, depending on size of object and position when pause is pressed. This is why I used absolute to move the head to the park position and on resume zpl's firmware returns the head to the correct XY and Z position. all I wanted to accomplish was to actually reverse what the pause had done by moving XY first and then Z but I guess it is easier said than done.

This is my pause.g file

M83 ; extruder relative position
G1 E-10 F3600 ; retract filament
G91 ; relative positioning
G1 Z+10 F200 ; raise the head
G90 ; absolute positioning
G1 X10 Y200 ; move the head out of the way
G91 ; relative positioning

This is my resume.g

G91 ; relative positioning
G1 Z-10 F200 ; lower the head
M83 ; extruder relative position
G1 E10 F3600 ; feed filament
G1 F6000

Paul

It seems that you are leaving the printer in relative position mode with those macros. A suggested modification :

pause.g file

M120 ; push absolute/relative & feed speeds
M83 ; extruder relative position
G1 E-10 F3600 ; retract filament
G91 ; relative positioning
G1 Z+10 F200 ; raise the head
G90 ; absolute positioning
G1 X10 Y200 ; move the head out of the way
M121 ; pop absolute/relative & feed speeds

resume.g
M120 ; push absolute/relative & feed speeds
G91 ; relative positioning
G1 Z-10 F200 ; lower the head
M83 ; extruder relative position
G1 E10 F3600 ; feed filament
M121 ; pop absolute/relative & feed speeds

The problem with that is that unless the move following the pause position is a non-printing move, it will print the next line from your home position to where the next line ends. It really needs a push/pop position command (with feedrate on the pop). maybe DC42 or zombiepantslol could implement such a command pair.

Dave

Quote
dmould
To move away from the part & back again with G code macro files, just switch to relative moves before moving away, then reverse the directions to move back, and finally switch back to absolute moves. You just need to pause in a position where you are sure that the relative moves won't try to take the head outside the print area.

Thanks Dave, that is what I meant to say. Basically the "Move Head" controls don't do anything else.

Quote
appjaws1
Would your "R" parameter achieve what I have described? If so YES PLEASE.

Yep, the concept I have in mind will retrieve the right coordinates and go back to them. If the 'R' parameter is specified along with G0/G1, it will go back to the right coordinates for you.

Quote
dmould
The problem with that is that unless the move following the pause position is a non-printing move, it will print the next line from your home position to where the next line ends. It really needs a push/pop position command (with feedrate on the pop). maybe DC42 or zombiepantslol could implement such a command pair.

Well, you actually don't need to isolate anything within macro files using M120+M121. Whenever a macro file is run, the firmware will automatically perform stack operations, so it doesn't matter if you use relative or absolute positioning/extruder moves within those files. But be aware it does matter when you switch between relative or absolute coordinates on the web interface for example, in fact you'd have to run M120+M121 there to ensure nothing is messed up when the print is resumed.

My ormerod froze during a print with the active head 1 in contact with the object and a temperature of 191, head 2 standby at 155 and bed active at 63
If I pause and resume the head returns to the same spot and nothing happens. I need to abort this print but below is the output of M122.

M122
Platform Diagnostics:
Memory usage:
Program static ram used: 47516
Dynamic ram used: 36404
Recycled dynamic ram: 2096
Current stack ram used: 1608
Maximum stack ram used: 5144
Never used ram: 7144
Last reset 03:26:59 ago, cause: power up
Last software reset code & available RAM: 0x0000, 9040
Error status: 1
Bed probe heights: 0.000 0.050 -0.050 -0.050 0.000
Free file entries: 9
Longest block write time: 156.8ms
Slowest main loop (seconds): 0.158691; fastest: 0.000000
Move Diagnostics:
State: running
Heat Diagnostics:
Heater 0: I-accumulator = 0.0
Heater 1: I-accumulator = 104.4
GCodes Diagnostics:
Move available? no
Internal code queue is not empty:
Total moves: 5538, moves completed: 5524
Queued 'M106 S127
' for move 5525
Queued 'M106 S153
' for move 5526
Queued 'M106 S127
' for move 5527
Queued 'M106 S153
' for move 5531
Queued 'M106 S127
' for move 5532
Queued 'M106 S153
' for move 5533
Queued 'M106 S127
' for move 5534
Queued 'M106 S153
' for move 5537
8 codes have been queued.
Network diagnostics:
Free connections: 15 of 16
Free transactions: 23 of 24
Free send buffers: 19 of 20
Webserver Diagnostics:
17:06:32Print resumed!
17:05:38Print paused!
16:49:43File [tempWebPrint.gcode] sent to print

This is a bit worrying, hope the M122 helps.

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,
sorry to hear you're having problems, but thanks for the diagnostics info. Could you send me your G-Code file? I reduced the size of my code queue in the last release and it looks like it's no longer big enough to queue all of your M106 codes. I didn't expect it to freeze when that happens though.

That looks similar to the problem I reported in the fan control and printer halts thread.

E.g a bunch of M106 or M107 commands looks like they might get queued and never executed.

Quote
zombiepantslol
Hi Paul,
sorry to hear you're having problems, but thanks for the diagnostics info. Could you send me your G-Code file? I reduced the size of my code queue in the last release and it looks like it's no longer big enough to queue all of your M106 codes. I didn't expect it to freeze when that happens though.

I was manually adjusting the external fan control when this happened, I think I adjusted it 3 times because it kept going back to what slic3r wanted.

Anyway attached g.code file.Test.zip
Hope that helps
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

I carried out a thin wall test earlier on both nozzles and each print had a gap at the rear left hand corner where the layer change happened. Watching the nozzle you can see that each time it passed that point their was a hesitation, a slight pause, it is almost like the very last bit of the run, not enough filament was extruded, or the extrusion stopped too early.

---

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 the help zombiepantslol! It was the tip temp! I will spend the rest of the evening experimenting with different filaments.I printed with T-Glass and the result was quite nice!
I should re-rear the Changes for RRP file I guess to avoid any more questions like this one but it has so many things that I tend to forget them...!

Best,
Achilles