Fix for USB printing [and other firmware improvements]

EDIT: RRP have now merged my firmware changes into the official release here. Ignore the version with the -dc42 suffix, download the -056 (or whatever is the latest version when you read this) in Raw mode. Then flash it to the Duet using bossac, and patch Pronterface as described at steps 1 and 4 below.

I have a fix for the stuttering USB printing. Before I check it in to github, I'd appreciate some feedback from other users. Here's what to do:

1. You must be using the RepRapPro version of Pronterface (the one where you start pronterface.py), not the precompiled .exe version.

2. Test your existing setup. If you print circle.g from the SD card, it runs smoothly. If you print it direct over USB, it stutters.

3. Download and install my modified firmware RepRapFirmware.bin. [EDIT: latest version is now on github - press the Raw button to download it]

4. Edit file printrun.py printcore.py in the Pronterface directory. Look for the statement "self.clear = False" at line 300. Comment this out with a single # character at the start.

5. Reload Pronterface and try printing circle.g over USB again. Preferably, send command M111 S0 first to disable command echoing - not sure whether this is really necessary.

6. If circle.g runs smoothly, try printing something!

Thanks to 3D-ES for pointing me to the right area in the firmware.

Edited 7 time(s). Last edit at 01/13/2014 07:22AM 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].

Cool! Have you updated your github fork? I'll email Adrian (if you haven't already), so he can check your fix and hopefully roll it into the main branch.
With the Pronterface change, we may need to test it to check that it doesn't break Pronterface communication on Melzi (for our Mendel and Huxley printers). Then we may be able to update the precompiled versions, too.

Ian
RepRapPro tech support

I haven't updated github yet because I am still identifying which of my changes are needed and which are not.

Re the Pronterface change, the later version you referred me to has this code instead:

# Only wait for oks when using serial connections
if not self.printer_tcp:
   self.clear = False

I'm assuming that flow control will kick in on the serial-over-usb connection if the data is sent too quickly, but I haven't tested it with large files yet.

My interpretation of the Arduino documentation is that the Arduinos that have a USB port built-in to the chip have flow control built into the serial-over-USB protocol. However, the older Ardinos that use a separate USB-to-serial-converter and actual serial comms to the mcu have no flow control. So I guess whether the mod is OK on the Melzi depends on what chip and corresponding Arduino core it is using.

Edited 1 time(s). Last edit at 01/11/2014 11:58AM 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].

Hmm, that's going to make it tricky, then. The Melzi uses an FTDi chip for USB to serial. No idea if it has flow control. Looks like a specific version of Pronterface for Ormerod will be needed.

Ian
RepRapPro tech support

Quote
droftarts
Hmm, that's going to make it tricky, then. The Melzi uses an FTDi chip for USB to serial. No idea if it has flow control. Looks like a specific version of Pronterface for Ormerod will be needed.

Ian
RepRapPro tech support

Perhaps you could make it configurable in the Settings->Options menu?

---

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

Genius! However, I think Jean-Marc looked at the new version of Pronterface and started adding his changes, but stopped, because it was so different to the old version. Your fix only works for the new version?

Ian
RepRapPro tech support

My fix works for the new version too. Just comment out the 2 lines I referred to in this post, or extend the condition to depend on the new serial flow control yes/no setting as well. The instructions I gave earlier are for the RRP version.

EDIT: and I just completed a 1h15m direct-through-USB print, so I know the USB flow control is working fine between Pronterface and the Duet.

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

