Prusaslicer: No Serial/USB facility

[RosieTheRabbit]

Version

_Version of Slic3r Prusa Edition used goes here_
_Use About->About Slic3r for release versions_
_For -dev versions, use git describe --tag or get the hash value for the version you downloaded
or git rev-parse HEAD_

Slic3rPE-1.42.0-beta+win64-full-201903171406

Operating system type + version -

_What OS are you using, and state any version #s_
_In case of 3D rendering issues, please attach the content of menu Help -> System Info dialog_

Windows 10 Home edition

3D printer brand / version + firmware version (if known) -

_What 3D printer brand / version are you printing on, is it a stock model or did you modify the printer, what firmware is running on your printer, version of the firmware #s_

Prusa I3Mk2.5s

Behavior

• _Describe the problem_
• _Steps needed to reproduce the problem_
  
  
  
  • _If this is a command-line slicing issue, include the options used_
  
  
• _Expected Results_
• _Actual Results_
  
  
  
  • _Screenshots from __Slic3r__ preview are preferred_
  
  

In previous versions there was an option to set up the virtual Serial Comm port to allow connection from PC to Printer via USB cable. In the Configuration/Preferences menu there used to be an option to disable / enable the serial port. In the Printer Settings menu there was an option to select a Serial port and speed and do a test connection to the printer.

Neither of these two options are available.

Image one - screenshot of Serial Port enable/disable option

Image two - same menu in most recent version showing the Serial Port option missing

Image three - shows the selection of the Serial Port, speed and test button

Image four - shows that option of selecting Serial Port is not available now

_Is this a new feature request?_

No - it is a request to reinstate a very useful feature that has been left out of latest version

Project File (.3MF) where problem occurs

_Upload a Slic3r PE Project File (.3MF) (Plater -> Export plate as 3MF for Slic3r PE 1.41.2 and older, File -> Save / Save Project for Slic3r PE 1.42.0-alpha and newer)_

Problem occurs all the time

By the way - thanks for a fantastic piece of software.

[HuguesDug]

Same problem for my version.

It is really a missing capability of last release 1.42.0-beta + win64

[RosieTheRabbit]

Prusa commented that the USB/Serial connectivity to the printer has been removed from latest versions of Slic3r. I don't really understand why but it is what it is. For Firmware upgrades, the part of Slic3r that does that is still able to connect via USB/Serial so upgrading to a newer firmware won't be a problem.

There are other options but to be honest I am just putting the GCode onto an SD card on my PC and the putting that in the printer. There is a benefit to doing printing this way. If the PC decides to restart, like it did after installing windows updates recently, in the middle of a print job then the file on the SD is unaffected. If I'd had the PC controlling the printer there would have been loud and extreme expletives coming from my workshop after over 20 hours of printing was wasted. Lucky for me I was already using the SD card method.

An alternative is CURA. On the PRUSA site there is a link to the configuration files for Cura for the various things like material, bed size and so on. Seems to work OK and you can use the USB/Serial link to control the printer.

I think if Prusa receive enough requests to reinstate USB/Serial capability they might reconsider - who knows ?

[uniacke1]

I'd like to request it be reinstated as well - I found it very useful for quickly iterating over various print settings (calibration prints, for example) as opposed to doing the SD card shuffle. Sure, it may not be ideal for lengthy prints but I think the legitimate use case of successive short prints is a valid one.

[supermerill]

You can install octoprint as a middle-man between slic3rPE and the printer. "send to printer" will send it to octoprint and it can start the print directly. You need to install an other software, but it's much more powerful and versatile.

[nate98252]

The usb/serial feature was very handy don't remove it. forcing people to do things a certain way is kind of messed up.....give your users options instead of taking them away

[vojtechkral]

forcing people to do things a certain way is kind of messed up.....give your users options instead of taking them away

The USB serial feature was kind of messed up too. It wasn't removed in a bad faith to force users to do something, it was removed because we figured we don't have the cycles to fix / polish / finalize / maintain it, and so it was removed rather than keeping an unreliable functionality.

[frakman1]

it was removed rather than keeping an unreliable functionality.

That's interesting. I didn't know it was unreliable. It has worked almost perfectly for me. If it ever failed to start a print for whatever reason, I just hit Disconnect, and Connect and it worked fine. That is a lot less hassle than shuffling SD cards around and selecting the file from the menu every time I made a small change and wanted to try again.

I'm sure you weren't acting in bad faith either. Still, it's very disappointing to have a very convenient and crucial (albeit slightly flawed and imperfect) feature go away so suddenly and completely like this. I hope you will reconsider and re-instate USB printing in the future.

[davidelang]

On Fri, 17 May 2019, Frak wrote:

I'm sure you weren't acting in bad faith either. Still, it's very
disappointing to have a very convenient and crucial (albeit slightly flawed
and imperfect) feature go away so suddenly and completely like this. I hope
you will reconsider and re-instate USB printing in the future.

The good thing about having the project in git is that it's very easy to pull
back in code that was removed, so if anyone is willing to do the needed
development, they can pick it up fairly easily.

I'm new here, what were the problems that people were having that got it marked
as unreliable?

David Lang

[HuguesDug]

Via USB, I had sometime the necessity to go to the touch pannel of the printer and to do a "confirmation" thing for the print to start... but otherwise, never had any kind of problem in USB.

Still, seeing this option was gone, I installed Octoprint. It took me a week-end and 50 euros to do so... I would have like to avoid this spending, although Octoprint is top.

[TimBloom]

The card-shuffle is unacceptable in my situation. I won't be using this PrusaSlicer until it's reimplemented. I have had no problem with it from Mac until now.

[pepelevamp]

oh my god this is driving me insane. they have removed this feature for the most ridiculous of reasons. it is NOT ok to make using sd-cards the norm. how are you going to make 3d printing common-place if they insist on this weird sd-card thing?

gcode? exporting? what the hell is that? we don't need to know these things. by removing usb printing you've made it necessarily for people to do technical things. and given them lots of extra steps.

it is an extremely unwise decision to remove USB printing. and why? because it was effort to maintain? it worked fine before.

[RosieTheRabbit]

I have been using the usb connection since I first got my printer, years ago. Never once had a problem transferring models direct from slic3r. Faffing around with SD card is a total nightmare. The thing is that the slic3r still has usb capability cos the firmware updates have to be done that way.

Senseless drop of a useful feature.

On 24 May 2019, at 18:01, pepelevamp [e-mail] wrote:

oh my god this is driving me insane. they have removed this feature for the most ridiculous of reasons. it is NOT ok to make using sd-cards the norm. how are you going to make 3d printing common-place if they insist on this weird sd-card thing?

gcode? exporting? what the hell is that? we don't need to know these things. by removing usb printing you've made it necessarily for people to do technical things. and given them lots of extra steps.

it is an extremely unwise decision to remove USB printing. and why? because it was effort to maintain? it worked fine before.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[StephenRC]

I haven't used USB since I bought a Duet. :)

On Fri, 24 May 2019 10:01:47 -0700, pepelevamp
[e-mail] had a flock of green cheek conures squawk
out:

oh my god this is driving me insane. they have removed this feature for the most ridiculous of reasons. it is NOT ok to make using sd-cards the norm. how are you going to make 3d printing common-place if they insist on this weird sd-card thing?

gcode? exporting? what the hell is that? we don't need to know these things. by removing usb printing you've made it necessarily for people to do technical things. and given them lots of extra steps.

it is an extremely unwise decision to remove USB printing. and why? because it was effort to maintain? it worked fine before.

[vojtechkral]

From technical standpoint, I don't think the USB Sender GUI was ever re-written from Perl. There are also some problems in the C++ part, it doesn't build against new versions of Boost, for instance. I also remember there being some realiability problems, either during in-house testing or maybe even reported, I don't remember which one.

TL;DR to include the Sender in the current or next release, it would need to be refactored one way or another. No one has had the cycles to do that. Sorry.

[haarp]

Due to the removal in Slic3r/Prusaslicer, I ended up writing a small G-code streamer for Linux in Python. It shouldn't be too hard to adapt for Windows either. It does exactly the same, but being independent from the slicer means you don't lose a print when your slicer crashes yet again. And it shows you the current line in the G-code file it's at, so you can restart it with the next line in case you accidently unplug the USB cable or something (untested)

Find it here: https://gist.github.com/haarp/79d957f5be7e2de437dc41dd1b38eace

[frakman1]

@haarp That's an awesome python utility. Thank you for sharing. I had no idea it was so straightforward to write to the printer like that.

So you mean if I know what line I was at, I can start from there and it will continue where I left off? I've lost so many prints midway due to filament change errors that never fully recovered and ended up resetting the printer.

I can't wait to try this at home on Windows. If I get it to work , I'll post an update.

[haarp]

So you mean if I know what line I was at, I can start from there and it will continue where I left off?

Yes, exactly. My script will also continuously print the line number so you know where you stopped.

But I just remembered that the printer resets when you first open the serial port, and I haven't figured out a way to prevent that. So unfortunately you can't continue prints as-is, since the printer needs the setup g-codes again, or at the very least the temperatures.

[vojtechkral]

But I just remembered that the printer resets when you first open the serial port, and I haven't figured out a way to prevent that.

