[BUG] TFT35 - Busy processing, please wait.

[Magiquall]

Hello,
I have the same problem as another post closed without really solution, with my BTT TFT35, for the moment connected to a MKS SGEN L V2 while waiting for my SKR-2, I have the message "busy processing, please wait "

I reduced the speed from 250,000 to 115,200 it was less frequent, but still present.
I swapped out the COM ports and had no more worries, until I printed. A one hour thirty minute print and the printer is frozen 3 layers from the end.

When it is frozen, it is not easy to put it back into service, you have to turn it off and then wait a little before turning it back on, often twice in a row.

Every time it was frozen there was "Processing busy, please wait" at the top and in red, but nothing at all, the screen gets stuck even after several minutes and as during printing it continues to heat up. have a hole in my impression.

I specify that I put the last update, the Marlin patch and the last firmware available on the github for the screen.

Is it a loss of connection with the motherboard, or the screen which is overloaded?

[oldman4U]

Hi.

There has been no solution mentioned in this repository, because literally all users do not have the reported issue, but a few, and we are all using the same firmware. This makes it very unlikely that the firmware of the TFT causes this issue and this repository is about the firmware of the TFT's only. In case there is a way to reproduce the issue and there is a way to fix this in the TFT firmware, I am sure it will be done.

[Magiquall]

Ok, I hope this is from the MKS SGEN L V2 board, because I stop the makerbase. I also had a problem with their screen, maybe this is the same source of the problem.
So I will wait for the SKR2, hoping that it fixes the problem and that it does not come from the BTT screen.

Is the memory of the BTT TFT35 display sufficient where you need to be careful?
For example, do not enable all of the features in the config.ini file.

Or are there functions that should not be activated together? Functions which could interfere with the operation.

In any case, thank you for your responsiveness.

And excuse me for my English.

[oldman4U]

SKR-2 is for sure a great board, but Marlin support is not finished as we speak, as far as I know.

Resources are very limited on the TFTs but so far you can activate all functions in config.ini. If this makes sense - I do not know;-)

Most of us are not native English - so no worry.

[Magiquall]

I got the github firmwaire for the SKR-2, I managed to compile it. Otherwise, I would not have ordered this card.
But as it becomes difficult to find an SKR 1.4 turbo on its own, I opted for the SKR2.

I looked a bit at the code and indeed there are things added in this BTT version compared to the official marlin, but the processor already existed on another card that was already released. Adaptation should therefore not take too long. Finally, I hope.
What interested me was not having to cut the diag pin of the tmc 2209 pilots. I don't like it.😭😭

[Guilouz]

@Magiquall Where do you buy SKR2 ?I can't find it anywhere.

EDIt : just find it on Aliexpress

[oldman4U]

Great board. Mixture of SKR v1.x and Pro/GTR plus some nice add ons both do not have.

[oldman4U]

@Magiquall

Please help the community and close the ticket once you do not need it anymore. Thank you

[Magiquall]

Excuse me oldman4U, but do I have to close the ticket now? If I have the same problem with the SKR-2 I will have to recreate another identical post. The card is on its way, but I actually don't have a precise date when it arrived. However, I still had hope to be able to work with the MKS while waiting for what is not possible by the BTT screen.
Tomorrow I will do a test with Octoprint.

[oldman4U]

Once you do not need it anymore.

Happy printing

[Magiquall]

Hello,

I tested a long 5h30 printout with Octoprint plugged into the motherboard's USB (MKS).
The screen was connected and turned on too, but I didn't touch it at all during the entire print.
The screen is crashed and it is set to "Busy processing ..." during the 1st layer. 1st layer long enough, because I was printing a box. But he no longer received information from the printer, I no longer had the X, Y and Z co-ordinate news.

