Printer pausing during prints

[bobginpgh]

Dale,

I haven't touched the serialCacheSize parameter, so it should be the default. I've only experienced the issue when printing from Creator, but haven't had the problem at all since I've only been printing directly from the tool chain (i.e. NOT printing from an already processed .gcode file)

[Simplify3D]

The serial cache size represents the space on the Arduino for storing serial data before it is processed. In general, larger cache sizes mean faster and more robust transfers. The standard size used to be 127 bytes, but I believe Arduino 1.0 downgraded this to just 63 bytes to add extra programming space (booo!). The size entered into Creator actually needs to be one less than the true size for implementation reasons, so you may see the buffers listed as 128 or 64 bytes, but just know that you would need to enter 127 or 63, etc. For those who are interested, there are actually ways to manually increase this buffer capacity which can help a LOT if you're encountering communication errors leading to stalled prints. Here's a great example: http://www.hobbytronics.co.uk/arduino-s ... uffer-size.

[Walt44]

Yep, I just had it happen once yesterday and once on the first print today. I don't recall it happening until this 1.1.4 version was installed. I've printed many many 3+ hour prints in the past and never had a problem, but now I can't leave the printer unattended and THAT is a major pain. I'm going to run this print again but with version 1.1.2 and see what happens.

[Walt44]

Well I can tell you that the G-code generated by version 1.1.4 is Ok as I've been running it using version 1.1.2 software and the print is well past the point where the same code under 1.1.4 hung up. I hand a simple 15 minute print hang up last night under 1.1.4, and so I'm beginning to believe that there is a bug in the 1.1.4 software. I'm sticking with 1.1.2 until I see a report that the pause issue has been resolved. Good luck!

[dalew8abz]

So, Simplify3D, if you're saying the outgoing byte buffer from S3DC to the printer is "the number the user configured plus 1" (like a gun holds n bullets in the magazine plus one in the chamber for a total of (n + 1) ), then perhaps there is a VERY low but non-zero probability of overrunning the printer buffer (63 bytes in RAMBo, 63+1 bytes in Creator).

If the printer buffer declared in building the RAMBo firmware is 63 bytes, and the printer can send (63 + 1), then there is at least the possibility of an overrun. It would be interesting to see if setting the outgoing serial cache to 62 (or a few less even) solves the issue. (To make it look right to the user, take the number displayed in the setup dialog and subtract one when creating the buffer. The result would be (n - 1) in the cache plus the one in the "chamber" (USART outgoing data register) for a total of "n", the number the user entered.

Does the USB link (hardware or driver) support any kind of buffer-full handshaking (like RTS/CTS, DSR/DTR or XON/XOFF on an old style serial port)? Is such handshaking being USED (configured enabled)? Can the link detect errors (ACK/NAK) and retransmit (and tell the difference between an original send and the retransmission)?

I'll let those having the issue try the experiment with the outgoing buffer size configuration. I have not been printing from the PC (usually print from SD Card) enough to run into it. Yet.

Dale

[Walt44]

I don't even know how this is working, but my 'serial cache size' is set to 99 bytes in version 1.1.2, and it works without fail. I went back and checked version 1.1.1, and it also had a setting of 99. The firmware hasn't been changed on the printer as far as I know. What gives?

[Winstonc]

I am having the same problem on my Lulzbot A0-101 with Repetier Firmware loaded.

David

[sir-mike]

Hi,
I experience the same trouble via USB Ver.1.1.4 but if I start the same print in Ver.1.1.3 no trouble at all. It looks like there is a bug in in Ver.1.1.4.
My solution for know I create with 1.1.4 and use 1.1.3 as machine panel, this way I had no trouble even with a 23h print.

And for all those who would say why don't you print from SD? There are a few nice monitoring options in creator and they wouldn't work from SD. That's why.

Michael

[turnrock]

This has happened to me a few more times, i dont have a SD so I'm going back to Pronterface untill the bug or solution gets found.

[Walt44]

Does anyone know if this bug is being worked on, or do we just scrap this entire program. A little periodic feedback on the issue from Simplify3D would sure be nice unless they don't agree it is an issue.