New RepRapFirmware 1.09r-dc42

Some suggestions:

1. Make sure you are running DuetWebControl 1.08. It avoids an issue caused by over-long cookies that affected some systems, depending on what browser you used.

2. Clear all cookies used by the Duet's IP address from your browser(s).

3. Check that the same IP address isn't allocated to another device. If in doubt, allocate a static IP address to the Duet, outside the range that your router auto-allocates from.

4. Does it work well for a while and then start to fail after the printer has been on for a while? If so, it could be a sign that the Duet is getting too hot, especially if it is mounted in a confined space.

5. Try a different browser, to see if the problems occur using one browser and not another. I have found Chrome the most reliable. A recent version of FireFox that I tried was refusing to send file upload data for on apparent reason when uploading large files.

6. Try a different SD card.

7. Otherwise post a Wireshark trace, filtered by the IP address of the Duet, showing what happened before a disconnect.

---

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
Some suggestions:

1. Make sure you are running DuetWebControl 1.08. It avoids an issue caused by over-long cookies that affected some systems, depending on what browser you used.

Already on it and loving the ability to edit the config file!

2. Clear all cookies used by the Duet's IP address from your browser(s).

Gave it a go with no change

3. Check that the same IP address isn't allocated to another device. If in doubt, allocate a static IP address to the Duet, outside the range that your router auto-allocates from.

I think this was my issue with dropouts/unable to connect. Tried on anther router first so the was just the kossel and laptop, all worked (but slow, see below). Went back to my home network and forced the router to reasign the printer a new IP and can now connect. Will change to static IP (need to do some house keeping for all my connected devices it looks)

4. Does it work well for a while and then start to fail after the printer has been on for a while? If so, it could be a sign that the Duet is getting too hot, especially if it is mounted in a confined space.

The board isn't enclosed and not confined.

5. Try a different browser, to see if the problems occur using one browser and not another. I have found Chrome the most reliable. A recent version of FireFox that I tried was refusing to send file upload data for on apparent reason when uploading large files.

Yep, always use chrome.

6. Try a different SD card.

Now this was a known good SD card and was working fast, but i swapped it out (again) for a freshly formatted one and now those connection/download speeds are nice and quick again! I still feel like the cards are getting corrupted after a few shutdowns maybe?

7. Otherwise post a Wireshark trace, filtered by the IP address of the Duet, showing what happened before a disconnect.

Thanks for all the help once again!

Quote
wayno complaino

Quote
mhackney
Routinely seeing > 200 kb/s

I saw significant speed increases on the first day of use, the web app opened and connected within seconds and uploading files didnt feel like a wait.

Now though im getting AJAX errors, dropouts, taking forever to load the web app and when it does work im seeing 11kb/s uploads. Pretty much as i was getting before when using k and previous. I have a feeling (because my knowledge is limited) this is more of a network problem than firmware or web app problem though. I dont get network problems with access to Pi's or webcams if i use the same connection though (physically unplugging the network cable from the duet and using on another network heavy device). Its unreliable enough for me to go back to manually using the SD Card to transfer files between the computer and Duet, really annoying.

Any help really appreciated!

I was seeing the same issues. But I upgraded to 1.08 and the issue went away.
Firmware Name: RepRapFirmware
Firmware Version: 1.09r-dc42 (2016-01-16)
Web Interface Version: HTML: 1.08, JS: 1.08
Web Interface by Christian Hammacher
Licensed under the terms of the GPL v2

You need to delete the cache from your browser. Close the browser. Then reload the browser. I did this everytime I have an issue with uploading a file (it uploads slowly). I also have been plugging in the USB cable to the PC. Then upload files. It seems a little more reliable. However, even with 1.08 I get intermittent upload gcode file failure. Again, the plugged in USB cable to the PC helps a bit but not 100%.

Edited 1 time(s). Last edit at 01/27/2016 11:48AM by DRTak.

Firmware Name: RepRapFirmware
Firmware Version: 1.09r-dc42 (2016-01-16)
Web Interface Version: HTML: 1.08, JS: 1.08

Getting wrong response after following request, this happens rarely and randomly, maybe around 10 mins after connection sometimes quicker.

I encountered this while trying to reproduce the following issue:

[forums.reprap.org]

