bear20212120
-
Posts
6 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by bear20212120
-
-
1 hour ago, nallath said:
But there is no clearly defined protocol 😉 The USB bit is, but what is then actually sent over is very far from standardised. The problem is not "getting a message to reach the other side". The problem is "Making sure that the other side understands what you mean".
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, you may and shall have it in each end very place where you want to send data between two separated entities. If I speak German and you speak English it is absolutely irrelevant what type of connection were are going to use - usb, phone, or written letters. We won't understand each other. So no need to blame "horrible sheet of paper" if a reader cannot understand the writer in this case.
1 hour ago, nallath said:Well, usb printing is worse for 3D printing, because of the implementation and all other things involved. You might be theoretically right that it's stable enough to work, the reality is that it's horrible
"Horrible" - it is not any quantitative explanation, sorry. Again, there are software products which do support it and their vendors and users don't find it "horrible". USB , serial, or WiFi - are all legitimate carriers layers to send bits over at discussable data rates. There is nothing horrible about any of them. The horrible part starts when software comes in play.
1 hour ago, nallath said:I just argued that it's too much work to spend on something that we don't even use for our own printers.
And here is the major point: "our own printers". Precisely! You see, if Cura will position itself as piece of software that supports some specific "our own printers" - then it would be absolutely fine to say "our printers don't have that and our users don't need that either". Anybody who needs something different shall use something different, too - including software. Many vendors, especially printer vendors, do exactly this.
But 90% of CURA's popularity is a result of it's claimed universality and being "best 3D printer software" in a market - plus, certainly, because like those abovementioned "cheap Chinese printers", - it is cheap, too. And somewhere here the failure starts: it is very difficult to claim that you are "universally best" and be at the same time "software for our own printers". And then describe anything that interferes that claim as "horrible thing", including USB 🙂No matter what, I understood, that there no any plans to include support for low latency wired printer control for your own printers, hence for CURA, too. At least this part is very clear, thanks!
-
12 minutes ago, gr5 said:
I think Marlin uses just a one character checksum and it's not even 256 bits - it's something like a number 0 through F maybe? So it's only 16 bits. So 1 out of 16 bad corrupted gcodes (I believe) make it through USB and get "printed" by Marlin
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.
-
4 minutes ago, gr5 said:
All words, all statements are a simplification of reality. It's impossible to be 100% thorough on any statement. So I was simplifying above.
OK 🙂
5 minutes ago, gr5 said:I think Marlin uses just a one character checksum and it's not even 256 bits - it's something like a number 0 through F maybe? So it's only 16 bits. So 1 out of 16 bad corrupted gcodes (I believe) make it through USB and get "printed" by Marlin.
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] != '*' && cmd[i] != NULL; i++)
cs = cs ^ cmd[i];
cs &= 0xff; // Defensive programming...
and the value is appended as a decimal integer to the command after the * character" -
2 hours ago, nallath said:
Have you looked at the way that all the different firmwares and operating systems handle this? I am pretty sure that you did not, since you would not be making this statement if you did
QuoteIt's also not the USB connection that is the problem. You are confusing two things here.
I'm confusion nothing. I meant the following statement when was answering:
QuoteOn 1/29/2019 at 6:33 PM, gr5 said:
USB is less reliable. Amazingly bad gcodes end up making it to the arduino. I blame the arduino usb hardware because for other devices, usb is very reliable. But for 3d printing not so much.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 that it was simply decided to drop it, justifying it by “nobody needs it”.
Although in fact, while keep saying “USB” it should be understood, that there is nothing about USB at all, as far as software concerns. The communication protocol says nothing about USB – it is simplest possible ACII characters exchange. USB is just a physical medium and hardly handled by software on any PC host at low-level USB stack. Most of printers now days use some kind of FTDI chip so most of staff inside of software appears as ages-old and many decades proven, and simple as a brick serial COM port communication.
And the other point is that maybe there is no need in attempting to cover all possible things in the world? ))Quoteall firmwares itself also handle this different
Again, with clearly defined protocol, the host’s software should not care how firmware handles it.
Thanks, anyway, for giving a decent reason for missing this functionality, anyway. Because “we don’t care about this part of functionality” sounds much better and realistic than all other points given earlier in this thread like “users don’t need it” or “USB is not reliable” or “Arduino is crap” or “use something else, like Octoprint” - have very little sense and are out of any criticism.
There are quite a few products in a market, both free and commercial, which do provide direct printer control over the wired connection and that fact renders any other than “we don’t have time/ don’t care” reasons fictional.Good luck in your work anyway 🙂
-
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 wretched. So the CURA is “best” when it is paired with some other software (and hardware, other than printer itself, in fact) and not so “best” when it is not? )))USB connection is one of the most reliable connection and protocol in the world, and by far one of the most common one. It is definitely more reliable and less interruptible than any radio communication channels (any type of wireless) or internet ones. Any complains about “Windows updates interruption” worth nothing, as the latter can be either disabled or scheduled accordingly, to avoid corresponding problems.
Moreover, the software shall be written in the way that mitigates this type of problems. Especially for software, that naturally supposed to run continuously and reliably for many hours. Get back to a known state before the interruption after system resume – it is not any rocket science. All computers in the world support hibernation now days, which won’t be possible without ability to continue at interruption point. Something like lifting the nozzle by 1 mm retracting filament and shutting heaters and motors down if the printer cannot see any commands from USB within 100 ms – not any magic either and not extremely bulky code not to fit in even simplest controller’s memory. Therefore, it is also very disappointing, if the printers don’t do that. Because direct wired connection to the printer is the only way that gives small enough latency, and total control over data flow , which together allow reasonably “real time” corrections of the actual print, either manual or automated.The conclusion is that lack of USB channel to the printer is not USB, OS, computer’s, or "lack of user’s interest" problem. IT’s a problem of the way the software on both ends is developed and/or implemented. Not sure if it is a result of SW being “free” (Simplify3D supports USB connection out of the shelf, for instance) or there are some other reasons behind – but in any case it’s pretty disappointing.
How can I print directly from cura to my 3d printer using usb?
in UltiMaker Cura
Posted · Edited by 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.