bear20212120

You answered yourself what it will do: it will stop the print for 30 seconds. 🙂 Doesn't sound to me a s huge problem over "not unusual 24 hours job", isn't it? Not to say that PC that does things like you've described requires a fix, regardless of what it is used for. Sure, nobody wants. That's why people invented installers, which address 99% percents of type of problems you described as a very first step of software use.

As to me, RepRap describes its protocol clear enough (see link above). There are variations yet not so significant to make it impossible to implement. This is first. Second, when you are saying that "the problem is "Making sure that the other side understands what you mean"." -- what it has to do with USB, serial comm, WiFi, BLuetooth, Ehtenrnet etc? It still down to the fact that one piece of software cannot (and in our case, as it is clearly seen from the discussion, doesn't want to either), understand another piece of software. That's it. Based on the problem as you've described it,

Also, you are messing with bits. You means ranges, but saying "bits ":) To have corrupted data at communication speed of 115 kbits/second in the channel with a bandwidth of at least several MBytes/second - it's something special. It's definitely nothing to do with the channel but with the software. Teh way it handles data. Drops bytes because it cannot keep up with the rate or so - but it is really very hard to imagine any kind of physical corruption at this data rate over USB cable within its allowed length.

OK 🙂 I think it's pretty clear describe here. And it's easy to check even with PUTTY that MARLIN supports it exactly this way. "The RepRap firmware checks the line number and the checksum. You can leave both of these out - RepRap will still work, but it won't do checking. You have to have both or neither though. If only one appears, it produces an error. The checksum "cs" for a G-code string "cmd" (including its line number) is computed by exor-ing the bytes in the string up to and not including the * character as follows: int cs = 0; for(i = 0; cmd[i] !=

I'm confusion nothing. I meant the following statement when was answering: The above is not true: "USB is less reliable". And if someone blames arduino's HW, it should not be referred as "usb is not good for 3D printing", but "usb is not good for/on arduino", because 3D printing on Arduino is not 3D printing in general. As for your statement - sure, different firmware and different operating systems handle many things differently. GUI, any hardware related stuff etc. It’s just amazing that exactly USB communication appears so difficult to handle because of all those differences t

Lifting up this thread a bit.. So, after nearly 2 years since this discussion I'm trying to use almost newest CURA 4.8.0 to print GCode directly to 3D printer via USB and still cannot do it? With the software that claims on its startup splash screen to be "the world's most advanced 3D printing software2" I cannot do the task a s simple as sending text file over wired connection directly to the printer? This is amazing. )) All the rants in some of the above posts about “using something else to do the print” from within the “world’s most advanced 3D printing software” sound pretty wretche