New firmware 065g-dc42 and web interface 0.91

I've release a minor update (version 0.65g-dc42) to my firmware fork at [github.com], and another (0.91) to the web interface at [github.com].

The change to the firmware is that the M190 command no longer sets the standby temperature. This fixes a problem whereby the M1 command would heat the bed up again.

The change to the web interface is that only two estimated end times are displayed, one based on layer time and the other on filament consumption. Both use the average of the last 5 layers to work out the rate, or the average of all layers if there are fewer than 5 completed layers.

Edited 1 time(s). Last edit at 06/14/2014 07:56PM 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].

Wall gave it a try. Don't have jtag so I can't give much, but hear is my observations:

Web interface:
1. Cant tell when the printer has been homes All.
2. Cant get the current coordinates of X, Y and Z.
3. Temperature Graph is not working, I can set head bed to on and the Hot end.
4. The Version for the FW is not printing on the Settings tab.

Going back to the RepRapFirmware-059e-dc42.bin FW. I do need the Web Interface for that version though. Still haven't figured out ho to get prev versions in Git. Thanks for letting me try

It sounds to me that you updated the firmware but not the web interface, or vice versa, or you didn't install all of the web interface files. Versions 0.65e-dc42 and later need web interface 0.90 or later. You need to put all the web files on the SD card. Those upgrading from 0.90 need only upload reprap.js and reprap.htm because the other files have not changed.

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

Hi dc42,

I'm trying your 65g-dc42 firmware and have some comments to do about it :
- it would be nice to have an echo of the commands typed in the "Send Gcode" entry. This command echo should appear in the message log frame along with the ok's displayed if "Show ok" is checked. This echo is interesting for debugging because it gives you some sort of commands history.
- reloading the HTTP page seems to reboot the Duet. The procedure to test is easy : access your printer IP with a browser, connect, reload the page, re-connect and check the message log. If you have a Pronterface running at the same time, you can see the firmware version being displayed in its console.
- I tried to upload a Gcode file generated with Slic3r, and it seemed to crash or stuck my printer every time. The beginning of this file is :
G21 ; set units to millimeters
M107
M190 S57 ; wait for bed temperature to be reached
M104 S200 ; set temperature
M109 S200 ; wait for temperature to be reached
Ok, it looks strange to have M104 followed by M109, but that's what Slic3r generated, but that's not an issue. Executing these lines manually one after another (that's why I'd appreciate the command echo !), it appears that M109 reboots the Duet.
The same test performed with Pronterface ends the same, I even simplified the test by sending a single M109 command : power on the printer, connect either with a browser or Pronterface, send M109 and you're done :-(
- the moves in X and Y are very slow while compensating Z.

I downgraded to 65f-dc42, same issues.
New downgrade to 65e (back to the first one I used), same issue with the HTTP reload but no more problem with M109 and moves are much faster.

I attached my config.g file in case it's relevant, but I'm not sure.

I've a question for you, for my curiosity : why are you developing your own firmware and web console versions rather than working on the main stream ?

Thanks
Patrice

No i downloaded the binary from Git (RepRapFirmware-065g-dc42.bin) and the part of the interface that works is telling me i am running html and js v0.91.

This might help. I am getting and error in java Script:

Uncaught TypeError: Cannot read property 'hasOwnProperty' of undefined

if (resp.hasOwnProperty('myName') && resp.myName.length != 0)

reprap.js:131

Hi Patrice,

Quote
paflviet
Ok, it looks strange to have M104 followed by M109, but that's what Slic3r generated, but that's not an issue. Executing these lines manually one after another (that's why I'd appreciate the command echo !), it appears that M109 reboots the Duet.
The same test performed with Pronterface ends the same, I even simplified the test by sending a single M109 command : power on the printer, connect either with a browser or Pronterface, send M109 and you're done :-(

That's strange because I think most people (including me) have a slic3r-generated M109 command in their gcode files. I'll re-test it when I am back in the office.

Quote
paflviet
I've a question for you, for my curiosity : why are you developing your own firmware and web console versions rather than working on the main stream ?

Only RepRapPro staff can submit changes to the RepRapPro/RepRapFirmware repository, so it is up to them whether they integrate my changes into the main stream or not.

---

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 just found a bug in the M109 code. This is actually a bug in RRP's firmware which got copied into my fork when I merged their 0.65e branch into mine. The bug means that if you don't execute a T command before executing M109, or you execute a T command with an argument that is negative or too high (e.g. T2), then the selected head is -1 when it is used as the index into the array of PIDs used to control the heaters. This might result in a hang, a crash, or nothing.

The code also makes the assumption that there are at least as many heaters as the number of extruders plus one, but that is true in the current firmware builds.

