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.

[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 notifications@github.com 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.

[dreamalligator]

looking forward to usb capabilities to come back. would rather use prusa slicer than some other alternatives.

[OverWorldD]

I was very excited go try superslicer when I heard of it today, but the lack of direct USB printing is a deal breaker for me. I hope someone has time to re-implement it.

[pepelevamp]

What's super slicer? I've been out of the loop for ages, because I use USB printing & I havent upgraded since before it was removed.

On Wed, Oct 27, 2021, 4:00 PM OverWorldD @.***> wrote:

I was very excited go try superslicer when I heard of it today, but the lack of direct USB printing is a deal breaker for me. I hope someone has time to re-implement it.

— 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-952494374, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ3Q23XO7IU5TCX6P65WILUI52O3ANCNFSM4HCISPDQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[OverWorldD]

SuperSlicer is a fork of PrusaSlicer

[pepelevamp]

Cool! What's the motivation behind the fork? Did they add anti-aliasing to the graphics? Its so strange how people argued against including that. It's about as mindless as no USB printing

On Wed, Oct 27, 2021, 4:18 PM OverWorldD @.***> wrote:

SuperSlicer is a fork of PrusaSlicer

— 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-952502014, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ3Q272L5PBGG6VD4M47DDUI54SLANCNFSM4HCISPDQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[OverWorldD]

I have no idea, I just heard about it. I'll try it later today and see what gives. It seems they don't include a USB/serial function either but more places to request it! :)

[scotfor]

I posted May 4 2020 saying that I did not agree with dropping USB printing.

Since then I have changed my mind and now prefer printing from an SD card. Reasons?: 1) Removes Windows from the situation. No update based reboots mid-print, no messing with hibernation etc. settings for long prints

2) Printing on multiple printers at the same time.

[owebeeone]

For a while now I've been using octoprint. I can now push gcode directly from PrusaSlicer to octoprint. I have a camera pointing at my printer so (via octprint) I can see how the print is going. It also shows thumbnails of the models (that was tricky to get PS to get to work). I'm much happier with Octoprint than I'd ever be with the serial support in PS.

[pepelevamp]

If you run windows I can understand problems, but if you have a Linux machine right next to your printer, you don't need to put a whole new Linux machine on just to control it redundanly.

But the point isn't to argue why you don't want USB printing or the pros/cons. There is good workflows for some people which uses direct serial connection.

This thread shouldn't be derailed by that kind of discussion - its already concluded & USB printing removal was an unwise & very destructive decision.

On Wed, Oct 27, 2021, 4:47 PM scotfor @.***> wrote:

I posted May 4 2020 saying that I did not agree with dropping USB printing.

Since then I have changed my mind and now prefer printing from an SD card. Reasons?:

1.

Removes Windows from the situation. No update based reboots mid-print, no messing with hibernation etc. settings for long prints 2.

Printing on multiple printers at the same time.

— 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-952511797, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ3Q22OYB43SRL6CYEHTOLUI5Y33ANCNFSM4HCISPDQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[owebeeone]

I don't think it's clear that it was unwise to remove the functionality. I can understand that if the team wanted to concentrate their lmited efforts on slicer features, then the USB connectivity feature would be a distraction and inevitably decay over time. I think this is a case of the classic Peter Drucker "​Starve the Problems, Feed the Opportunities" principle. I was originally very dissapoitned there was no serial support but I can toally respect the descision especially when Octoprint is really quite awesome and it would be hard to imagine PS would ever be able to compete.

I don't think it was a destructive decision in the sense that keeping it may have been more destructive.

[pepelevamp]

Nah that argument really breaks down when you see that they have added any features.

Plus it's been like 2 years right? Its just a multitude of arguments like that which don't stack up. They've already covered this ground.

We don't really need to continue critiquing Yes or No by citing use cases that don't apply. Its not 2019.

Rather, let people who want USB printing to continue asking and let them have their needs considered legit instead of further repeating already-addressed and not-applicable reasons to avoid USB. If you do wish to convince people to not use USB, read old posts first.

On Wed, Oct 27, 2021, 6:05 PM owebeeone @.***> wrote:

I don't think it's clear that it was unwise to remove the functionality. I can understand that if the team wanted to concentrate their lmited efforts on slicer features, then the USB connectivity feature would be a distraction and inevitably decay over time. I think this is a case of the classic Peter Drucker "​Starve the Problems, Feed the Opportunities" principle. I was originally very dissapoitned there was no serial support but I can toally respect the descision especially when Octoprint is really quite awesome and it would be hard to imagine PS would ever be able to compete.

