New Duet Web Control 1.14 and RepRapFirmware 1.17a-ch

chrishamm · 4 Jan 2017, 22:37

I'm very pleased to officially release version 1.14 of Duet Web Control and version 1.17a of my RepRapFirmware fork.

The new DWC version includes a new 3D visualisation to display the height deviations as generated by G29/G32. If you ran G29 before and already have /sys/heightmap.csv on your SD card, you can go to "Settings" -> "Machine Properties" -> "Show Heightmap" to visualise your results.

Here the full changelog for this new DWC release since the last version 1.13:

All the built files are now gzipped (even on wired Duets)
Implemented interactive WebGL-based control to display height deviations for G29/G32
Added new button to "Machine Properties" tab to download and show the heightmap results
Added new firmware status ('T') to show when a tool is being changed
Added "New file" button to "System Editor" tab
Rewrote tool change code and added options to specify which macros shall be run to the settings page (not implemented in the fw yet)
Added initial support for the upcoming Duet Ethernet
Changed file upload speed precision to 2 decimal places if it is greater than 1MiB/s
Bug fix: Macro filenames were stripped if they contained a dot even if their ending wasn't g, gcode or gc
Bug fix: Uploads caused an AJAX error if the firmware responded with an HTML error code

Since my inofficial RC1 the following things have changed:

Bug fix: AJAX requests to download heightmap.csv should not cache anything any more
Bug fix: Changed firmware binary name for Duet Ethernet from "DuetEthernet*.bin" to "DuetEthernetFirmware*.bin"
Bug fix: 3D heightmap visualisation doesn't pop up any more if a print is in progress

Prebuilt DWC packages are available here: https://github.com/chrishamm/DuetWebControl
If you own a Duet WiFi, upload DuetWebControl-1.14.bin to your machine, otherwise use DuetWebControl-1.14.zip.

Apart from that I have released version 1.17a of my firmware fork on GitHub. Credits for most of the changes since my last official release 1.13 go to dc42 - please refer to the WHATS_NEW file on his repository to get a full list of what has changed since then. So far the only considerable differences between his latest firmware version and mine are:

Implementation of a code queue mechanism to ensure that certain codes like M106 are performed just-in-time and not when moves are initially processed by the firmware. This comes in handy when printing bridges or overhangs with a part cooling fan because the fan will be turned on and off in sync with the moves that are being executed.

The way G-codes are read and buffered internally is different. Prior firmware versions used to rely on buffers in each of the File instances and IMO was a waste of memory because at least the older Duets have very little free RAM. Hence I came up with a slightly more efficient approach that works just as well and saves a few KB of RAM.

On first-gen Duets (0.6 / 0.8.5) the official firmware will report two SD card volumes to the web interface whereas mine reports only one. This guarantees that the "SD Card" mount button on the "G-Code Files" page is hidden on first-gen Duets.

My build system relies entirely on Makefiles instead of a full-grown Eclipse environment and based on dc42's CoreNG I provide a separate Arduino board package that allows you to easily create custom sketches on each of the available Duet boards. If anyone is interested, it can be found here: https://github.com/chrishamm/ArduinoDuet

Prebuilt firmware binaries of my 1.17a fork can be downloaded here: https://github.com/chrishamm/RepRapFirmware/tree/dev/Release

If you find any issues in either DWC or my RRF fork, please report them here or on GitHub.

Last but not least many thanks again to T3P3 and dc42 for their continuous support - without them this whole release wouldn't have been possible.

lolorc · 1 Apr 2017, 22:44

ACE, Thanks !
(make instead of eclipse is ACE !)

roboduet · 4 Jan 2017, 22:53

Congratulations!

Visual representation of height map will not be available for the "standard" N-factor delta calibration (using a G30 command)?

Russ Gries · 1 May 2017, 05:21

so far so good… love the height map.

nice work you guys.

thanks for working so hard so the rest of us can create and make new thing with your improvements

is there a way to save the height map as an image? i can right click on the scale image and "save as" but i have to screen capture to save the height map.

~Russ

burtoogle · 5 Jan 2017, 09:22

Firstly, thanks a lot for your work on this.

A suggestion: how about changing the colour of the -ve peaks in the heightmap image to something other than red (I suggest blue) so that when you view the map from above you can tell which areas are high and which are low.

chrishamm · 5 Jan 2017, 11:54

@roboduet:

Visual representation of height map will not be available for the "standard" N-factor delta calibration (using a G30 command)?

The 3D visualisation is triggered either by the final G29 output or by the "Bed equation fits points …" response that comes up after the final G30 S command has been processed.

@Russ:

is there a way to save the height map as an image? i can right click on the scale image and "save as" but i have to screen capture to save the height map.

At the moment you can only save the grid view by taking a screenshot. If more people request this feature, I can add it to the next DWC version.

@burtoogle:

A suggestion: how about changing the colour of the -ve peaks in the heightmap image to something other than red (I suggest blue) so that when you view the map from above you can tell which areas are high and which are low.

I don't really see the need for this, because we already have the 2D grid to reflect an even bed. If you see the grey lines above the coloured grid, you know the Z coordinates under these points are negative, else they're positive. I guess it wouldn't be impossible to implement a different colour scale in a future version though.

burtoogle · 5 Jan 2017, 12:03

@chrishamm:

I don't really see the need for this, because we already have the 2D grid to reflect an even bed. If you see the grey lines above the coloured grid, you know the Z coordinates under these points are negative, else they're positive. I guess it wouldn't be impossible to implement a different colour scale in a future version though.