Well done DC - it works a treat with Repetier host too (on the mac anyhow, which is all I've tested) - the whole thing is a lot smoother with the firmware changes you've made (circles sing like they're running from SD card) - the one setting in repetier that removes the final scrap of jittering is to make sure that "Ping Pong" is not checked in the pritner prefs (this makes the host wait for OK's from the firmware, and I presume it's the same thing as self.clear in pronterface).

Thanks to you and to 3D-ES for fixing this!

Now to see if <.24mm steps are sent properly - if so then this is a major upgrade imo...

Ray

quick update - printing with filament (I was running files without extruding before) makes for some lumpiness - although the xand y seem to work more harmoniously, the extrusion still seems to overshoot. so far the prints have stalled on the second or third layer, maybe a host or usb problem...

[edit] DOh! I'd forgotten about the thermistor beta updates - maybe the extrusion's not so bad if I get teh temperatures right I've got a definite (unrelated to this update) usb comms issue, drops characters quite often, and i was running at higher baud than I usually do when I got the stalls[/edit]



Ray

Edited 1 time(s). Last edit at 01/11/2014 02:51PM by rayhicks.

Ray, thanks for your feedback. I needed to reduce the extruder temp by around 10C to get good prints after switching to the new temp calculation.

Regarding the printer stalling, I believe this is due to ground loops. There are reports in another thread that a ferrite bead on the USB cable, or on the power feed between the ATX board and the Duet board, resolves this. Also you could try running the host PC and Ormerod and nothing else from the same mains socket block.

Now that I've dealt with printing over USB, I'm planning to do some tests on 0.12mm z-moves, still while printing over USB.

Edited 1 time(s). Last edit at 01/11/2014 03:31PM 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].

Good luck with the finer res - I'll try also once I've got my link sorted out (and printed a new driven gear or replaced the current mechanism with something else...) - I'm going to try a different cable first (the t3dp3d duet came with a longer one and I have a blackberry one I can try), then I'll clip some ferrites round if they don't work

Cheers

Ray

I've published the USB printing fixes to github. Note that the patch to Pronterface is still needed, see start of this thread.

---

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've put a new test version of my firmware build here (not on github yet) with some additional improvements:

1. SD card upload speed increased to 2.2Mb/min (you also need the Pronterface patch I already described to get up to this speed).

2. Fix for incorrect Z-axis movement when extruding 0.12mm layers and either printing from SD, or printing direct over USB and using my firmware build. The Z-axis movement *might* not have been not fully stable using 0.24mm layers either under some conditions, I haven't fully analysed the bug to see whether this was the case.

---

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

This firmware with the Pronterface fix is working great for me.

Does this binary also include your previous Network Fixes ?, My Network connection with this seems to have gone back to the
works sometimes stage with lots of Network connection error code -10.

Having said that the improvement in USB speed is great, SD upload over USB is about 12 times faster
With the various mechanical electrical and software issues it did seem at one point that the Ormerod was going
to have been a bit of a lemon, but having now got most of the mechanical issues patched/sorted and the firmware
starting to come together it's actually looking quite good.

Printed my first 2 'useful' parts today (Servo mounts for a CNC mill) this was about my 9000th attempt (only slight exageration)
they are fairly large (185mm * 90mm * 20mm) and the gcode is just over 3 gig. So attempts so far had suffered from almost all
of the issues (fan cooling, X runnoer bearing, head droop, z runner wobble and it took about 15 mins each time to upload gcode)

With a new fan cover, new Z runner, new hot end mount block, new fan (orig one seized for some reason!!), new 12 volt PSU (not an ATX)
and this firmware upload of code was less than 1 min, printing went well, took 5 hours but I have the speeds set rather conservatively
and the part came out great :-)

At last it feels like the Ormerod may become a useful tool.

Still some work, I think I will be making an aluminium bed and need to do something about the X axis (the taped on hacksaw blade is
a bit too much of a bodge to last) but closer :-)




Thanks for all your efforts and the various other people who are helping a lot.

Chris

Quote
chriscain
This firmware with the Pronterface fix is working great for me.

Does this binary also include your previous Network Fixes ?, My Network connection with this seems to have gone back to the
works sometimes stage with lots of Network connection error code -10.