You can't prevent that, sorry. The printers are hard-wired to reset on serial connection. The purpose of that is to ensure that the printer is in a well-defined state upon serial connection.

[frakman1]

Even after a reset of the printer, can we just do an initial setup (set temperature but skip the bed leveling) then continue with the print?

[haarp]

I've updated the script to try to avoid the reset if a print is to be resumed. I've also moved it to it's own repo to avoid spamming the PrusaSlicer issue tracker with this topic. It can be found here: https://github.com/haarp/gcode-streamer

[BorisKozo]

I am just starting with my MK3S and I can't believe I can't print directly from the PC. My other printer CEL ROBOX has this option and I worked with it all the time.

[owebeeone]

I just got my MK3 and I am very disappointed this is missing. I was using an someone else's printers and it was working perfectly with this and now I have this funky thing with sneakernet and sdcards. No loving it.

[pepelevamp]

well-said. me too. me freaking too.
it really, really cheeses me off.

On Sat, 25 May 2019 at 05:28, RosieTheRabbit [e-mail]
wrote:

I have been using the usb connection since I first got my printer, years
ago. Never once had a problem transferring models direct from slic3r.
Faffing around with SD card is a total nightmare. The thing is that the
slic3r still has usb capability cos the firmware updates have to be done
that way.

Senseless drop of a useful feature.

On 24 May 2019, at 18:01, pepelevamp [e-mail] wrote:

oh my god this is driving me insane. they have removed this feature for
the most ridiculous of reasons. it is NOT ok to make using sd-cards the
norm. how are you going to make 3d printing common-place if they insist on
this weird sd-card thing?

gcode? exporting? what the hell is that? we don't need to know these
things. by removing usb printing you've made it necessarily for people to
do technical things. and given them lots of extra steps.

it is an extremely unwise decision to remove USB printing. and why?
because it was effort to maintain? it worked fine before.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/PrusaSlicer/issues/2046?email_source=notifications&email_token=AAJ3Q23N5TSOPOTBR55BEALPXAQUBA5CNFSM4HCISPD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWGBTIY#issuecomment-495720867,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJ3Q2Y6K2JFFTHQV5I6KPLPXAQUBANCNFSM4HCISPDQ
.

[dietzm]

I send gcode files through dropbox, google drive or direct network connection to a cheap Android tablet which is connected through USB to the MK3S. Then using the GCodePrintr App to print works reliably.

[Gallion]

This is incredibly annoying. I hadn't used my printer in a while. Right now I can't print because I have nothing to read/write an SD card with and those crappy little SD to USB readers just keep breaking.

[BorisKozo]

I started using Pronterface that comes with the Prusa Slicer and its ok.
The annoying thing is that it is live so you cant turn off the computer while it prints but it does solve the problem

[supermerill]

The annoying thing is that it is live so you cant turn off the computer while it prints

so as the USB Sender, no?

[BorisKozo]

The annoying thing is that it is live so you cant turn off the computer while it prints

so as the USB Sender, no?

Before Prusa I had CEL Robox and when you print something on it via USB, the g-code is transmitted to the printer internal memory and you can turn off the computer. The only thing Prusa needed to do is to have an option to write to the SD card directly over the USB connection then all this fuss would be avoided.

[vintagepc]

Technically Marlin has that capability but from what I recall because you're writing to the SD over SPI it's incredibly slow and not really practical. (as in minutes for even a small file).

[pepelevamp]

Before Prusa I had CEL Robox and when you print something on it via USB, the g-code is transmitted to the printer internal memory and you can turn off the computer. The only thing Prusa needed to do is to have an option to write to the SD card directly over the USB connection then all this fuss would be avoided.

this. this is exactly what i said too. people say that its slow - well, ok let it be slow. the prints take hours to finish. send the first 100kb of gcode before the print starts, and then read in & save the sd-card as the print is going.

i hear the microcontroller has no DMA which kind of sucks. you know what could have solved this problem? an 8mb memory buffer. buying a second computer (raspi) and connecting it to the bus of the printer is no safer than an x86 linux machine talking to it over USB.

we want 3d printing to be normal and easy. this means no floppy disks and removing bullshit like 'export' steps.

[flxs]

Quite disappointed this is missing. I don't really see how transferring files using a USB key or SD card is supposed to be a viable alternative for quickly iterating on small parts (like, just the hinge part of a larger model) – am I supposed to perform this ballet every 20 minutes, for hours on end if need be? I don't really believe I'm the only person with that sort of workflow.
I've never had any issues with USB printing over what must be thousands of prints with other printers and software. Being able to quickly eyeball whether what's on the build plate on the other side of the room roughly matches the live preview on screen has saved me a couple of times.

[vintagepc]

