New firmware 1.08e and Duet Web Control 1.06

Quote

Moved tool number check to GCodes class (to prevent possible memory leak)
Responses from macro files are no longer followed by "ok" if Marlin is emulated (ok will be reported as soon as the macro has finished)
Modified M20 S2 to report directories with '*' prefix (useful for future PanelDue firmware versions)
Implemented M116 C-parameter to wait for the chamber temperature to be reached
Implemented M141 with additional 'H' parameter to specify the chamber heater to use
Implemented M408 as described on the G-code wiki page (for future PanelDue firmware versions)
PIDs may be turned on only if no heater fault occurred before
Implemented safety feature to prevent too high heater temperatures (thanks dc42 for this idea)
Moved some FatFs variables back to the stack (thanks dc42)
Moved watchdog routines into the Arduino hardware tree
Updated Arduino hardware tree and build instructions for Arduino 1.6.3 (though I wish Arduino had kept their SAM3X files in their core package)
Updated SD image files: 1) Added M116 P-parameter again to tpost*.g macros 2) Increased travel speed in Ormerod bed.g macros
Checksums are (hopefully) enabled for serial AUX line (thanks dc42)
Updated Ormerod bed.g files to call G30 S again after last point
Bug fix: Average heater PWM values should be reported properly (thanks dc42)
Bug fix: HeaterAtSetTemperature won't block the G-codes class if a heater fault occurs
Bug fix: Heat::GetStatus never returned heater fault status (although I couldn't see anything obviously wrong in dc42's original implementation, maybe a GCC bug?)
Bug fix: Motor currents were occasionally not updated when in idle mode
Other minor changes

Quote

Added heater no. 5 to tool page and to heater table
Added support for heated chamber (also see M141)
Implemented auto connect option (this is enabled by default)
Only two heaters and drives and the heated bed are visible in the info row (behavior after connect with more heaters hasn't changed though)
Placeholder is shown on config.g page if the file cannot be displayed
Fan RPM cell is hidden if fan controls are not shown
Bed state can now be toggled (also see M144) by clicking on the Bed label
Minor changes

• css/defaults.css
• js/interface.js
• reprap.htm
• language.xml (optional)

Quote
zombiepantslol
Hmm, looks like your config file is too long. I'm planning to getting rid of the format buffer (which is currently limited to 2KB of data), but these changes will require quite some work, which is why I haven't started yet. Scrollbars won't help you there. If you want it to display correctly, I suggest you remove some of your commented lines - then it should be displayed properly again.

screen-shot-1.jpg

Quote
BenBB
Hi There, any one else with this issue ?? S1 is not recognized...

I did the following:
- Downloaded RepRapFirmware-108d-zpl.bin
- Then downloaded the WEB interface as is
- Copied the DEFAULT.g to CONFIG.g, changed the IP addr...thats all for now
- Erased the OR2, did a reset
- Loaded the file via BOSSAC
- All 100%

Now I connect via the WEB interface, all 100% the OR is connected
now I click on the HomeAll button and things go south... the bed simply continues, hit the limit switch and just continues, NO STOPPING just tries to move the bed
Then the X axis moves forward... while the limit is reached...
I also tried to to change the HOMEALL.g but that also did not help... this works in DC42`s code but what can cause this.... the stop is recognized since the LED on the DUET comes on when I manually push against the limits switch
I have converted back to DC42 V104e... no WEB interface, I will use Pronterface for now

G91
G1 Z5 F200
G90
M558 P1
G1 X-240 F2000 S1
G1 X3 F2000
G1 X-30 F200 S1
M558 P2
G1 X45 F2000
G1 Y-240 F2000 S1
G1 Y3 F2000
G1 Y-30 F200 S1
G30
G1 Z5 F200
G1 X0 Y0 F6000

Tx Ben

Quote
dc42
Paul, try shortening the comments. I think what matters is the file size, not the number of lines.

Quote
dc42
If you really want to use M32 or M23 in a file macro, then I believe it should work in my fork.

Quote
zombiepantslol

Quote
dc42
If you really want to use M32 or M23 in a file macro, then I believe it should work in my fork.

I'm sceptical - both of our implementations rely on GCodes::fileBeingPrinted for both file prints and macro files, and M32/M23 overwrite/reuse this variable. Hence I've added a check to my fork to prevent calls to these two G-codes from macro files. But I must admit I haven't tested that with your fork, so you might be right

Quote
zombiepantslol
Doug, the bowden tube length should be saved automatically when you've finished your input and then deselect the input field. If it doesn't work for you, can you tell me which browser you're using?

cannibalistic_cow, thanks for your feedback, nice to hear it's working well. You cannot use M32 or M23 in file macros, instead run your macro and then send a file to print. The printer will wait for the macro to complete first and then run any other G-code.

Quote
zombiepantslol
dc42, I agree. We should utilise the stack in future firmware versions for file prints - I've been wondering why M32/M23 don't already do this anyway.

Melmie, the web interface only shows this pop-up if your password from your config.g file doesn't match "reprap". Please check your configuration again and try the password you specified in there.

Doug, am I right thinking you've got this sorted out?