Thanks for your feedback. Yes, it does include the network fixes. I gets lots of these code -10 errors when trying to connect, but the software usually recovers from them. Occasionally, the browser will display the control page and then the password page, but the wait-cursor never goes away. I've found that entering the password never works in this state, so when this happens I re-submit the IP address in the address bar to start a new connection attempt.

If I get time, I will take a look at the network traffic with Wireshark to see if I can work out what is causing the code -10 errors.

Quote
chriscain
Having said that the improvement in USB speed is great, SD upload over USB is about 12 times faster
With the various mechanical electrical and software issues it did seem at one point that the Ormerod was going
to have been a bit of a lemon, but having now got most of the mechanical issues patched/sorted and the firmware
starting to come together it's actually looking quite good.

Printed my first 2 'useful' parts today (Servo mounts for a CNC mill) this was about my 9000th attempt (only slight exageration)
they are fairly large (185mm * 90mm * 20mm) and the gcode is just over 3 gig. So attempts so far had suffered from almost all
of the issues (fan cooling, X runnoer bearing, head droop, z runner wobble and it took about 15 mins each time to upload gcode)

With a new fan cover, new Z runner, new hot end mount block, new fan (orig one seized for some reason!!), new 12 volt PSU (not an ATX)
and this firmware upload of code was less than 1 min, printing went well, took 5 hours but I have the speeds set rather conservatively
and the part came out great :-)

At last it feels like the Ormerod may become a useful tool.

Still some work, I think I will be making an aluminium bed and need to do something about the X axis (the taped on hacksaw blade is
a bit too much of a bodge to last) but closer :-)

Yes, I think the Ormerod is a good design with some teething troubles. I made a triangular aluminium bed mount for my Ormerod, described I the thread ion z-axis instability. I fixed the x-axis issue by a combination of lengthening the slot and the nut trap, and using a 10mm bearing. I've also found a UK source of 11mm bearings, but I've managed without one so far. I hope RRP or someone else will modify the x-carriage design to move or extend the slot inwards by at least 1.5mm.

---

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've just put my latest build on github, see link in first post in this thread. The significant changes from the Duet 0.53 standard build are:

- Ethernet interface usually now recovers from disconnects and network errors. This also makes initial connection more reliable. It still gets stuck at the password page sometimes, but when this happens you can load the initial web page again to retry.

- USB printing now works at full speed and uses the same lookahead mechanism as printing from the SD card does. Needs patch to Pronterface to make it work properly (see first post). USB printing should yield identical results to SD card printing.

- Fix for incorrect z-axis movement when printing thin layers.

- SD card upload speed improved, I now get 2.2Mbytes/minute. Needs the Pronterface patch to work at full speed.

I've updated my github pull request, so hopefully RRP will start integrating these changes soon.

---

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

Nice work dc42.

Markus

---

XBee & electronics blog: [lookmanowire.blogspot.com]

I totally agree with Markus - great job DC. The Z drive works a treat, I'm just finishing a "real life" print, roughly three hours in and not a hiccup in the z drive (it's a 0.04mm sliced driven gear for the Z axis, nothing too exciting, but I've got a "pro" printed version to compare to ).

Looking forward to the rapid turnaround that faster USB -> SD transfers offers, and accurate USB printing (will try a snowman tomorrow since that was the eye-opener for me way back on the 16th of December [forums.reprap.org]).

Hopefully you've taken some load off RRP for them to focus on other improvements

Cheers

Ray

Quote
rayhicks
Hopefully you've taken some load off RRP for them to focus on other improvements

[dream_sequence]
Haha, I've been sitting on a beach in the Caribbean, counting piles of money, drinking Mojitos, while being fanned by dusky maidens, while dc42 does all the work, all this time!
[/dream_sequence]

Well, I've finally caught up with support emails, at least. Which means I'll hopefully have time to do some documentation updates through this week, when I'm not receiving/sending out Duets!

Ian
RepRapPro tech support

Edited 1 time(s). Last edit at 01/12/2014 12:52PM by droftarts.