Octoprint continued to the end. Once finished I touched the screen and it was not frozen, I was able to navigate the menus (I have not tried them all). But I was in "System / connection" Then I clicked on disconnected. The message "Busy processing" has disappeared, unfortunately there is no connection button, but I tricked. I change the speed of the COM port then I put it back to 115200 baud, and it is connected. I was able to move the axes.
So it is really the connection of the COM port which is blocked, not the processor.
If the screen then freezes, it means that we are trying to communicate with the card and that it is surely waiting for a response.

The next print I will try Octoprint with the Marlin menu on the screen. But as it is an emulation I do not know if it is not yet communicating by the COM port?

I forgot,
I just plugged Octoprint into the USB for this print.
When I had my previous printing stop, there was only the screen, Octoprint was not connected.

[bigtreetech]

@Magiquall Hello, Can you adjust the TFT menu to terminal to monitor the communication between TFT and motherboard in real time? So that we can see the communication information between TFT and motherboard after the screen is frozen.

[Magiquall]

@Magiquall Bonjour, Pouvez-vous ajuster le menu TFT au terminal pour surveiller la communication entre TFT et la carte mère en temps réel? Pour que nous puissions voir les informations de communication entre TFT et la carte mère une fois que l'écran est gelé.

Hello,

I don't mind, but when I go to the TFT menu / terminal I have to enter a Gcode command, with the virtual keyboard, I have to put what? Thank you

[moebis]

@bigtreetech having the same issue, I noticed when I try to go to the menu to disconnect and then touch anywhere to reconnect, a bunch of gcode starts spilling on the screen with an "ok" button. (this is while I'm printing, which is when I need the screen to monitor temp and coordinates). After I close the last invalid window on the TFT35 it goes back to "Busy processing..." I also noticed you released 2 new firmwares on the same day (about 1-2 days ago) one in the morning and one later in the day, both had the same version number (BIGTREE_TFT35_V3.0_E3.27.bin), so I might try the newer one that was uploaded about 12-14 hour later.

EDIT: I'm using Marlin mode for now, because it's the only thing that works reliable to monitor the printer while printing.

[Magiquall]

Hello,

I have the same problem with the SKR-2.
Even without doing anything, leaving the printer on, after a certain time (random) the display will still show "Processing busy. Please wait".
Sometimes when switching on the connection does not work. Forced to restart the printer and sometimes this has to be done multiple times. It is not manageable.

For the SKR-2, I used the firmware available on the bigtreetech github.

In the firmware I left the communication:
#define SERIAL_PORT 1
#define SERIAL_PORT_2 -1
#define BAUDRATE 115200

I'm preparing a video, but as the switch to Busy processing mode is random, I don't know when I could shoot the 2nd sequence to show you.

Regarding the display in the terminal I would like a little more details, as I told you when I go to the terminal part, it asks me to enter a command, and if I do send without a command, I have the terminal which opens but nothing appears.
Please a little help.

[oldman4U]

What else do you have connected to the Mainboard and TFT?

Which power supply do you have?

[Magiquall]

Hello,

I'll show you a video, more exactly 2 video.
On ignition:
https://drive.google.com/file/d/11xBUbM7MYcW1djlhxD7xPpG1rrHl110b/view?usp=sharing
When I saw the fault:
https://drive.google.com/file/d/11z9huO4asRivbRq-oPNOrAlFMl2_5bIu/view?usp=sharing

I plugged in all that concerns the printer, but nothing more, I did not connect the Raspberry.
Regarding my power supply is an industrial power supply (I work in the field) 24V 240W (the bed being 220V), the regulation is perfect, really very little residual.

[Magiquall]

Hello, no one to help me anymore , sniffff...(sob out) ;)

I made several attempts to configure Serial Ports.
By default in the firmware of the SKR2 available on this github, there are:
#define SERIAL_PORT 1
#define SERIAL_PORT_2 -1
and 115200 baudrate.

I tested several combinations with more or less conclusive results, some do not allow communication with the screen and others seem to improve, less crashes but still afraid of doing a long print because I still had crashes (Busy proces...) .