I'll fix this and do some more tests when I am next in the office. The workaround is to put a T1 command in config.g and/or at the start of the slic3r custom start gcode. However, Patrice already has a T1 command in config.g that he attached to his post, so perhaps there is another problem.

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

A "detail" bothers me : the Ormerod is a one-extruder printer, what's the number of its head ? 0 or 1 ? I've seen configuration or G-code examples using either T0 or T1.

Couldn't it be interesting to have in some file (sys/config.g ?) a parameter to set the actual number of heads of the printer, which value could be used by the firmware to avoid such crashes in case of bad commands in the file to print ? I haven't found a Gcode usable for this, maybe a sys/parameters.sys or sys/defaults file could be ok. This could be used also for future needs I can't imagine now. The startup sequence of the Duet board should become :
1. initial boot sequence
2. read the defaults file
3. read the config.g file
3.1 in case of something wrong while running config.g, output some log to the console and overload the G commands parameters to the defaults if the overloading is non-ambiguous. For example, let's see a Tx command (say T3) with x greater than the maximum value set by the defaults :
3.1.1 if the defaults set the maximum value of x as 1 (printer with a single head), x can be safely overloaded with 1 : T3 is automatically changed to T1 and a log is printed to warn about this change
3.1.2 if the defaults set x to 2 (2-headed printer), no decision can be made because we can't decide automatically if x should be replaced with 1 or 2 : a log is printed and the file loading and execution stop.
4. go on with the boot sequence if there's anything else to do when the file is completely loaded.

I'm thinking while writing ;-) Couldn't some checks be performed when the Gcode file is loaded, before starting its execution ? These checks could be performed on the fly, it won't take a lot more time than simply loading it, and the file is executed only if it's clean. All the invalid lines should be logged like this :
#line [invalid line content] [as explanatory as possible message]
So you know immediately which line and G-code are involved, and probably the beginning of the solution.

My 2cts
Patrice

Hi Patrice

From 0.65e, we changed the numbering of the first tool to T1, rather than T0, for consistency, as the bed is usually referred to as heater 0, while the first hot end is usually heater 1. This also allows us to use T0 (or any other non-defined tool number) as a command to put all extruder/hot ends/tools into standby. The multihead support has only recently been added to the RepRap Firmware, so we're still working out how to get everything working correctly.

There is a gcode to define the 'tools'; it's M563 - [reprap.org] . You can see how it's used in the config.g in our 'test' branch - [github.com]

You define what tools you want, and select the tool with T[tool number]. When you select (or deselect) a tool, it can run a macro (set of commands); these are the tpre1.g, tpost1.g and tfree1.g files in the sys folder. This does mean, at the moment in firmware 0.78 (which is in testing), we cannot put the tool number in config.g - the code for nested macros (calling one macro from within another, and returning it to the same point at the end) has not been written. When you start having multiple hot ends, which have a standby temperature, you don't really want them all activating when you turn the machine on, anyway! However, we'll update the instructions, to remind people that you always need to select the tool number before manually setting hot end temperature, and that the tool should be added to the the Slic3r configuration. I think a log message is generated (rather than a crash) if a hot end temperature is set, but no tool is selected.

We will always release the firmware in a standard configuration for single hot end/extruder machines, so new users are shielded from this complexity. Proper documentation for all this is 'developing'.

Ian
RepRapPro tech support

I've just confirmed that sending M109 without a valid tool selected crashes 0.65g-dc42 firmware. This was easily reproducible by sending T2 followed b M109 S100.

I've implemented a fix for this bug in version 0.65h-dc42, now available at [github.com].

As I previously mentioned, this bug was inherited from RRP 0.65e firmware, so it is present in that firmware too. However, the behaviour when it is triggered may be different. On my firmware, the bug causes a lockup, which is detected by the watchdog, which resets the system to protect against over-temperature conditions. The RRP firmware doesn't have a watchdog, so it might just hang, or it might eventually recover, having overwritten some variables and therefore leaving the system in an unpredictable state.

---

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
paflviet
Hi dc42,

I'm trying your 65g-dc42 firmware and have some comments to do about it :
...
- reloading the HTTP page seems to reboot the Duet. The procedure to test is easy : access your printer IP with a browser, connect, reload the page, re-connect and check the message log. If you have a Pronterface running at the same time, you can see the firmware version being displayed in its console.

No, it doesn't reboot the Duet. However, whenever the browser connects, it sends the M115 command so that it can display the firmware version. That is why you can see the firmware version being displayed in the Pronterface console. If it really did reboot the Duet, and you are running Pronterface under Windows, then you would lose the connection with Pronterface. if Pronterface didn't disconnect on a reboot, then you would see the "Network up, IP=..." message.

