Faster way to download gcode to sd?

[limhyon]

Hi. A faster way to download gcode to SD card using COM port exist? Current download method seems to be writing by simulating printing sequence from M28 to M29 command.

I think employing Xmodel protocol or binary gcode and decode seems to be a candidate. How is your opinion?

[bkubicek]

I really recommend "downloading" the code by taking the sd card into the pc slot and putting it back in. No USB connection whatsoever, no cable, the printer can be hanging from the ceiling, can print in the celler or anywhere else.

SD download could be faster, if one had 512byte free memory to do block transfers. But it will never be as fast as moving the sd card.

Bernhard

On Mon, Feb 4, 2013 at 2:33 PM, limhyon notifications@github.com wrote:

Hi. A faster way to download gcode to SD card using COM port exist? Current download method seems to be writing by simulating printing sequence from M28 to M29 command.

I think employing Xmodel protocol or binary gcode and decode seems to be a candidate. How is your opinion?

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382.

[Banjer]

"downloading" via putting the card in your pc works ok, but has some major drawbacks when you don't use a LCD/keypad/encoder to control the printer. On inserting the SD-card the printer resets, meaning my host-application on the pc goes ape :( I can work around that, and i can understand this isn't a high prio, or even possible, but faster SD upload would be nice.

[paenian]

huh... your SD card shouldn't reset your printer... sounds like a different bug. What electronics?

I'd also enjoy faster SD upload, but only as a small convenience.

Is there a standard binary format for gcode? It shouldn't be too hard to encode/decode, might make sending regular commands a little faster and more robust as well. Just make M28/29 recognize binary gcode as well, it'd speed up the transfer somewhat. From there, adding a special SD upload mode would be relatively easy, if it's even necessary.

Paul

On Mon, Feb 4, 2013 at 9:28 AM, Bas notifications@github.com wrote:

"downloading" via putting the card in your pc works ok, but has some major drawbacks when you don't use a LCD/keypad/encoder to control the printer. On inserting the SD-card the printer resets, meaning my host-application on the pc goes ape :( I can work around that, and i can understand this isn't a high prio, or even possible, but faster SD upload would be nice.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13078946.

[nophead]

Inserting the card on a Melzi causes a reset. I assumed it was a firmware thing as I can't see how it would do a hardware reset.

On 4 February 2013 14:36, Paul Chase notifications@github.com wrote:

huh... your SD card shouldn't reset your printer... sounds like a different bug. What electronics?

I'd also enjoy faster SD upload, but only as a small convenience.

Is there a standard binary format for gcode? It shouldn't be too hard to encode/decode, might make sending regular commands a little faster and more robust as well. Just make M28/29 recognize binary gcode as well, it'd speed up the transfer somewhat. From there, adding a special SD upload mode would be relatively easy, if it's even necessary.

Paul

On Mon, Feb 4, 2013 at 9:28 AM, Bas notifications@github.com wrote:

"downloading" via putting the card in your pc works ok, but has some major drawbacks when you don't use a LCD/keypad/encoder to control the printer. On inserting the SD-card the printer resets, meaning my host-application on the pc goes ape :( I can work around that, and i can understand this isn't a high prio, or even possible, but faster SD upload would be nice.

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13078946>.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13079357.

[limhyon]

I also give a vote to binary gcode download. Moving a file by SD card reader works, however, it is inconvenient.

[nophead]

It needs a sliding window protocol because USB latency is large compared to its transfer speed.

On 4 February 2013 14:46, limhyon notifications@github.com wrote:

I also give a vote to binary gcode download. Moving a file by SD card reader works, however, it is inconvenient.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13079823.

[nothinman]

A lot of work and no true benefit. Either put everything on the card and print of the card, or print via computer. Or get an Eye-Fi SD card if bothered?...

[nothinman]

Actually wonder if Eye-Fi card would work in both directions, that would be really cool...

[limhyon]

Does eye-fi support reverse directional upload?

I know eye-fi support sd to pc. However, I don't know pc to sd.

-Hyon

This mail was written in mobile phone.

On 2013. 2. 5., at 오전 12:45, nothinman notifications@github.com wrote:

Actually wonder if Eye-Fi card would work in both directions, that would be really cool...

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13082686.

[daid]