What would be the configuration for this part:
With the BTT TFT35, it connect on TFT port, and EXP1 and EXP2 screen also connected to the screen (by the way, no problem when I'm in marlin mode), then the Raspberry also connected in USB or UART on the screen or elsewhere !! !.

For the moment I have tried with the raspberry, it works well, but during the print the screen crashes with "Busy processing", but hey it crashes even if nothing is done on the printer anyway .
But when I tried to make the screen work in "Touch" mode the Raspberry was still disconnected from the USB.

I also tried not to put SERIAL_PORT_2 but in this case the screen does not communicate any more.

I've seen some say that removing marlin mode (don't connect EXP1 and EXP2) will make it work, but I hope there is another solution. Personally I have not tried because I took this screen precisely because there is the Marlin mode.

[oldman4U]

I wrote it before and only got thumbs down for telling the truth but I repeat it here:

If you look for the solution in software, I believe you are looking in the wrong area. Issues like this and similar have been solved so far by:

1. shielding the cables
2. changing the power supply to something more reliable and better suited for the need of a 3D printer
3. one could solve a similar problem by moving the printer to another power line (household)
4. and I remember one user who could solve the problem by removing the electrical filament dryer from the same power outlet

So far I haven't seen a single user solving the problem in the firmware of the TFT. More likely it is a problem in Marlin, where several tickets are related to problems with the serial portS, in case one serial port is in troubles.

It would be important to be able to force the problem to happen, for example by disconnecting things from the mainboard or TFT which are connected there, or by turning electrical devices in the same household on and off.

I have seen software changing settings itself, in case the software has been running on a computer driven by the power supply of a certain vendor - and other crazy things. If there is a problem in a chain, most of the time you can only see it at the end of the chain, and in this case the end is the TFT.

BTT probably sold hundreds if not thousands of each kind of TFT they offer, but "only" a handful of users has problems and all others do not have it, even they use the same hard- and software. So what is more likely, that the TFT is the problem or that something else causes this?

Btw. your printer looks great!

oldman

[Magiquall]

Hello oldman4U,

Sorry it's quite long and with my English ... sorry :)

Being in the field of industrial electricity, battery charger, energy supplier in direct and alternating current, I am concerned with problems linked to the electromagnetic field. At work we have a room dedicated precisely to the measurement of these electromagnetic fields to certify CE conformity.

This is also why I separated the 230v alternating current and 24v direct current. But I have some faults in my setup on the subject on the left side so I will try to remedy it quickly so that the separation of the 230V is even further from the 24V. Because you're right, electromagnetic disturbances are sneaky and can cause random malfunctions. There is one place that may be complicated, it is the power cable of the BED with the cable of the temperature sensor. They are together under the BED so it is not easy to separate them.

Regarding the power supply that I use, it is an industrial power supply intended for telecom systems (very precise in this area) and CE validated precisely to avoid electromagnetic radiation, but it is true that it is not of our design and that it has not been tested with us. I will therefore also carry out tests with the power supply of the Ender 3, I do not need more power since my bed is 230V. But honestly, I have less confidence in the Ender 3 power supply than in my industrial power supply.
I am going to ask my boss if he would have a time to check the conformity of this industrial power supply.
In addition, it is quite far from the screen, but you never actually know.

Then I also heard about COM errors in marlin on the bugfix version. I saw it in a post on an Octoprint forum. Apparently the stable version didn't have this problem, so I used the stable version when I was with the MKS SGEN_L v2, but the result was the same.

Regarding shielded cables, I completely agree with you, using a simple flat cable is really not ideal and using shielded cables would not be a luxury, but do you have any references?
I admit that concerning RS232 communication it is not really disturbed over such a short distance, unlike Ethernet which even with 10cm is declared defective with our testers if we use basic flat cable. In our systems we have transformers of several tenths of a kilowatt, therefore a potentially very strong radiation, and the "simple" communication cables are not disturbed more than its, but we are in RS232 so with a potential between -12V and + 12V, if there is TTL between our motherboards and screen, which is between 0v and 5V, the possibility of transmission errors is indeed much greater.

