[Q] How to set up Advanced_OK?

[V1EngineeringInc]

I have read the config.ini section a bunch of times and I have to be doing something wrong. A couple of my printers have randomly spazzed out since switching to advaced_ok.

I have tried a bunch of different values, can someone give me a hint on what works for you?

// The number of linear moves that can be in the planner at once.
#if ALL(HAS_MEDIA, DIRECT_STEPPING)
  #define BLOCK_BUFFER_SIZE  8
#elif HAS_MEDIA
  #define BLOCK_BUFFER_SIZE 16
#else
  #define BLOCK_BUFFER_SIZE 16
#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 flash (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 32

// 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

In the config.ini file for the TFT advanced ok is enabled, and are the TX slots needing to be changed or is that only for when Marlin does not have it enabled?

[V1EngineeringInc]

I am seeing that #2840 was merged but it looks like the bin files were not updated, could this be my issue. Do I need to generate my own new bin files to include it?

[digant73]

@V1EngineeringInc tx_slots in config.ini is used only if ADVANCED_OK is disabled in Marlin and enabled in TFT (advanced_ok set to 1 in config.ini). If you have ADVANCED_OK enabled in both Marlin and TFT then at boot Marlin will provide to TFT the value (BUFSIZE - 1) used by TFT as the new tx_slots. In you case BUFFSIZE is 4 so the TFT will be able to maintain 3 pending gcodes. Try to compile by yourself the current TFT source code (including also PR #2840) and you can also access to the stats window clicking on title bar and then on Info button. Once in the stats window, monitor the Pending gcodes and Free TX slots. On printing you should see 3 for Pending gcodes while on idle you should see 3 for Free TX slots

[V1EngineeringInc]

Thank you let me see what I can do. Is buffsize=4 okay, would more be better?

I have had 2 printers completely go haywire mid-print, and all of them show random gcode errors a couple of times a print that does not seem to affect anything. (and those are not valid errors, just random characters missing that are not actually missing).

[digant73]

a buffsize of 4 is OK (I also use this value on one of my printer). If you get some errors sometimes then it could be an issue on your HW. Try to disable advanced_ok on TFT side (advanced_ok set to 0 in config.ini or even from the Feature menu) and verify if the issue is no more present.

[V1EngineeringInc]

Yeah, so far using the marlin side I get no errors, but that was only one day of testing. I will run 6 printers today and test again. Updating my fork now to run the newer code.

[V1EngineeringInc]

Sorry, I still have not updated. It took a few days but each one of my 6 printers failed randomly. Changed to Marlin mode and no issues yet at all. I don't even get the "unknown command, or prevent long extrusion errors". I think there is something wrong with advanced ok in the current compiled binaries.

[thisiskeithb]

Do I need to generate my own new bin files to include it?

Yep. I fixed the GitHub Actions/firmware building last month in #2862, but the "Build Binaries" Action will run after the next PR merge/commit since the .github folder & *.md files are excluded.

[V1EngineeringInc]

Okay, thank you for the clarification.

[V1EngineeringInc]

Okay, they updated the binaries, that saves me some work. I will reload and test them again.

[V1EngineeringInc]

Nope first one just lost it mind 3-4 hours after flashing. I have them all running the info screen. Everything showed all zeros when it happened. I can try to take a picture next time but the printer sounds horrible while it is happening. It just looses its position and can't move, both steppers making tons of noise and not moving.

Any suggestions?

Do you guys do long prints, or run your printers multiple prints in a row? I am not running superfast, 55mm/s with a 0.5nozzle with .35 layers. CoreXY, maybe that makes a difference?

[V1EngineeringInc]

I am running that printer again with advanced ok turned off in the menu, and nothing else changed to see what happens.

[digant73]

ok. let us know the result with advanced ok disabled on TFT side. I suspect more an issue on mainboard when multiple gcodes have to be read by mainboard (advanced ok used)

[V1EngineeringInc]

It crashed with Advanced OK off of as well. I will try it one more time today to confirm.

[rondlh]

Could you tell me which hardware you are using? (Motherboard and TFT version)
What serial baud rate?

[kisslorand]

@V1EngineeringInc
You can try the FW from my repository.

[V1EngineeringInc]

Sorry I have been distant. Post xmas rush is insane.

Turning off Advanced ok on the TFT keeps the touch side working fine. Flip that switch and it fails within a few hours.

I have a skr pro, tft e3 v3 on all the printers.

You can try the FW from

It will be a few days until I can experiment, I am running the farm hard right now and can't afford to lose a printer right now.

[kisslorand]

Turning off Advanced ok on the TFT keeps the touch side working fine. Flip that switch and it fails within a few hours.

The proposed FW doesn't use ADVANCED_OK at all but delivers all the advantages of it and more. It does it in a dynamic way, based on the load of the TFT.

[V1EngineeringInc]

I think we talked about this before. I can not stray from the main open source software. I can not ship a board to my customers that I can not check what is on it. I am willing to test your changes but I will not ship it until it gets merged back into BTT main.

[rondlh]

I have a skr pro, tft e3 v3 on all the printers.

OK, the hardware should be no problem.

1. Make sure that there are enough RX buffers defined in Marlin (RX_BUFFER_SIZE in Configuration_Adv.h). Set it to 256 or 512 bytes.
2. Are you aware that @digant73 implemented a debug screen in the FW? Enable "DEBUG_MONITORING" in Configuration.h. This will give you more insight into how Advanced OK is performing. With adding a few lines you can do a quick test of the serial communication, what will show serial communication issues very quickly. Let me know if you want to give it a try.

Could you tell me what you mean with "spazzed out"? What actually happens? Any messages on the TFT?

NOTE: kisslorand is not a reliable player, he made many false claims and blocks the people who found that his code was slow, buggy and unreliable. He doesn't understand peer review and open source software, better stay clear of his closed source FW.

[digant73]

Sorry I have been distant. Post xmas rush is insane.

Turning off Advanced ok on the TFT keeps the touch side working fine. Flip that switch and it fails within a few hours.

@V1EngineeringInc as far as I understood, while waiting for a deep troubleshooting from our side, at least you can use the (old) logic based on a single gcode at a time without any issue on your prints.
I'm pretty much confident the issue is on Marlin side not being able to properly read a burst of gcodes from TFT. When possible, please try the indications proposed by rondlh just to see if they fix the issue

[kisslorand]

Sparky and Il Duce... inseparable...

[V1EngineeringInc]

Just getting back to it.

1- I have it set to 1024 now, so go less?

2- the debug screen shows all good number the whole time until it doesn't. I have run the same exact file several times, sometimes it makes it, other times it does not. Not in the same place or any pattern like that. The same file I have ran thousands of other times.

Spazzed out - the gantry moves out of the way a bit and both directional steppers just grind back and forth and the gantry does not move other than shaking violently. (coreXY). Crud...I took a picture of the debug screen when it last freaked out. I can't find it I really do not want to do that to any of the printers again. It is bound to break something.

[rondlh]

1- I have it set to 1024 now, so go less?

1024 is excellent! No need to set it to a lower value.

2- the debug screen shows all good number the whole time until it doesn't. I have run the same exact file several times, sometimes it makes it, other times it does not. Not in the same place or any pattern like that. The same file I have ran thousands of other times.

Here a test (designed by @digant73) to help diagnose serial communication issues.
In Monitoring.c, in void menuMonitoring(void), just above "loopProcess();" at these lines:

if (!isFullCmdQueue()) {
  sprintf(str, "M118 TEST %d\n", infoHost.line_number % 512); 
  mustStoreCmd(str);

Now when you go to the monitoring menu a test will be executed that test the serial communication, you should see quite high numbers of commands being send and received. If the communication fails, then the numbers will go down or even become 0. You should be able to exit the the screen without issues.
NOTE: Never do this while printing (print might be lost), and reset the printer before starting an actual print.

Spazzed out - the gantry moves out of the way a bit and both directional steppers just grind back and forth and the gantry does not move other than shaking violently. (coreXY). Crud...I took a picture of the debug screen when it last freaked out. I can't find it I really do not want to do that to any of the printers again. It is bound to break something.

OK, strange, this means that the TFT is continuing to feed commands to the motherboard. Could it be that the motherboard rebooted for some reason?

@digant73 The TFT can detect a motherboard restart and will reconnect, but this does not affect the ongoing print process. The TFT will continue to feed data to the motherboard without warning, which could cause unpredictable results. Perhaps that is what is happening here.

[digant73]

@digant73 The TFT can detect a motherboard restart and will reconnect, but this does not affect the ongoing print process. The TFT will continue to feed data to the motherboard without warning, with causes very unpredictable results. Perhaps that is what is happening here.

@rondlh TFT feeds data to the mainboard if the mainboard is providing an ACK reporting free slots. It is even possible that the mainboard is not blocking the TFT when needed.
The issue seems to me more similar to what you have already detected on your mainboard. I refer to the lost/corruption of some bit in the serial transmission. Bulk transmission of gcodes (e.g. with advanced ok enabled) could accentuate that issue If I'm not wrong, you also provided a fix on Marlin repo.

[digant73]

@V1EngineeringInc could you please provide some files for which you had the issue with advanced ok enabled? I probably found the possible cause (I already had suspects on that) and I need to make some tests before. If it will be confirmed by testing, the issue seems to be on some mainboards (even on a fast board such as btt bx) not able to properly read/buffer contiguous (with no gap) messages sent by the TFT when the mainboard is also performing printing tasks. Probably the issue is also accentuated in case more serial ports are available/configured in the mainboard (Marlin has to scan multiple ports). With some real printing files I got only a single unknown/corrupted message error reported on TFT always at the beginning of the print. Forcing the TFT to insert a gap between contiguous messages should solve the issue.

@rondlh I saw that your PR (DMA Serial Reading to Circular buffer #26328) was merged on Marlin repo. I have a BTT SE-BX mainboard based on stm32h7x (so not affected by the improvements made by your PR on some STM32Fx). With that mainboard I occasionally had some reported unknown/corrupted message errors on TFT. I'm making some testing on TFT providing some delay on TFT before retrieving a next command to process and send to mainboard but even with 40ms of delay I got the issue

[V1EngineeringInc]

What files would you like?

[digant73]

What files would you like?

simply a gcode file which you had the issue with

[V1EngineeringInc]

pen_mount.zip

This is the last one I was using, but I am almost certain it has happened with all my gcode files.

[digant73]

thanks. I will also use it in my testing

[digant73]

@V1EngineeringInc
Try to disable LED event feature from the Feature menu before printing.
I suggest you also to make a full power cycle thus removing also the power cable. So disable first the LED event from menu, then full power cycle and then start a print. Also make testing with both advanced ok enabled and disabled in TFT (you can leave advanced ok always enabled in Marlin).
Just yesterday night I got some errors (also at the beginning of a print exactly when the LED was switched on). Do you have a LED strip on your printer or a simple LED close to the nozzle?
I had the issue (unknown command errors) only on the printer with a LED strip and advanced ok enabled (no issue at all on the printer with only a simple LED). The printer seems also to be noisier during all the print. When disabling LED event on TFT and making a full power cycle the issue was no more present (and the printing was more silent). I repeated the tests several times with the same results.
it seems to me a possible bug in Marlin maybe caused by LED commands sent by TFT. It seems Marlin starts to be very slow/unresponsive causing all the issues in particular with advanced_ok enabled. I will continue with the analysis this night.

[digant73]

@V1EngineeringInc Just made a lot of testing.

On the printer with a LED strip and an ST chip (printer biqu BX) I got sometimes 1 or 2 errors when printing your provided gcode file (a 2 hours printing) with advanced_ok enabled while I didn't get any error with advanced_ok disabled. It was found that on Marlin fw the code to read incoming messages is not completely reliable for ST chips and a fix for some ST chips (unfortunately not available for my printer based on a more recent ST chip) was provided by @rondlh and it is currently available only in Marlin bugfix version (not yet integrated on the official stable Marlin fw). Those errors on my printer are probably related only to that issue on Marlin fw that is more frequent when using advanced_ok. I was also able to reproduce the issue with advanced_ok disabled and it was a little bit less frequent but still present, thus confirming the main issue is on Marlin's not reliable/efficient implementation. I also sniffed the traffic between TFT and mainboard just to confirm that the gcodes/ack sent/received by the TFT were not affected by corruption at the source and that was confirmed (e.g. the gcodes have been received by the mainboard without any corruption but the mainboard was not able to properly read them).

On another printer not based on an ST chip I never have any kind of errors even with advanced_ok enabled (using also the same baudrate of 250K on both printers).

In the meanwhile (just today Feb 28) a new TFT fw has been released fixing some bugs, improving speed and adding also the new command_checksum feature on config.ini file (also configurable from Feature menu). That feature has to be used only if advanced_ok feature is disabled (it is only a matter of resources needed on TFT fw not related to advanced ok feature).
I would suggest you to update to the latest TFT fw and eventually (if advanced_ok feature is still not ok for your printer) to disable advanced_ok (it is enough to disable it only on TFT) and to enable command_checksum feature. That feature will provide you also an indication of errors (if any) on the serial line and to successfully retransmit the affected gcode (so you will have no more corrupted gcode skipped or processed by the mainboard).

[V1EngineeringInc]

Awesome, thank you for confirming and doing such a deep dive. I will make some changes.

Another side effect I had not noticed was my SD cards fail to recognize after a few prints. Sometimes I can trick it to see them again by selecting USB, then TFT, backing out, then SD card again. If not I have to reboot and it works fine.

I will try what you suggested when I get some time. I have to update my Marlin git builder, and the TFT builder I use though so it might take a while I made a few changes and just have not had the time to sit down and brings things fully up to date.

[digant73]

@V1EngineeringInc no problem, take the time you need and if possible let us know the results (even possible bugs) with the new TFT fw.
For the issue with the SD card, in my case it was the SD to mini SD adapter (TFT notified when the adapter was inserted/removed but then when browsing through the Print menu no files were displayed). When I have this issue (rarely after I swapped the adapter with a better one) I usually unplug and plug again the SD adapter non pressing to much the adapter on the SD slot. I will try also to replicate your issue with the SD card after long usage of the slot (maybe it's only a question of temperature/false pin contacts)