New RepRapFirmware 1.10-dc42

Chrome is working fine with config file saving. Thanx pkm!

Are there any plans to add this feature to Safari and/or IE ??

RepRapFirmware-1.10-b7-ch fixed it for me too

Quote
pkm
BTW, what is the difference between your version and David's?

We share a lot of the same code (my fork is actually based on David's and I've merged in most of his changes, and vice versa), but I added a code queue to my fork and implemented G-code interleaving to some extend. That means multiple G-codes can be run from different G-code sources in my fork, which are USB, AUX, Telnet, web interface and file/macro at the moment. The code queue is responsible for executing G-codes when they're supposed to be run (e.g. M106) and not when they're processed by the GCodes class, which would take place a few moves before they're actually performed. I found this quite important if a part cooling fan is present, but it may not be as critical as before now that we use dc42's excellent new move code.

Quote
pkm
The firmware seems to work, thanks a lot!

Now IE11 loads DWC very fast on the troublesome PC too, and there's a delay in Chrome (on any PC). I can use Wireshark with Chrome, if you're willing to look at it.

I'm glad the fix helps, thanks for testing it! IE11 loads the page a bit quicker because it uses client-side caching while Chrome and other browsers tend to load the entire web interface every time it's accessed, but the downside may be that updating to a newer DWC version might not work out of the box. If anyone has problems after doing so, it may be necessary to clear the browser cache first and/or force a full reload of the interface via Ctrl+F5.

I'll have a look at the IE config save issue when I start working on DWC 1.12. I wasn't aware there was a problem with it, but I must admit haven't used IE in a while (and I don't use Safari at all) because I've been using Firefox/Chrome/Opera on Linux instead.

I have now merged chishamm's latest changes to the Network and Webserver modules into my fork and put a test binary (version 1.10+4-dc42) here [github.com] (as usual, follow the link and press Raw to download it). Hopefully this will fix the problems that some users had with 1.10.

Chris, if you want to support a Microsoft browser then I suggest you ignore IE11 and concentrate on Edge. It works OK with DWC on my Windows 10 machine.

Edited 2 time(s). Last edit at 03/30/2016 09:10AM 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].

1.10+4-dc42 seems to work, thanks!

Sure, IE11 is not nesessary... I wonder if anyone here is using it at all. As they say, IE is a software that lets you install Chrome

Quote
pkm
1.10+4-dc42 seems to work, thanks!

pkm, thanks for the feedback, Chris, thanks for the fixes.

---

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

1.10+4 working here as well. Thanx david!

@chris: is it possible to show the printspeed from a gcode file? You can readout first and other Layerheights, maybe it´s possible to catch the printspeed as well out of the infos in a gcode-file.
This would help a lot when testing same files sliced with differnt speeds.

cheers
Dirk

There is no one print speed in a file. Different parts of a print will have different speeds. Perimeters can be done at a different speed than infill. Inner and outer perimeters can be done at different speeds. Movement without laying down plastic is normally at a higher speed.

I have seen some slicers dumb down the printer speed to a single number, but that doesn't really reflect reality.

Quote
critical_limit
@chris: is it possible to show the printspeed from a gcode file? You can readout first and other Layerheights, maybe it´s possible to catch the printspeed as well out of the infos in a gcode-file.
This would help a lot when testing same files sliced with differnt speeds.

I guess that would be possible, but instead I'd rather add simulation support (see M37) to the web interface and make the firmware write an extra tag to G-code files, which could be reused when a file print is started. I didn't find the print estimations generated by several slicers very accurate, which is why I don't want to use them, but I figure the results of M37 would be much better. OTOH there are so many other items on my TODO list that I want to get done first...

As for the web interface compatibility, I've been trying to develop the web interface to maintain compatiblity with all browsers that are supported by Boostrap and JQuery (see [getbootstrap.com] and [jquery.com]), but IE and Edge sometimes need special treatment. For that reason translations are (currently) not available in IE/Edge.

Is it too cumbersome to show current F value?

Simulation support would be great! But for long files it must take a lot of time, right?

Edited 1 time(s). Last edit at 03/30/2016 01:34PM by pkm.

Hmm, I guess I could replace "last layer time" on the print page with the current feedrate in my next version.

Simulating big files takes a while, but it will give you the most accurate print time estimation.

Quote
chrishamm
Hmm, I guess I could replace "last layer time" on the print page with the current feedrate in my next version.