Quote
paflviet
- I tried to upload a Gcode file generated with Slic3r, and it seemed to crash or stuck my printer every time. The beginning of this file is :
...The same test performed with Pronterface ends the same, I even simplified the test by sending a single M109 command : power on the printer, connect either with a browser or Pronterface, send M109 and you're done :e

I'm fairly sure this was caused by the M109 bug that I have already mentioned in earlier posts, and which is fixed in version 0.65h. I think that somehow you must have ended up with an invalid tool selected when the M109 command was executed. Although you posted your config.g.file, you didn't post the gcode file you were running, so perhaps there was something in the gcode causing an invalid tool selection, or in setbed.g or something else you run before you try to print..

---

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
No, it doesn't reboot the Duet. However, whenever the browser connects, it sends the M115 command so that it can display the firmware version. That is why you can see the firmware version being displayed in the Pronterface console. If it really did reboot the Duet, and you are running Pronterface under Windows, then you would lose the connection with Pronterface. if Pronterface didn't disconnect on a reboot, then you would see the "Network up, IP=..." message.

Ok, understood.

Quote
dc42
I'm fairly sure this was caused by the M109 bug that I have already mentioned in earlier posts, and which is fixed in version 0.65h. I think that somehow you must have ended up with an invalid tool selected when the M109 command was executed. Although you posted your config.g.file, you didn't post the gcode file you were running, so perhaps there was something in the gcode causing an invalid tool selection, or in setbed.g or something else you run before you try to print..

I'm now running your 65h firmware which seems to handle well the M109 bug.

I've another issue but still don't know if it's related to Slic3r or the firmware, I hadn't enough time to run more tests. When a print is finished, as I'm a lazy boy and like to avoid efforts as much as possible , I tried to send a second print to benefit of the Z compensation which is supposed to be ok. The G-code file of this second printing is executed as expected, but the head doesn't heat. I suppose it's related to some Tx command, certainly a bad tool is selected :
- if Slic3r is involved, a Tx (T1 I guess) has to be added as a prefix of the printing. Easy to do.
- if the firmware is involved, I suppose some Tx order has been executed, T1 I guess, _before_ executing any G-code file in order to reset the printer in an initial well-known state.

Patrice

Quote
paflviet
I've another issue but still don't know if it's related to Slic3r or the firmware, I hadn't enough time to run more tests. When a print is finished, as I'm a lazy boy and like to avoid efforts as much as possible , I tried to send a second print to benefit of the Z compensation which is supposed to be ok. The G-code file of this second printing is executed as expected, but the head doesn't heat. I suppose it's related to some Tx command, certainly a bad tool is selected :
- if Slic3r is involved, a Tx (T1 I guess) has to be added as a prefix of the printing. Easy to do.
- if the firmware is involved, I suppose some Tx order has been executed, T1 I guess, _before_ executing any G-code file in order to reset the printer in an initial well-known state.

I've just checked, and the firmware sets the current tool to -1 when M0 or M1 is executed. So you need to execute T1 before printing again, either by having slic3r do this in the start gcode, or manually.

btw I don't know why RepRapPro set the current tool to -1 rather than 0 at startup and when M0 or M1 is executed. I thought the whole point of renumbering the first extruder to be T1 was because by convention, tool 0 is the empty tool.

Edited 2 time(s). Last edit at 06/20/2014 04:27PM 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].

Quote
dc42
I've just checked, and the firmware sets the current tool to -1 when M0 or M1 is executed. So you need to execute T1 before printing again, either by having slic3r do this in the start gcode, or manually.

That was it, I added T1 in the Slic3r / Printer settings / Custom G-code / Start G-code and it's fine.

Thanks
Patrice

I finally decided to update to the latest firmware & web interface, downloading what is shown as the latest on the GITs.

Firmware was downloaded and installed - Pronterface reports "FIRMWARE_NAME:RepRapFirmware FIRMWARE_VERSION:0.65h-dc42 ELECTRONICSuet DATE:2014-06-18"

Web interface reports Duet Firmware, reprap.htm 0.93, reprap.js 0.93

I changed all references from T0 to T1 in config and print G files.

I can print OK, but the web interface does not update. Temperatures and printing values are updated just once after connecting, and then remain static. G code upload works OK, as does drag & drop printing.

Perhaps a file is missing from the web folder ZIP? This time I deleted the "www" folder on the SD card and renamed the extracted ZIP folder from the web GIT to "www" rather than replace files individually.

[edit] update - I can get the web interface to update by toggling the "online/connect" button (i.e. going offline then online), whereupon it updates once for each "online" toggle. The update rate is set to 1000mS in the "settings" page, but it looks like that's not functioning. I'm using Chrome, which updated OK on previous versions.