IP 192.168.1.2.65205 > 192.168.1.42.http: tcp 393
	0x0000:  4500 01b1 ef9b 4000 4006 c62e c0a8 0102  E.....@.@.......
	0x0010:  c0a8 012a feb5 0050 7b45 5168 00cc 92b5  ...*...P{EQh....
	0x0020:  5018 ffff 0ce3 0000 4745 5420 2f72 725f  P.......GET./rr_
	0x0030:  7374 6174 7573 3f74 7970 653d 3320 4854  status?type=3.HT
	0x0040:  5450 2f31 2e31 0d0a 486f 7374 3a20 3139  TP/1.1..Host:.19
	0x0050:  322e 3136 382e 312e 3432 0d0a 4163 6365  2.168.1.42..Acce
	0x0060:  7074 2d4c 616e 6775 6167 653a 2065 6e2d  pt-Language:.en-
	0x0070:  7573 0d0a 4163 6365 7074 2d45 6e63 6f64  us..Accept-Encod
	0x0080:  696e 673a 2067 7a69 702c 2064 6566 6c61  ing:.gzip,.defla
	0x0090:  7465 0d0a 436f 6e6e 6563 7469 6f6e 3a20  te..Connection:.
	0x00a0:  6b65 6570 2d61 6c69 7665 0d0a 4163 6365  keep-alive..Acce
	0x00b0:  7074 3a20 6170 706c 6963 6174 696f 6e2f  pt:.application/
	0x00c0:  6a73 6f6e 2c20 7465 7874 2f6a 6176 6173  json,.text/javas
	0x00d0:  6372 6970 742c 202a 2f2a 3b20 713d 302e  cript,.*/*;.q=0.
	0x00e0:  3031 0d0a 5573 6572 2d41 6765 6e74 3a20  01..User-Agent:.
	0x00f0:  4d6f 7a69 6c6c 612f 352e 3020 284d 6163  Mozilla/5.0.(Mac
	0x0100:  696e 746f 7368 3b20 496e 7465 6c20 4d61  intosh;.Intel.Ma
	0x0110:  6320 4f53 2058 2031 305f 395f 3529 2041  c.OS.X.10_9_5).A
	0x0120:  7070 6c65 5765 624b 6974 2f36 3031 2e33  ppleWebKit/601.3
	0x0130:  2e39 2028 4b48 544d 4c2c 206c 696b 6520  .9.(KHTML,.like.
	0x0140:  4765 636b 6f29 2056 6572 7369 6f6e 2f39  Gecko).Version/9
	0x0150:  2e30 2e32 2053 6166 6172 692f 3533 372e  .0.2.Safari/537.
	0x0160:  3836 2e33 0d0a 5265 6665 7265 723a 2068  86.3..Referer:.h
	0x0170:  7474 703a 2f2f 3139 322e 3136 382e 312e  ttp://192.168.1.
	0x0180:  3432 2f0d 0a44 4e54 3a20 310d 0a58 2d52  42/..DNT:.1..X-R
	0x0190:  6571 7565 7374 6564 2d57 6974 683a 2058  equested-With:.X
	0x01a0:  4d4c 4874 7470 5265 7175 6573 740d 0a0d  MLHttpRequest...
	0x01b0:  0a                                       .
IP 192.168.1.42.http > 192.168.1.2.65205: tcp 47
	0x0000:  4500 0057 71b5 0000 ff06 c66e c0a8 012a  E..Wq......n...*
	0x0010:  c0a8 0102 0050 feb5 00cc 92b5 7b45 52f1  .....P......{ER.
	0x0020:  5018 09df 2113 0000 4854 5450 2f31 2e31  P...!...HTTP/1.1
	0x0030:  2035 3030 204e 6f74 2061 7574 686f 7269  .500.Not.authori
	0x0040:  7a65 640a 436f 6e6e 6563 7469 6f6e 3a20  zed.Connection:.
	0x0050:  636c 6f73 650a 0a                        close..

Thanks, that's very informative. Did the Duet have just one web client when this happened, or more than one?

---

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

No only one. I think that the problem is a timeout of the auth credentials on the web server or similar.
It does only happen when there is no interaction with the web gui for some time.
I think the parse error was due to communication problem within my network, I was not able to reproduce this other issue until now, I will keep looking.

I have had a lot of issues with file uploads, using 1.09r and web 1.08. Still trying to localize when and why it happens, as it may not be duet related but I figured I give the data I have. Using a Mac laptop and either Chrome, Firefox or Safari I get frequent (more often than not) super slow or stopping file transfers or a file that makes it to 100% and hangs without completion. With Firefox/Chrome and Ubuntu on a different box I get less issues, but still have similar problems. The duet is connected to a wireless extender for network access which appears to work fine for the most part. I have no problems with the web interface staying active through a print or beyond.

Quote
Koko76
I have had a lot of issues with file uploads, using 1.09r and web 1.08. Still trying to localize when and why it happens, as it may not be duet related but I figured I give the data I have. Using a Mac laptop and either Chrome, Firefox or Safari I get frequent (more often than not) super slow or stopping file transfers or a file that makes it to 100% and hangs without completion. With Firefox/Chrome and Ubuntu on a different box I get less issues, but still have similar problems. The duet is connected to a wireless extender for network access which appears to work fine for the most part. I have no problems with the web interface staying active through a print or beyond.

Sorry to hear you are having trouble. Please can you try a couple of things:

1. After having these problems, run M122 and report the buffer usage stats, in particular the maximum number of buffer used.

2. Try reverting to firmware version 1.09m and see if that improves things. You can keep DuetWebControl 1.08, although some of the new features won't be available, e.g. editing config.g.

---

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'll see what I can do this weekend. I'm in the process of testing a new hot end/extruder. When you say "when I have these problems" I'm not sure what you mean, it is consistent and regular. In other words I'm not sure there is a specific incident t isolate.

Hi,
here some more infos regarding different bugs I found so far.

Regarding the connection bug, although I said, that there was only one connection, it might not be true.
I did reconnect often, so there might be more unclosed connections in the background.
Also after reconnecting 10+ times during a longer print, I was not anymore able to connect at all, reload did also not work anymore, but the print did continue...
I also notice this very slow uploads and downloads, sometime the interface does not come up at all, because the downloads (html, js, css,etc.) are so slow.
I checked a little with the code and it seems that the response buffer is disappearing somehow, its so bad, that I have currently not more time to help a little bit with the programming....

I also found that if you use M572 D1 S0.1, M566 does not work more as expected, gets completely strange, I loose steps on X,Y and it seems to extrude too much at corners.
To get somehow better results I had to turn off M572, and to not loose steps I need to increase M566 to amounts > 1300, even with M572 turned off, which makes the printer sound very hard while cornering.

I hope to help a litte bit with this infos...

I am still trying to figure out why some users experience connectivity problems. If anyone gets a similar problem, please do the following:

1) Record a wireshark dump to capture the traffic between your PC and the Duet
2) Attach a USB cable to your Duet
3) Enable network debugging via "M111 P1 S1" and look for error messages in the serial log
4) After a communication problem has occurred, send M122 via the serial console and send me the whole excerpt

I hope this will help me to track down the underlying problem.

Chris, thanks for looking into this. There are some related issue reports at [github.com].

A few weeks ago had an issue whereby FireFox failed to upload any file larger than about 167Kb. Wireshark showed no errors at all, but that FireFox was simply failing to send the POST data. I never did find out why. The same files uploaded perfectly using Chrome.

---

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

No wireshark (not sure what that is) but:

Used output buffers 4 of 16
Memory
static ram 39856
dynamic ram 40912
recycled dynamic ram 1152
current stack ram 2984
max stack ram used 4264
never used 12120
error status 1
free file 9
longest block write time 616.6ms
slowesrt main loop .617249; fastest 0.000122


this is from a second machine connected to the web interface when upload "finished" at 100% from laptop but would not complete, hung on the laptop.

DC42
Didnt do a firmware update in a long time (still at 0.78v) so just to confirm what I need to download/update.

2 download:
- .bin firmware file
- from SD-image folder : www (all files updated for DWC 1.08)

here I am not sure - from sys-Ormerod1 folder: all files?

Edited 1 time(s). Last edit at 02/20/2016 06:12AM by Sardi.

I suggest you look at the differences between the config.g in my sys-Ormerod1 folder and your own config.g file, then work out what changes to make to yours. The main one is the M574 command to tell the firmware that the Y endstop is at the high end.

With the power off, you should reverse the X motor connector so that the wire colours are in the same order as the other motors. Or you can edit the M569 command for the X motor. Otherwise it will run backwards.

You may also wish to adapt my homeall.g file for your printer, because it does simultaneous X and Y homing.

---

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 suggest you look at the differences between the config.g in my sys-Ormerod1 folder and your own config.g file, then work out what changes to make to yours. The main one is the M574 command to tell the firmware that the Y endstop is at the high end.

Three questions please.

1) In general, when updating firmware, I dont -need- to change the config.g file, or is it a must?
2) Are we back at tool being T0, so I dont have to add T1 to the start of every CURA gcode output? I have a single nozzle Ormerod 1.

Yours:
M563 P0 D0 H1 ; Define tool 0
G10 P0 S0 R0 ; Set tool 1 operating and standby temperatures

Mine:
M563 P1 D0 H1 ; Define tool 1
G10 P1 S0 R0 ; Set tool 1 operating and standby

3) M574 - Am I suppose to delete that? As my Y endstop is on its default place near the motor on the left side.

Edited 3 time(s). Last edit at 02/21/2016 03:05PM by Sardi.

1. When changing the firmware version number (but not the letter at the end), there are often config.g file changes needed. When changing just the letter at the end, usually no config file changes are needed.

2. Yes. RRP changed back to the convention of tools being numbered T0, T1 etc. for better compatibility with slicing programs and other firmware. Use T-1 to deselect all tools. But you may still need to include T0 in your Cura start gcode.

3. The firmware default position for the homing switches is at the low end of each axis, as it is on Ormerod 2. For Ormerod 1, you need at least M574 Y2 to tell it that the Y homing switch is at the high end of the axis.

---

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
2. Yes. RRP changed back to the convention of tools being numbered T0, T1 etc. for better compatibility with slicing programs and other firmware. Use T-1 to deselect all tools. But you may still need to include T0 in your Cura start gcode.

3. The firmware default position for the homing switches is at the low end of each axis, as it is on Ormerod 2. For Ormerod 1, you need at least M574 Y2 to tell it that the Y homing switch is at the high end of the axis.

Thank you for answering.

Regarding:

2. All clear there. I am doing a c/p of your code to my config.g, and will see how Cura behaves now.

3. Thats what Im asking you. In my original config.g file, I didnt have the M574 code at all. From my point of view the high end is the one on the right side. But if Ormerod2 has it on the low end, that means that mine is on the high end and my point of view is wrong (meaning high is on the left side of the printer, where the motherboard is on Ormerod1). So if I understood it correctly, I still need to add the M574 X0 Y2 Z0 S1 to my config.g file?

Yes, you need the M574 command. By high end I mean the switch triggers when the Y coordinate is as high as it can go. By low end I mean it triggers when the Y coordinate is as low as it can go.

---

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
Yes, you need the M574 command. By high end I mean the switch triggers when the Y coordinate is as high as it can go. By low end I mean it triggers when the Y coordinate is as low as it can go.

Thank you!

NVM. Had problem with the Web Interface, wouldnt start up, and It just stared working.
Sometimes I need to restart the board, unplug usb and lan cables on both ends and reconect everything a bit later.

Regarding this

Quote
DC42
With the power off, you should reverse the X motor connector so that the wire colours are in the same order as the other motors. Or you can edit the M569 command for the X motor. Otherwise it will run backwards.

All of the connectors on the motherboard are allready in the same order as any other motor. Direction as follows from left to right when I face the motherboard - RED, BLUE, GREEN, BLACK. So I guess no need to reverse the connectors?

Edited 5 time(s). Last edit at 02/22/2016 02:12PM by Sardi.

That's right, they should all have the colours in the same order, so no need to reverse the X connector.

---

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,

I have loaded last firm RepRapFirmware-1.09r-dc42 end Web Interface Version: HTML: 1.08, JS: 1.08


with older versions, using the button "Upload & Print" software sent the gcode to sd card, printed it, and later erase it. Now do not erase more .... it is a bug or is there a setting that I did not?

Really old versions of the web interface used to upload the file to filename /gcodes/tempwebprint.g on the SD card. It didn't get erased, but it got overwritten the next time you did Upload & 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].