Firmware 2.02 Release candidate 3 now available

[fma]

Please, don't disable commands in firmware ! Sooner or later, someone will need to change something while printing, to make specific stuff. And this is where RRF is great: it allows us to experiment, and make amazing things.

I vote to only disable some critical buttons from DWC/Panel Due, or, better, just add a confirm dialog, so we can still use them. And having the ability to define which buttons we want a confirmation for would be great (not too complicated to do with DWC, maybe more tricky with Panel Due).

[kuhnikuehnast]

Or implement a switch like enable / disable potential "dangerous" commands during print. (like a "child safety lock" )

[Jacotheron]

I think for this specific issue faced above, if the firmware could prevent having no tool selected during a print (in stead of simply preventing a tool change), it might have solved it. Changing tools mid print is sometimes needed and very useful.

Also another vote for the switch to disable/enable these potential dangerous commands, or the confirm dialog. Someone should know what they are doing, when running them.

[deckingman]

@garyd9 said in Firmware 2.02 Release candidate 3 now available:

You don't pause before changing tools? Would it be disruptive to pause before changing tools? (I've never worked with a mixing hot end, so I don't know if pausing causes a problem or not.)

Correct. That is to say, with a mixing hot end all filaments are loaded all the time. So there is no need to pause between tool changes. I just set the active and standby temperatures the same for all tools in the start gcode. Sometimes, it is necessary to purge between tool changes but not always. It depends on the model and often the purge can be accomplished during infill so that printing with multiple tools (colours) is a continuous process.

[DocTrucker]

@dc42 Previously I suggested that while in the print process that gcode should be encapsulated in another command, sort of like linux 'sudo dosomethingmad'.

Enabling or disabling this behaviour could be set in config and the PanelDue firmware could have a log in and configurable time out to enable the use of dodgy commands mid build.

[Greg3D]

I'm in the process of setting up a menu system on the 12864 LCD for my freshly acquired Duet Maestro

The video in this tweet https://twitter.com/Greg191134/status/1060312518659358720 illustrates the glitches I'm having with buttons appearing and disappearing.

Also for the horizontal bars, which are an image, the eight pixels on the right are not displayed.

Are these some limitations of the current implementation of the menu system?

[zerspaner_gerd]

Something must be done against the accidental confirmations!

But scary that apparently all existing buttons / commands can be executed in print, what could happen there.

Everyone is responsible for themselves which G M command he sends over the g-code Console Manuel. But the buttons, menus Head Movement should actually be locked at a printing, so rather DWC and PanelDue firmware?

[kuhnikuehnast]

@zerspaner_gerd said in Firmware 2.02 Release candidate 3 now available:

Something must be done against the accidental confirmations!

But scary that apparently all existing buttons / commands can be executed in print, what could happen there.

Everyone is responsible for themselves which G M command he sends over the g-code Console Manuel. But the buttons, menus Head Movement should actually be locked at a printing, so rather DWC and PanelDue firmware?

Good point. And if you really have to change something during a print you could just uncheck the child safety button in the Duet Web Control. If you programm these changes in the config.g file it would be pretty difficult to make any changes during a print

[dc42]

@greg3d said in Firmware 2.02 Release candidate 3 now available:

I'm in the process of setting up a menu system on the 12864 LCD for my freshly acquired Duet Maestro

The video in this tweet https://twitter.com/Greg191134/status/1060312518659358720 illustrates the glitches I'm having with buttons appearing and disappearing.

Also for the horizontal bars, which are an image, the eight pixels on the right are not displayed.

Are these some limitations of the current implementation of the menu system?

Please confirm that you using firmware 2.02RC3. If so, please start a new thread about this issue, and share your menu files.

[Googliola]

@dc42 maybe it's a minor bug, but it does not work as you said. Could you please have a look into it.

[dc42]

@googliola said in Firmware 2.02 Release candidate 3 now available:

@dc42 maybe it's a minor bug, but it does not work as you said. Could you please have a look into it.

I assume you mean this:

Googliola 7 Nov 2018, 07:45
@dc42 @claustro
M557 X15:325 Y-15:270 P3 (in config.g)
resulting in
Error: M557: Error: M557 P parameter is no longer supported. Use a bed.g file instead.

Seems like a bug to me. Or what am I missing? (It worked just fine with S parameter, but defining the number of probing points is so much handier...)

I confirm, it's a bug. Will be fixed in 2.02RC4.

[Drammy]