Simulating big files takes a while, but it will give you the most accurate print time estimation.

That would be great! Last layer is on the graph anyway.
BTW the layer time is wrong in vase mode, is there a simple way to correct it? Probably read the layer height from the file and show how much time it takes?

If the velocity slider is adjusted, should the simulation start over?

Edited 1 time(s). Last edit at 03/31/2016 01:53PM by pkm.

Quote
chrishamm
Hmm, I guess I could replace "last layer time" on the print page with the current feedrate in my next version.

Simulating big files takes a while, but it will give you the most accurate print time estimation.

Perhaps the value you display could be the topSpeed value in the most recent DDA that includes both XY movement and extrusion? Or compute an average speed for the move by dividing totalDistance by clocksNeeded and converting to mm/sec?? I see little point in displaying the requested speed when many moves are too short to reach that speed.

Edited 1 time(s). Last edit at 03/31/2016 04:46PM 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].

Many thanks to Chris and DC! If you are changing the displayed statistics, would it be possible to record and display previous run times for models? Variation from run to run should be very small and when a print is repeated the run time is known.

David, Chris, I see that "resume after power failure" is getting popular for upper class 3D printers.
How does it work?
Is it very hard to implement to RRF?

I've given this some thought. It's possible to do, however, you need a UPS or SLA backup battery to do it propely. When a power failure occurs, you need enough power left to move the head away from the print, retract a little filament, and then run the hot end fan for long enough to prevent the filament melting and then solidifying in the top of the heat break.

---

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

A while ago I heard that it was planned to have a function to run macro when the extruder endstop is triggered.
Has it been implemented yet? I am planning to add some sort of filament sensor to the Duet

Hi David and Chrishamm. I'm using the 1.10 version and the last version of the web interface. It's printing fine.

Only problem, I can't seem to be able to connect to my printer with my cellphone anymore. It was working great before. When I go to the page, it opens but stays at disconnected. If I click on connect, it doesn't work. It's not the worse problem and I can live with it.

Edited 1 time(s). Last edit at 04/03/2016 09:39AM by Domterran.

Quote
SleepyPrince
A while ago I heard that it was planned to have a function to run macro when the extruder endstop is triggered.
Has it been implemented yet? I am planning to add some sort of filament sensor to the Duet

There is a new command M581 (and M582) which was documented on 22 march, where an endstop status change could trigger a macro, an emergency stop or a pause. [reprap.org]

I have not yet tested it, but I think that open a lot of possibilities. Yet the trigger is only on endstops (extruders or movement drives), but documentation suggests it may be extended later to other I/O pins.

Edited 1 time(s). Last edit at 04/03/2016 04:26PM by PRZ.

Guys congratulations to both of you . ...! i flashed the last firmware and all seems to workign fine untill now.

Good job guys be well.

---

Delta Printer
Duet 0.8.5 firmware 1.19

Quote
PRZ

Quote
SleepyPrince
A while ago I heard that it was planned to have a function to run macro when the extruder endstop is triggered.
Has it been implemented yet? I am planning to add some sort of filament sensor to the Duet

There is a new command M581 (and M582) which was documented on 22 march, where an endstop status change could trigger a macro, an emergency stop or a pause. [reprap.org]

I have not yet tested it, but I think that open a lot of possibilities. Yet the trigger is only on endstops (extruders or movement drives), but documentation suggests it may be extended later to other I/O pins.

I forgot that as the Duet could run 6 extruders, there is spare end stops on the expansion connector.
Pinout is defined here [reprap.org] , however, there are a few differences for the Duet 0.6 and Duet 0.8.5 (as there is one extruder more on board) and this pinout seems for the Duet 0.6.

Quote
dc42
I've given this some thought. It's possible to do, however, you need a UPS or SLA backup battery to do it propely. When a power failure occurs, you need enough power left to move the head away from the print, retract a little filament, and then run the hot end fan for long enough to prevent the filament melting and then solidifying in the top of the heat break.

If I just would like to stop the print and then continue it the next day, it's almost the same problem, right? How do I find where to restart?

Quote
pkm

Quote
dc42
I've given this some thought. It's possible to do, however, you need a UPS or SLA backup battery to do it properly. When a power failure occurs, you need enough power left to move the head away from the print, retract a little filament, and then run the hot end fan for long enough to prevent the filament melting and then solidifying in the top of the heat break.

