New firmware 058-dc42 and web interface 0.69

I just did an upload/print of a file (a variant of circle.g with 3 layers) with M0 on the end, and the interface is still responsive afterwards. So I don't know why it became unresponsive for you. If the 0.58 firmware becomes unresponsive for any reason, this should be detected either by the tck interrupt or by the watchdog, and either way, the Duet processor will be reset. All I can suggest is that if it happens again, you try the debugging techniques I mentioned earlier, and also check whether you can still ping the Duet from the PC.

---

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 will check if it happens again.
Thanks for your time
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 DC42,


No, I didn't patch the pronterface, I'm not using the special pronterface from Ormerod page, because it won't work on my osx 10.8.5
I'll try to patch and see, and get back here soon . Thank you !

Just like to say that firmware 0.58 and web control v0.69 have been rock solid for me now for several days. Not had a single glitch.

Thanks Steve, I'm glad it's working well for you too.

---

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, when I had the problems with 58 locking up, I found that the gcode file it happend to had M110 tacked on the front and back of it.
It was my Clean.g file I use with my cleaning pad (ski slope). Now I think just before then I'd done a directory list via Pronterface to see what
your long name listing looked like...

Hope that helps.

Kim

---

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

Very strange, the interface is working well today with no hang-ups, I have printed 3 small items with no resets.
So maybe yesterday was just a glitch.

Now that the interface correctly works out the height and % completed, should all of the other information, Print Duration, Last Layer and estimated Print End Time be working now? or is that something that needs work to get it completed?
I see that there is a graph to the side but I wonder what that should be showing.

****This is NOT a criticism at all******* just wondering what the long term plan for the interface is.
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

Yes the print duration etc. and graph should be working. You need to have the layer height configured correctly in the Settings tab. They all work for me, except that before the print actually starts, while the hot end is heating up, it says the print is some % completed depending on the height of the nozzle. Once the print starts, the readings get sensible. It takes a couple of layers at least before you start getting estimated end time. I don't understand why they would not be working for you, assuming you are using Chrome browser.

---

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

Well the layer height is set correctly and I applied & saved the settings again just to be sure. Started another print of 38 layers with an object height of 9.024mm.
It is a reprint of your insulator for ultrasonic.
I am now at 10% layer 4 of 38 and all of the boxes just have zeros in them.
I am using the Chrome browser version 34.0.1847.116n. on windows 7
Now layer 6 15% completed all other boxes zeros.

When I come to think of it these boxes have never worked for me.

---

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'd like to try the web interface, but to be honest I haven't a clue about setting it up, and when I'm away I have to tether my Laptop to the phone, so have no control or a connection for linking the printer to the network.
I think I could do it with a cross over lead which I have here to connect the Railway controller to the laptop to upgrade it's software etc. But then that seems quite straight forward compared to the printer.

As for 58 doing strange things, I wonder if it's something behind the scenes not behaiving like it should like a variable type not working properly in the compiler software. I had something similar years ago when I was doing allot of programming, and eventualy it turned out to be a coding error in the compiler, that took them a year or so to find. In the mean time I just used a different variable type till they released a fix.

Another thing I was going to ask was, would it be possible to have the Firmware check the Axi limit switches during a movement. I'd like to add a limit switch to the idler end of the X-axis to stop the HotEnd sometimes running in to the idler bracket... I'm just thinking the same teeth on the belt are getting a hammering all the time, and soon the belt will throw its hand in...

---

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

appjaws, when you have a print running and the graph etc. is not working, please can you press control-shift-J to get the Javascript console, and see if it is reporting any errors.

PS - I presume you are loading all the web interface files from the Duet, and they (in particular, reprap.htm and js/reprap.js) are in step?

Edited 1 time(s). Last edit at 04/23/2014 04:39PM 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].

appjaws, was it you who said in an earlier post that you were using a larger first layer height than for the remaining layers? If so, then I think that is what is confusing it. The web interface code sets the print start time when the current layer is 1. If your print is starting at layer 2 (based on the configured layer height), it will never get the print start time, which means it will never estimate the end time.

---

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
KimBrown
I'd like to try the web interface, but to be honest I haven't a clue about setting it up, and when I'm away I have to tether my Laptop to the phone, so have no control or a connection for linking the printer to the network.
I think I could do it with a cross over lead which I have here to connect the Railway controller to the laptop to upgrade it's software etc. But then that seems quite straight forward compared to the printer.

