Experimental firmware 059b-dc42 and web interface 0.77

I've put experimental firmware version 0.59b-dc42 and web interface files 0.77 in a zip file at [dl.dropboxusercontent.com]. I've not committed it to github yet because I haven't finished mending the file upload protocol, nor have I done a long print with it yet. But as it may be a while before I get a chance to work on this again, I'm making it available to anyone who wants to try it out.

The 0.59b firmware should work with my previous web interface release (0.76), however web interface 0.77 requires firmware 0.59b for file upload to work.

Changes in firmware 0.59b since 0.59a:

* The M208 command can now set the lower limit of axis travel as well as the upper limit. For example, you can set the X-axis lower limit to e.g. -10 so that X=0 is at the edge of the bed. Add parameter S1 to set the lower limit, otherwise the upper limit it set. If you set an X-axis lower limit, then this will be the value set when the endstop is hit - but note that if there is a G92 command in the homex.g file (as in the standard version supplied by RRP) then that will override it.

* The M208 command with no X, Y or Z parameters now returns the axis upper limits, or the lower limits if parameter S1 is included.

* Web files can now be uploaded to subdirectories of /www (in conjunction with web interface 0.77).

* There is no longer a limit on the maximum line length permitted in uploaded files (in conjunction with web interface 0.77).

* File upload speed increased, to 3.9Mb/min for non-gcode files and 3.4Mb/min for gcode files (in conjunction with web interface 0.77).

* Reduced max reported upload buffer space to 950 bytes. Some Windows 8.1 clients did not work with the value (1024 bytes) reported by version 0.59a.

Changes in web interface 0.77 since 0.76:

* In the SD card file list, the delete buttons now work in Firefox as well as Chrome.

* Temperature chart max temperature value shown increased from 250C to 280C.

* Web files other than reprap.htm can now be uploaded. If you upload a .js file, it will be written to the www/js folder. If you upload a .css file, it will be written to the www/css folder.

* File upload speed increased (see firmware notes). Note: when uploading from FireFox, or when the Chrome tab used for uploading is put into the background, upload speeds may be substantially reduced (this behaviour is not new).

* Direct web print facility removed. As file upload is no longer sending individual lines that resemble gcodes, it no longer made sense to use the same code for file upload and direct web print, and I decided that maintaining direct web print was too expensive in relation to its utility.

If you decide to try it, please let me know how you get on with it. Be prepared to revert to 0.59b and 0.76 if you have any problems (a spare SD card will make this easier).

Edited 1 time(s). Last edit at 05/18/2014 03:47PM 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].

Great Job again DC

I did flash this firmware (59b-dc42 and 0.77) last night and did a 4-5 hour print over night. So far so good as long as i can see.
I had some problems with 59a as i could not upload files at all. on 59b it seems to work just fine, both with chrome and firefox. (can also delete files on sd card from firefox now)
still have some issues with print information, it tells me im 63% done when i print layer 23 of 638

But so far it seems good for me exept a little problem that occured with my printer (se another post)

Regards
Christian
Norway

Edited 2 time(s). Last edit at 05/19/2014 02:08AM by CJansen.

Quote
CJansen
Great Job again DC

still have some issues with print information, it tells me im 63% done when i print layer 23 of 638

That's maybe O.K. - it not calculate the layers than the usage of filament.

with regards
freerap

Thanks very much Dave. From what I see, it does what it says on the tin.

Ken.

oh. learning something new every day

That is solved then. ty for info
Regards
Christian

More precisely: if the firmware can find the total filament needed for the print from the comment that slic3r adds at the end of the file, then it reports this to the web interface, and the web interface calculates the %complete from the filament used since the print started to the total filament needed. If the firmware can't find the total filament needed, then it reports the %complete based on numbers of layers. I've done it this way because I find that the completion time estimate based on filament consumption is the most accurate until quite near the end of the print. But I'm prepared to reconsider if users find this confusing. Or should there be two progress bars and %complete figures, one based on filament usage and one based on layers?

---

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

Maybe 2 progress bars would be nice and less confusing, but now when i know how it works it doesnt matter to much to me tbh.
And again thank you for your effort making the firmware, awsome job and im getting more and more happy with my ormerod for every release you have.

Best Regards
Christian Jansen
Norway

Hi David, I tried 59b, but when I home the Z axis, with or with out the HotEnd Heater on, it turns it off...
59a is fine with homing Z.
Homez.g follows:-

homez.g

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

Quote
KimBrown
Hi David, I tried 59b, but when I home the Z axis, with or with out the HotEnd Heater on, it turns it off...
59a is fine with homing Z.
Homez.g follows:-

[attachment 33129 homez.g]

Hi Kim, what do you mean when you say "it turns it off"? Are you aware that you still have the M109 command in homez.g?

---

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

Yes David..... 59b turns the heater off when the temp isnt near 195

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

Quote
KimBrown
Yes David..... 59b turns the heater off when the temp isnt near 195

