I think some people had the X motor going in the wrong direction by having the plug reversed at the Duet because that one is different to the others. So I think you can reverse the direction by reversing the plug.by bobtidey - Ormerod
Thanks. I have in the meantime tried a few other files which worked OK so I was beginning to suspect something wrong with that file. It was written by Slic3r. I have it on both Windows platform and Ubuntu. The problem file was sliced on the Ubuntu one and is a different version and is built from source as the pre-compiled one won't run any more. So I'll stick to the Windows Slic3r for the momenby bobtidey - Ormerod
The link has a zip with original file (dragged onto upload) and the file as read off the SD card (has SD prefix) GCodeFilesby bobtidey - Ormerod
Fin not set in any of the URL Get packets carrying the Gcodes.by bobtidey - Ormerod
Capture shows that the bits missing from the big file are sent and are all in the last packet. Reception of the packet is acknowledged and the M29 to close the file follows on about 20msec later. So I think there is some hazard which can lead to the last packet getting lost.by bobtidey - Ormerod
Quotedc42 OK, it's at . Tried it out. No lockup with Maxbuffer back to 1024! Major success. 2.9MByte file took 80 seconds. I did, however, decide to check the files uploaded onto the SD card to make sure the different packet handling was keeping the data intact. That is a bit puzzling / worrying. I tested with 2 files; a short 180kByte file and a longer 2.9Mbyte file. The short one was OK; tby bobtidey - Ormerod
I'll give it a go as soon as you likeby bobtidey - Ormerod
I think I may have found a little clue as to the fragmentation problem from Ubuntu. The captures show that the fragments to the Duet are 750 bytes or exactly half of the MTU. Buried in the tcp stack on Linux is a function called tcp_bound_to_half_wnd. I think the purpose of this function is to limit the size of outgoing packets to no more than half of the windowing size advertised by the receiverby bobtidey - Ormerod
tracepath to the duet from Ubuntu shows a pmtu of 1500 I checked the basic Ubuntu webserver traffic to Windows Chrome and that was running at about 6MByte/s. Regular external web traffic is going at greater than 1MB/s. These transfers are running full TCP windowing so that multiple packets are received before ACks are needed. The captures from the Duet showed that each packet needs an ACK befoby bobtidey - Ormerod
Normally one would have expected the serving speed to be quite a bit faster than the upload as it doesn't involve the URL parsing and breaking down into G codes. Looking at my capture the current duet firmware is serving the main reprap.htm (30kbytes) in about 0.7 seconds (2.5Mbyte/min) when accessed from Ubuntu Chrome but quite a lot slower from Windows Chrome, about 3 seconds. The difference iby bobtidey - Ormerod
Quotedc42 btw I tried setting the MTU on my computer to 600 bytes, and could no longer print circle.g. The firmware says via the USB interface that the client buffer is overflowing. So it appears that the code in the network interface to reassemble fragmented packets does not work. I probably won't have time to look at why before next weekend. I have now tried this with Ubuntu 13.10 and same resby bobtidey - Ormerod
Quotedc42 and I've replaced all 9 occurrences of the IP address in reprap.htm with my own. Is there any anywhere new that I need to patch the IP address? I count 10 replacements now. It used to be 9. I think the new one is cookie.by bobtidey - Ormerod
Quotedc42 Thanks, Matt! Bob: can you use Wireshark to trace the initial connection between the client and the Ormerod, under both Ubuntu and Windows? Maybe there is some negotiation going on that causes Ubuntu to use short packets. Thanks for the pointer to the ip_no_pmtu_disc stuff. That sounded promising but, unfortunately, hasn't done the trick. I definitely turned it off and rebooted to maby bobtidey - Ormerod
That's the behaviour I see, See above few posts. The workaround if you are using the local version with your own webserver is to edit the reprap.js in the js folder so that near the top the line var maxUploadBuffer = 1024; is changed to var maxUploadBuffer = 350; This can't be used for the remote version. I am trying to find why the packets are getting split on Ubuntu and causing the Duet toby bobtidey - Ormerod
MTU is 1500 which is pretty standard Regular GET poll packets to the Duet are about 440 bytes long When I use a 350 byte buffer the GET sending data packets are about 785 bytes containing the whole request which sounds about right. They are all in one packet and that works. When I use a 450 byte buffer the GET is split into 2 packets of 804 and 151 bytes and that cracks up on the first requestby bobtidey - Ormerod
Interesting about the Debian Chrome. Can you give details of OS and Chrome version? I still have file upload lock up problems on Ubuntu 12.04 Chrome 32.0.1700.102 if I use upload buffers above 395. By changing the max buffer in reprap.js below this I can make it reliable. I don't think it is anything to do with the web page or js though. I captured the network traffic (Wireshark) for a workingby bobtidey - Ormerod
Bit more on the problems using a Linux browser. I established by stepping through the code that the first packet is constructed OK about 1024 bytes long and the system cracks up at the ajax call sending out the packet and waiting for a response which never comes. So I then tried experimenting with maxUploadBuffer (normally set to 1024). If I use values below 380 it works OK and the file gets seby bobtidey - Ormerod
I tried 57f and the updated reprap.js. I still get data overflow and same behaviour. I can now confirm this is a Chrome on Linux (Ubuntu) issue as I tried it from a WIndows platform and it is fine on that. Both Chromes are up to date and close in version number. I see that null is not necessarily a good test for uninitialised so I did a quick test replacing that by setting buffer = 0 at the staby bobtidey - Ormerod
Great. I'll give that a try. I think the issue with the uninitialised is that it tested the uninitialised buffer variable to see if it should update from the poll. So it was possible for the variable to not get set when constructing the first packet.by bobtidey - Ormerod
Attached file is Pronterface log at start of file upload showing the data overflow I get when trying to file upload. Firmware is updated 0.57d and I tried local and remote versions with same result. This was with Chrome in Ubuntu. I wonder whether there might be a difference with the javascript execution on Windows. Looking at the upload code there is a test against the buffer variable which Iby bobtidey - Ormerod
Trying out 0.57d and updated web code. Basic functionality OK but I can't seem to get file upload working. A tiny test file like setbed.g works OK but once it needs to split the file it cracks up. Behaviour is one of two types as shown in pronterface. First is a stuck repetitive loop with Client read buffer overflow. Second is it grinds to a halt after first buffer. Either way web side is unrespby bobtidey - Ormerod
These updates are very welcome thanks. Making it easier to use all the time. On the file upload speed, I thought I saw an even bigger buffer on DC-42's firmware potentially allowing even more lines to be grouped together but it now seems to be reverted to the original and the web side allows up to 5. Was there no speed benefit above that or I guess there may have been some compatibility problemby bobtidey - Ormerod
If you have internet network connection near printer then getting the iamburny web interface working is definitely worth it. You can easily be put off by trying to make the original one work with all its foibles but the new one makes it easy. I have the ,py version of pronterface but now only use it if I want to update config.sys or the web htm itself. All normal control can be done from the broby bobtidey - Ormerod
I'd give a thumbs up to Kapton 50mm wet method. 50mm makes it quicker with less joints than the supplied 25mm. I did contemplate getting 100 or 200mm but they start getting expensive and a 50mm roll will do a lot of beds. Wet method makes all the difference; allowing all the time to slide tape around to get perfect butt joints. Good to have the soapy water in a spray bottle to make it easier ifby bobtidey - Ormerod
This is my solution for spool holder as I didn't like it on the Duet enclosure as well as not big enough for larger spools. Fabricated out of 22mm overflow pipe, 6 90 elbows and 2 tees. Top two elbows are cut to form a drop in axle 'shelf. I sized it to take widest / biggest diameter spools I have got so far and have a couple of tube axles for different diameter spools. Took me about 30 minutesby bobtidey - Ormerod
Remote version is working OK. The response panel in light blue shows up and shows the response and ZProbe now is showing the value. If you need further tests to see what the difference is with local one then let me know. Looking at differences I see the local files are lower cased, e.g fileDrop. I wonder whether that might be causing an issue with a Linux webserver where case sensitivity kicksby bobtidey - Ormerod
Updating the js and other sever folders didn't change anything. Response to rr_poll is {"poll":["I","19.0","8.4","1.98","0.00","1.00","0.0000"],"probe":"314","resp":"T:3.6 B:18.7"} I have seen the firmware version in the pronterface debug lines I've also tried browsing from Windows but server still on Ubuntu - same resultby bobtidey - Ormerod
I have flashed the new firmware and put the latest reprap.htm on (minimised running local web server mode). Basic functionality is still fine but I am struggling with the new feedback features. I can't see gcode responses and the Z probe display is stuck at 0. If I attach Pronterface as well I can see the poll requests and the JSOn reponses which have meaningful zprobe values in. This is as vby bobtidey - Ormerod
First, thanks a huge amount for doing this and helping make the promise of network controlled printer a reality. I haven't had too many issues with build and after early Duet swap out, initial printing has been working OK via pronterface. However, I was very keen to get web control of the device. My question is to do with the local and remote versions of reprap.htm. I can run either as machine iby bobtidey - Ormerod