As for 58 doing strange things, I wonder if it's something behind the scenes not behaiving like it should like a variable type not working properly in the compiler software. I had something similar years ago when I was doing allot of programming, and eventualy it turned out to be a coding error in the compiler, that took them a year or so to find. In the mean time I just used a different variable type till they released a fix.

Another thing I was going to ask was, would it be possible to have the Firmware check the Axi limit switches during a movement. I'd like to add a limit switch to the idler end of the X-axis to stop the HotEnd sometimes running in to the idler bracket... I'm just thinking the same teeth on the belt are getting a hammering all the time, and soon the belt will throw its hand in...

I just plug the Ethernet into my laptop and bridge it with the wifi connection, seems to work great.

Regards,

Les

---

Pointy's Things
Pointy's Blog

Quote
KimBrown
Another thing I was going to ask was, would it be possible to have the Firmware check the Axi limit switches during a movement. I'd like to add a limit switch to the idler end of the X-axis to stop the HotEnd sometimes running in to the idler bracket... I'm just thinking the same teeth on the belt are getting a hammering all the time, and soon the belt will throw its hand in...

Once you have homed the X-axis, the firmware already prevents you moving to negative X or above the upper limit of x-axis travel (which you can change using M208).

---

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

David,
I haven't said that I use a thicker layer in another thread. But I do I have 1st layer set at 160% of layer height. This was recommended ages ago in order to obtain a good finish on the bottom layer and to help with adhesion.

This certainly explains why the Print Duration, Last Layer and estimated Print End Time have never worked for me and why the print information starts at layer 2.
I am under the impression that a large number of users have a thicker 1st layer, in which case they would not have the Print Duration etc. working.
Or perhaps it is me that is in the minority and I should used layer height for every layer.

I'll check a print with 1st layer at 100% tomorrow and let you know, I'm sure the estimates will work correctly.

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

It was I who said I use a thicker 1st layer. When using the same layer height for the first layer, I can confirm that the times sort of work, though it will occasionally fail to update the current time after a layer change and then report the next layer as taking the time of the previous two layers. The graph then shows the times of (e.g.) layer 6, layer 7, layer 7, layers 8+9. The layer count increments correctly however, so it is not that it failed to detect a layer change.

For most of my designs the layer times vary too much for that method to give any sort of accurate estimate so I ignored the times, but I did find the running layer number/Z height to be useful. On one of my prints over Easter for example, the first few mm of the design started with a layer time of 25 minutes for the solid bottom layers, then went down to 4 minutes for the infill layers, then back to 25 minutes for the top solid layers of the base section, then between 90 seconds and 6 minutes for the structural detail and walls after the base part had printed - and any box-shaped part would exhibit the same characteristics. So my estimated times began as 40+ hours, reached a minimum of 3 hours and back to 7 hours later. If you slice with Cura it reports a pretty accurate estimated time (in that case about 10.5 hours total which was about right). In any case, I usually want to know how long a print will take before I start printing - if I have to wait until many layers have printed it's too late to decide whether I have enough time to start the print!

Possibly it would be more accurate to input the total filament length instead of the height, and make an estimate based on the rate & percentage of filament extruded, though maybe the interface is not fast enough to be able to record every extrusion amount to keep a tally (but the firmware should be able to be modified to keep count and give that information to the web interface when asked). I have a feeling that rate of filament consumption varies less than rate of layer change for most prints - though it is still far from steady, with layers containing large areas of infill extruding at a faster rate than layers with separate small area features.