No matter the compression or block transfers you add, the USB->SD transfer will be remain in the "pretty slow" range. At 250k baud, you can still transfer only 25k/s which makes it long to transfer any GCode file, even compressed.

[thecrazy]

wouldn't there be a way to zip the file and have the arduino decompress it automatically once its on the card?

On Mon, Feb 4, 2013 at 12:42 PM, daid notifications@github.com wrote:

No matter the compression or block transfers you add, the USB->SD transfer will be remain in the "pretty slow" range. At 250k baud, you can still transfer only 25k/s which makes it long to transfer any GCode file, even compressed.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13088963.

[nothinman]

There's a way to do anything, and everything. Just tell me why... are people really so lazy they can't take a SD card out of the printer and stick it into the computer? It will take 10 seconds, print takes (usually) hours. Where's the benefit?

[bkubicek]

there is a simple reason: some boards are designed so that they have e.g. a micro-sd card directly on the main pcb, on a side opposit to the usb connectors. So if the pcb is hidden from view, you cannot simply remove the sd card. And also micro-sd is stupid to insert in a normal computer, you need a intermediate converter.

So some printers are not very well suited for it, although, I personally think that the printers should change.

Bernhard

On Mon, Feb 4, 2013 at 6:57 PM, nothinman notifications@github.com wrote:

There's a way to do anything, and everything. Just tell me why... are people really so lazy they can't take a SD card out of the printer and stick it into the computer? It will take 10 seconds, print takes (usually) hours. Where's the benefit?

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13089694.

[nophead]

I imagine it will wear out the socket eventually.

On 4 February 2013 17:57, nothinman notifications@github.com wrote:

There's a way to do anything, and everything. Just tell me why... are people really so lazy they can't take a SD card out of the printer and stick it into the computer? It will take 10 seconds, print takes (usually) hours. Where's the benefit?

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13089694.

[Banjer]

Ideally i would like to see the host programs upload the gcode file and start the print when it's uploaded. The user experience would be much more like the common 2d printer, you press print, the file gets send to the printers buffer and gets printed. I guess that could be done now, but with the current SD upload speeds it's not worth it.

[thecrazy]

Personally, I hate dealing with micro SD cards, they are just a pain in the ass, plus the sd slot on my printer is all the way in the back and there is a ton of wires around it.

The reprap community has to get rid of the *&%! com port. That usb cable is just a tease.

BTW I ran a few compression tests, here are the results:

Original stl file 2994K

Zip normal 1297k ultra 1288k

7zip ultra w/LZMA 593k (quick)

Bzip2 ultra 1303k (slow)

Gzip ultra 1288k (slow)

XZ ultra 1255 (quick)

Now to find a 7zip library that would work on a arduino... I dont even know if its possible. Ill leave that to those who can code.

On Mon, Feb 4, 2013 at 1:03 PM, Chris notifications@github.com wrote:

I imagine it will wear out the socket eventually.

On 4 February 2013 17:57, nothinman notifications@github.com wrote:

There's a way to do anything, and everything. Just tell me why... are people really so lazy they can't take a SD card out of the printer and stick it into the computer? It will take 10 seconds, print takes (usually) hours. Where's the benefit?

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13089694>.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13090013.

[scotty1024]

Maybe I am a cheap bastard and don't want all the extra wear and tear on my PC, controller board and card. :-)

Sent from my iPad mini 4G

On Feb 4, 2013, at 9:57, nothinman notifications@github.com wrote:

There's a way to do anything, and everything. Just tell me why... are people really so lazy they can't take a SD card out of the printer and stick it into the computer? It will take 10 seconds, print takes (usually) hours. Where's the benefit?

— Reply to this email directly or view it on GitHub.

Sr

[thecrazy]

BTW I have allready looked at the eyefi sd cards and contacted them, currently from what they say it only transfers one way. They really missed the point on that one, It could have added wifi to every device using an SD card...

If the way the file is transfered over the USB cant be changed the only other solution would be to figure out a hack to allow us to upload files to the sd card while its still in the printer... maybe it would be possible to hack the sd ramps to work like a usb SD card reader and have a switch to change between the PC and the RAMPS.

[limhyon]

Use cubify. You will notice that pulling in and out sd card is so cumbersome.

-Hyon

This mail was written in mobile phone.

