Sudden Hesitancy

Something weird just started happening. I have been printing from the same computer over USB for months. Now, suddenly, my print jobs are pausing for several seconds at a time, multiple times per job. It doesn’t seem to be happening when printing from an SD card. It’s weird. Why now, out of the blue?

I know, I know, an OctoPi might solve it, but that’s not the question, which is, how could this just suddenly crop up?

It’s most likely your computer getting busy with something for a few seconds. and not being able to send the commands to the printer.
Check your CPU Usage while printing. Also check memory while printing. I assume your running Windows?

If your memory usage is high it could be a swapping problem

The only issue with that argument is that nothing’s changed on the computer for quite a while, not even updates.

Drive may be getting fragmented.

My first check on the system is open a command prompt and run SFC /Scannow
That will check your system

Hmmmm, I have another computer nearby. I may just install only Win10 & Cura 4.7 on it. See if there’s a difference.

Good idea. I know , I know but I use Octoprint. works great and frees up my computer

SFC is not a bad basic tool, but I have a number of much more sophisticated tools available.

That is the problem with direct printing using a system, that can do anything in the background. It can be a system update, a program that updates and virus and so on.

It is like the claim of “Never having problems with online gaming over wifi!”. well, yeah. Until your neighbour has a party and all the new phones are scanning for access. The point is you never know what a complex device like a PC is doing and when.

Heck Windows even does not know what it is doing itself and restarts to install an update, while a DVD got burned with the included desktop tools.

Use OctoPrint and you never ever will have any problems. You also won´t loose the Cura-connect-functionality as OctoPrint supports that, too.

You can spend a few hours to find out what it is. Maybe it is gone before you find out and comes back later ruining your prints. Just mount a little RaspberryPi box onto your system and it not only connects to your computer, but also to your phone, ipad and everything supporting websites. Incl. camera feeds, ability to control the printer and abort prints in an emergency.

I’m aware of the available options, and I’ve considered the other possibilities you mentioned, but they’re not possible in this case. The computer I’m using has zero Internet access. It simply cannot do any updates. Naturally, it also cannot be infected with a virus (although it is extremely unlikely it would get infected even if it had Internet access, due to the layers of protection I have in place).

Try upgrading to the latest Cura. I recall one of the versions of 4.7.x had problems generating too much gcode (more than 4.6) that overloaded some printer buffers and caused stuttering.

Cheers!

When I posted Cura 4.7 I meant 4.7.1, but that was wrong. I’m actually running 4.8.0.

@Alan Overloading isn´t actually a thing unless a gcode line exceeds 96 characters.

Marlin has a buffer and when the buffer is full, it simply does not take any more data and puts the serial line on hold. It does not take any further data, until there is space to store it inside the ring buffer. That is how serial transfer works. By default the buffer is quite small. The maximal command size is 96 and the default size is 4, so the serial buffer is 383 bytes of text. (ringbuffer have a waste byte for end detection)

The opposite is the case. When you press e.g. pause in OctoPrint or any other application connected, the printer may continue to print a while, because it needs to process all commands before the pause command to react. If you have a lot of small command like lines, then it can be a minute till the printer is reacting to the pause command. This is not because the printer got overloaded by the computer, but the buffered command chain.

@Geit Yes, we are in agreement: https://chen.do/mitigating-print-quality-issues-with-bufferbuddy/

@Ender5r Are you printing things with more curves? Or, maybe (something) has changed with the USB cable. In the Pi forums, people sometimes talk about using shielded cables to fix stuttering.

Cheers

The beauty of modern 32bit boards is you can increase the buffer by a lot, so if you really want to use a desktop system to driver your printer, a bigger buffer will ensure there is backup. Also you can use a proper baud rate, which could cause troubles, too.

Hi guys. First, thanks for your input. I always appreciate it. I would remind you that I do have decades of experience with serial comms. In fact, I still have an RS232-C breakout box in my kit.

@Geit, actually, overloading can be a thing. Back in the day, it wasn’t uncommon to have overloading, and underloading too. This usually occurred because 1 or both ends of the comm link weren’t properly obeying the start and stop commands. It could also occur simply because the comm link was too long. If the serial cable was too long for the BAUD rate, data could still be coming down the wire after the receiver’s buffer had filled up. The receiver issues a stop command, but it’s too late: data is still on its way. That’s just 1 example. There are others.

Now, normally, this issue was taken care of by employing a robust protocol, 1 that allowed proper buffering. 1 of these protocols employed “sliding windows”. It was a very efficient protocol. You can read more about it by searching for “Kermit RS232-C”. Almost all of the robust protocols employed a way to number packets of data. That way, if they were garbled, or otherwise incomplete, the receiver could ask for them to be re-transmitted: e.g. please re-send packet 143. Of course, the buffer had to be large enough to hold enough data to make the sorting, collating, & verifying possible in time. If it was a simple file transfer, no big deal. Real-time comms was a different matter.

@Alan, no, the test print had zero curves. It was the hollow box used to test flow rate.

Also, I have an update. I suspect the issue is with the computer I’ve been using. Not sure what happened, but I likely will reinstall it. The serial cable has been confirmed to be OK.

EDIT: I looked up Kermit: you can read about it here: [U]http://www.kermitproject.org/kproto.pdf[/U]. FYI, I used it a LOT several decades ago.

Ender 5, I have to agree with the others, get a Pi and let it do the work

That may well happen in the future. In the meantime, this is a computer mystery that needs solving, and that’s what I’ve done for 60 years. As I said, I believe it’s the computer I’ve been using. Now, I can’t delve completely into Windows 10, or any modern OS for that matter, because they’re simply too large & complex. I wouldn’t live long enough. Even Linux is too huge to tackle.

That is what I did decades ago, but operating systems were much smaller & simpler then. Today, I settle for identifying & correcting at a higher level; in this case, finding out that the OS on the computer has an issue, and fixing it by reinstalling, or restoring from a backup of the initial installation, with updates.

I confirmed that the issue is with the computer I was using, by printing from my original Surface Pro; there were no pauses.

So, troubleshooting complete. On to remediation… :slight_smile:

That is part of the reason my main system is not running Window, MacOS or Linux. :smiley:

I am part of a group of enthusiast and who started to build out own operation system about 20 years ago. It is hobby based, but we came along a good way not to mention that the Computer I am using right now is from 2001 :smiley: It got a dual monitor setup, so I can “import” stuff I still cannot do - like FreeCAD or a Slicer - via VNC, which works great.

The other thing is that I love that I can change anything in this OS to my liking and simply add features I miss.

Yes, you’ve posted about your OS project previously. I don’t really consider the inability to delve deeply into modern operating systems to be disaster. I think the advantages of modern operating systems outweigh the disadvantages. Would it be nice to have deep access to them? Perhaps, but I’m not so sure. There is a huge human tendency to downplay negative things from the past and remember the positive ones. All in all, I’m still able to troubleshoot issues effectively, and that’s the main concern.