Dave
(#106)

Based on the previous posts, I can see a few options:

1. Change the web interface to set the print start time on layer 2 if it doesn't see layer 1. This should work as long as the first layer is no more than double the height of the other layers.

2. Have the web interface try to work out the layer height for itself by looking at the changes in current height, and allow for the first layer being a different height from the rest.

3. Read the comment that slic3r adds to the end of the file that gives the total filament used. Also have the firmware send back the cumulative filament used instead of the last movement. Then an estimate can be worked out based on the filament usage. But this won't work with Cura, unless Cura also emits the amount of filament used in the file.

Thoughts, anyone?

---

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 tend to use gcode viewer - its estimate of time to print has proved to be quite good.
[gcode.ws]

On another matter: what is the optimum way of updating to web interface 0.69?
I am currently running 057y firmware.
Greg

---

Ormerod #17

David,
I'm not at home at the moment but I think option 3 would be best followed by option 2.
I think most users use slic3r, but maybe the interface could have a button to select which slicer was used. Oh wait, the interface already detects this.
So for me option 3.
Maybe cure users would want option 2

---

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
dc42
Based on the previous posts, I can see a few options:

1. Change the web interface to set the print start time on layer 2 if it doesn't see layer 1. This should work as long as the first layer is no more than double the height of the other layers.

2. Have the web interface try to work out the layer height for itself by looking at the changes in current height, and allow for the first layer being a different height from the rest.

3. Read the comment that slic3r adds to the end of the file that gives the total filament used. Also have the firmware send back the cumulative filament used instead of the last movement. Then an estimate can be worked out based on the filament usage. But this won't work with Cura, unless Cura also emits the amount of filament used in the file.

Thoughts, anyone?

Well, presently the height is input manually, so it would not be any bigger hassle to input the filament length manually (Cura reports it on the screen when you slice so it could be noted down). I suspect that Cura has a variable name assigned to the total filament length which could be used in the start or end code to mimic the comment at the end of Slic3r's G file, BICBW - I'll experiment.

Dave
(#106)

Dave,

1. You don't need to enter the height manually if the file you are printing is the last one you uploaded. But I am modifying the firmware to send back the height, so that you will be able to print any file from SD and it will know the height. I could have it send back the filament length too.

2. Cura does have a variable that gives the total filament length, but it doesn't work. See [github.com].

---

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
Dave,

1. You don't need to enter the height manually if the file you are printing is the last one you uploaded. But I am modifying the firmware to send back the height, so that you will be able to print any file from SD and it will know the height. I could have it send back the filament length too.

2. Cura does have a variable that gives the total filament length, but it doesn't work. See [github.com].

Ah well - hopefully it will be fixed before too long, and meanwhile a manual entry/over-ride option could be provided on the web interface, and/or we could manually tack a Slic3r style comment into a Cura file with a text editor - which would be quite a good thing to do in any case should you want to print the G file at a later date and want to know how much filament will be required, so please don't disable parsing for the filament length after determining that it is a Cura file. I like the upload feature a lot, but it is still too slow to use for large G files, and I also often re-print old files on the SD card, so parsing the SD card file instead of relying on the last upload will be a great improvement.

As a not-thought-through suggestion, it might be faster/easier for the firmware to create a separate but associated file on the SD card to store metadata such as filament length, height, actual print time etc.

e.g. at reset, the firmware takes a directory listing of each G file and looks to see if there is an associated metadata file. If not, the firmware parses the G file for all the information it requires and creates an associated metadata file, which is then used by the web interface at print time. The metadata file also contains the last-modified timestamp of the G file so it knows whether the G file has been altered since the metadata file was created. When a G file is printed, the firmware can add the actual print time (perhaps even of each layer) and filament length used to the metadata file so that if that file is printed again the information will be super-accurate. Conversely, at reset the firmware initially takes a listing of all metadata files and sees if there is still an associated G file, and if so whether its timestamp agrees with that recorded in the metadata file. If not, it deletes the metadata file. A person could send both the G file and the metadata file to another Ormerod user who wants to print the same item (they will however need to be transferred to the other SD card in a way that retains the G file's original timestamps).

Having a "remaining filament length" and/or "used filament length" window might be useful in any case, even if not used to estimate the remaining time, especially for those of us who experiment with 10m sample lengths of different filament materials. I might start a trial print, but the first attempt doesn't go quite right and I am debating whether to abort the print and try again with different settings or press on and see how it turns out. It would be nice to see at a glance whether or not I have enough filament left to start again. My tape measure always seems to run away and hide itself when it knows I need it in a hurry!

Dave
(#106)

David,
Just had my first crash whilst printing.
The chrome interface completely froze, the printer just stopped.
I tried to get ctrl/shift J but no response.
Tried to refresh chrome but I ended up with the Oops message.
Restarted Chrome, again Oops message.
Turned Ormerod power off and back on. still the Oops message
I can ping the Ormerod.

Connected via usb and Pronterface - connected.
Issued M111 S1 - Debugging enabled nothing else
After a short time this appears:-
Class Webserver spinning.
Class GCodes spinning.
Class Move spinning.
Class Platform spinning.
Class Heat spinning.

Tried the interface again and the interface refreshed and I can connect, this is the output in Pronterface:-
HTTP request: GET / HTTP/1.1
HTTP request: GET /css/bootstrap.min.css HTTP/1.1
HTTP request: GET /css/main.css HTTP/1.1
HTTP request: GET /js/jquery-2.1.0.min.js HTTP/1.1
HTTP request: GET /js/bootstrap.min.js HTTP/1.1
HTTP request: GET /js/jquery.flot.navigate.js HTTP/1.1
HTTP request: GET /js/jquery.storageapi.min.js HTTP/1.1
HTTP request: GET /js/jquery.flot.min.js HTTP/1.1
HTTP request: GET /js/jquery.filedrop.min.js HTTP/1.1
HTTP request: GET /js/reprap.js HTTP/1.1
HTTP request: GET /fonts/glyphicons-halflings-regular.woff HTTP/1.1
HTTP request: GET /favicon.ico HTTP/1.1
HTTP request: GET /rr_status HTTP/1.1
JSON response: {"status":"I","heaters":["27.6","25.5"],"pos":["0.00","0.00","0.00","0.0000"],"probe":"12","buff":900,"homed":[0,0,0],"seq":40,"resp":"Debugging enabled\n"} queued
HTTP request: GET /rr_files HTTP/1.1
JSON response: {"files":["AllTest.g","test1.g","setman.g","setbed.g","paul-pad.g","paultest.g","thinwall.g","ormaxis.g","vibratio.g","damperv3.g","vents.g","front co.g","paulfan6.g","saftycov.g","rwedge54.g","boardset.g","tempWebPrint.gcode","60 and 80 bridge tests.g"]} queued
HTTP request: GET /rr_gcode?gcode=M115 HTTP/1.1
JSON response: {"buff":900} queued
web: M115
FIRMWARE_NAME:RepRapFirmware FIRMWARE_VERSION:0.58-dc42 ELECTRONICSuet DATE:2014-04-19
HTTP request: GET /rr_status HTTP/1.1
JSON response: {"status":"I","heaters":["27.6","25.0"],"pos":["0.00","0.00","0.00","0.0000"],"probe":"15","buff":900,"homed":[0,0,0],"seq":41,"resp":"FIRMWARE_NAME:RepRapFirmware FIRMWARE_VERSION:0.58-dc42 ELECTRONICSuet DATE:2014-04-19"} queued
HTTP request: GET /rr_gcode?gcode=M105 HTTP/1.1
JSON response: {"buff":900} queued
web: M105
T:25.0 B:27.6
HTTP request: GET /rr_status HTTP/1.1
JSON response: {"status":"I","heaters":["27.6","25.5"],"pos":["0.00","0.00","0.00","0.0000"],"probe":"14","buff":900,"homed":[0,0,0],"seq":42,"resp":"T:25.0 B:27.6"} queued
HTTP request: GET /rr_status HTTP/1.1

Now all seems to be working again.

Very strange.

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

The last 2 days after work hours I have assembled a RepRap Ormerod from RS (green version). Today I was trying to commissioning the printer. Can't get a stable communication to the webinterface can't connect to pronterface. (printer is not connected, reed tons of posts on the web to se if other got the problems. Can connect withe the ardrino IDE. send commands so I decided to update to the new firmware and web interface.. now nothing works. The webinterface I can see but the printer do not respond to the input..

any idea?? meybe a new SD card??

Best Regards
Henrik
(Denmark)

Quote
Rothestar
The last 2 days after work hours I have assembled a RepRap Ormerod from RS (green version). Today I was trying to commissioning the printer. Can't get a stable communication to the webinterface can't connect to pronterface. (printer is not connected, reed tons of posts on the web to se if other got the problems. Can connect withe the ardrino IDE. send commands so I decided to update to the new firmware and web interface.. now nothing works. The webinterface I can see but the printer do not respond to the input..

any idea?? meybe a new SD card??

Best Regards
Henrik
(Denmark)

Hi Henrik,

1. Which firmware version are you using (use M115 to check), and which version of the web interface? [EDIT: sorry you can't do that if it isn't responding at all.]

2. Have you set the IP address in config.g? Can you ping the Duet from the PC?

Edited 1 time(s). Last edit at 04/24/2014 04:41PM 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].

I have flashed the RepRapFirmware-058-dc42.bin as descripbed. And it was verifyed by the bossac.exe file...

I used the command bossac --port=COM6 -U true -e -w -v -b RepRapFirmware-058-dc42.bin -R

No I can't ping the board.

I can't get access via the Arduino IDE software either..

So i can not confirm the firmware version...

I tried (just an hour ago, to flash back to the RepRapFirmware-057a-16-01-2014.bin version, same result no communication what so ever..

And that is the strange part, I had communication yesterday, not stable, where I tested the temperature sensors, heatbed nozzle etc. motors also responded perfectly.

Nothing has changed it is sitting on my desk, it runs on the power surply.

OS Windows 7 Pro 32 bit, it says on the port settings in windows it says "Bossa program port (com6)" se atteched file.

Best regards
Henrik

Quote
Rothestar
I tried (just an hour ago, to flash back to the RepRapFirmware-057a-16-01-2014.bin version, same result no communication what so ever..

And that is the strange part, I had communication yesterday, not stable, where I tested the temperature sensors, heatbed nozzle etc. motors also responded perfectly.

Nothing has changed it is sitting on my desk, it runs on the power surply.

OS Windows 7 Pro 32 bit, it says on the port settings in windows it says "Bossa program port (com6)" se atteched file.

Best regards
Henrik

After you have flashed the firmware, the Duet should connect to the USB using a different identity (VID/PID), and so will use a different driver and COM port number. Maybe try erasing (with the hardware erase button on the board), and re-flashing the firmware. As said - the COM port used to program (via Bossac) should be a different number to the port used by Pronterface after the firmware is running.

Another thing that can prevent communication after the firmware is loaded is if your SD card is not being read by the Duet. I thought RRP had sorted that issue, but perhaps like many of us you were supplied with an SD card that the Duet can only read occasionally - so it read it OK yesterday by now cannot do so. If you have another SD card to hand, it would be worthwhile formatting it to FAT32, copy the Duet folders & files to it and see if it makes a difference.

Dave
(#106)

Hi Henrik,

1. When you downloaded the firmware, did you remember to use the Raw button?

2. When you flash the firmware, how many pages does it say it is writing and verifying? It should be about 680 for 0.57a, and a bit more for 0.58.

3. After flashing the firmware, use Device Manager to see if Windows recognises the Duet, and on what COM port.

Edited 1 time(s). Last edit at 04/25/2014 09:01AM 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].

Got communication back
M115: FIRMWARE_NAME:RepRapFirmware FIRMWARE_VERSION:0.57a ELECTRONICSuet DATE:2014-01-16,

Did a z axes calibration, worked well. wrote all in the config.g file on the SD card.

Did a reboot but it seem like the board is not reading ti sd card. (change password, but is still the default).

X-axes homeing is not working after I updated the cong.g file. tryed putting some tinfoil on the little nob to see if that worked out... it didnt.


What is the best firmware and webinterface and where can i get it?? should be in a bundle as thoose two things go together...

Best regards

Henrik

Quote
Rothestar
Got communication back
M115: FIRMWARE_NAME:RepRapFirmware FIRMWARE_VERSION:0.57a ELECTRONICSuet DATE:2014-01-16,

Did a z axes calibration, worked well. wrote all in the config.g file on the SD card.

Did a reboot but it seem like the board is not reading ti sd card. (change password, but is still the default).

X-axes homeing is not working after I updated the cong.g file. tryed putting some tinfoil on the little nob to see if that worked out... it didnt.


What is the best firmware and webinterface and where can i get it?? should be in a bundle as thoose two things go together...

Best regards

Henrik

You need to replace the SD card with one that works before doing anything else. Homing is done using files on the SD card, so won't work properly if the Duet is having problems reading the card. The RRP web interface doesn't work properly, so don't waste your time with it, use DC42's latest firmware and web interface versions (as per thread title) - though you'll still need to use Chrome to get it to work.

Dave
(#106)