RE: USB printing gone (!!!)
now that boggles my mind because if you can do that with octoprint, why cant slic3r do it?
RE: USB printing gone (!!!)
hey you two raise very valid points. god i didnt realize how weenie the chip really was. i thought it would at least have DMA.
hrm running octoprint on the PC thats a new one. how do ya figure that? bunch of jumper wires along the carpet connected up to the GPIO pins of the printer?
i should apologize for my earlier rantmode mood. its just this turns my world upside down. at least theres real legit reasons for this.
i heard horror stories about the raspi-w not wanting to work properly cos of a wifi bug or something? what do you guys know about that? this is all so terrible. there is nothing worse that could happen to a person ever.
Most RPi Octoprint (so I would extend this to a PC running Octoprint as well) setups that I've seen connect via USB. But they don't send the entire print-job (g-code file) to the printer, rather it feeds the g-code line-by-line to the printer, I suppose that could be called (and I do, below) streaming the g-code.
Also, when I installed the Prusa software package, Pronterface was also installed. But I'm on Winblows. Is Pronterface not available for your Linux distro? (Pronterface will stream g-code to anything at the other end of the USB, reads telemetry reports from the printer and can show line graphs of the temperatures, provides a button interface for moving the head around (I haven't tried it while printing, I suspect that would work but will probably ruin your print), and a place to type g-codes directly to the printer. I personally haven't tried sending g-codes to the printer (I use the SD card) and I can't get it to tell the printer to print a file from the SD card (Pronterface only seems to recognize the 8+3 filenames, where my MK3S firmware understands extended filenames...). But I often have Pronterface running so I can keep tabs on telemetry.
YMMV
See my (limited) designs on:
Printables - https://www.printables.com/@Sembazuru
Thingiverse - https://www.thingiverse.com/Sembazuru/designs
RE: USB printing gone (!!!)
Slic3r certainly can do it, or rather could in the past. But if I understand correctly, for the sake of maintainability, that functionality was dropped, as it can be supplied by other specialized tools better. Slic3r is a slicer and not necessarily a print control tool. (But yes, it was nice to have it all in one.)
RE: USB printing gone (!!!)
Just wanted to ask where the "Print"-Button (and print-queue) is gone.
I did USB-printing in the past and was searching around what was wrong with my settings.
Would have been nice to announce that USB printing is no longer available, could have saved my time.
Greetings,
tox
RE: USB printing gone (!!!)
The code is gone since this commit, the explanation is indeed somewhat lacking.
commit d934b63424ab76ddcd8a87f272838df611dfcd0c
Author: bubnikv <[email protected]>
Date: Mon Sep 17 12:01:02 2018 +0200
Removed Print.pm,
ported execution of post processing scripts into C++ (WIP, waits for
update of boost::system module on our build server)
Removed other mention of the "Controller".
It's all just wrapped in
#if 0
#endif
in the code, so I suppose one could still enable it again and recompile. Most likely it'll require some fixes, though.
RE: USB printing gone (!!!)
Apparently they're rewriting the whole thing from Perl to C++, mainly to speed things up and the Print module wasn't deemed worth the effort to rewrite. Perhaps if someone did that, it'd be accepted.
RE: USB printing gone (!!!)
They call it out in ‘Features dropped” section of the 1.42-alpha1 changelog:
- Online printing over serial line aka the "Controller" was dropped for now. We are not sure yet whether we will integrate it into Slic3r again, or whether we will create a separate application for printer and printer queue control, or whether we will drop the serial line printing for good, as there are other applications that serve the same purpose. Please let us know what you think.
I will mention that i had a different printer that could ONLY print via USB. Untethered printing was an often requested feature. They did have something where you could upload the gcode to the printer, but their USB interface was so slow that the transfer took almost as long as the print.
When someone asks you if you're a god, you say, "YES!"
RE: USB printing gone (!!!)
Is flashing the firmware still available within Slic3r?
I only ask this because there are other applications that serve the same purpose...
Peter
Please note: I do not have any affiliation with Prusa Research. Any advices given are offered in good faith. It is your responsibility to ensure that by following my advice you do not suffer or cause injury, damage…
RE: USB printing gone (!!!)
Is flashing the firmware still available within Slic3r? I only ask this because there are other applications that serve the same purpose...
Yes. But shhh, lest it gets removed, too. 😉
RE: USB printing gone (!!!)
Is flashing the firmware still available within Slic3r? I only ask this because there are other applications that serve the same purpose...
Yes. But shhh, lest it gets removed, too. 😉
I have a feeling that I should probably have asked:
"Is Slic3r still available as there are other applications that serve the same purpose?"
Peter
Please note: I do not have any affiliation with Prusa Research. Any advices given are offered in good faith. It is your responsibility to ensure that by following my advice you do not suffer or cause injury, damage…
RE: USB printing gone (!!!)
I just got word from tech support that they're going to put USB printing back into the release versions. They removed stuff only for the testing.
To be honest I have to say that if its byte-byte-byte access to the SDcard and no buffering then the USB connection would have to be less problematic for the main CPU than the SD card. Simply because the USB is handled by a discrete second CPU (Atmega8u2), which has balls loads of FIFO and then only appears to the main CPU as a serial connection, which, by nature, is buffered because its asynchronous.
SPI is host-initiated communications so an output goes out, for every byte that comes in. That means the CPU can't be assured a new instruction will arrive unless it has time to request it. Dangerous. But serial is interrupt triggered on the USART and not even handled by the main cpu. So an instruction will always be there.
RE: USB printing gone (!!!)
Apparently they're rewriting the whole thing from Perl to C++, mainly to speed things up and the Print module wasn't deemed worth the effort to rewrite. Perhaps if someone did that, it'd be accepted.
krikey didn't realize this. perl, though? really? to me perl always seemed like a 'hey i made you something' language. the kind of language where you go 'gee, thanks ... its ... made in perl'.
RE: USB printing gone (!!!)
To be honest I have to say that if its byte-byte-byte access to the SDcard and no buffering then the USB connection would have to be less problematic for the main CPU than the SD card. Simply because the USB is handled by a discrete second CPU (Atmega8u2), which has balls loads of FIFO and then only appears to the main CPU as a serial connection, which, by nature, is buffered because its asynchronous.
SPI is host-initiated communications so an output goes out, for every byte that comes in. That means the CPU can't be assured a new instruction will arrive unless it has time to request it. Dangerous. But serial is interrupt triggered on the USART and not even handled by the main cpu. So an instruction will always be there.
The synchronous/asynchronous part doesn't make much difference, both SPI and USART are very similar from the main ATMega's point of view. Via USART, the CPU has first to send bytes to confirm it can receive the next command, via SPI it has to ask the SD for the right bytes. In both cases the CPU gets an interrupt when the data is available in the 1 byte buffer. In terms of CPU load, probably the same. The disadvantage of USB/USART is that the CPU has to act quickly to read the byte from the buffer, because the next one is coming right after, sent by the 8U2. On SPI it can delay the next transaction if it feels so. On the other hand, on the SD it has to interpret the FAT filesystem and do a bit more SD protocol handling.
I wouldn't declare a winner here. In any case, this all is well within the ATMega2560's ability, as long as the data rate is limited by the comparably slow speed of printing anyway.
RE: USB printing gone (!!!)
krikey didn't realize this. perl, though? really? to me perl always seemed like a 'hey i made you something' language. the kind of language where you go 'gee, thanks ... its ... made in perl'.
Perl is the world's #1 write-only language. 🙂
RE: USB printing gone (!!!)
To be honest I have to say that if its byte-byte-byte access to the SDcard and no buffering then the USB connection would have to be less problematic for the main CPU than the SD card. Simply because the USB is handled by a discrete second CPU (Atmega8u2), which has balls loads of FIFO and then only appears to the main CPU as a serial connection, which, by nature, is buffered because its asynchronous.
SPI is host-initiated communications so an output goes out, for every byte that comes in. That means the CPU can't be assured a new instruction will arrive unless it has time to request it. Dangerous. But serial is interrupt triggered on the USART and not even handled by the main cpu. So an instruction will always be there.
The synchronous/asynchronous part doesn't make much difference, both SPI and USART are very similar from the main ATMega's point of view. Via USART, the CPU has first to send bytes to confirm it can receive the next command, via SPI it has to ask the SD for the right bytes. In both cases the CPU gets an interrupt when the data is available in the 1 byte buffer. In terms of CPU load, probably the same. The disadvantage of USB/USART is that the CPU has to act quickly to read the byte from the buffer, because the next one is coming right after, sent by the 8U2. On SPI it can delay the next transaction if it feels so. On the other hand, on the SD it has to interpret the FAT filesystem and do a bit more SD protocol handling.
I wouldn't declare a winner here. In any case, this all is well within the ATMega2560's ability, as long as the data rate is limited by the comparably slow speed of printing anyway.
haha touche~ yeah you raise valid points. i bow to your wisdom.
RE: USB printing gone (!!!)
I haven't looked at the code, but a common thing that happens is everyone codes as if the other end handles the buffering and handshaking: the result is unstoppable data bursts, buffer overflows, collisions, etc. Not so much bandwidth, but coders saying "Not my problem if it breaks" ...
AKA: no interface design spec.
RE: USB printing gone (!!!)
Funny how this seems to be an issue with 3D printers but not with CNC machines that are running one of many different CAM packages on Windows machines and not having issues with interrupts at all. This is being done over Parallel, Serial (USB mainly), and Ethernet controls with a wide range of cards using traditional g-code. There should be a way of insuring that windows also respects the priority of the 3D printers code running over doing a restart. I have run CNC g-code that took over 24 hours to do the full cutting (large panel with a lot of detail in a material that limited cutting speeds do to a tendency to shear). I have run my printers twice on very long prints (over 35 hours) and had no issue with either SD card nor going from USB control. It will be interesting to see how the USB control does function IF they choose to bring it back or IF a member of the community decides to write code to support the firmware and bring back USB control (Would Ethernet as that makes setting up multiple machines so easy).
RE: USB printing gone (!!!)
Ladies & gentlemen, may I introduce Software Flow Control
https://en.wikipedia.org/wiki/Software_flow_control
I too find it remarkable that this is even a problem. I hear the biggest issue is MS Windows being a dick and shutting down & stuff. But to be honest that isn't a reason to take a feature a way. Its a reason to try & fix it. Say do what youtube can do & set the flag to 'disable sleep'.
Or simply program some code so the printer doesn't care if the connection is dropped & reopened.
Not being able to have a computer sit there connected to your machine & have it do work is a complete mind to me, especially considering how its been 2+ decades that computers have been controlling machines in factories.
RE: USB printing gone (!!!)
Actually, the way Marlin works is it sends back 'ok' to the host when it's able to receive another line of gcode data. Which handles the flow control problem rather nicely. It still needs to be able to receive the individual characters of the line at full speed of the serial interface, though, which may be challenging for the ATMega CPU if a high bitrate is selected.
USB is a higher level packet-based protocol and handles flow control transparently (the device can simply NAK a request and the host will keep trying until the device is ready).
There is no need for XON/XOFF and I hope they can rest in peace. 🙂
RE: USB printing gone (!!!)
but i love XON/XOFF
didn't know that the printer sent 'gimme more' packets. makes sense to me since its the one doing all the hard work. i wonder how well gcode compresses. be a pain in the bum to keep the dictionary in memory but i bet it compresses good.
my mk3 printer wont actually connect at anything other than 250,000baud.