USB printing

Hi,
I am grateful to anyone who can give me information on USB printing.
with USB printing I just created garbage and I'm already tired of throwing sd card.

[www.reprappro.com]
quote: Computer interface: USB

Thanks
Dario

Hi Dario

I have received your emails, but I'm a couple of days behind, because of the large number of emails we're getting, while I'm also trying to investigate and resolve problems. And, like your emails, I really need some more detail than you have posted here to be able to help you. What problems are you having? Have you updated the firmware on your Duet? Are you making your own gcode? Can you post an example of your gcode? Pictures of what is printing? Anything would help me (and perhaps others) help you!

Ian
RepRapPro tech support

Ian,
thanks for your reply!
Attached y-bearing-clamp.jpg print from USB.
Firmware update ...done but uselessly.
More problems? Yes!
Urgently I need in alluminium:
Bed
y-cross-rib
y-rib
x-axis-plate
x-rib
More? yes I found a lot of problems....
I'll keep you informed through this forum

Looks like you are printing directly from Pronterface. The serial connection is not fast enough to send the gcode without the movement pausing. You need to copy the gcode to the SD card, and print from that.

We don't supply the parts you list in aluminium.

Ian
RepRapPro tech support

Ian ...
sorry...
better tell me you can not do anything!

Hi Ormerod187,

I'm far from convinced that so many parts need to be in aluminium. The only one I intend to replace is the MDF bed support. I've ordered some 250x250x3mm alu sheet via eBay, and I intend to use the MDF part as a template to get the holes in the right place. I have a 0.1mm bend in the x-plate, but I expect to resolve that by clamping or gluing it to the x-rib.

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

Thanks DC42
I'm not sure that the aluminum functions ....because I have not tried.
I'm just trying not to throw this printer out the window ...
probably the fan drives me crazy.

Ormerod187, don't give up! Despite the issues I have encountered, I have managed to print these pieces and more:



Some Ormerod owners appear to have printed much bigger pieces. I'm a perfectionist, and because Ormerod is an open-source design that is easily improved, I won't be satisfied until I have resolved all the niggles I have with it (e.g. the sagging corners of the bed support). But my printer is already printing things!

Regarding printing over USB, I agree it is a pain to have to keep swapping the SD card in and out. I've just looked at the firmware, and I think it is an easy change to make the print-over-USB work much faster. I hope to find time to look at this tomorrow.

---

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

Thank you very much for your encouragement,
but my bed is now broken into a corner, due to the continuous tightening the screws to come loose.
I am now looking for a solution.
Post the firmware and I try to as soon as possible.

Hi there!

I have been looking at the "stuttering while serial printing" problem and found
something in the firmware that can easily be fixed and makes it stutter a lot less...

In Move.cpp at line 532 (function DoLookAhead) you'll find the following code:

// If we are just doing one isolated move, set its end velocity to InstantDv(Z_AXIS).
    
if(addNoMoreMoves || !gCodes->PrintingAFile())
{
  n1->SetV(platform->InstantDv(Z_AXIS));
  n1->SetProcessed(complete);
}

My translation:

When the Ormerod receives a gcode command, it checks if it is running a
printjob from the SD card, if not, it changes the stepper velocity to its max.

You can test this by sending a G1 command with a slow F parameter,
whatever feedrate you use in the command, the Ormerod will ignore it.

Since a serial printjob is currently not recognized as a printjob, the velocity
setting (feedrate) is overwritten, and the nozzle is rushed to its destination.

The stutter problem seems to be 'fixed' when I change the code to this:

// If we are just doing one isolated move, set its end velocity to InstantDv(Z_AXIS).
    
if(addNoMoreMoves)
{
  n1->SetV(platform->InstantDv(Z_AXIS));
  n1->SetProcessed(complete);
}

After this code change the movements are a lot smoother!

Unfortunately it is still not as perfect as when printing using the SD card...
The printed object contains tiny blobs that are probably caused by the I/O...?

Since I am new to this software it is possible that I am doing some silly things,
it is very possible that I have introduced some other problems with this hack

Edited 1 time(s). Last edit at 01/09/2014 04:07AM by 3D-ES.

---

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

Good catch! Maybe the "|| !gCodes->PrintingAFile()" bit also needs to be removed from lines 444 and 500?

---

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 have printed the electronic-candlelight-holder again for comparison,
this time I also removed the two PrintingAFile() calls you mentioned.

The previous object was printed with the debugging output disabled,
for this test I left the debugging output enabled to compare the result.

The results are in:

* The object is still covered with the same dotted pattern.
* Transmitting debug data to the PC does not make it worse.
* The print head regularly stops moving for a very short time.
* It stops every time when Pronterface is scrolling the serial log...

The million dollar question: Where does this glitch hide itself?

A: Transmission of data from PC to Ormerod?

If there is a process being interrupted by the serial data,
this could probably cause the kind of problems I see here.

Before I can answer this I need to dig deeper in the firmware.

If I transmit more data over the line, does that make the problem worse?
I can test this by simulating transmission errors while uploading the file.

B: Transmission of data from Ormerod to PC?

But... There is not much data being transmitted by the Ormerod!?
It only needs to acknowledge the validity of the commands... Right?

And even with debugging enabled it did not change the dotted pattern.

I have the feeling it does not have anything to do with the Ormerod TXD,
I can test this by sending 10x the usual debugging output to Pronterface.

C: Calculating the path to the next destination?

There seems to be an equal amount of work to print from SD and USB.
The commands are the same and are processed from a gcode stream...

I might be wrong here, but since the commands are buffered, the CPU
is fast and printing is a slow process... This should not be a problem...?

D: Some other location that I don't know yet...?

When you have eliminated the impossible, whatever remains, however improbable, must be the truth...

I have attached an image of the dotted pattern.

On the left is a close-up of the electric-candlelight-holder, printed from SD.
On the right you see a close-up of the same g-file, printed via the USB port.

This object is printed with transparent PLA, this makes the glitch stand out.
The glitch is probably less visible when you are printing with opaque filament.

The USB object feels a bit less smooth than the perfect SD version.

You can probably use the printer without complications even with this glitch,
but you might run into problems with complex objects that need high precision.

And now...?

... now there is something left to test when I have some more time...

I almost don't care about the pattern anymore, it is the best looking glitch I have ever seen!

---

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

3D-ES, there is another change that I intended to try, but I haven't had time yet. At Gcodes.cpp line 176, it checks to see if a byte is available from USB, and fetches it if there is. I think it needs to loop here and read all available characters up to a maximum of (say) 10, or until a gcode is complete. Otherwise, it may not read the serial data fast enough.

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

Another problem we have just spotted... All Duet boards have been supplied with only two of the four USB lugs soldered. Some have been supplied with none of them soldered! This can make the USB connection electrically unstable, and makes it much easier to pull the USB socket off the board. Please carefully solder up all four pins. I'll be adding this to the documentation (along with the long-awaited troubleshooting...) at the weekend, hopefully.

All subsequent boards should have all four lugs solder up. I think someone else pointed this out in an earlier thread, but it got lost in the noise!

Ian
RepRapPro tech support

@ dc42

Interesting!

I had looked at that, and have ignored it until now... I thought:
All sources are read equally, only one byte every spin cycle.

But reading serial input is not the same as reading from a file:

* The file reader always returns a new byte at every spin cycle.
* The serial reader probably returns often without reading a byte.

Reading multiple bytes per spin cycle is an easy test to write.

Waiting for a gcode to complete will probably take too much time,
the other classes need to spin or it will introduce other problems.

I am "Away From Printer" at the moment, I'll try to test this tonight!

Edited 1 time(s). Last edit at 01/10/2014 08:30AM by 3D-ES.

---

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

Quote
3D-ES
Waiting for a gcode to complete will probably take too much time,
the other classes need to spin or it will introduce other problems.

I was suggesting to read characters until no more were available OR (say) 10 had been read OR a gcode was complete (the statement serialGCode->SetFinished(ActOnGcode(serialGCode)) may yield enough information to determine this). My concern is that some of the other spin actions may be quite slow, for example there is a call to PollZHeight that makes an analogRead call. But I take your other point, reading from SD card is also done a byte at a time.

---

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 established that the main barrier to printing properly over USB isn't the Ormerod or the USB connection, it's Pronterface.

First, I made some mods to the Ormerod firmware, to enable the lookahead when printing from USB (just as it does when printing from SD), provided the data is coming in fast enough. I used circle.g as a test file. Whatever I did, circle.g was jerky, to a greater or lesser extent.

Then, still with the modified firmware, I ran this under Windows:

copy circle.g \\.\COM11

It draws circle.g perfectly! I'll try printing a file this way later today.

Are there any Python experts listening, who can speed up the serial output in Pronterface?

---

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 - it might be worth having a look at the latest Pronterface/Printrun, as I believe it's been heavily rewritten since we forked our version. It's written by a guy called Kliment. Github here: [github.com]

