Sometimes when I upload to my RPi 3B+ from PrusaSlicer, the print slows down for a few seconds. I guess there may be some throttling going on.
NOTE - I have experience with low level electronics including power supply filters, so I know that everything starts with a good quality power supply! I am putting together a nice clean analog supply in order to prove there are issues with my Pi hardware onboard regulators... I'm sorting this out separately, but whilst I wait for a shipment of parts, I had this spin-off question, which is the purpose of my post:
I know the gcode can be uploaded to the SD through OctoPrint, but my question is this: can OctoPrint be configured to work in a way such that it directs the printer to print from SD card directly, to avoid any OS issues? i.e. with Octoprint just providing general monitoring and control? This way if the Pi fails or does a Windows Update during print (joke) then the job would be safe.
Perhaps this isn't viable / possible, but I'm just asking.
What did you already try to solve it?
Perhaps the power supply is not high quality, or power consumption from the wireless chip increases, and I am troubleshooting power supply issues separately (I've bought a USB voltage tester to monitor, as well as a few high quality PSUs to test).
Yes, OctoPrint can start a print from the SD card. Monitoring and control are limited.
Upload to SD is very slow because it uses the same serial interface used for printing. SneakerNet (physically moving the SD card between desktop and printer) is faster for most objects.
I have an RPi 3B connected to a LulzBot TAZ 6 and have no issues with printing files uploaded to the RPi.
What 3D printer do you have? You deleted the template which, when filled out, provides us with much needed details about your configuration.
PrusaSlicer with the OctoPrint interface has basically three steps: slicing, uploading, and initiating / monitoring the print. Exactly when does the print "slow down"? The last two steps can be completed outside of PrusaSlicer by using your browser instead.
Thanks for your response. Very interesting. (My system info below.)
So to answer your question, the print "slows down"* directly after the upload has finished, for a few seconds. It doesn't seem to affect the print quality. I sometimes print continuously throughout the day, so it isn't practical to wait until a print is finished before uploading a new file.
I'm using a plugin called "continuous print", so I only use "Upload" option in Prusa Slicer, not "Upload and Print". So when the upload has finished, the current print slows down. Perhaps it's possible this plugin might be causing the problem, I am not exactly sure how it works. Do you think that's possible?
Is this the default behaviour, when you print an item from the SD card from within OctoPrint? Or is there some other way to start a print from the SD card?
Additional information about your setup
Sysinfo bundle: I prefer not to post this as the info within is not anonymised OctoPrint Version: 1.9.3 OctoPi Version: Build 2023.10.09.154319, based on OctoPi 1.0.0, running on Raspberry Pi 3 Model B Rev 1.2 Printer: Prusa MK3S running firmware 3.13.1 Browser: Chrome Version 118.0.5993.89 for Windows 11
What information in the systeminfo bundle do you believe needs to be "anonymised"? I've looked at many bundles and except for local LAN addresses there's nothing in any of the ones I've looked at (including my own) which would, IMO, compromise security. I'm retired now but I did network security for a living.
I don't use that plugin but it sounds like the RPi is doing some processing on the uploaded file. I briefly looked at the documentation for that plugin and it is quite complex. You might want to open an issue on the plugin's github and see if they have an answer. Since you say the print quality isn't affected, it may just be an anomoly you will have to live with.
It's exactly that, I prefer not to disclose internal IPs. Not sure why it would be useful to collect these anyway for diagnostic reasons, but I haven't looked at what the diags actually do show in detail so maybe there's some good reason.
After a bit more testing I noticed the print also slows down when I rename a file. So given the file is stored on local SD card, and as you say this uses the same serial interface used for printing, I suspect the file transfer just stores to local memory then once the transfer is complete it's committed to storage.
Can you let me know exactly how I might use Octoprint to control / start / monitor prints from SD card as you mentioned, because that sounds like a good option? Thanks
Internal IP addresses are almost exclusively from netblocks assigned for private use and are not routable. Mine are 192.168.0.1-192.168.0.254 and are used by "millions" of other people for their home networks. The other information in a system info bundle will allow us to give you better help and obfuscating the internal IP addresses isn't necessary because we (or any malicious actor) can't do anything with them.
The RPi local SD card doesn't use the serial interface, the serial interface is used to communicate with the printer's firmware. Since the printer's SD card is also controlled by the printer's firmware, the only way OctoPrint can upload files to the printer's SD card is via the same serial interface it uses to send gcode commands to the firmware. This is why it is slow.
Given the level of automation you seem to be using with the continuous print plugin and the limited capabilities of the firmware controlling the printer's SD card, I'm not sure you will be able to improve on what you are already doing.
I misunderstood your original point about using the same serial connection - now I understand.
However, the point is that when I upload the file to OctoPrint (or indeed rename a file in OctoPrint) - where that file is not stored on the SD card local to the printer, this is when the slow-down takes place.
Anyway I hear your point that if I did upload it to the printer's SD then that would also potentially slow down the print.
I guess I will work next on my power supply issues...
Re your point about internal IPs - let's just say my home network is probably not like yours if you use that IP range, either way despite having VLANs set up it's just poor hygiene to share info about one's internal network online, there are many valid reasons why not to share such info online. Hostnames, IPs, locations of light switches, where my electricity meter is stored, where I'm going on holiday - nobody can do anything with that info, except build up a massive picture of my life. I run a small datacentre for customers (not from home) and there's absolutely no way I'd post info about their internal networks online so why would my own home be any different?