I will follow your advice for the moment;) and therefore separate the 230V and 24V even more. This would also indicate, if this is the case, that the cards are quite sensitive to this phenomenon. The CE certification is in both directions. We must not emit too much radiation but also be able to collect it without disturbing the system ;)

[digant73]

@Magiquall Viewing your solution, the first thing I can say is it's a EMI problem. Did you test if the problem is present also not closing the drawer? also did you try to simply power on the system only via USB (so with no main power on) and verify if the problem is present after some hours?

[oldman4U]

Driver and motor will work only with usb power!?

[digant73]

no obviously he cannot print, But the TFT on main page periodically communicate with mainboard. I think in that situation, the connection will never be lost. Or he can also use the power supply with no print and probably he will have the problem after some time. Just preheat bed and nozzle and nothing more. Verify if soner or later the problem will be present

[Magiquall]

Good evening,
Indeed it is a try to make since it also crashed without printing.
For the moment I cannot do a test because I have dismantled everything. I redid my drawer and it is painted. In order to have the 230v button on the left and the 24v and screen part on the right.
My colleague, in the laboratory, gave me a part (sorry I can't find the name in English) to filter out of the 24v power supply.
I also modify the wiring to avoid as much as possible that the 230v wires are in contact with the 24v wires and measures, as well as moving the motor away from the fan which is an 80mm and which was just above.
There is only the plateau or I have no choice. The power wires are with the temperature probe.

[MLiv79]

I have this issue too. BTT TFT 70, Latest 27 firmare version, Marlin 2.0.8 on a SKR 1.4T with everything written in config.ini activated . I got message "Busy processing, please wait" even during print, now for example is printing with progress bar and elapsed time increasing regularly but not layer. Layer freezed at 2.4mm. PS: baudrate 250000

[Magiquall]

Personally, today I finished painting my new drawer and started to put everything back together.

I know I won't reassure you, but I feel less alone.

I'll keep you posted on this new setup, but I still need some time.

As a reminder:
I separate all 230v and 24v voltages to avoid interference.
I also move the driver fan to avoid possible interference as well.
If this is still the case, I test with the power supply of my ender3.

[MLiv79]

I think i solved my issue compiling the firmware by myself. I have to test a little bit more before to sing victory but in the last 2 prints no issues.

[digant73]

@MLiv79 after your verifications, please post here your solution so it will help other users facing the some problems

[MLiv79]

@MLiv79 after your verifications, please post here your solution so it will help other users facing the some problems

I don't know the differences from the ones compiled by myself and the ones already included bin file... that's the problem to understand what was the issue at least for me

[Magiquall]

Excuse me, but what firmware are you talking about? The one from marlin or the one from the screen, I admit compiling the one from the screen to see if it worked, but I haven't tried it.
If it's marlin I'd like to see your configuration files.
Thank you

[digant73]

@MLiv79 It should be better to understand if it was a EMI problem or maybe there is also something else not related to EMI. For that reason I suggested you to test also the scenario with no power from power supply. As you were "lucky" to get the problem even in idling state, you can replicate the scenario with no power supply and verify the result. If you still continue to get the freeze then you can probably discard EMI from the candidates

[radek8]

@MLiv79 but you should try it to understand if it is an EMI problem or a wrong configuration/bug in Marlin

I've to try to replace the cable with a shielded one because configuration side i can quiet 100% exclude issues. I've tested also the config (marlin+tft) of a marlin fb group user that with tft 35 doesn't have the issue and my config and his config are almost the same except for some customizations but i have the issue with my tft 70 and he has not.

@MLiv79
Almost the same configuration does not mean the same configuration. The problem may only be in the setting of one parameter.
Of course, you won't spoil anything with a shielded serial cable, on the contrary, you will eliminate other possible errors.
I don't understand why the display manufacturer doesn't put it to TFT automatically instead of flat.

[radek8]

@Magiquall

I was looking at your configuration files.
I prefer a slightly different Buffers setting but the configuration looks fine.

[MLiv79]

@MLiv79 but you should try it to understand if it is an EMI problem or a wrong configuration/bug in Marlin

I've to try to replace the cable with a shielded one because configuration side i can quiet 100% exclude issues. I've tested also the config (marlin+tft) of a marlin fb group user that with tft 35 doesn't have the issue and my config and his config are almost the same except for some customizations but i have the issue with my tft 70 and he has not.

@MLiv79
Almost the same configuration does not mean the same configuration. The problem may only be in the setting of one parameter.
Of course, you won't spoil anything with a shielded serial cable, on the contrary, you will eliminate other possible errors.
I don't understand why the display manufacturer doesn't put it to TFT automatically instead of flat.

Almost the same i mean that the differences have nothing to do with the tft and communication between tft and marlin.
What are your buffers settings values?

[Magiquall]

Good morning all,

Well, the news is not good, but it's good anyway, let me explain.
So I left the printer to my manager who tested in the FCEM room, I will put pictures for you this evening.

The reinjection into the network is correct, but there is indeed radiation on certain frequencies which exceeds the threshold for consumer products.
On the other hand, the measurement is the same with the power supply of the Ender 3. And so to find the troublemaker, it's complicated, change the parts as you go etc etc.

However considering the components in the system there is one possible troublemaker (and even several troublemakers) that I hadn't really thought of, and that's the stepper motors. Apparently these devices that generate a lot of radiation.

Now the good thing about this demonstration is that the printer didn't crash once during testing. I have browsed the menus several times, I launched 3 impressions and no problem.
And then I noticed when I unplugged the printer this morning that my tests last night were done with the raspberry plugged in and turned on, and it had worked. For FCEM tests, I have it unplugged.

For the conclusion of this day. Radiation is therefore still not to be excluded if the problem returns, but suddenly it will be difficult to find.
But the printer is working well , for the moment, since I applied the updates yesterday. Anyway I think it becomes essential to put a shielded cable for the TFT communication, even if it works now, it is not the top in the state.
If despite this I still have faults I will therefore buy a good power supply, it's not that expensive since my heat bed is 220V, so I don't need a lot of power.

Then I would fall back on more high-end engines (if there is one), because the ones I have are relatively noisy despite the TMC2209. It's the stepperonline brand, they're cheap but maybe not great.

[Magiquall]

[radek8]

Interesting and informative. I've never seen an EMI measurement chamber.
Therefore, if the stepper motor and its controller are the largest source of interference, if all measures are ineffective, it could also help to use shielded cables between the stepper motor and its controller. The engine itself will not radiate much, it is all-metal. The supply cables to the motor will radiate.
Occasionally there is a user who has problems with a lot of interference and then swears at the wrong FW. Maybe shielded cables to stepper motors could help. In the extreme case, only made of aluminum foil and adhesive tape.

[radek8]

Almost the same i mean that the differences have nothing to do with the tft and communication between tft and marlin.
What are your buffers settings values?

[Magiquall]

Hello,

@radek8
Indeed the EMI chamber does not allow targeting a particular component. In order to target a more precise area you have to test the pieces separately by disconnecting other components, but this is sometimes not possible.
My manager also has the possibility of generating disturbances in order to verify that the components are sufficiently protected to resist this radiation.

And thank you for buffer parameter.

For those who still have worries,
You have applied the new Marlin 2.0.8.2 version as well as the new version of the TFT screen (be careful, it's the same index number, but it's not the same program, moreover the config file also contains some differences) ?

[Magiquall]

Hello,

So for the moment without any other modification.
I made 3 prints with the screen and the SD card, Raspberry disconnected.
2 prints of 5 hours and one print of 2 hours, and no worries. During the 1st printing I retouched the babystep and no crash, on the other hand I did not touch then, I did not want it to crash on such a long print.
But that sounds really encouraging.

As a reminder:

I updated marlin to stable version 2.0.8.2, then I updated the screen to version BIGTREE_TFT35_V3.0_B1.27.x.bin, the image files (THEME_The Round Miracle Menu Material theme), "bmp" + "font", files from June 3, 2021.

What remains for me to do:
Replace the flat TFT cable with a shielded cable. I will try to find a USB3.0 cable in order to have my 5 wires, the USB2.0 only has 4 wires.
Today I am going to test several functions available with the screen, in order to check that everything goes well, I will also change the size of the buffer as indicated by @ radeck8

Thanks again to everyone.

I put you my Marlin configuration files (with buffer correction, but not yet tested), as well as the screen config.ini.

config.zip

Marlin.zip

[MLiv79]

Finally i've had some time to update the TFT with build from 2 June (I was already on marlin 2.0.8.2 on my SKR1.4T) and in the last 2 prints i've never had screen not responding because of "busy processing please wait". Print finished regularly, no issue while adjusting speed or Babysteps (i got the message once for some instants but then disappear and screen works regularly).
I'll print again tomorrow and see but never happens to me to have 2 prints without the message...so i've hope

[Magiquall]

Good evening,

I come to the news and eventually close this problem.
I continued several prints and I had no problem, but today the same message again, but this time, it was perfectly mastered and understandable since the message at disappeared and it could continue.

I explain how it happened:

I changed the printer nozzle so I redo the "POffest" setting since it calls it like that on the screen. But I started the process and forgot to heat the tray and the nozzle, so while it was moving, I was in the "Preheat" menu and as soon as I clicked on PLA it send this "Busy Processing,..." message, it had not finished the "POffset".
Once the nozzle was in place, the "Busy Processing" disappeared and it started heating the bed and nozzle.

It's perfectly understandable, and above all non-blocking, so it's perfect.

[oldman4U]

And what finally solved the issue?

[radek8]

TFT Update

[MLiv79]

Yes only tft update. I've everything as before stock cable included. So EMI were not the issue and marlin config too...
I'm afraid now to update with newer version the tft... 😅

[oldman4U]

The one which disables all ports by default. So turning them on the issue should come back.

Worth a try

[radek8]

The one which disables all ports by default. So turning them on the issue should come back.

Worth a try

#1959

[MLiv79]

The one which disables all ports by default. So turning them on the issue should come back.
Worth a try

#1959

Yes!! This has been the fix for sure

[oldman4U]

So reducing EMI solved the problem. Great.

👍🏻

[digant73]

busy message, busy symbol, freeze in some menus like babystep etc... helped to identify that kind of possible issue in #1959. babystep and other menus use mustStoreCmd function that was affected by the bug.
EMI on communication cable should not freeze the TFT but simply must cause a connection lost or displaying error messages

[Magiquall]

So reducing EMI solved the problem. Great.

👍🏻

I dont change my setup, juste change firmware (screen and motherboard) and this is OK now.
But I will change the cable as a precaution.

[oldman4U]

3 things

1 busy processing because Marlin does not respond- goes away as soon as Marlin is ready.

2. bug mentioned by digant

3. emi based - solved using TFT firmware update which turns all additional serial ports off. Once you need them and you turn them on in config.ini the problem will come back. We do not call this problem solved but good working work around Because the initial reason for the problem is not solved but even so the problem does not exist anymore.

[oldman4U]

It is a bit like asking the repair center to deinstall the brakes of the car because they are so noisy. Works fine until you need them.

[radek8]

Oldman4U what don't you understand?
Digant73 solved the problem with his PR.

[oldman4U]

I believe I understand everything.

Just want to say that the new firmware did not fix the reason for the problem but the symptoms.

[MLiv79]

busy message, busy symbol, freeze in some menus like babystep etc... helped to identify that kind of possible issue in #1959. babystep and other menus use mustStoreCmd function that was affected by the bug.
EMI on communication cable should not freeze the TFT but simply must cause a connection lost or displaying error messages

With your PR i can even print from tft sd or USB! Before the printer freeze somewhere during the print...
Thanks!

[github-actions]

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.