I don't think it was a destructive decision in the sense that keeping it may have been more destructive.

— 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-952541745, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ3Q2Z7373JKP3NBFTMQFLUI6CARANCNFSM4HCISPDQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[owebeeone]

Oh I did read it all a while ago. Then I read the post by vojtechkral and while I felt let down at first I had to respect the comment. I now definitly prefer Octoprint.

[OverWorldD]

I installed Octoprint in Windows, works well as a workaround. I have my Windows machine set to run "undisturbed" by updates (And I always run the win10 debloat script by Chris Titus: https://www.christitus.com/debloat-windows-10-2020/ to get rid of extra processes) and for longer prints I always print from SDCard. But USB printing is nice for smaller prints.

A lot of settings to get used to, but the Eiffel tower printed nicely.

[Infiltratr]

For me, this is really simple.

I have a print server that controls all my printers. I want it to control my Prusa as well. I should be able to plug my USB printer into my Server and print to it from anywhere.

This shouldn't be an issue this far down the Prusa lifecycle.

[deandv]

I too am in favor of reinstating direct-over-USB printing in PrusaSlicer. The SD card transfer dance is a hassle for small test prints. It also makes printing needlessly complex for beginners.

[owebeeone]

@deandv - Are you aware that PrusaSlicr can now send gcode directly to Octoprint and start printing immediately?

[dreamalligator]

Via usb? That's great news if so. 🎉

[pepelevamp]

Via USB???? :O explain

On Fri, Mar 11, 2022, 1:55 PM owebeeone @.***> wrote:

@deandv https://github.com/deandv - Are you aware that PrusaSlicr can now send gcode directly to Octoprint and start printing immediately?

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2046#issuecomment-1064664057, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ3Q27IIPZS6YI5QTH5TY3U7KKYRANCNFSM4HCISPDQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[owebeeone]

Via TCP/IP. If you set up IP over USB I suppose you can use USB but it would be much easier over WIFI or ethernet.

I also have a 64bit Raspberry PI OS setup on a PI4, you could loat Octoprint on it and also run PrusaSlicr on it and then connect to OctoPrint directly from the slicer. You might need the 8GB pi4 for that to work.

Anyway, my setup is Prusa->USB->Pi3->Octoprint->Wifi-> (Linux laptop, windows10 laptop or RPi4) -> Prusa with direct upload (& start) via TCP. i.e. anyone on my wifi network can start a print and monitor remotely with the USB camera connected to octoprint. Plus I also set up the image support from PrusaSlicr (a bit finniky) so the gcode comes with an image so you can see what all the uploaded gcode files are printing. It also means that when I get an unwanted windoze update and reboot, my octoprint continues running. Also octoprint comes with all kinds of really cool plugins.

I think the 3D printer is simply incomplete without Octoprint/RPi.

[pepelevamp]

Bla bla bla bla.

That's a lot of steps when you could just plug the printer into ya PC & hit go.

It's amazing how difficult it is to convey to some people that people purchase drills because they want holes - they don't want the drills.

Some people don't want to screw around with that & it's striking that it's lost on people that plugging a raspi into ya printer is basically a whole computer, and your PC is already a computer.

Yes - you enjoy your way of doing things and we are happy for you. But other people aren't you. USB right from the slicer makes sense for some people - people other then yourself.

On Fri, Mar 11, 2022, 5:34 PM owebeeone @.***> wrote:

Via TCP/IP. If you set up IP over USB I suppose you can use USB but it would be much easier over WIFI or ethernet.

I also have a 64bit Raspberry PI OS setup on a PI4, you could loat Octoprint on it and also run PrusaSlicr on it and then connect to OctoPrint directly from the slicer. You might need the 8GB pi4 for that to work.

Anyway, my setup is Prusa->USB->Pi3->Octoprint->Wifi-> (Linux laptop, windows10 laptop or RPi4) -> Prusa with direct upload (& start) via TCP. i.e. anyone on my wifi network can start a print and monitor remotely with the USB camera connected to octoprint. Plus I also set up the image support from PrusaSlicr (a bit finniky) so the gcode comes with an image so you can see what all the uploaded gcode files are printing. It also means that when I get an unwanted windoze update and reboot, my octoprint continues running. Also octoprint comes with all kinds of really cool plugins.

I think the 3D printer is simply incomplete without Octoprint/RPi.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2046#issuecomment-1064763787, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ3Q27SKHYTH4P7655Q2VLU7LEO7ANCNFSM4HCISPDQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[owebeeone]

You remember when people used to burn CDs on their PCs in the early days of CD drives? Half the time, the drive would be starved of data and you'd have another CD to throw away. People used to make dedicated machines but finally hardware was faster/more memory and drivers worked better and no more broken CDs. You didn't expect your music download software to burn CDs. You ended up getting software specifically for burning CDs.

Same thing here, the Prusa engrs are saying they'd rather spend time on features for better slicing and less on controlling the printer. You want better than an SDCARD, sure, go install one.

[pepelevamp]

So you're saying the USB printing functionality sucks in prusaslicer because USB functionality in prusaslicer sucks.

Not only is that circulars logic, your analogy forgot the fact that CD burning eventually became a native OS feature.

On top of that you forget other people aren't you. There are people here saying they want something - and you're saying 'no you dont, because I dont want it'.

The feature existed initially and for a long time, so obviously there's rationale for it.

Listen to people when they tell you their needs. They're their needs - not yours. Your way isn't for everybody.

USB printing from the slicer to the printer is a simple workflow that's rapid & doesn't require stupid hacks with entire second computers bolted onto the motherboard, network stacks, operating systems, or small floppy disks.

It's like talking to a brick wall sometimes.

On Fri, Mar 11, 2022, 7:55 PM owebeeone @.***> wrote:

You remember when people used to burn CDs on their PCs in the early days of CD drives? Half the time, the drive would be starved of data and you'd have another CD to throw away. People used to make dedicated machines but finally hardware was faster/more memory and drivers worked better and no more broken CDs. You didn't expect your music download software to burn CDs. You ended up getting software specifically for burning CDs.

Same thing here, the Prusa engrs are saying they'd rather spend time on features for better slicing and less on controlling the printer. You want better than an SDCARD, sure, go install one.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2046#issuecomment-1064827570, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ3Q24ZFHPINBWVRLJX2E3U7LU4JANCNFSM4HCISPDQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[owebeeone]

I'm saying the engrs choose to put effort into other features they deem more important so they shut this feature down because it's not a core competency and the feature sucked.

Just buy a raspberry pi4, 3d print a case, install octoprint and never look back. Problem solved.

[haarp]

You don't need to buy additional hardware. You shouldn't need to. Any PC with an USB port will do fine.

Prusaslicer used to have a G-code sender, but I agree with its removal. The best place for such a tool would be not integrated, but as an independent tool shipped alongside PS, similar to how PS comes with an independent "G-code viewer".

[owebeeone]

@haarp - Agree that you can run it all on the one PC. I prefer a dedicated RPi with Octoprint because it was painless to install and it runs flawlessly.

[deandv]

@deandv - Are you aware that PrusaSlicr can now send gcode directly to Octoprint and start printing immediately?

Yes I looked at that option yesterday. It seemed like it was going to take a significant amount of time to understand and set up.

For now I'm saving the gcode from PrusaSlicr and sending it to the printer over USB with Pronterface. Not as simple as a "print" function within PrusaSlicr, but better than the SD card transfer for my needs.

[GoGunner]

Just got a hand me down printer and already want to upgrade to SuperSlicer for it. Was looking at Prusa for my next machine already. I wanted to use USB for initial work and likely more the norm in the future as well as I really abhor the idea of SSD swapping. During the course of trying to figure out SuperSlicer I find that it has gone the way of the dodo. As I prefer direct connections over WiFi any day of the week, I guess my next printer won't be a Prusa after all.

[pepelevamp]

Dean for president. He's 100% right.

For me it's such a no brainer - imagine if you could just plug a 3d printer in & press print like a laser printer. Convenience always wins.

It's with any product - convenience always wins.

I'll say it again in case anyone was sneezing at the same time: convenience always wins.

Removing USB is the anti-feature of the century. Should be up there in the Hall of Fame of bad decisions.

On Fri, Mar 11, 2022, 4:24 AM dean @.***> wrote:

I too am in favor of reinstating direct-over-USB printing in PrusaSlicer. The SD card transfer dance is a hassle for small test prints. It also makes printing needlessly complex for beginners.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2046#issuecomment-1064180374, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ3Q22NIOPYD4VDKC35K4TU7IH4NANCNFSM4HCISPDQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[ignatio]

Why not just add a button in PS that sends the gcode file to printrun/pronterface and starts the print automatically since PS already ships with pr/pf? It accomplishes the same goal, is essentially transparent to the user and also doesn't involve PS team maintaining the usb functionality, just a button that launches a command line/console.

[pepelevamp]

I like it. I'm a bit behind the times cos I stopped 3D printing for some months.

I think prontoface etc can do it but was a little old - am I right?

I like your angle. From what I understand the USB printing can be as simple as streaming gcode - and the serial connection itself has flow control. But there's all these quality of life features which people feel would be duplicated worload & there's good live print monitors tools already.

I like the idea of handing off to a legit print monitoring tool that runs on the PC & talks over USB.

It's just so annoying having to use sd cards and I do not want my printer on a network with an entire OS available for dicking with.

On Thu, Oct 13, 2022, 8:54 AM ignatio @.***> wrote:

Why not just add a button in PS that sends the gcode file to printrun/pronterface and starts the print automatically since PS already ships with pr/pf? It accomplishes the same goal, is essentially transparent to the user and also doesn't involve PS team maintaining the usb functionality, just a button that launches a command line/console.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2046#issuecomment-1276665221, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ3Q22FEPGH27LT2R6QNVDWC4JPNANCNFSM4HCISPDQ . You are receiving this because you were mentioned.Message ID: @.***>

[bevinhex]

another side effect of our modern endless update cycle, endless new features and endless bugs, endlesscahnges , endless unpredictability

[bevinhex]

anyone want to achieve same thing can try out cura

[phazei]

I could care less about printing directly over USB from my PC, SD card printing is my go-to method and I'm fine with that. But the addition of a G-code console in PrusaSlicer for sending and receiving printer commands would be highly beneficial, particularly for users who are not employing a Raspberry Pi or similar setup.

Currently, the available options for a direct USB connection to the printer are quite limited. Pronterface serves the purpose but falls short aesthetically, lacking a modern interface and a dark mode.

MatterControl presents a better console experience, offering a history-access feature via the up arrow key, which simplifies repeated testing, and a message filter. However, it lacks the crucial ability to select and copy printer output text.

Cura’s interface, while it permits command sending, does not display responses or even echo sent commands, it's so bad it might as well not even be there.

Therefore, I'd really like to see a dedicated tab for an integrated G-code console. This would greatly enhance the utility of PrusaSlicer removing the need for any other program just to send G-code commands and monitor their printer’s responses during calibration and testing phases. The console should include:

Command history navigation. The ability to filter out non-essential messages. Functionality to select and copy text from the printer's output.

An integrated console within PrusaSlicer would make it a more centralized go-to choice.

[wafflecart]

“Therefore, I'd really like to see a dedicated tab for an integrated G-code console. This would greatly enhance the utility of PrusaSlicer removing the need for any other program just to send G-code commands and monitor their printer’s responses during calibration and testing phases.”

I don’t think this belongs in a slicer, it’s a slicer not a tool for debugging your printer via a console.

[phazei]

I think it exactly belongs there. 90% of the time someone's debugging their printer they're testing different config settings in their slicer. They go hand in hand.

[pepelevamp]

thats only an artificial separation.

to be frank, most of this stuff is just artificial extra steps that serve little constructive purpose. sd cards is absolutely absurd. gcode's absurd as well. we should be minimizing the amount of different tools needed for 3d printing not making extra steps.

plug in your printer to your computer. put a model in your slicer. hit print. results.

"whats the program i use the 3d printer with?" should be a pretty basic question. some times i think smart people can really be cognitively slow with basic concepts like this.

it really feels like pushing shit up hill sometimes.

On Tue, 16 Apr 2024 at 20:47, wafflecart @.***> wrote:

“Therefore, I'd really like to see a dedicated tab for an integrated G-code console. This would greatly enhance the utility of PrusaSlicer removing the need for any other program just to send G-code commands and monitor their printer’s responses during calibration and testing phases.”

I don’t think this belongs in a slicer, it’s a slicer not a tool for debugging your printer via a console.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2046#issuecomment-2058565477, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ3Q2ZXODLLNICRFAQ7QOLY5TQQPAVCNFSM4HCISPD2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBVHA2TMNJUG43Q . You are receiving this because you were mentioned.Message ID: @.***>

[majodi]

It’s just like laser printers where you have postscript (kind of the gcode). The word processor program (like the slicer) produces this intermediate format. You can have a local print spooler service (built into the OS) to feed it to a printer (the gcode sender) or you have a printserver in between. Modern network printers have a printserver built in. Modern 3D printers should have this gcode sender built in too.

[pepelevamp]

Absolutely. It should dunk it to the SD card as a buffer.

Though I hear the MK3 is too slow for this. I think that's a shame and a reason to call the MK3 poor, not to discredit the idea.

It could send information between print layers. Send a few kb between layers, and buffer up the latest layer into memory & goo-away from the in-memory later.

It's clearly fast enough to read from SDcard and print.

There's so many options. It's just an absolutely mad idea to take away USB cable printing and make people think an SDcard is somehow a good idea.

It's like watching people drive with square wheels, who voted to outlaw round wheels because if you could have just bought a plane if you hate square wheels so much.

Some people just shouldn't be allowed to make decisions on behalf of others

On Sat, Apr 20, 2024, 17:41 Majodi Ploegmakers @.***> wrote:

It’s just like laser printers where you have postscript (kind of the gcode). The word processor program (like the slicer) produces this intermediate format. You can have a local print spooler service (built into the OS) to feed it to a printer (the gcode sender) or you have a printserver in between. Modern network printers have a printserver built in. Modern 3D printers should have this gcode sender built in too.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2046#issuecomment-2067565617, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ3Q24ZWFDD63OBFNILESTY6H5Y3AVCNFSM4HCISPD2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBWG42TMNJWGE3Q . You are receiving this because you were mentioned.Message ID: @.***>

[vojtechkral]

This is ridiculous. This is a solved problem and has been for ages for MK3 + there's MK4 now with LAN and Prusa Connect printing and whatnot. The comparison with paper printer USB printing makes no sense. For a paper printer, the OS has a built-in print server that runs in the background and takes care of print tasks. Also, the USB printer protocols are much more reliable compared to just streaming GCode over a serial line.

So the USB paper printer setup is actually much more similar to running OctoPrint on your PC. The only difference is that in case of paper printers the "Octoprint" thing comes with the OS for you already. But it works the same way. Printing in MS Word is the same as "send to Octoprint", not as the old serial GCode sender. The feature that was removed from Slicer was equivalent to MS Word directly controlling printer head in the printer. You close MS Word - printer stops printing and stays in a weird state. That's what you're arguing for here.

It was simply a bad feature. Deal with it already. Stop beating a dead horse. In fact the horse is so dead it's long decomposed now and there's flower patch growing on its grave and you're still beating it senseless.

I'm gonna un-subscribe from here and I recommend the issue to be closed & locked.

[pepelevamp]

nah, you're wrong. you haven't provided an alternative. just merely a substitute which isn't what was required.

feature is needed. you analogies have been address already above.

On Wed, 24 Apr 2024 at 02:52, Vojtech Kral @.***> wrote:

This is ridiculous. This is a solved problem and has been for ages for MK3

• there's MK4 now with LAN and Prusa Connect printing and whatnot. The comparison with paper printer USB printing makes no sense. For a paper printer, the OS has a built-in print server that runs in the background and takes care of print tasks. Also, the USB printer protocols are much more reliable compared to just streaming GCode over a serial line.

So the USB paper printer setup is actually much more similar to running OctoPrint on your PC. The only difference is that in case of paper printers the "Octoprint" thing comes with the OS for you already. But it works the same way. Printing in MS Word is the same as "send to Octoprint", not as the old serial GCode sender. The feature that was removed from Slicer was equivalent to MS Word directly controlling printer head in the printer. You close MS Word - printer stops printing and stays in a weird state. That's what you're arguing for here.

It was simply a bad feature. Deal with it already. Stop beating a dead horse. In fact the horse is so dead it's long decomposed now and there's flower patch growing on its grave and you're still beating it senseless.

I'm gonna un-subscribe from here and I recommend the issue to be closed & locked.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2046#issuecomment-2072564334, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ3Q27O6EL2B3YKKBFMD2LY6ZYT3AVCNFSM4HCISPD2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBXGI2TMNBTGM2A . You are receiving this because you were mentioned.Message ID: @.***>