TBH now that the latest build supports uploading directly to FlashAir cards, I miss this feature a lot less. I can basically one-click iterations of any slice over to the printer without doing the SD card shuffle.

[scotfor]

Seems absurd to remove USB given that it is a mature technology.
I am learning 3d printing with a friends Lulzbot (using USB cable with no problems) and was going to buy an MK3.
I am just now testing the prusa slicer and discovered this USB problem. It is enough of an issue for me that I may not get the MK3.

[BorisKozo]

I use Pronterface which comes bundled with PrusaSlicer and it works ok.
Still weird to see this feature gone from the main app

[frakman1]

Yes, I use Pronterface. It's an extra step but at least I don't have to move files around or use an SD card.
I actually like Pronterface because it lets me manually control the printer which I often need to do.

[majodi]

What? Wait a minute, is this true that the Prusa slicer can not print?? So, to print I have to save the file to a memory stick, walk to the printer stick it in, choose the file again? For every iteration? What is this? For years I used Cura and just click print. Now that I got my Prusa mini of course I immediately downloaded the Prusa slicer but can not find a print button. I looked at this Prontoface pyton thing but it will not run on a Mac (we only have Macs here). So when will Prusa add this most basic functionality of sending the bytes to the printer directly? And what do I do in the mean time? Use Cura? I was hoping for close integration (I read somewhere that the Prusa slicer will produce specialized gcode).

[frakman1]

There is a Pronterface for Mac. I am running it on my High Sierrea MBP.
Direct link here
Project page here

[majodi]

There is a Pronterface for Mac. I am running it on my High Sierrea MBP.

High Sierra? That was 2017..., of course I updated many times since then. Also I don't know about a Python script thingy with dependencies etc. I think I have a look at Repetier Server (I use that to print gcode to my CNC machine also). But very disappointing to find out that the official Prusa software can not even print to their own printers in 2020.

[frakman1]

Also I don't know about a Python script thingy with dependencies

It's an app. You don't have to worry about any dependencies. You just open it like any other app.

[frakman1]

For 64 bit only MacOS like Catalina and above, you'll need this version:

[majodi]

For 64 bit only MacOS linke Catalina and above, you'll need this version:

Okay, Printrun and Repetier Server both work. I will have to find out which one I prefer. Repetier is just using a daemon, the UI is through a browser which has the advantage that it (the UI) can run on any machine on the (same) network, even a phone. Both need tweaking for the correct bed settings (I think the home position for the Mini is 176/24). I hope Prusa will have a decent solution soon (preferable printing directly from the slicer to the printer connected by UTP, wifi or USB).

[flxs]

Another option to get a somewhat similar experience would be to use Octoprint; that requires a Raspberry Pi, but you can set an Octoprint URL in PrusaSlicer and then it'll give you another button next to "Export GCode" that will send the print directly to Octoprint and optionally start it right away. It's not controlling the printer directly, Octoprint does that, but it takes care of the SD/USB key part very well.

I think Prusa said at some point they want to put something like Octoprint on the Mini, so that may be the general direction they're moving. I've been using it like this for quite a while now, and it's been a very nice experience (though if you have different needs YMMV.)

[majodi]

Yep, after working with Repetier Server for some time now I'm fine with the setup. I have a dedicated old notebook attached to the Mini and on my design desk computer I have the UI of Repetier open and also (remote) webcam of the notebook. So now I can design and slice, then upload and print plus watch the printer from one place. This works for me now but I can see Octoprint also as a good solution.
Maybe Prusa could make a deal with Repetier or Octoprint to bundle it as a complete solution. Anyway, I guess my expectations were a bit too high. But on the positive side I can see Prusa growing in this area.

[pepelevamp]

all prusa has to do is reinstate the USB printing facility and then say
'the problems with USB printing are not because of us' and then leave it at
that. Because not everybody has problems with USB. If there are any
problems with USB its because of the silly implementations.

If somebody's USB port plays up during a print - then that is nothing to do
with prusa-slicer. this whole thing is a terrible miscalculation and
reinforced an awful norm of 'sd cards'.

Its not OK to make it seem normal to use yet another system to 3D print
like octoprint or repetier. A desktop laserjet printer has no problem
taking in megabytes at a time & then printing. The whole situation is a
cop-out.

On Mon, 20 Jul 2020 at 03:03, Majodi Ploegmakers [e-mail]
wrote:

Yep, after working with Repetier Server for some time now I'm fine with
the setup. I have a dedicated old notebook attached to the Mini and on my
design desk computer I have the UI of Repetier open and also (remote)
webcam of the notebook. So now I can design and slice, then upload and
print plus watch the printer from one place. This works for me now but I
can see Octoprint also as a good solution.
Maybe Prusa could make a deal with Repetier or Octoprint to bundle it as a
complete solution. Anyway, I guess my expectations were a bit too high. But
on the positive side I can see Prusa growing in this area.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/PrusaSlicer/issues/2046#issuecomment-660659141,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ3Q2Y56CEQSYOPHYABVHLR4MDM3ANCNFSM4HCISPDQ
.