If I just would like to stop the print and then continue it the next day, it's almost the same problem, right? How do I find where to restart?

Stopping the print and continuing the next day is easier. You would press the Pause button on the web interface or PanelDue, and we would provide an extra option to create a restore file on the SD card. We would need to save not only the head position when it was paused but also the file path, file position, current feed rate, fan speed, tool selected, temperatures, bed compensation or delta calibration values, pressure advance, firmware retraction settings and perhaps a few other things.

To resume, you would need to home the printer without the head colliding with the print (easy on a delta, not so easy on a Cartesian printer), then run the resume file.

This is likely to get implemented within the next few months, because some OEM customers for the Duet have asked for 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].

Quote
dc42
Stopping the print and continuing the next day is easier. You would press the Pause button on the web interface or PanelDue, and we would provide an extra option to create a restore file on the SD card. We would need to save not only the head position when it was paused but also the file path, file position, current feed rate, fan speed, tool selected, temperatures, bed compensation or delta calibration values, pressure advance, firmware retraction settings and perhaps a few other things.

To resume, you would need to home the printer without the head colliding with the print (easy on a delta, not so easy on a Cartesian printer), then run the resume file.

This is likely to get implemented within the next few months, because some OEM customers for the Duet have asked for it.

Great! This would be a *very* useful option because sometimes I just have to go and I can't leave the printer unattended overnight (or even for a few hours).

How about thermal expansion? Some larger parts might shrink with cooling. But I think that manual height adjustment before resuming can help.

I think there's still some sort of bug in the 1.10-dc42 firmware present. I had previously done only somewhat short prints (< 30 minutes) but now had a watchdog reset somewhere between 30-60 minutes in a print. This first happen with 1.10 (2016-03-24), then I found this thread and upgraded to 1.10+4 (2016-03-30). However, the print got again interrupted at some point after the 30 minute mark (sorry, don't have the exact time). M122 showed "watchdog" as cause for the last reset.

I did a third try with the same model gcode but this time with the DWC page closed after the print started and the print completed without issues. That's why I assume there's still something causing problems in the firmware if DWC is kept open while printing. My printer is a Kossel Mini rev3 from think3dprint3d with the Duet 0.8.5 board. LAN is connected without wlan using a static ip address and no usb connection is used. Firefox 45.0 (Linux) was used as browser and I got a "Communication Error. An AJAX error has been reported, so the current session has been terminated. Please check if the printer is still on and try to connect aing. Error reason: Not authorized" message visible in screen after the watchdog reset.

Vergo, thanks for your report. If the problems persist then please try reverting to 1.09x or even 1.09r.

---

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

On duet 0.6 i get an error if i tried to logon at the same time from two different pc. Apart fro that i ve printed more than one time with both of the mendels and everything was working fine. I ve never printed below 1hour....

Edited 1 time(s). Last edit at 04/06/2016 01:03AM by Gaou.

---

Delta Printer
Duet 0.8.5 firmware 1.19

It seems I've just had this exact same thing, a few hours into a 14 hour print.
I had the same error message, then could not re-connect. Refreshed the page and was presented with: ERR_NAME_NOT_RESOLVED
Searched for the MAC address on the network and it showed up so tried connecting via the ip address rather than the machine name. This just timed out.
Searched connected devices again and it was gone completely. Print meanwhile is still going ahead fine so just going to let it run it's course then cycle the power at the end. Hopefully it'll come back then.

Vergo, were you doing anything specific when it happened?

ByteSlinger, am I right thinking you're using dc42's latest 1.10+4 firmware with my latest DWC 1.11? If you get a chance, please don't turn off your printer after the problem occurred, connect it via USB , send the following codes and post their output here:

M111 P1 S1
M122

Quote
chrishamm
Vergo, were you doing anything specific when it happened?

No, I only had the "Print Status" view open in a browser window in order to see the progress of the print when randomly passing by the monitor and the PC wasn't being used when the watchdog triggered the reset. There wasn't either any other connections to DWC being opened apart from the "Print Status" view that appears to be doing some polling for json data. In settings, I have the UI Timings as default (Status Update Interval: 250, Extended Status Update after every: 10, AJAX Timeout: 8000, Default Notification Timeout: 5000, Reconnect Delay on Halt: 5000, Reconnect Delay on Firmware Update: 20000).