Dave
(#106)

Edited 2 time(s). Last edit at 06/20/2014 06:00PM by dmould.

Hi Dave, I've just checked that all the files are in Github. You should have 4 in the css folder, 4 in the fonts folder, 1 in the img folder, 8 in the js folder, and 3 in the root (plus README.md if you have that one too).

If you press control-shift-J in Chrome to get the Javascript console, does it show any errors?

---

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

PS - also check your Settings tab to make sure the UI refresh interval setting is sensible.

---

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

As said, the UI settings interval is 1000mS, so that's OK. I tried changing it to 100mS with no effect.

Yes, there are the correct number of files in all www folders.

ctrl-shift-J brings up one error message:

Uncaught TypeError: Cannot read property 'hasOwnProperty' of undefined 192.168.1.250/js/reprap.js:131


Dave
(#106)

Do you have a M550 command in config.g to set the machine name? If not, try adding one, e.g.:

M550 PDave's Ormerod; Set the machine's name

[Explanation: the line giving the Javascript error is looking at the response to querying the machine name from the webserver. I just spotted a long-standing firmware bug, which is that the machine name is not initialized.]

Edited 2 time(s). Last edit at 06/20/2014 06:56PM 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].

Yes - here's my config.g

; RepRapPro Ormerod
; Standard configuration G Codes
M111 S1 ; Debug on
M550 POrmerod ; Set the machine's name
M551 Preprap ; Set the password
M552 P192.168.1.250 ; Set the IP address
M553 P255.255.255.0 ; Set netmask
M554 P192.168.1.254 ; Set the gateway
M555 P2 ; Emulate Marlin USB output
T1 ; Select extruder 1
G21 ; Work in mm
M208 X220 Y220 ; Set bed size
M92 E429 ; Set extruder steps/mm 1.75mm
G90 ; Absolute positioning
M83 ; Extrusions relative
M558 P1 ; Turn Z Probe on
G31 Z1 P269 ; Set Z probe height and threshold
M203 X6000 Y6000 Z240 E6000 ;set feedrates - divide by 60 for mm/s
M201 X1500 Y1500 Z30 E500 ;set accels
M906 X1000 Y1000 Z1000 E1000 ;set currents
M561 ; Remove compensation

Dave
(#106)

Hmmm - just went into "message log" page in the web browser and see some errors. I've copy & pasted all that's there to the attached text file (my Ormerod is printing now).

Dave
(#106)

On the other hand the "disconnected" error messages occur only when I disconnect/reconnect by hand so are not significant ...
Also just tried I.E. and Firefox - both connect but with the same problem.

{edit} in case it's of help. attached is my SD image (all except "gcodes" folder)

Dave
(#106)

Edited 2 time(s). Last edit at 06/20/2014 07:21PM by dmould.

Dave, what would really help is a Wireshark capture of the network traffic. In particular, I think the firmware is returning a malformed response to the rr_name request, and I would like to see what the response is. Older versions of my web interface don't ask for the machine name.

However, to get up and running, you could put // at the start of each of these 4 lines of reprap.js at around line 130, to comment them out and avoid fetching the machine name:

		var resp = $.askElle("name");
		if (resp.hasOwnProperty('myName') && resp.myName.length != 0) {
			$('span#machineName').text(resp.myName);
		}

btw another user (gdwinslow) reported the same Javascript error a few posts back.

Edited 1 time(s). Last edit at 06/21/2014 03:59AM 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].

Dave, you could also try the attached firmware build, which does additional checks when sending the machine name.

EDIT: removed download, because I have now released version 0.65i-dc42, which contains this change and some others (see separate thread).

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

Quote
dmould
On the other hand the "disconnected" error messages occur only when I disconnect/reconnect by hand so are not significant ...
Also just tried I.E. and Firefox - both connect but with the same problem.

{edit} in case it's of help. attached is my SD image (all except "gcodes" folder)

Found the problem, I think. It's the tab character after the machine name in config.g. Try firmware 0.65i-dc42.

Edited 2 time(s). Last edit at 06/21/2014 04:21PM 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].

Yes, that's done the trick, thanks - very fast work!

Dave
(#106)

DC42, just to let you know, Ive installed the RepRapFirmware-065j-dc42.bin with web interface 0.95 and my extruder motor stoped working, it was completely dead in the water.

Now I am back to 57y-dc42 firmware with 0.74 web interface and the motor is running normally.

EDIT: Extruder not working with 065h also.

Edited 1 time(s). Last edit at 06/26/2014 04:25PM by Sardi.

That's because you didn't change T0 to T1 in your config.g file and slic3r start gcode file. I've covered this in the thread in which I announced 0.65e-dc42 and in one of my more recent firmware threads too.

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

uh uh,. must be honest, Ive seen that about T0 to T1 a couple of times, but have just completely forgot about it. Thanks for the info (again)!