On 2013. 2. 5., at 오전 2:57, nothinman notifications@github.com wrote:

There's a way to do anything, and everything. Just tell me why... are people really so lazy they can't take a SD card out of the printer and stick it into the computer? It will take 10 seconds, print takes (usually) hours. Where's the benefit?

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13089694.

[limhyon]

I agree with this

-Hyon

This mail was written in mobile phone.

On 2013. 2. 5., at 오전 3:01, Bernhard Kubicek notifications@github.com wrote:

there is a simple reason: some boards are designed so that they have e.g. a micro-sd card directly on the main pcb, on a side opposit to the usb connectors. So if the pcb is hidden from view, you cannot simply remove the sd card. And also micro-sd is stupid to insert in a normal computer, you need a intermediate converter.

So some printers are not very well suited for it, although, I personally think that the printers should change.

Bernhard

On Mon, Feb 4, 2013 at 6:57 PM, nothinman notifications@github.com wrote:

There's a way to do anything, and everything. Just tell me why... are people really so lazy they can't take a SD card out of the printer and stick it into the computer? It will take 10 seconds, print takes (usually) hours. Where's the benefit?

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13089694>.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13089875.

[limhyon]

I agree with this.

-Hyon

This mail was written in mobile phone.

On 2013. 2. 5., at 오전 3:23, Bas notifications@github.com wrote:

Ideally i would like to see the host programs upload the gcode file and start the print when it's uploaded. The user experience would be much more like the common 2d printer, you press print, the file gets send to the printers buffer and gets printed. I guess that could be done now, but with the current SD upload speeds it's not worth it.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13091068.

[nothinman]

