Fix for USB printing [and other firmware improvements]

I love open source this is amazing I get a new printer every day
Thanks!
/Joar #25

Quote
dc42
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.

That's great news dc.Official acceptance of the hard work done on these forums is well deserved. I only wish I had the same free time I had over the festive hols. to keep up with progress here.

---

RS Components Reprap Ormerod No. 481

Hi dc42,

Great work, great news!

Regarding Pronterface and uploading files to SD card it seems to hang if you don't disable debugging.

Markus

---

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

Quote
markbee
Regarding Pronterface and uploading files to SD card it seems to hang if you don't disable debugging.

My initial tests for both printing circle.g and for uploading large (3.7Mb) files were done with debugging info on. I didn't see any hanging, although during SD upload there is a very long pause between the last "Serial:" message displayed in the Pronterface window and the "Finished" message. But I always turn off debug output now. For one thing, SD uploading is faster with debugging info off. Also, I usually have the web interface connected as well as Pronterface, so that I get a continuous readout of the temperatures; and with debugging on, you get all the http messages messing up the Pronterface window.

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

Just a reminder that your fix works for repetier host USB comms too, the critical settings in repetier's printer options seem to be turning off "ping-pong" and setting the buffer size ("receive cache") to a larger amount than default. The default is 63 bytes, repetier's hints state that older arduinos had this limit but that many newer firmwares use 127 bytes - 63 gives a lot of stuttering still, 127 is much smoother. I just set mine to 255 and it makes the printing as smooth as SD printing - any idea how large the cache would be in the duet? It doesn't seem to overflow at 255, but I'd like to set it to something that matches the duet's capabilities, rather than stretching them...

Cheers

Ray

Quote
rayhicks
I just set mine to 255 and it makes the printing as smooth as SD printing - any idea how large the cache would be in the duet? It doesn't seem to overflow at 255, but I'd like to set it to something that matches the duet's capabilities, rather than stretching them...

The Duet supports USB natively, so there is flow control and you can't overflow the buffers (that is why you can run without ping-pong). It looks like the receive buffer in the Arduino library that is used by the firmware is 63 bytes, however I added an extra 256 byte buffer in the Duet firmware. There is probably some additional buffering in the USB stack.

---

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 Ray,

the Arduino libraries show 512 bytes receive buffer (RingBuffer) for the Arduino Due. Can't see any change in the RepRap implementation.

[EDIT: That's of cause for the implementation of the serialUSB class in Arduino]

Markus

Edited 3 time(s). Last edit at 01/13/2014 06:25AM by markbee.

---

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

Thanks Markus - I really should learn how to read !!!

Ray

Hi Ray,

unfortunately I had not any time to at least skim through the firmware. I'm just about thinking doing a touch controlled standalone interface for the Ormerod or an Android app controlling the printer via Bluetooth/ WIFi (with webcam integration of course if WiFi is available). But I think there are still too many mechanical issues before doing such "luxury" things.
Uh and I forgot about the water cooling stuff I have already laying around...

Markus

Edited 1 time(s). Last edit at 01/13/2014 06:35AM by markbee.

---

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

Quote
markbee
the Arduino libraries show 512 bytes receive buffer (RingBuffer) for the Arduino Due. Can't see any change in the RepRap implementation.

Hi Markus,

Where did you find that? I just rechecked and it appears to be 64 (of which 1 byte is unusable, so 63 really). I'm looking at the Arduino 1.5.4 source, because that is the version the firmware is compiled against.

---

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: A big thank you from us! Adrian said he had accepted the network code (and 3D-ES web interface fix), but I didn't know he had accepted all the other changes too. Maybe he doesn't...

I've spoke to Jean-Marc about changing Pronterface to, to have a menu option for Melzi/Duet, which would enable/disable self.clear true/false.

Everyone - Please be aware that the 'Duet' branch is, effectively the unstable development branch, for testing; the master branch is still the main release branch. I expect it will be a couple of days before this gets moved to the master branch, once we have some feedback.

Right, back to emails and documentation...

Ian
RepRapPro tech support

DC

Regarding the Pronterface change:

"4. Edit file printrun.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."

The file to be edited is not printrun.py but printcore.py.

So it changes from ??

def _sendnext(self):
if not self.printer:
return
while self.printer and self.printing and not self.clear:
time.sleep(0.001)
self.clear = False
if not (self.printing and self.printer and self.online):
self.clear = True
return

to
def _sendnext(self):
if not self.printer:
return
while self.printer and self.printing and not self.clear:
time.sleep(0.001)
# self.clear = False
if not (self.printing and self.printer and self.online):
self.clear = True
return

looks like there are two buffers for serial, the larger one is used and defined in /Duet-master/Archive_Files/eclipse_examples/ArduinoDueCore/src/core/USB/CDC.cpp (which seems to be used for serialUSB ) : - #define CDC_SERIAL_BUFFER_SIZE 512), the other is presumably not used for USB (since I'm not overflowing it when sending it 255 bytes) - it's size is defined in /Duet-master/Archive_Files/eclipse_examples/ArduinoDueCore/src/core/RingBuffer.h :-#define SERIAL_BUFFER_SIZE 64


Ray

edited to make US read as USB ) - damn smileys