Ray & Markus, thanks for your kind words and for testing my changes. 0.04mm layers - wow! Looking forward to seeing your photos.

btw the firmware only sees the first 24 files on the SD card, and the M30 command to delete files is not implemented. So if you want to print from SD, you either have to remove it to delete old files occasionally, or re-use the same filenames. I'm doing all my prints via USB at present.

---

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

@Ian

I would really appreciate a centralised point of

* "Hardware" (mechanical build/ Duet board) developments/ revisions since the first build (like a release history)
* same for Software (yes I know it's @ github but you have to skim through the history)

* Improvement pool with suggestions from RRP/ community regarding hardware/ software
* Sticky FAQ (mechanical build, hardware, software)

Everything could be very compact with references to Instructions, forum threads or github.

Might save you some more time and bring you near the Caribbean

Just my 2 c

Markus

Edited 1 time(s). Last edit at 01/12/2014 01:00PM by markbee.

---

XBee & electronics blog: [lookmanowire.blogspot.com]

Quote
droftarts
[dream_sequence]
Haha, I've been sitting on a beach in the Caribbean, counting piles of money, drinking Mojitos, while being fanned by dusky maidens, while dc42 does all the work, all this time!
[/dream_sequence]

Don't worry, I can add it to the hardware bill (currently standing at 62p for one The Range photo frame and a few SMD resistors) if that makes you feel better!

---

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

@DC42, Yes thanks for all your hard work in pushing everything forward so fast, really appreciated.
@Markus, thanks also pushing the layers resolution (with DC42 and Ray), this really excites me.

I hope to get back to starting printing this week, so with all the developments since I last 'powered up' (probably two weeks ago), nake this an exciting time.

@Ian, you didn't have to add the
[dream_sequence] ... [/dream_sequence] comments!

Well on second thoughts perhaps you did!

---

Ormerod #007 (shaken but not stirred!)

To bring this discussion back down to earth, I should point out that there is a disadvantage to the fix for fast USB printing, which is that it now takes a long time to pause the print from Pronterface. This is because there is a lot of end-to-end buffering in the serial-over-USB subsystem, so all the preceding data has to be received and processed by the Duet firmware before the pause request is seen.

It would be possible to use a protocol between Pronterface and the Duet firmware such that each gcode received does get acknowledged, but the acknowledgements are allowed to get a few gcodes behind so as not to slow transmission. That should also work for the Melzi electronics even if it has no flow control on the serial-over-USB connection.

Edited 2 time(s). Last edit at 01/12/2014 01:22PM 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].

@ dc I thought I'd uploaded the pic before I came home - I've added it now to the 60micron thread - the surface finish to the eye is somewhere between fine silk and satin, and I'm ery pleased -I don't intend printing this fine often, it's very slow, but wanted to give the z axis a good work-out, 40 microns as ian pointed out is 10 pulses from the motor, and from the appearance of the layers (and backed up with caliper measurement) it doesn't seem to have missed a pulse throughout the three hour run (well maybe one or two, but not a 99% which is what seemed to be happening before the fix!).

On the pausing issue, I've never had satisfactory recovery from pausing (not tried it much), and it's always been delayed - the main problem on trying to resume a paused print for me (which may be a repetier issue) is that extrusion becomes flaky, retraction works fine, but extrusion just jitters, so I won't miss that! if I need to do an emergency stop I cut power on the atx, which is 100% reliable and instant, though I then have to start from scratch... maybe a hardware interrupt (Markus implied he's working on a control panel earlier - a button for pause would be good) could be a more general (and host-independent) solution?, though I guess the firmware would have to store a big buffer of commands if it didn't tell the host it was stalled...

Ray