That's true but, personally, I find the grid lines rather confusing when the view is from overhead. I find it difficult to work out which parts of the map are above and which are below the grid. Blue lakes and red mountain tops would be easier to interpret.

mhackney · 5 Jan 2017, 15:24

burtoogle wrote
A suggestion: how about changing the colour of the -ve peaks in the heightmap image to something other than red (I suggest blue) so that when you view the map from above you can tell which areas are high and which are low.
I don't really see the need for this, because we already have the 2D grid to reflect an even bed. If you see the grey lines above the coloured grid, you know the Z coordinates under these points are negative, else they're positive. I guess it wouldn't be impossible to implement a different colour scale in a future version though.

I really would like this feature as well. It would take all the guess work out of it for us older gents with bifocals.

Jackal · 5 Jan 2017, 17:02

I am having multiple "SetPositions called when DDA ring not empty" in the log while printing
What is causing it and what does it mean?

dc42 · 5 Jan 2017, 17:05

@Jackal:

I am having multiple "SetPositions called when DDA ring not empty" in the log while printing
What is causing it and what does it mean?

That indicates that something is happening that I did not expect to happen. Are you running firmware 1.17a or 1.17a-ch? Can you make the gcode file available?

Jackal · 1 May 2017, 17:32

I was running on 1.17a-ch, 1.17a does not show such problem.
Here is the file, it's a bit large.
https://www.dropbox.com/s/yrw160n6cmfgp5r/PART_3%2B4.gcode?dl=0

I have stopped my 1.17a-ch print since I got a bad first layer and I am now printing on 1.17a

dc42 · 5 Jan 2017, 17:44

@Jackal:

I was running on 1.17a-ch, 1.17a does not show such problem.
Here is the file, it's a bit large.
https://www.dropbox.com/s/yrw160n6cmfgp5r/PART_3%2B4.gcode?dl=0

I have stopped my 1.17a-ch print since I got a bad first layer and I am now printing on 1.17a

That's one for chrishamm to look at then.

chrishamm · 5 Jan 2017, 17:54

Thanks for that file, I'll check if I can reproduce your problem.

Russ Gries · 5 Jan 2017, 21:04

Chris, is there any plan to make online editing for the G code files available?

I would think it would be easy, just like editing the other things like macro and system files.

I find my self wanting to make simple changes to a g code file but have to re upload every time.

Thanks!!

~Russ

Russ Gries · 5 Jan 2017, 21:42

also it might just be me, but when i try to download a Gcode file that is in a folder, i get "File not found"

just pointing this out.

also something very strange. is going on when i run a print. i have pause commands in my files and when the pause command is ran everything locked up. web interface, PanelDue, its a forced restart by pulling power???

very strange.

when i Pause the print with the M25 command from buttons. its fine. only when its in the g code its self???

oh yeah, its busted. same exact file, one with an M25 in there and one with out. just locks up. STRANGE

can some one else else test this?

Thanks!!

~Russ

crc1337 · 6 Jan 2017, 03:43

I get this message repeatedly (multiple times per second sometimes) when printing using these builds on a Duet WiFi:

SetPositions called when DDA ring not empty

I definitely wasn't seeing this prior to the update. The machine seems to be functioning, I haven't printed anything significant but it has printed a few calibration pieces fine.

Jackal · 6 Jan 2017, 07:37

I have another problem with chrishamm's build.
I got M557 command right before my G29 probe in my bed.g
but when I run it it shows error that my grid was not defined
The same bed.g works fine in David's build.
Maybe something to do with the code queue or buffering?

chrishamm · 6 Jan 2017, 12:30

Thanks for your feedback so far! I have just put another firmware build here: https://www.dropbox.com/s/xkw0f3xxdunposk/RRF-1.17a%2B1.zip?dl=0
This one should fix issues with M226, G92 (i.e. the SetPositions problem) and M557. Please let me know if this resolves your problems.

Russ, you're saying you get a "File not found" error message when you try to download a file from the Duet. Can you tell me what board you're using and what the name of your file is? I'd like to be able to reproduce your problem so I can fix it as well.

G-code file editing except on the macros+sys pages is not on my TODO list, but I may implement that when I add checkboxes to the file pages.

Jackal · 6 Jan 2017, 17:36

I am about an hour into the print with 1.17a+1, everything seems fine.
Both the SetPositions and M557 problems are gone.
Great work

Russ Gries · 1 Jun 2017, 22:08

@chrishamm:

Russ, you're saying you get a "File not found" error message when you try to download a file from the Duet. Can you tell me what board you're using and what the name of your file is? I'd like to be able to reproduce your problem so I can fix it as well.

I'm using a DuetWifi V1.0

when i get the "File not found" error, its only when I'm in the Gcode section of the web interface. & the file Must be in a folder. It dose not matter what file. as long as its not in the root gcode folder. ( i have other folders that i keep G code file's organized, its the files in those folders that show the error when clicking download) im guessing that its just not grabbing the directory correctly? if its in the root Gcode folder its fine…

@chrishamm:

G-code file editing except on the macros+sys pages is not on my TODO list, but I may implement that when I add checkboxes to the file pages.

it would be extremely helpful if there was an edit function. re uploading all the time for a simple change like editing something in the start script is a pain,

so an edit option would be very helpful.

i think i heard others say it was good also in another thread a while back.

[h]also,[/h] did you see my strange M25 command problem?

it could be a firmware thing ism not sure. but if some one could test theses files that would be good.

test theses, this is the original file but with an added M25 on line 200.

http://open-source-energy.org/rwg42985/russ/photos%20for%20other%20sites/Russ%20M25%20HollowDodecahedron%20prob.zip

Thanks!!

~Russ