Sorry Kim, I've tried using your homez.g file on my machine and I can't reproduce the problem. When I press the Home Z button on the web interface, the head moves to the centre of the bed, waits until it reaches at least 192.5C, then homes Z, then moves the head up slightly. The head temperature stays at 195C.

---

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, yes that's what it's supposed to do, to melt any boble of plastic on the nozzle.
95a does it fine here, and I've re-installed it. With 95b I tried it two ways.... Putting the heater on manually before homing Z, and just letting the homez file do it it's self.
Each time it moved the head, by which time the temp was about 150' and rising... As soon as the move finished it then turned the heater OFF when the temp was about 170'
so it was going to endlessly wait for it to reach 195'.
Also, I tried Chrome and Firefox, and I think the machine thought it was Bin Day...


In a couple of hours I hope to have a bit of time to play with the machine. I'll re-install 95b again, and give it another go...

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

Looks like the bin icons don't like filenames that take more than 1 line.

Dave (#106)

Quote
KimBrown
In a couple of hours I hope to have a bit of time to play with the machine. I'll re-install 95b again, and give it another go...

Kim, when you do that, if you do get the same problem again, please can you also try printing homez.g as if it were a normal file, and see if the problem still occurs.

---

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
dmould
Looks like the bin icons don't like filenames that take more than 1 line.

Dave (#106)

I did say it needed more testing! I'll see what I can do when I get back to it.

---

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

I have a suggestion for future versions but I don't know how easy it is to implement. Simple compression of the g-code files makes the files about 1/2 - 1/3 the size and should therefor be so much quicker to transfer. I obviously don't know what goes on when it is being streamed. Since even 3.4MB/s is oddly slow for a modern network transfer there is something in there that I don't understand.

David, I found it... It was a broken heater wire..... Intermittently working...
Just going to fix it now.

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

Quote
michaelljunggren
I have a suggestion for future versions but I don't know how easy it is to implement. Simple compression of the g-code files makes the files about 1/2 - 1/3 the size and should therefor be so much quicker to transfer. I obviously don't know what goes on when it is being streamed. Since even 3.4MB/s is oddly slow for a modern network transfer there is something in there that I don't understand.

Michael, that's an excellent idea! I found a Javascipt LZW compression library at [pieroxy.net] and it should be simple enough to port the decompression function to C++.

There are several reasons for the upload being slow:

* Inefficient implementation of the web server and file system interface, resulting in the uploaded data being copied character-by-character several times
* The web server doesn't use persistent connections
* The underlying TCP/IP library (lwip) depends on polling to process messages, so if it doesn't get polled often enough, data gets delayed
* At the PC end, the data is packaged into blocks by Javascript code

I have work in progress to improve the firmware to do less copying, and I am hopeful to get above 5Mb/min when this is complete. Beyond that I was going to try using persistent connections, but data compression might be a better option.

It's tempting to store the uploaded files in compressed format, and decompress them when printing. One small complication is that the firmware needs to read backwards from the end of the file to find the object height and total filament used. So I think it would be necessary for the uploader to extract that data first and copy it into comments prepended to the start of the file prior to compression.

I've also been looking at supporting FTP in the Duet firmware.

Edited 1 time(s). Last edit at 05/19/2014 01:19PM 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].

Quote
dc42

Quote
michaelljunggren
I have a suggestion for future versions but I don't know how easy it is to implement. Simple compression of the g-code files makes the files about 1/2 - 1/3 the size and should therefor be so much quicker to transfer. I obviously don't know what goes on when it is being streamed. Since even 3.4MB/s is oddly slow for a modern network transfer there is something in there that I don't understand.

Michael, that's an excellent idea! I found a Javascipt LZW compression library at [pieroxy.net] and it should be simple enough to port the decompression function to C++.

I'm glad. Also, fortunate that compression wasn't already a part of the solution.

Quote
dc42
* At the PC end, the data is packaged into blocks by Javascript code

That's odd. I would have thought file transfer would be handled by regular HTTP POST. I wish I had time to spare or I could look into it and helping out. I'm busy until end f summer, really. I shouldn't even be reading the forum now... ;-)

Quote
michaelljunggren

Quote
dc42
* At the PC end, the data is packaged into blocks by Javascript code

That's odd. I would have thought file transfer would be handled by regular HTTP POST. I wish I had time to spare or I could look into it and helping out. I'm busy until end f summer, really. I shouldn't even be reading the forum now... ;-)

Yes, I think uploading the file in chunks using POST or PUT with Content-Range would be a better solution. The current protocol is a hangover from how it is done over USB.

---

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

So Heater Wire Fixed, sorry about the confusion.

Uploaded a Gcode file, 100% complete it says.
Homed all axi, then selected it, all the Temps are ready, but it just says Printing, and does nothing...

So tried Pronterface.... File listed, but does nothing....
Shutdown Printer to look at file, and found it Empty....
So copied file to SD using a card reader...
Checked file is ok.
Back in Printer, but it still won't print.
Took card out, and renamed file... Now working..
It didn't like the name:-
50% 0.8 Ext final_pinup_v2.gcode

Edited 1 time(s). Last edit at 05/19/2014 04:28PM by KimBrown.

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

Another thought would be to use tftp protocol for simplicity and lightweight. Although some look down on it as it obviously doesn't have all the niceties of real ftp, it can still work fine for its intended purpose of simple file transfer primarily on a local network. That's why it is still used quite a bit for file / firmware updates on embedded systems like routers.

There are quite a few examples of server end code like here. I think there are also some javascript client ends.

Guess I'm over tired here.... Just realised the filename had two "." in it... I'm supprised windoze8.1 accepted it.... Doh!

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

Quote
KimBrown
Guess I'm over tired here.... Just realised the filename had two "." in it... I'm supprised windoze8.1 accepted it.... Doh!

I've just tried renaming one of my test files (based on circle.g with some z movement added) to have two '.' character in it, then uploading it to SD card, then printing it. It worked OK. So did the one I renamed to have a % character in it.

---

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

I did a 2-hour print today with this firmware bundle and everything worked well. Thank you, dc42

Thanks to all of you who have tried this and provided feedback. Based on your reports, I have released the firmware 059b-dc42 at [github.com].

I am having problems uploading some web files via the web interface, in particular reprap.js. So I advise removing the SD card to update these files for now.

I have implemented a partial fix for the problem with the trash icons appearing in the wrong place when the filenames exceed the size of the box. It's not perfect, but better than before. The new web interface files are attached.

---

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

I've played with this firmware (0.59b, web interface 0.74) for a couple of days now and it's fantastic - thanks! The only slightly odd thing I've noticed is that the XY move that happens when I home the Z axis is now much slower - is this deliberate/expected, or has something odd happened? I'll look into it a bit further in case it's just my configuration that's odd.

Also, in the G code field (top right), the "add command" in the drop-down menu is always disabled - is that a bug, and if so what information can I usefully collect on it? I'd love to add a couple more commands (e.g. G32) to it.

Thanks so much to dc42 and iamburny for this, I've just upgraded from January's stock firmware - what an improvement!

I think the Add command was probably put in originally as a placeholder and I don't believe has been implemented yet. It was put on the wish list for future versions as it would be nice to add one's own favourites.

It is a little bit complicated to do as added commands have to be persisted to be useful.

Quote
rwb27
I've played with this firmware (0.59b, web interface 0.74) for a couple of days now and it's fantastic - thanks! The only slightly odd thing I've noticed is that the XY move that happens when I home the Z axis is now much slower - is this deliberate/expected, or has something odd happened? I'll look into it a bit further in case it's just my configuration that's odd.

I've reduced the minimum XY feed rate from 15mm/s to 10mm/s because I found that I couldn't get small perimeters to print slowly enough. So if the G1 XY command in homez.g either specifies a very low feed fate, or doesn't specify a feed fate and inherits a slow one (e.g. from a previous Z move), then it will be slower using my firmware. You might like to add a feed fate to that move in homez.g and homeall.g. In my homing files, I also remove the G92 commands so that when the endstops are hit, they take the values from the axis limits set by M208. But this won't work using RRP official firmware, which gets the coordinates wrong if the G1 S1 command that looks for the endstop isn't followed immediately by a G92. And in homey.g, I increase the feed rate of the command that moves back to Y=0 to F12000.

---

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
... Changes in firmware 0.59b since 0.59a:

* The M208 command can now set the lower limit of axis travel as well as the upper limit. For example, you can set the X-axis lower limit to e.g. -10 so that X=0 is at the edge of the bed. Add parameter S1 to set the lower limit, otherwise the upper limit it set. If you set an X-axis lower limit, then this will be the value set when the endstop is hit - but note that if there is a G92 command in the homex.g file (as in the standard version supplied by RRP) then that will override it.

* The M208 command with no X, Y or Z parameters now returns the axis upper limits, or the lower limits if parameter S1 is included. ...

I'm working on an arrangement where I have a Z limit switch which opens in response to the nozzle touching the glass, and so far with some success (reliable to within about 20 microns). It would be nice when levelling the glass if I could move to x,y positions other than my central 0,0 homing position to see at what Z position the switch opens. However, if I use a G1 Z-200 S1 command (whether absolute or relative), it resets the Z position when the switch is hit and always returns Z=0 at that position.

{{ Something similar happens with X and Y moves, except that when the X or Y switch is hit, it resets X or Y to the value in a previous M208 ... S0 or M208 ... S1 command, regardless of whether M564 has been invoked, and if there hasn't been any previous M208 command, it uses a default value. }}

So, what I'd like to know is, is there any way with the current firmware to move to the switch-opening position without also resetting the associated coordinate? If not, is there any simple tweak to the firmware which would allow this, for example modifying the G1 command so that, say, 'G1 Z-200 S2' would move Z down until the switch is hit without doing anything else, or modifying 'G1 ... S1' so that it doesn't reset the associated coordinate if the M564 command is in operation?

Ken.