This feature already exists. Go to Tools > Firmware Configuration, and click on the Communication tab. It's the "Communication timeout" option at the bottom. You can even customize how long it waits before forcefully sending the next command (from my testing, you never want that value to go below about 5 seconds or so, since some normal commands will take several seconds to execute before the firmware responds, so if you take it too low, it will start messing with those normal commands).robgermino wrote:This issue can be fixed by implementing an AUTO FORCE NEXT FEATURE! As it stands now, I have to sit there and keep pressing FORCE NEXT to stop the melting from the hot nozzle.
arhi wrote:if you plan to use windows and usb you have to deal with a problem that you cannot push enough data at enough speed from windows and you will have this pauses.. you can try to use higher serial port speed but depending on what's on other side it will or will not work. Linux can be bit more stable but if you are using the computer while printing or if the moves are too small you will have issue with macos/linux too. SDcard is the only way to deliver code fast enough in some cases.AndersE wrote: I do NOT want to use SD.
many printers support pause themselves, octoprint on a dedicated rpi/opi also supports it an makes your printer untethered from your computer while retaining full control over the printer.gearsawe wrote:printing over SD is not an option since I need to pause to change out filament for multi color jobs
btw, in 99% of cases when you have pauses 'cause moves are too slow it's actually bad g-code with too many too small movements.. S3D had issue with those before (creating too many small movements in case STL was too detailed) but that was fixed some time ago... still, make sure the STL that goes into S3D is adequate for your printer (no point in having 0.1mm features in your stl printing with 0.5mm line).. would be nice if S3D could do some STL optimization before the print but you can do it in many other packages (for me best STL optimization can be done with AOI)
Same for my K8400 but this is not a problem with S3D. I have micro pauses with Vertex Repetier too.AndersE wrote:by the way: i run at 250k baud and has always done since i bought this velleman k8200 as it is standard speed for that.
Yes, that's exactly the behavior I was seeing. It looked just like it was paused. I thought this must have been an issue with USB. Transferred to SD, same thing in the exact same spots. Took a look at the gcode and saw that often on dense support layers there were feedrates as low as 17 (F17 is really freaking slow for a 4 mm retraction). Look at your feedrates to be sure.AndersE wrote:It has nothing to do with "wipe while retract". as it REALLY STOPS for 0.5-1 second and BLOBS.
Also, i have run with wipe while retract for a long time with no problems.