BIGTREETECH-TouchScreenFirmware
BIGTREETECH-TouchScreenFirmware copied to clipboard
bigtreetech
[Q] How to set up Advanced_OK?
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?
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?
@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
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).
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.
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.
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.
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.
Okay, they updated the binaries, that saves me some work. I will reload and test them again.
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?
I am running that printer again with advanced ok turned off in the menu, and nothing else changed to see what happens.
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)
It crashed with Advanced OK off of as well. I will try it one more time today to confirm.
Could you tell me which hardware you are using? (Motherboard and TFT version) What serial baud rate?
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.
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.
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.
I have a skr pro, tft e3 v3 on all the printers.
OK, the hardware should be no problem.
- 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.
- 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.
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
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.
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 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.
@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
What files would you like?
simply a gcode file which you had the issue with
This is the last one I was using, but I am almost certain it has happened with all my gcode files.
@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.