[2.0.x] MKS SBASE stubborn serial crash.

[Zakm0n]

So, I've got two different MKS sbase boards. One of which I've used with smoothie for well over a year now, the other was an unused backup. Every commit of marlin I've tried over the last month has had intermittent serial crash errors with both my Ubuntu laptop running octoprint as well as my windows pc running simplify3d. On octoprint I get the "SerialException: 'device reports readiness to read but returned no data" error and on S3d the printer just stops responding to commands and S3D just sits there connected but not doing anything. Commands will work again as soon as I reconnect. I've tried multiple different usb cables, multiple sd cards, and even fully reformatted the sd card. I've managed to get a print or two out, but on average, I'm getting 40 minutes to an hour into a print max before it stalls out. Also, I noticed that it's not a full printer crash because the heaters stay on until I reconnect and turn them off.

[DirtyDerv]

Ive had the same issue as this with an arduino and ramps

[thinkyhead]

Depending on your host OS and software, you may benefit from XON/XOFF handshaking. See if it helps to use these extra options:

// Host Receive Buffer Size
// Without XON/XOFF flow control (see SERIAL_XON_XOFF below) 32 bytes should be enough.
// To use flow control, set this buffer size to at least 1024 bytes.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048]
//#define RX_BUFFER_SIZE 1024

#if RX_BUFFER_SIZE >= 1024
  // Enable to have the controller send XON/XOFF control characters to
  // the host to signal the RX buffer is becoming full.
  //#define SERIAL_XON_XOFF
#endif

Enable and set RX_BUFFER_SIZE to 1024, and enable SERIAL_XON_XOFF.

[boelle]

@Zakm0n did you try what thinky suggested?

[boelle]

@thinkyhead i think we can close this one

[EvyCatsune]

same problem, i tried what you said and i'm getting "Low memory available, stability problems may occur." error when uploading, along with a bunch of "avrdude: stk500v2_ReceiveMessage(): timeout".

[EvyCatsune]

i have an anycubic i3 mega, by the way, it as a trigorilla mainboard...

[EvyCatsune]

i'm expecting a mainboard or power supply issue at this point, even avrdude is making read errors...

[ghost]

@EvyCatsune

i'm expecting a mainboard or power supply issue at this point, even avrdude is making read errors...

That would be the first thing to fix, and then:

AFAIK, trigorilla is Arduino Mega2560 based. That's an 8-bit processor with potentially not enough RAM to handle large buffer sizes. You get close to or exceed the maximum RAM easily when using non-default buffer size settings - or you at least exceed the threshhold set in the arduino IDE for minimum RAM left free to cater for the stack, which grows downward from the end of the RAM. If you get too close to a certain limit, execution may work initially, but later on in the course of normal processing, the stack may overwrite variables or vice versa, causing unpredictable behaviour.

On my 8-bit boards, I use the default serial buffer config and use a 115200 baud rate, anything higher turned out to be unreliable. One of the reasons I moved to 32-bit.

The original post concerned a 32-bit board, the MKS sbase. It has more RAM available so you can add buffers generously.

@Zakm0n On my MKS SBASE I am currently using:

//===========================================================================
//================================= Buffers =================================
//===========================================================================

// @section hidden

// The number of linear motions that can be in the plan at any give time.
// THE BLOCK_BUFFER_SIZE NEEDS TO BE A POWER OF 2 (e.g. 8, 16, 32) because shifts and ors are used to do the ring-buffering.
#if ENABLED(SDSUPPORT)
  #define BLOCK_BUFFER_SIZE 64 // SD,LCD,Buttons take more memory, block buffer needs to be smaller §§§§
#else
  #define BLOCK_BUFFER_SIZE 16 // maximize block buffer
#endif

// @section serial

// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
#define BUFSIZE 4

// Transmission to Host Buffer Size
// To save 386 bytes of PROGMEM (and TX_BUFFER_SIZE+3 bytes of RAM) set to 0.
// To buffer a simple "ok" you need 4 bytes.
// For ADVANCED_OK (M105) you need 32 bytes.
// For debug-echo: 128 bytes for the optimal speed.
// Other output doesn't need to be that speedy.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256]
#define TX_BUFFER_SIZE 128 //§§§§

// Host Receive Buffer Size
// Without XON/XOFF flow control (see SERIAL_XON_XOFF below) 32 bytes should be enough.
// To use flow control, set this buffer size to at least 1024 bytes.
// :[0, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048]
#define RX_BUFFER_SIZE 2048 //§§§§

#if RX_BUFFER_SIZE >= 1024
  // Enable to have the controller send XON/XOFF control characters to
  // the host to signal the RX buffer is becoming full.
  //#define SERIAL_XON_XOFF
#endif

I have not needed to resort to SERIAL_XON_XOFF yet, but as @thinkyhead stated, that is the next step. Also note that I am using a baudrate of 250000 on this board with octoprint and that there is a mega-long thread on the octoprint git concerning the "SerialException: 'device reports readiness to read but returned no data" which also adds to the confusion.

[EvyCatsune]

i see, i've put buffer settings as they where, and used a BAUDRATE of 115200. My power supply seems fine, it goes between 12.74v and 12.90v. i only have a multimeter so if there is noise, i wouldn't see it. However, the problem is still there.

i've had an issue when printing with the sd card when the usb cable is hooked to the computer. The print just stalls right after touching the plate. i'm thinking that might be a pid issue and so i didn't mention it before. however i've realized that it doesn't happen when the usb cable is not hooked to the printer. So i'll just use the printer like that from now on. i'll buy a wifi sd card or something...

i should've said that before but, please note that i'm using, MNieddu91/Marlin-AI3M-BLTouch since my printer as an unsupported touch lcd. As far as i know, that lcd has its own microcontroller. The interface didn't change between anycubic's original firmware and Marlin. Its still displaying the same firmware version. So i suppose the communication between the lcd and the mega 2560 must be minimal...

However since the problem might be coming from someone else's code, i suppose you can ignore my previous comments and close this one... unless the original poster suddenly shows up...

Sorry for the mess, next time i have an issue, i'll make sure to report it at the right place...

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.