Better FTDI (I know some boards don't use it) <-> uC PCB routing will allow one to use 2Mbps. SD card is only good if you print out the same stuff over and over again and want your computer to be off during that time. That's the purpose of storage. My Sanguinololu runs kinda fine at 1Mbps. Kinda, as it destroyed two out of say 30 prints. Better idea would be an ethernet. I tried doing it, but code was just too messy to change and I've given up. Not sure how these worked, but this could be helpful http://www.mobiletechreview.com/tips/sandisk_SD_wifi.htm (MiFi only supports photos (restricted by host soft/firmware) and download; silly as hell :/)

[limhyon]

I think print on SD is more stable than streaming gcode over serial.

Main purpose of moving gcode into SD card is for printing stability.

How do you think?

-Hyon

This mail was written in mobile phone.

On 2013. 2. 5., at 오전 3:59, nothinman notifications@github.com wrote:

Better FTDI (I know some boards don't use it) <-> uC PCB routing will allow one to use 2Mbps. SD card is only good if you print out the same stuff over and over again and want your computer to be off during that time. That's the purpose of storage. My Sanguinololu runs kinda fine at 1Mbps. Kinda, as it destroyed two out of say 30 prints. Better idea would be an ethernet. I tried doing it, but code was just too messy to change and I've given up. Not sure how these worked, but this could be helpful http://www.mobiletechreview.com/tips/sandisk_SD_wifi.htm (MiFi only supports photos (restricted by host soft/firmware) and download; silly as hell :/)

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13092915.

[nophead]

Yes I get random blobs with USB from a WinXP machine. The same machine can run three machines over Ethernet with absolutely no command buffering and not get blobs.

On 4 February 2013 19:01, limhyon notifications@github.com wrote:

I think print on SD is more stable than streaming gcode over serial.

Main purpose of moving gcode into SD card is for printing stability.

How do you think?

-Hyon

This mail was written in mobile phone.

On 2013. 2. 5., at 오전 3:59, nothinman notifications@github.com wrote:

Better FTDI (I know some boards don't use it) <-> uC PCB routing will allow one to use 2Mbps. SD card is only good if you print out the same stuff over and over again and want your computer to be off during that time. That's the purpose of storage. My Sanguinololu runs kinda fine at 1Mbps. Kinda, as it destroyed two out of say 30 prints. Better idea would be an ethernet. I tried doing it, but code was just too messy to change and I've given up. Not sure how these worked, but this could be helpful http://www.mobiletechreview.com/tips/sandisk_SD_wifi.htm (MiFi only supports photos (restricted by host soft/firmware) and download; silly as hell :/)

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13092915.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13093039.

[thecrazy]

I stream all my prints and have no problems, but I needed an Online UPS with double conversion to achieve that AND I switched to a shielded USB cable. Before using this setup my prints crashed all the times and I had slowdowns while printing.

At the price of a Online UPS though, we cant expect everyone to be able to go that route, I was lucky to get mine for cheap.

BTW You have to run both the pc AND the printer from it otherwise you still get crashes.

@nophead you have three printers setup over ethernet? How did you do that?

[larsbrubaker]

It might be useful to stream gcode to a new buffer in ram rather than the planner buffer. It could be defined that the gcode buffer only contains g1 with x y e in it, and if anything else is seen, we wait to exhaust the gcode buffer and get commands directly to the planner like normal, going back opportunistically when we see a stream of G1s.

The current block_t is about 80 bytes. A gcode buffer (G1 commands) could be stored in about 6 bytes as shorts (x y e) yielding about 13x the number of queued commands.

[buildrob]

I tend to agree that with the current hardware,whilst some definite improvements could be made to the current SD write functionality, it is never going to be as fast as people would expect it to be over a 250kpbs link.

I wired up an XBee wi-fi module to my printer: http://bukobot.com/make-your-bukobot-wireless

The crazy thing is that with the $35 low cost of a raspberry pi board, then for the same cost you can have a thin server which supports connection and disconnection of a client, job upload over ethernet, progress reporting with a much richer user interface than allowed for by an SD card print or LCD (and can be accessed anywhere through the webserver). [Such as the new Repetier-Server project: http://www.repetier.com/repetier-server-download/]

[daid]

I take your $35 raspberry pi and raise you a $25.70 Wireless OpenWRT router (TL-WR703N) for wireless printing.

Anyhow, compression won't help, as you'll add processing time, which is part of the current problem for transfer speed. What you can do is 'shrink' the GCode file. Most GCode commands are "G1 X10.0 Y11.1 E10.3" Now, first, the GCode reader in Marlin doesn't care for spaces, so you can save yourself a few % right there by stripping out all spaces. Next, G0 and G1 are the same thing, also "G" without a number behind it is seen as G0. So your command can become "GX10Y11.1E10.3", all without changing a letter in the firmware.

But in the end, no matter what you do, even if you add a binary protocol to compress a segment of moves even better, you will still be on the slow side.

[limhyon]

I use Cubify too. It is relatively faster than serial. I disassembled cubify, I found that there is WLAN to serial tranceiver to do this. Does anyone know how this speed achieved? (Cubify)

-Hyon

This mail was written in mobile phone.

On 2013. 2. 5., at 오후 11:26, daid notifications@github.com wrote:

I take your $35 raspberry pi and raise you a $25.70 Wireless OpenWRT router (TL-WR703N) for wireless printing.

Anyhow, compression won't help, as you'll add processing time, which is part of the current problem for transfer speed. What you can do is 'shrink' the GCode file. Most GCode commands are "G1 X10.0 Y11.1 E10.3" Now, first, the GCode reader in Marlin doesn't care for spaces, so you can save yourself a few % right there by stripping out all spaces. Next, G0 and G1 are the same thing, also "G" without a number behind it is seen as G0. So your command can become "GX10Y11.1E10.3", all without changing a letter in the firmware.

But in the end, no matter what you do, even if you add a binary protocol to compress a segment of moves even better, you will still be on the slow side.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13131333..

[nothinman]

@limhyon: define "serial's" speed? If you're talking 115kbit serial then yes, can easily be faster than that. Bear in mind that uC is capable of doing 2Mbps serial, some transceivers (USB to serial) like my FTDI that sits on Sanguinololu is also capable of doing 2Mbps. The only problem is you get some noise, due to poor routing. If you have everything SMD and soldered you could probably run at higher speeds. Or you could change retransmission retries in the code to say... 20? If you're getting a lot of garbage on the wire. Experiment. In my case 1Mbps seems to be behaving nicely.

[thecrazy]

So your saying that with a better protocol and with adequate error correction we could transmit faster? That's kind of like what repetier host in combination with repetier firmware does. I know his transmission speed is faster but no idea how much.

[ErikZalm]

A more compact protocol will be better. But then you need a host who does that. repetier and makerbot use a compressed protocol. But then you are limited to 1 host software.

[Banjer]

That's not entirely true, at least Repetier supports both normal and binary in the firmware and host software, so both can talk to other firmware/hosts. Only if you want to use the binary protocol you need to use a host that supports it, you still can use other hosts with plain ASCII.

[ErikZalm]

If you want to use the compressed protocol you are limited to 1 host software.

[thecrazy]

If the protocol is good, and open source, I don't see why It wouldn't be implemented by others and become a standard. But before doing any of that, we would need to get an idea of how much better it could make things for us. Maybe its not worth the effort.

[nothinman]

I think some of you can't or don't want to read with understanding. No, not a good idea because it's not worth it. But if anyone thinks otherwise you can always open your favourite editor and start coding. Admins would be happy to merge your code :-)

1) Speed is not limited by hardware, but by poor hardware routing/design; I get 1Mbps from mine and it works fine, so one should be looking at fixing it at the source, not focusing on a work-around; atmega can handle 2Mbps, 2) If you (for whatever reason) need speed, print from SD card, 3) Adding compression adds more CPU cycles, so you copy it faster, but then it takes longer to process it -> no gain. It is just not worth it. This time would be better spent implementing Ethernet via say ENC28J60; SPI <-> Eth module costs $10.

[thecrazy]

That's a good idea.

[bkubicek]

also, please note that faster recieving means faster necessary requirements for the firmware to process the data. There is nearly no hardware buffering by the atmega. If you don't process data while this IIRC two byte buffer is written, you would need flow control. It caused many problems with the quite long stepping ISR routine, which EvdZ had solved by putting additional serial processing into ths ISR. Which is crazy, but necessary.

The one and only thing to do is to go ARM. The atmega is at a limit, has been since a while already. Its stupid to optimize code up to unreadability, when a much better hardware platform exists. We have squeezed it enough already.

Bernhard

On Wed, Feb 6, 2013 at 8:09 PM, Frederic Defoy notifications@github.comwrote:

That's a good idea.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13199190.

[buildrob]

The nice thing about the Write To Sd Card command is that it requires no other hardware and many controlllers are coming with them as standard today.

I found a PD Zmodem library which is amenable to constrained embedded environment (So I can implement it without needing lots of Ram). Anyway I'll see what throughput a "write to Sd card using zmodem" command gets. You can simply use Teraterm or similar to upload the file (this doesn't do compression of course).