Edited 1 time(s). Last edit at 01/13/2014 07:09AM by rayhicks.

Hi,

the "old" 8-Bit Arduinos used to have 63 byte ringbuffer for the serial class implemented.

Markus

Edited 1 time(s). Last edit at 01/13/2014 07:10AM by markbee.

---

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

Quote
victors
Regarding the Pronterface change:

"4. Edit file printrun.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."

The file to be edited is not printrun.py but printcore.py.

Thanks victors, I've connected the original post.

---

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

:-) Big smiles over here ;-)

I have programmed version 57 with Pronter mod. Working great. My SD image did not have the homex/y/z.g files. Loaded it and now everything works.Just doing a quick snowman.g print. Moves and sounds just like SD card print.

Great work.



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

Quote
victors
:-) Big smiles over here ;-)

I have programmed version 57 with Pronter mod. Working great. My SD image did not have the homex/y/z.g files. Loaded it and now everything works.Just doing a quick snowman.g print. Moves and sounds just like SD card print.

Great work.

It's great to hear it singing like that, eh? - I like listening to circles best dc really has worked wonders over the last few days. I did my first long print over usb today with (what we had been calling) a fine print at 0.12mm - it came out perfect on the third attempt - because I was using USB I could see repetier's next moves printing on screen just ahead of the actual moves, and then stop and reslice with different settings (change retraction, temperatures etc) without having to restart the duet or the mac, and no need to re-upload to SD - saved me what felt like two hours - soon I might catch up on time!

Anyhow, 0.1(ish) is my new standard printing height (as advertised as standardby many manufacturers and I was starting to feel left out until last week's workaround that didn't really do the same thing as the fix), and I can use usb or SD printing at whim, and I'm very impressed

I went on [github.com] and found that printcore.py of today is different from the one referred by previous posts.

def _sendnext(self):
        if not self.printer:
            return
        while self.printer and self.printing and not self.clear:
            time.sleep(0.001)
        if self.clearNext:
            self.clear = False
        if not (self.printing and self.printer and self.online):
            self.clear = True
            return
        if self.resendfrom < self.lineno and self.resendfrom > -1:
            self._send(self.sentlines[self.resendfrom], self.resendfrom, False)
            self.resendfrom += 1
            return
        self.resendfrom = -1
        for i in self.priqueue[:]:
            self._send(i)
            del self.priqueue[0]
            return
        if self.printing and self.queueindex < len(self.mainqueue):
            tline = self.mainqueue[self.queueindex]
            tline = tline.split(";")[0]
            if len(tline) > 0:
                self._send(tline, self.lineno, True)
                self.lineno += 1
            else:
                self.clear = True
            self.queueindex += 1
        else:
            self.printing = False
            self.clear = True
            if not self.paused:
                self.queueindex = 0
                self.lineno = 0
                self._send("M110", -1, True)

Is the patch still needed (although I'm not sure what line to change, now), or has it been included already on RepRapPro github?

I believe you still need to apply the fix which is to comment out the line

if self.clearNext:

which is line 6 in your quote and around line 300 in the actual file.

This has not been done in the printcore.py on reprap Github

It appears to me that RRP has removed the need for the patch. If you go to Settings->Options there is a setting called clearnext. It looks to me that this needs to be set to 0 when talking to the Duet board, or 1 when talking to the older boards. So just make sure that clearnext is set to 0. To test whether this is sufficient, time the upload a large file to the SD card. If you don't need the patch, it should be about 2Mb/min. If you do need the patch, it will be much slower.

---

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 guys,

Until now I used the precompiled Mac version of Pronterface supplied by RRP:
[reprappro.com] OR
[myreprappro.com]

As I found out, this version was missing the "clear_next" flag described by dc42. So I tried to compile pronterface from the master branch, on my Mac: [github.com]

I duly followed the instructions and installed all Python modules first:
- wxPython3.0-osx-cocoa-py2.7: [downloads.sourceforge.net]
- pyserial 2.5: [pypi.python.org]
- pyglet 1.1.4: [pyglet.googlecode.com]

It turns out that this version indeed contained the "clear_next" flag, so hurray! Now here's the issue: I am missing all graphical indicators, namely the XYZ "dial" to move and home the axes, as well as the temperature graph. I thought that maybe I did not install the Python modules correctly (my guess was wxPython), so I went on to download the vanilla pronterface from here: [github.com]

When I run this original software everything displays just fine! So now my guess is that the RRP pronterface flavour requires a different version of the wxPython module. Does anybody of you know whether my diagnosis is correct and if so, which version I need to have installed on my machine?

BTW, sorry that I don't have any illustrative screenshots available, but I'm currently not on my Mac - will try to upload pictures this evening.


Alex

Edited 1 time(s). Last edit at 05/06/2014 04:15AM by Blindseeker.

Hi again,

just to make things clear, I've attached a couple of screenshots:

1. RRP precompiled Pronterface
2. RRP pronterface, compiled on my own
3. Vanilla pronterface, compiled by myself

Maybe somebody encountered and overcame the same issues?

Best,
Alex