[pepelevamp]

furthermore why should you use an entire complete linux operating system on
a raspi just to send gcode to a printer, when you can use a USB cable with
a complete linux OS (say my workstation) to send gcode to the printer?
the decision to remove USB printing can be proven-stupid in 101 different
ways.

On Tue, 21 Jul 2020 at 06:00, Pepe le Vamp [e-mail] wrote:

all prusa has to do is reinstate the USB printing facility and then say
'the problems with USB printing are not because of us' and then leave it at
that. Because not everybody has problems with USB. If there are any
problems with USB its because of the silly implementations.

If somebody's USB port plays up during a print - then that is nothing to
do with prusa-slicer. this whole thing is a terrible miscalculation and
reinforced an awful norm of 'sd cards'.

Its not OK to make it seem normal to use yet another system to 3D print
like octoprint or repetier. A desktop laserjet printer has no problem
taking in megabytes at a time & then printing. The whole situation is a
cop-out.

On Mon, 20 Jul 2020 at 03:03, Majodi Ploegmakers [e-mail]
wrote:

Yep, after working with Repetier Server for some time now I'm fine with
the setup. I have a dedicated old notebook attached to the Mini and on my
design desk computer I have the UI of Repetier open and also (remote)
webcam of the notebook. So now I can design and slice, then upload and
print plus watch the printer from one place. This works for me now but I
can see Octoprint also as a good solution.
Maybe Prusa could make a deal with Repetier or Octoprint to bundle it as
a complete solution. Anyway, I guess my expectations were a bit too high.
But on the positive side I can see Prusa growing in this area.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/PrusaSlicer/issues/2046#issuecomment-660659141,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ3Q2Y56CEQSYOPHYABVHLR4MDM3ANCNFSM4HCISPDQ
.

[flxs]

It seems Simplify3D recently added a profile for the Prusa Mini, so that would be another alternative for those with a license. They support all the other Prusas as well as far as I can see. I've been using it for years and while the UX could use some polishing, it's incredibly capable and the support generation might be reason enough to give it a try with my Mini. I wonder if I can get Simplify3D to run on a Raspi 4...

Besides, I've checked again, in their last firmware update notification for the Mini Prusa specifically mention:

We have enabled the first section of Prusa Connect Local. By connecting your MINI to a local area network, you can use your web browser to monitor the status of the ongoing print job. Prusa Connect Local will evolve over time to give you complete control over your networked 3D printers, and it will become a full-fledged print farm software.

So at least for the Mini, the need for a separate Octoprint/Repetier Server machine seems to be going away. Yay for network 3D printing out of the box?

[pepelevamp]

looks great for the newer printers that have internet capability. problem
is - ya shouldn't need to have these things on the network. operating
systems today are garbage and putting these things on the network is just
asking for trouble unless you can secure the whole environment they sit in.

its just one more IoT bullshit device talking over the network when it
doesn't need to. prusa forget about their old printers & they will forget
about the prusa minis too in time. they will just forget and you're left
with some out of date untrustable device that needs the internet or a raspi
to function. theres no longevity there. all thats needed is a COM port over
USB. even if you had 3 printers, im sure you got more than 3 usb ports.

this is all just wankery & not really a solution to the problem that they
artificially created by removing USB support.

On Tue, 21 Jul 2020 at 09:36, flxs [e-mail] wrote:

It seems Simplify3D recently added a profile for the Prusa Mini, so that
would be another alternative for those with a license and a Mini. They
support all the other Prusas as well as far as I can see.

I've checked again, in their last firmware update notification for the
Mini they specifically mention:

We have enabled the first section of Prusa Connect Local. By connecting
your MINI to a local area network, you can use your web browser to monitor
the status of the ongoing print job. Prusa Connect Local will evolve over
time to give you complete control over your networked 3D printers, and it
will become a full-fledged print farm software.

So at least for the Mini, the need for a separate Octoprint/Repetier
Server machine seems to be going away. Yay for network 3D printing out of
the box?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/PrusaSlicer/issues/2046#issuecomment-661346400,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ3Q22QBAGQFA3C2J4CGMLR4S2HBANCNFSM4HCISPDQ
.

[vojtechkral]