Ian
RepRapPro tech support

Repetier host has a buffer size setting (63 by default) and a ping-pong mode (where it waits for an OK from the printer) - maybe printrun/pronterface also has a similar small buffer constraint, or may be awaiting OK's, I can't find the preferences on my pronterface (I updated my system since the last time I ran it and now it's lost its menus!).

Ray

Just tried circle.g over usb with "ping pong" turned off, at various buffer sizes and transfer speeds in repetier, and it stutters no matter what - so my last post is probably irrelevant

Quote
droftarts
@dc42 - it might be worth having a look at the latest Pronterface/Printrun, as I believe it's been heavily rewritten since we forked our version. It's written by a guy called Kliment. Github here: [github.com]

Thanks. I tried running that version as-is, and it exhibits the same jerky behaviour as your forked version.

Just to be clear, to make it work smoothly I have to copy the file directly to the COM port (instead of via Pronterface), AND use my modified formware. I'm currently backing out some of the firmware changes I made to see which ones are actually needed.

@Ray: thanks, I'll look at the Pronterface code and see if it is waiting for OKs or something similar.

Edited 1 time(s). Last edit at 01/11/2014 09:27AM 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
rayhicks
Just tried circle.g over usb with "ping pong" turned off, at various buffer sizes and transfer speeds in repetier, and it stutters no matter what - so my last post is probably irrelevant

Ray, would you like to try the same test using my modified firmware here ?

---

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

will do - I've downloaded it, but am in the middle of a long test print, do I need to update any other files? (I'm running an older version of firmware than I should at the moment, should I update to the current main duet branch along with SD files then install your firmware over the top?)

Cheers

Ray

I believe I have a solution to the USB printing problem. It's a combination of firmware mods and a 1-line mod to Kliment's Pronterface. I'd like to get it working with the RRP version of Pronterface too. Unfortunately, since installing Kliment's Pronterface, the RRP version no longer works. It gives a pile of "Unknown variable" errors in the console window. I've tried re-installing the RepRap version, to no avail. I'm guessing that Kliment's version has installed a new version of a library, or something like that. I'm not familiar with Python, so does anyone have any suggestions about how to restore the system so that the RRP version works again?

Edited 2 time(s). Last edit at 01/11/2014 10:36AM 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
rayhicks
will do - I've downloaded it, but am in the middle of a long test print, do I need to update any other files? (I'm running an older version of firmware than I should at the moment, should I update to the current main duet branch along with SD files then install your firmware over the top?)

Yes, you need to at least update the SD files in the sys directory, except of course for your own config.g.

I've now got the USB print working without stuttering in Pronterface.

---

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

excellent news DC - will kill my print soon and try it out,

Cheers

Ray

Quote
reprappro
Another problem we have just spotted... All Duet boards have been supplied with only two of the four USB lugs soldered. Some have been supplied with none of them soldered! This can make the USB connection electrically unstable, and makes it much easier to pull the USB socket off the board. Please carefully solder up all four pins. I'll be adding this to the documentation (along with the long-awaited troubleshooting...) at the weekend, hopefully.

All subsequent boards should have all four lugs solder up. I think someone else pointed this out in an earlier thread, but it got lost in the noise!

Ian
RepRapPro tech support

I wish I had known this earlier. I had USB connection issues and when I unpplugged the USB lead the whole socket came off!
I've emailed support but not got a reponse yet.

Daryl (Ormerod #299)

Edited 1 time(s). Last edit at 01/11/2014 11:15AM by djb.

Quote
djb
I wish I had known this earlier. I had USB connection issues and when I unpplugged the USB lead the whole socket came off!
I've emailed support but not got a reponse yet.

Daryl (Ormerod #299)

Yeah, Ian has loads of emails to go through including my email, where I am also waiting for a response, but like I said he probably hasn't got to our emails yet, so just sit tight.

Paul

---

RS Ormerod No 436

@djb: Yes, your email is in my inbox, I should get to it in a little while. We'll send you a new Duet, on an exchange basis, under warranty. Hopefully properly soldeder, this time.

@TMD_RS486: it's only your emails I ignore! (not really, just about got to it)

Ian
RepRapPro tech support

Hello Ian

Quote
droftarts
@djb: Yes, your email is in my inbox, I should get to it in a little while. We'll send you a new Duet, on an exchange basis, under warranty. Hopefully properly soldeder, this time.

@TMD_RS486: it's only your emails I ignore! (not really, just about got to it)

Ian
RepRapPro tech support

LOL, no probs.

Paul

---

RS Ormerod No 436