Hey @dc42 thanks for implementing the wifi re-connecting functionality in 2.02! (I'm running RC3) I've been doing some testing on the web connectivity...

At first I thought it was working perfectly and it was until...
I switched on my Pi running motionEye (which is normally running 24/7). The moment that the feed came up and started displaying in Duet Web Control the drop outs started immediately exactly.
I never thought the cause of all the problems I'd been having could be the web feed and the Pi just happened to be switched off. Sure enough, deleting the link to the feed in the user interface settings and, boom, the disconnects stopped.

Interestingly I have just put the web feed url back in (same url as I cut it previously to put in clipboard) and I am now not getting drop outs. I will continue to monitor and test this though.... EDIT: after about 5 mins of writing this email we're back in the state where it disconnects and reconnects.

I can open the web feed on a separate browser tab and it continues to feed as expected during the drop outs.

Could there be an issue with taking web feeds and it causing DWC connection drop outs?

My Duet config
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.02RC3(RTOS) (2018-10-17b2)
WiFi Server Version: 1.21
Web Interface Version: 1.22.4-b1

My network config
EE router in house on which my machine connects.
Netgear EX2700 extender in garage on which Duet WiFi and motionEye both connect.

Running Mac OSX Mojave & Google Chrome (Version 70.0.3538.77) but the same thing happens on Safari (Version 12.0.1 (14606.2.104.1.1)) and on my smart phone (Samsung s8+ on Chrome).

note: I work in IT and am pretty confident it is not my network as I work from home and use it constantly without any other issues.

I hope that helps?

[Drammy]

And another thing I noticed is that my first print on the new firmware started printing correctly but on DWC the layer had jumped to 4.

It wasn't until the real layer 4 completed that the layer counter started displaying the correct value.

Indeed, the first three layers were recorded as taking 0 time and layer 4 just under an hour.

hhmmmmm.. the stats have just changed to this..

[brunofporto]

Issues I am having so far:

Normal printing - no issues. I've been printing with RC3 since published.

But sometimes when I start a new print or use my filament unloading/loading macros without selecting the active tool (only one) first it just changes the status to "busy" and does nothing... Sometimes, not always, it complains about not having a selected tool but most times it just "locks" at Busy doing nothing.

For now, I just added "T0" at the end of config.g and I am pretty sure that the error is due to something wrong with my starting and loading/unloading macros. What should I do to not have this error?

[dc42]

I have improved the layer detection code in the forthcoming 2.02RC4 release. I'll ask chrishamm to look at whether dropouts in the IP camera feed could cause disconnections.

[Drammy]

Ah good stuff, cheers!

[garyd9]

@dc42 said in Firmware 2.02 Release candidate 3 now available:

I have improved the layer detection code in the forthcoming 2.02RC4 release.

I don't know if it's related, but I had a print (sliced by Cura engine 3.5.1) this weekend with a total height of 400mm, layer height of 0.2mm. The duet board (1.04 with 2.02RC3) failed to properly parse the proper total height of the print.

Instead, it showed an object height of 1mm. (It usually detects the object height properly with files sliced by this version of Cura.) Layer height and filament usage was properly detected.

GCode file (zipped) shared from my google drive here: https://drive.google.com/open?id=1LsdgTVO-XuDT8jmWM_NMnu4kEoQ3Fxpi

[chrishamm]

@drammy said in Firmware 2.02 Release candidate 3 now available:

I never thought the cause of all the problems I'd been having could be the web feed and the Pi just happened to be switched off. Sure enough, deleting the link to the feed in the user interface settings and, boom, the disconnects stopped.

It sounds very odd that a bad connection to your IP cam causes DWC to disconnect. In fact DWC does not track if the loading of a webcam image is successful, so I see no reason why it would misbehave. However if you get connectivity issues while using the webcam image, I suggest you press F12 to open the developer console and switch to the Network tab. There you can track which network requests suceeed and which ones fail. DWC should only disconnect if rr_ requests in there fail.

Is there any chance you can send over a screenshot of that section when the problem shows up again?

[Drammy]

@chrishamm thanks for your help.

I'm a developer so have had the Chrome dev tools open since the print began. I cleared the console down after the last time I removed the webcam url from settings and there has been 0 xhr exceptions raised for the last 2.2 hours; everything is working as expected. Like I said, 2.2 hours without a single failure

I then add the webcam url and within a couple of minutes it permanently loses connection. Some times it may reconnect for a couple of seconds which may be long enough to remove the web url and hit save and for the rr_upload to complete. If this happens then everything returns to normal but its rare to get long enough. I've found the best way to recover the connection is to reboot the motionEye server.

I've done a video of the problem if you need it? Here's the screen grab. Let me know if you need any more info.

EDIT: thought I may as well add the console exceptions..

arrrgghh, akismet.com is flagging the console log screenshot as spam!??

[chrishamm]

Hmm, thanks for that - I just saw the exceptions that you showed. But as you can see the web interface fails to receive four rr_ requests in a row, which causes a disconnect in DWC's logic (provided you have set the number of AJAX timeouts to 3).

May I ask what OS you are using and if the same problem occurs on a different device, too?