[limhyon]

This is good idea. I hope some host software (e.g., Printrin) support TCP/IP based g-code sending.

-Hyon

This mail was written in mobile phone.

On 2013. 2. 7., at 오전 3:58, nothinman notifications@github.com wrote:

I think some of you can't or don't want to read with understanding. No, not a good idea because it's not worth it. But if anyone thinks otherwise you can always open your favourite editor and start coding. Admins would be happy to merge your code :-)

1) Speed is not limited by hardware, but by poor hardware routing/design; I get 1Mbps from mine and it works fine, so one should be looking at fixing it at the source, not focusing on a work-around; atmega can handle 2Mbps, 2) If you (for whatever reason) need speed, print from SD card, 3) Adding compression adds more CPU cycles, so you copy it faster, but then it takes longer to process it -> no gain. It is just not worth it. This time would be better spent implementing Ethernet via say ENC28J60; SPI <-> Eth module costs $10.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13198596.

[nothinman]

Arduino provides a free library for ENC28J60, which the just call "Ethernet", the rest is just a matter of sending stuff to an open socket rather than UART. In the simplest form there would be a telnet-like communication, plain, unencrypted, uncompressed. But there's a lot of ifdef's that need to be added along with write_to_socket() all over the code, and I just had no time to do it, as I'm working on my own 3D printer project at present... Also, one would need to change printrun to open a socket on window/create, use socket rather than serial, and close socket on window/close. Doable, and you get 10Mbps.

[buildrob]

I'm using virtual com port provider software with my ethernet module [E.g., on Windows: HW Virtual Serial Port 3 (http://www.hw-group.com/products/hw_vsp/index_en.html) which is free for private use]. This way the Host software doesn't have to know anything about the fact that the connection is going over Ethernet. Obviously if the Host software did actually support TCP connections natively then this would be ideal.

[nothinman]