@pepelevamp What with the amount of rudeness in your comments I really am not keen on writing an elaborate reply, so I'll just state for the record that the USB facility wasn't arbitrarily removed, it was just never ported over from the old perl-based implenetation, because no one had the cycles to do decisions on it, refactor the implementation (which would've been inevitable), re-create the GUI, test the thing, maintain it... There wasn't manpower to do it, it's as simple as that...

[pepelevamp]

@pepelevamp What with the amount of rudeness in your comments I really am not keen on writing an elaborate reply, so I'll just state for the record that the USB facility wasn't arbitrarily removed, it was just never ported over from the old perl-based implenetation, because no one had the cycles to do decisions on it, refactor the implementation (which would've been inevitable), re-create the GUI, test the thing, maintain it... There wasn't manpower to do it, it's as simple as that...

for starters being 'rude' and actually describing something thats awful arent the same thing. second of all 'not porting it over' is the same as removing it from the software, if they port over everything else.

and their 'no good reasons for it' is whats on the table and being critiqued here. and saying there's nobody there to do manpower, testing etc is a non-starter. that applies to everything the software does and makes it just as relevant as any other feature from the manpower standpoint.

the bottom line is its a poor decision to remove USB printing support. alternatives to it such as sdcards, or network-printing via an entire new computer clipped into the mainboard - are simply ridiculous & overkill.

if you have a computer online 24/7 next to a 3d printer, which is hardly strange - then USB is realistic. its certainly a lot better than sdcards. if you're concerned about longevity of the USB port than that is a windows problem or what not & you can use an alternative.

[vojtechkral]

and saying there's nobody there to do manpower, testing etc is a non-starter. that applies to everything the software does and makes it just as relevant as any other feature from the manpower standpoint.

There's X features, each of which is considered critical by Y people, and then there's Z devs to implement & maintain them, who also have some opinions on the feature set. Your favourite feature
would've been implemented if Z and/or Y were higher, but that wasn't the case, so it wasn't. I'm not sure what exactly you're hoping to accomplish here, attitude the devs into implementing it? You don't need the device connected to internet, just local network is fine, or you could even install octoprint directly on your PC. If you say it's up 24/7, that pretty much makes it a server anyway...

[pepelevamp]

nobody's giving attitude except the critique from you of things i didn't
actually say. no, having a computer on 24/7 next to a 3d printer is not
like 'a server anyway'. you don't have to explain the rationale of having X
number of features versus workload, as if it wasn't understood. simply
refer to the topic at hand instead of critiquing others.

stay on-topic. don't argue against points nobody made. if youre saying "
I'm not sure what exactly you're hoping to accomplish here" then seek
clarification. you're trying to clarify things nobody expressed a
difficulty understanding, labelling others with an 'attitude'. so again -
stay on topic.

so going back to the actual topic at hand:
porting everything to the new codebase except USB printing is a conscious
decision. it is a poor decision to make, and there are several reasons why.
people dislike it, and we would like it implemented. .

which is why this ticket was created and exists.

here are reasons 1, 2 and 3. discuss.

On Wed, 29 Jul 2020 at 22:28, Vojtech Kral [e-mail] wrote:

and saying there's nobody there to do manpower, testing etc is a
non-starter. that applies to everything the software does and makes it just
as relevant as any other feature from the manpower standpoint.

There's X features, each of which is considered critical by Y people, and
then there's Z devs to implement & maintain them, who also have some
opinions on the feature set. Your favourite feature
would've been implemented if Z and/or Y were higher, but that wasn't the
case, so it wasn't. I'm not sure what exactly you're hoping to accomplish
here, attitude the devs into implementing it? You don't need the device
connected to internet, just local network is fine, or you could even
install octoprint directly on your PC. If you say it's up 24/7, that pretty
much makes it a server anyway...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/PrusaSlicer/issues/2046#issuecomment-665582317,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ3Q2ZRKGOE6VLARL4D4GDR572V7ANCNFSM4HCISPDQ
.

[neophyl]

What is the functional difference between printing from Prusa Slicer running on a PC connected to the printer via USB and the same pc running both Prusa Slicer and Octoprint connected to the printer via USB ? Or Prusa Slicer and Repetier Server.

Both still require the PC to be on and consuming power for the duration of the print, both still require an uninterrupted serial connection (ie no windows updates or power saving etc).

The only difference is running 2 bits of software which is hardly a hardship as every PC/MAC/Linux box I know routinely runs 70+ processes anyway.

As the software is open source you could always implement the USB printing again and then make a pull request to get it merged into the code again.
The situation as it is, is not the end of the world and people have suggested multiple workflow alternatives. Use them or don't, its your decision.

You don't like a decision, we get it. You think its bad, we get it. There have been other things Prusa has done that I disagreed with in the past. The thing is it is not your decision to make and the ones I didn't like it was not my call to make either.
You make your point and then you have to let it go. If you don't then you run the risk of sounding like a whiny b**ch.

[pepelevamp]

You make your point and then you have to let it go. If you don't then you run the risk of sounding like a whiny b**ch.

This is completely inappropriate. This section is for discussing the pros and cons of the ticket. It isn't for you to argue about people. We're talking about a _thing_. Things and ideas can be stupid. You're just gonna get flagged by moderators.

The only difference is running 2 bits of software which is hardly a hardship as every PC/MAC/Linux box I know routinely runs 70+ processes anyway.

This is a valid argument, but its not the end of the discussion. Its additional workflow, and its not wrong to disagree with you on this. Currently in old versions of slic3r prusa edition you can simply print and use the same program. No extra software is needed. No second computer is needed. Reducing things the user has to do to make prints is an improvement.

As the software is open source you could always implement the USB printing again and then make a pull request to get it merged into the code again.

Or we can open up a feature request and provide a convincing argument, finer refining and eliminating arguments against or for it. Do that.

You make your point and then you have to let it go.

Nope. Thats not what this is. Rebuttle and refinement of details & clarification of argument is valid. Calling people names & attacking their character is not. Stay on-topic. You have not put the cap on the end of the discussion. Thats not your role.

[neophyl]

If you actually read what I wrote instead of putting your own spin on it I did not accuse you of being anything. I said you run the risk of appearing that way. I am sorry if my opinion offends you. Please accept my apology.

I also did not say the issue should be closed, I expressed my opinion that as there are other possibilities then this is not a high priority, once again in my opinion. The problem with these issue forums is that only those who want something changed tend to post. You will see multiple posts saying yeah change this. That's ok but those who don't see the need rarely ever post, why should they ? its not a problem for them. That leads to the disproportionate look that everyone thinks there should be a change made when in reality its a fraction of the user base.

Its my understanding that the previous software versions implemented a background 'print server' anyway and that the main Slicer software could still be used to slice other projects while that other process was spooling out the data over USB. Once again I ask what is the functional difference to running Repetier or Octoprint now ? If someone could come up with something that is massively convincing why then that might sway the resource vs issue decision. So far I haven't seen anything that would tip the balance if it WERE my decision, which as I pointed out before it is not.

You can argue and refine and counter propose all you like but at the end of the day the decision is not yours or mine, its Mr Prusa's. We can ask politely or we can rant and rage, but its not up to us. We have to either accept that or do something about it ourselves if we can not accept it. That is the nature of open source software.

With over 1500 open issues the available resources are going to be spread thin.

[pepelevamp]

I am sorry if my opinion offends you. Please accept my apology.

no problem. but dont worry, i have no feelings here. its all about the usb printing.

With over 1500 open issues the available resources are going to be spread thin.

Thats why we talk more in here and articulate the need. You said about having more than one program required on the computer not being a problem. I can outlay a few issues why its bad, and offer a few norms from elsewhere.

The root of the issue? USB serial throughput:

We've had laserjet printers for 20 years that can have a large file sent to them more or less straight away, and then work fine without the computer. Why we have a 115200baud connection is anybody's guess - but it isn't justification for further architectural norms. It was a mistake.

Are 3d printers different? No:
A laserjet needs to keep the entire image in its head, it needs to do processing, it takes time to work, and works without a computer. Just like a 3D printer. There is no justifiable difference.

Different software worse than prusaslicer handling printer control itself?:
With laserjet printers we have tried desperately to make it seamless. You can print right from Word. The objective was always to hide the printer-specific stuff. gcode? extra steps. print controller? extra steps. slicer software itself? eventually just extra steps.

Raspi on printer board?:

A bad architecture is putting a huge OS onto a printer in order for it to do basic stuff. You seen the things a modern brother printer supports just to print a document? It is insanity. This is why a raspi with Linux on your printer is not an entirely good approach. Its an absolute nightmare on a LAN and good luck having it exposed to the internet. Why? Because you rely on the vendor still caring to have security. Just like any shit house broadband modem or IoT device with malware. Exceopt this can cause a fire. Engineer it to the minimum. Never make a rube goldberg machine.

An honest approach to the core of the problem:

A true technical solution to the core of the technical limitation is a firmware update to pre-cache the gcode on the internal memory (sdcard), and/or pre-send much more data between each print layer (or whenever the serial coms is quiet). An 8mb file only takes like what 10 minutes to send? Something on that order. And thats big. That eliminates the risk of a down USB connection while its printing. You could have 10 minutes of no-USB to get ya computer back in shape. Thus its not enough to use 'dodgy USB' as justification for not using USB. Plus thats other vendor's issues, not prusa.

Even a crack-head brother printer still comes with USB support.

[neophyl]

Interesting points but I would like to point out that you are not actually printing from Word. Word is passing the file to the built in Windows print spooler and that is passing it on to the printer. You are relying on the operating system and the printer driver, so the situation is not dissimilar to what we have now, except we don't have a built in 3D printer spooler baked into the operating system (yet) and we don't have specific 3D printer drivers (thankfully)

You can send the gcode to the sdcard over USB at the moment on a Prusa MK3, there is no firmware update needed to do that. However it takes an absolute age and is not what I would call convenient which is why no one in their right mind does so. This is limited by the hardware of the MK3 as it uses an old 8 bit board with very limited capabilities, its not something that can be fixed by a firmware update. Its hardware. The 115k2 baud is a limitation of that hardware. You say its a mistake but its one that is set in stone and can't be changed without a time machine. I'm sure there were very valid reasons for using the hardware they did at the time.
A modern paper printer has a fair bit of memory that is specifically designed to receive the files quickly over USB and then go from there. That is the result of decades worth of improvements to both the hardware and software to get to the current level. Some 3D printers aren't there yet.

You can make the point that a lot of 3D printers are at that point already and that Prusa Slicer should support that. That would be a valid point and might be one that would increase the priority of this issue. If that is the direction the company wanted to go in then I think it would have already been given that higher priority though. Why should Prusa spend resources duplicating software that can already do the job when its not going to be used as part of their eco system ?

From what we have seen with the current Mini development the long term plan seems to have future Prusa printers on the network independently and for files and print controls to be sent over tcp/ip. So once again USB transfer not a high priority.
I'm not sure I like that idea either, as like you mention that puts the security of the network in the hands of the printers implementation being good and given what we see with almost every network implementation so far on almost all devices there's always some form of security hole found in the long term that needs patching. Not my call, though I guess if I really don't like it I can buy a printer from another vendor that has capabilities that match my personal needs. That will factor into my buying decisions on future printers.

You could say that decision is also a mistake. I'd hazard a guess though that the decision was also made in good faith and considering many factors we are not aware of relating to other things beyond purely technical considerations.

[vojtechkral]

@pepelevamp

nobody's giving attitude (...) here are reasons 1, 2 and 3. discuss.

Yeah, you open with stuff like _"What the hell, this is stupid and ridiculous for 101 reasons, it cheeses me off..."_ and now you demand a rational discussion... like that's gonna happen...

@neophyl

I'm not sure I like that idea either, as like you mention that puts the security of the network in the hands of the printers implementation being good and given what we see with almost every network implementation so far on almost all devices there's always some form of security hole found in the long term that needs patching.

That is a valid concern, OTOH, it's not like people's personal computers are super secure either. You should probably not expose the printer to the wide internet just like you don't expose your personal PC. Of course, the printer still potentially receives data from 3rd party sources, and so its parsing code etc. is of concern, that's true (OTOH, that's the case whether it's on the network or not).

[pepelevamp]

Yeah thats all fair.

Good point about the print spool. It was my understanding now that printers just get the whole thing in memory anyhoo now & print at their leisure. I think it might actually be required to figure out some of the printing parameters.

I agree that its all just in general much tidier in the long run to have TCP/IP enabled 3d printers that can work by themselves. Have you seen that printer firmware called Klipper which runs on the raspi? The on-board atmega simply becomes a motor-interface. They get huge performance gains from having the raspi actually be the brain of the 3D printer.

But I want those things to be all offline and not need an IP or a full linux OS to work. It invites problems. Even today I can shut down appliance printers by doing REISUB on supposedly nailed-down appliance computers. Linux kernel will have a denial of service one day and it will be long after these Prusa I3 MK3 printers are supported.

My true personal belief is that 3D printers should give up on being deterministic and should have much, much more smarts. Shifting some of the logic from the slicer into the printer. Mo sensors, mo real-time decisions, mo reliability. So that could almost go against my own arguments here, but its a different story for another planet I think.

[pepelevamp]

@vojtechkral

nobody's giving attitude (...) here are reasons 1, 2 and 3. discuss.

Yeah, you open with stuff like _"What the hell, this is stupid and ridiculous for 101 reasons, it cheeses me off..."_ and now you demand a rational discussion... like that's gonna happen...

Its not irrational to call something stupid, ridiculous and say it cheeses you off. Nor is it rude, off-topic or personally insulting to anybody. People are human beings, not robots. We get annoyed and its perfectly fine to call ideas, machines and approaches to technology stupid & ridiculous, as well as emphasize it with metaphor. So again - stop the personality critique. Its pointless and unfair to others who wish to apply a context to their argument, which as pointed out - is helpful in gauging how important a certain feature request is among the 1500 other open tickets.

[vojtechkral]

Nor is it rude

It is rude.