Quote
markbee
* "Hardware" (mechanical build/ Duet board) developments/ revisions since the first build (like a release history)
* same for Software (yes I know it's @ github but you have to skim through the history)
* Improvement pool with suggestions from RRP/ community regarding hardware/ software
* Sticky FAQ (mechanical build, hardware, software)
Markus

I've planned to do all of this for some time, just got a bit waylaid by email. Our Mendel Tricolour pages are the template - there's more info there on printing, maintenance, troubleshooting and improvements, similar to what we plan for the Ormerod pages - plus a reference page. I also need to concatenate some of the existing instruction pages (it doesn't need 4 menu items for the heated bed, or 3 for the x axis) to make is fit on a normal screen, before adding more pages.

Linking to forum threads is a bit trickier, because the thread may take a while to provide the correct information. The information in the instructions needs to be a bit more definitive.

Sorry for the thread hijack!

Ian
RepRapPro tech support

Quote
rayhicks
@ dc I thought I'd uploaded the pic before I came home - I've added it now to the 60micron thread - the surface finish to the eye is somewhere between fine silk and satin, and I'm ery pleased

Yes, it looks great! I've just printed a new z-driven gear to replace my wobbly one, and I'm thinking of re-doing it in 0.1mm.

Quote
rayhicks
On the pausing issue, I've never had satisfactory recovery from pausing (not tried it much), and it's always been delayed - the main problem on trying to resume a paused print for me (which may be a repetier issue) is that extrusion becomes flaky, retraction works fine, but extrusion just jitters, so I won't miss that! if I need to do an emergency stop I cut power on the atx, which is 100% reliable and instant, though I then have to start from scratch... maybe a hardware interrupt (Markus implied he's working on a control panel earlier - a button for pause would be good) could be a more general (and host-independent) solution?, though I guess the firmware would have to store a big buffer of commands if it didn't tell the host it was stalled...

I either press the reset button, or I cut the ATX power and then turn it on again so that the fan can cool the extruder down. I've paused failing prints from SD via the web interface several times, and that usually take affect after around 5 to 10 seconds. I doubt whether restarting a paused print will work in most cases, some filament is bound to ooze out and form a blob. Maybe pausing a print should retract the filament too.

Although I don't feel the need for a full control panel, I like your idea of a pause button. It should be easy to implement even without using a hardware interrupt, since the firmware spends most of its time calling things in a loop, and polling the button can be done there.

---

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 printed my drive gear at 0.24 a couple of days ago, then my driven gear at 0.12 yesterday - the combination of two new gears made a huge difference (and it's why I printed the same thing today since I know what it looks like at various resolutions) - I didn't have time to print one of the threadless ballscrews that Ian pointed out before, but I've got one sliced and have the bearings on order to look at replacing the gears totally (as discussed with gregl here). My new gears mesh very well and both are more concentric than the originals, but depending long-term on the meshing is a bit hopeful I think (too good and they'll bind, too loose and they'll introduce play), it may not take too much wear for mine to go bad.
A direct drive from the motor would be useful as long as there's a vertical path through X for the leadscrew (or stud, or ground bar), it looks like there's vertical clearance above the current motor spindle for 5mm leadscrew, but this would stop the extruder head from homing (but that could be fixed by an offset tab or a microswitch). There would also probably be need to provide thrust support seperately from the motor's spindle bearing, and here may also be a problem of balance in the X arm (presumably the current nut trap is in an optimal position , but since the head travels it may not be best for x approaching 200mm). It would also require a flexible coupler to prevent too much lateral strain on motor spindle and "nut" -but I digress

A simple push button mod for pausing may be a good thing to try out (and any pin used for it could be mapped in a more sophisticated panel too) - if it's not too much effort for you I'd certainly test any mods you made.

Cheers

Ray

Thank you for curing one of my (gl)itches!

---

RS-Online Ormerod #263, Kossel mini with Minitronics, Prusa i3 MK2

I'm happy to report that RRP have now merged my changes into the Duet branch of the official firmware. The official 0.55 release build is here, I haven't tried it yet, but they seem to have accepted all of my changes. You still need to do the Pronterface patch to make USB printing and file upload work at full speed.

---

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