@buildrob: I don't see how this helps. It's still using serial, only encapsulated in Ethernet... We would ideally want to get rid of serial, or use it as a "backup" communication method.

[buildrob]

Your comment "Also, one would need to change printrun to open a socket on window/create, use socket rather than serial, and close socket on window/close. Doable, and you get 10Mbps." sounded like you were still talking about sending a serial-like connection over ethernet (rather than a completely separate protocol). You even mentioned it being a telnet-like communication. So I'm confused now. I wasn't saying that the VCP is an ideal solution just that you don't need to wait for Host software support to start using TCP based Ethernet connections.

[nothinman]

You took it out of context :-) -- I was talking about using pure Ethernet but don't do any print servers, job servers, rewrite protocols, just send data in a telnet-like fashing between two open TCP/IP sockets. That's what I meant. We can convert RS232 to anything we want, but that's not the point (nor an issue). The idea is to replace RS232 with something more reliable; such as the Ethernet...

[nophead]

RS232 isn't unreliable. It is USB that is unreliable when it forms a ground loop between two earthed devices.

On 7 February 2013 16:47, nothinman notifications@github.com wrote:

You took it out of context :-) -- I was talking about using pure Ethernet but don't do any print servers, job servers, rewrite protocols, just send data in a telnet-like fashing between two open TCP/IP sockets. That's what I meant. We can convert RS232 to anything we want, but that's not the point (nor an issue). The idea is to replace RS232 with something more reliable; such as the Ethernet...

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13245115.

[nothinman]

Or your system when it doesn't support say 250kbit, or 1Mb ;) I personally have no problems with serial, but I know that people do. Ethernet would be a nice step forward (into the right direction too). I can't imagine anyone having problems with Ethernet...

[nophead]

Yes Ethernet is much better than USB because it is isolated. I run my production machines with Ethernet and don't have any problems, apart from Win7 disrupting the comms occasionally until I disabled DHCP. I think it must block all comms while it renews the lease or something. XP was fine with DHCP enabled.

On 7 February 2013 17:09, nothinman notifications@github.com wrote:

Or your system when it doesn't support say 250kbit, or 1Mb ;) I personally have no problems with serial, but I know that people do. Ethernet would be a nice step forward (into the right direction too). I can't imagine anyone having problems with Ethernet...

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13246588.

[thecrazy]

Just wondering, how does HP, canon, lexmark etc.. do it? they all use usb and have no problems.

Wouldnt it be possible / better in the long run to simply work on a ramps 1.5 thats compatible with current firmwares but does the USB part properly?

On Thu, Feb 7, 2013 at 12:15 PM, Chris notifications@github.com wrote:

Yes Ethernet is much better than USB because it is isolated. I run my production machines with Ethernet and don't have any problems, apart from Win7 disrupting the comms occasionally until I disabled DHCP. I think it must block all comms while it renews the lease or something. XP was fine with DHCP enabled.

On 7 February 2013 17:09, nothinman notifications@github.com wrote:

Or your system when it doesn't support say 250kbit, or 1Mb ;) I personally have no problems with serial, but I know that people do. Ethernet would be a nice step forward (into the right direction too). I can't imagine anyone having problems with Ethernet...

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13246588>.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13247164.

[nophead]

All it would need is to power the FTDI chip from USB and opto couple the serial lines to the Atmega to break the ground loop.

On 7 February 2013 17:45, Frederic Defoy notifications@github.com wrote:

Just wondering, how does HP, canon, lexmark etc.. do it? they all use usb and have no problems.

Wouldnt it be possible / better in the long run to simply work on a ramps 1.5 thats compatible with current firmwares but does the USB part properly?

On Thu, Feb 7, 2013 at 12:15 PM, Chris notifications@github.com wrote:

Yes Ethernet is much better than USB because it is isolated. I run my production machines with Ethernet and don't have any problems, apart from Win7 disrupting the comms occasionally until I disabled DHCP. I think it must block all comms while it renews the lease or something. XP was fine with DHCP enabled.

On 7 February 2013 17:09, nothinman notifications@github.com wrote:

Or your system when it doesn't support say 250kbit, or 1Mb ;) I personally have no problems with serial, but I know that people do. Ethernet would be a nice step forward (into the right direction too). I can't imagine anyone having problems with Ethernet...

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13246588>.

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13247164>.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13249749.