PID Autotune not working on E3-TFT35 with E3-RRF in RepRap Mode

[Wombat37]

Description

I've already posted this in the E3-RRF repository:

https://github.com/bigtreetech/BTT-E3-RRF/issues/9

Someone suggested that it belongs better here.

Steps to reproduce

Run PID autotune for the hotend or bed from the TFT keypad. Appears to go into autotune mode and then just sits there doing nothing (nothing heats up) until it times out

Works OK when sending M303 g code

Expected behavior Should perform PID autotunes

Actual behavior Does nothing until it times out

Hardware Variant

TFT35v3.0 and E3-RRFv1.1

TFT Firmware Version & Main Board Firmware details

3.0.27 (RRF 3.2.2)

Additional Information

[radek8]

The problem you mentioned is that the FW TFT is programmed primarily for Marlin. RRF support has only recently begun to be implemented. Marlin and RRF use different parameters and therefore the command does not work. There are very few programmers who know RRF, commands and their parameters in RRF. :-(

[radek8]

You could try to resolve the issue by editing the Configuration.h file and recompiling.

E-1 = H0 E0 = H1 E1 = H2 E2 = H3 E3 = H4 E4 = H5 E5 = H6

RRF does not know parameter U you may need to remove it?

[oldman4U]

Wombat37

Have you tried what radek8 recommended to do?

Would be nice if you could answer your own ticket.

[Wombat37]

My apologies, I know it's important (and courteous) to respond to suggestions like this and I will do so very soon.

In the meantime I was trying to resolved why my prints were so much worse with the new E3-RRF board. I've just put a temperature probe on the nozzle and it looks like it's 24°C lower than the 220°C setpoint (I've tried two different probes and thermometers) - which may explain things. I'm currently tweaking the M308 settings to try and fix this.

Sorry for the distraction - will try out radek8's suggestions tonight. I'm a little hesitant about recompiling as I've not done it before and I'm worried that I'll break other stuff :)

[Wombat37]

Ok, I'm lost. I'm not a programmer although I can do some programming but this system is confusing me lots.

Which Configuration.h file do I need to modify? I know this is used in Marlin but I'm using RepRap firmware and I don't see this file on the BBT site. Do I need to download a version of RRF firmware from somewhere else and edit and compile that?

I'm sure you guys don't want to train me on how to do this stuff but I thought I was just a normal customer trying to use a product I had just bought and was giving feedback on possible bugs I found - to the company that produced this product.

I would be very pleased to test this fix but I can't edit and compile it.

Having said, that I really appreciate the efforts of people who do know how to do this stuff and I'm learning the hard way what open source truly means.

[radek8]

configuration.h is also a FW TFT configuration file https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/tree/master/TFT/src/User

[Wombat37]

Ah! My bad, OK - I'll see what I can do.

Thanks

[radek8]

BIGTREE_TFT35_V3.0.27.zip

Overwritten parameter E to H. You can try.

[Wombat37]

This is all a bit real-time:)

I tried to build the file myself by substituting the HX for the EX codes but failed miserably (compilation was successful but couldn't find the resultant .bin file in platformio).

Anyway, I've uploaded the file you you sent me to my printer - thank you for getting this to me.

The good news is that it looks like the PID Autotune now works for both the hot-end and the hot-bed.

HOWEVER...

There's some bad news :( The tuning process doesn't seem to stop and eventually times out. There's a message to look out for a green light - wherever that is. Now, touching the screen causes conflicts as it thinks the autotune is still running. Monitoring things on the DWC browser display shows that the autotune did run and finish properly and reported the tuning values. The system had to be rebooted before it would behave itself again.

[radek8]

@Msq001, can you insert a condition with the proposed modification into configuration.h? For RRF users, the M303 command in the display menu does not work.

[oldman4U]

I believe BTT has to decide first if they want to put everything into the same repository or not.

[digant73]

also the missing PID completion/failed message means that a different message has to be caught in parseAck()

[radek8]

also the missing PID completion/failed message means that a different message has to be caught in parseAck()

@Wombat37 , Can we capture in RRF the syntax of the message on the serial port?

• on the successful completion of the M303 order
• failure of command M303.

This would help solve your problem

[Wombat37]

Thank you again for your help.

I ran the tests you suggested with the current TFT firmware (I took out your earlier fix).

I ran 4 tests:

"M303 H1 P1 S220" (T0 worked as well instead of the H1) entered via

1. Putty terminal server through the E3-RRF USB port
2. Terminal screen on TFT
3. DWC Console

All three worked and tuned the Hot End PID parameters. The following output was seen simultaneously on Putty, the TFT terminal screen and the DWC.

M303 H1 P1 S220 Auto tuning heater 1 using target temperature 220.0°C and PWM 1.00 - do not leave printer unattended ok Auto tune starting phase 1, heater on Auto tune starting phase 2, heater settling Auto tune starting phase 3, fan off Auto tuning heater 1 completed after 3 idle and 5 tuning cycles in 381 seconds. This heater needs the following M307 command: M307 H1 R2.307 C135.0 D5.43 S1.00 V0.0 Edit the M307 H1 command in config.g to match this. Omit the V parameter if the heater is not powered from VIN.

This all seemed to work as expected - except the DWC status was displayed as being Idle even though the temperature changes etc. were being tracked.

The problems arose when trying to use the TFT touch screen to initiate PID tuning as can be seen on the following screen shots:

Although the TFT screen indicated that tuning was in progress, nothing was actually happening. Nothing was being heated and nothing appeared on Putty or DWC. After 30 minutes the system timed out as shown in the last image.

I hope this information will help, radek8 - let me know if you need more.

[Wombat37]

As a further note, with your modified Configuration.h build, the TFT touch screen could initiate a PID tune which could be monitored on the DWC. This went on to successful completion. However, the TFT didn't appear to realize this and timed out as before.

[radek8]

Yes TFT does not know from the tuning process finished. it is necessary to find out the syntax of the RRF message to the serial port on successful completion and also on failure. Without this, it is not possible to program the correct behavior. But I won't help you with that. But if this information was available from someone who uses RRF, one of the programmers could program it. It would be just a few lines of code.

https://forum.duet3d.com/topic/17932/rrf3-m303-reporting-a-pid-error

[bttguy]

@bigtreetech Can you please help resolve this limitation of the current state of the TFT firmware? We would be thankful for that :) I really like that there are a lot of different submenus are on the TFT, but some of them cant be used, because the different gcodes/communication form used in Marlin vs RRF.

[jaysuk]

And just to expand on that, a heated bed tune should be done by M303 H0 Sx with x being the temperature to tune to. a hotend should ideally be tuned as a tool using M303 Tx Sx where Tx is the tool number starting at T0 and Sx being the temperature to tune to. Both of these should be saved afterwards using M500

On Thu, May 27, 2021, 8:25 PM bttguy @.***> wrote:

@bigtreetech https://github.com/bigtreetech Can you please help resolve this limitation of the current state of the TFT firmware by editing the gcode commands in case of RRF mode in the PID tune menu? We would be thankful for that :) I really like that there are a lot of different submenus are on the TFT, but some of them cant be used, because the different gcodes/communication form used in Marlin vs RRF.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/1856#issuecomment-849882239, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATUSBT4B62LV5RDIIHR233TP2MEFANCNFSM43G5CF2Q .

[bigtreetech]

@bigtreetech Can you please help resolve this limitation of the current state of the TFT firmware? We would be thankful for that :) I really like that there are a lot of different submenus are on the TFT, but some of them cant be used, because the different gcodes/communication form used in Marlin vs RRF.

Hello, Please test #1962 It has solved this problem, Thank you very much for your time

[bttguy]

@bigtreetech PID menu still need some tweaking as it is in #1962. Now it can be executed, PID tuning start, but the part cooling fan stuck at 100%. The correct procedure is it only turn on at a specific phase of the tuning at 100% otherwise its off. So the tuning works, runs, ends, but with an always on fan it will give a bit off values. But the rework is a step into the right direction :)

[bttguy]

With the latest change, PID works corretly!

[Wombat37]

This issue seems to be deferred for the time being.

I just wanted to make sure that we don't forget that it still needs a bit of work.

Although on first try, the PID tuning seems to work, trying to tune a second time causes the original errors to return.

Resetting the system appears to be an easy work-around and why the issue is no longer a major concern - however it does look messy!

[pfn]

Looking at the code, and trying it out on my machine seems to work OK now. No problems appear to be remaining here. RRF ports to non-duet boards seem to take longer to tune that it may "time out"

I've heard these ports can take over 20 minutes to tune, while the TFT timeout is at 15 minutes. On my Duet boards, tuning takes around 10 minutes.

[digant73]

good. Eventually for RRF, the PID timeout could be increased to 25 min. PID on my HW takes about 10 min.

[bttguy]

@digant73, @pfn On my insulated heated bed, a tuneing with 3.3 took about 45 min to 1 hour... And its only a simple Ender 3 basic bed, with some cheap insulation. I can imagine the time needed to do all the cycles in a proper cast alu bed, with magnets/flexplate/glass and insulation... So it really need some time. Is it any safety hazard to set the timeout to like 90 min? What do you think? Maybe @jaysuk can help us determine the time really needed? @pfn Did you tested Wombat's issue of "Although on first try, the PID tuning seems to work, trying to tune a second time causes the original errors to return." too?

[pfn]

It does not error for me in any way no matter how many times tuning runs...

[digant73]

the PID timeout message is only an informative message. The PID continues on backgroud and when finished a message asking to save on EEPROM should be displayed. Eventually, the timeout could be differenciated for RRF setting it to 1h (although it seems to me very strange a so long duration)

[bttguy]

@digant73 This is from Duet wiki: "Tuning a hot end heater typically takes between five and ten minutes. Tuning a bed heater may take more than half an hour, depending on the thermal capacity of the bed. You can cancel tuning by sending M0." "Typically it will cycle heating/cooling 8 times, but can be as many as 30, if the readings are not consistent (noisy thermistor, or a large thermal mass)." (https://duet3d.dozuki.com/Wiki/Tuning_the_heater_temperature_control) I think if we set the timeout we can close this issue :)

[bttguy]

@pfn Could you increase the timeout, so we can test it, and give feedback if it solve problem? As you said PID worked fine for you, if only this small change solves this issue, that would be great! :) @Wombat37 Can you test it again with your screen, as pfn said it was all fine. Does you printer require a long time for tuning so it times out because of that? Do you have any other problem?

[Wombat37]

I'll test it tomorrow!

Which build should I use?

[bttguy]

I'll test it tomorrow!

Which build should I use?

Well, just use the most recent one, as far as I know there were no PID specific changes in a while, but RRF got some improvements along the way.

[Wombat37]

OK - I still see problems!

This is what I did tonight using the latest TFT FW build on my BTT-E3-RRF v1.1 and BTT-TFT35-E3 v3.0 ...

Power up the system Go to Tuning/PID Select nozzle Set target temperature to 220°C Press start All tuned OK - see DWC capture below At finish (~8 minutes) confirmation message shown on both DWC and TFT (where is that green LED I should be looking for?) Press OK Still tuning message appears on TFT Click on TFT and tuning message disappears and returned to PID screen Now press Bed Set temperature to 70°C Press Start PID tuning now reapplied to NOZZLE and NOT BED! DWC confirms successful NOZZLE tuning - see below TFT shows Process Aborted message

So, I don't know what's going on here. The subsequent tune (of the Bed) was bad because it didn't happen and the nozzle was retuned instead and the TFT Process Aborted message appeared.

I reset the system and I next tried successive PID of just the nozzle to different temperatures (220°C and 230°C)... THESE WORKED!

Following another reset, I tried successive Bed PID tunings to different temperatures (70°C and 80°C) ... This gave a TimeOut - Process aborted error at 15minutes although DWC indicated that the tuning was still being continued. So, I never got to the second tune. Clicking OK and clearing the PID autotune in progress screen brought me back to the PID screen and I could initiate another tuning process even though there was already one still in progress - last time I saw this it let set up a second tune to run in parallel with another - lots of nasty error messages resulted. The initial tuning process in the background was completed in about 40 minutes with a confirmation message on DWC.

I didn't bother testing a Bed Tune followed by a Nozzle tune as I felt the TimeOut error would reoccur

So, in summary :

1. Performing a Nozzle tune followed by a Bed tune causes the Nozzle to be retuned and a Process Aborted message to appear on the TFT
2. Successive nozzle retunes seem to work
3. Although the Bed appeared to start tuning correctly, it failed on the TFT with a TimeOut error after 15 minutes. This tuning continued in the background
4. The PID autotune in progress screen reappears after the successful tune confirmation screen is cleared. It required a manual click to clear it.. I don't know if the time-out logic would still be active.
5. The PID autotune in progress message refers to a green LED that is probably on some board somewhere and hidden. Mention of the green LED is not needed as there is a confirmation message to say that the tune has been successful.
6. An apparent tune failure on the TFT doesn't stop the active tuning which continues until it's complete. The tune screen becomes active even though that tune is still proceeding in the background allowing conflicting tune activities to occur.

Bottom line - if you just tune the nozzle, all seems to work well. Try and do anything else and it just seems to fall apart.

[Wombat37]

A few further thoughts...

While the retuning of the wrong heated zone needs to be fixed, how to handle the Time-Out errors is perhaps less clear.

My view is that a Time-Out error should occur only when the system gets stuck. In this case, the PID tuning is performing well in the background - is the TFT FW unaware of this? If the tuning stops on the mainboard because of an error, then the Time-Out counter should start.

If this is not possible, why not take out the Time-Out logic altogether and let the user press a Stop button if they feel things have got stuck. This action should also terminate any active tuning going on in the background (with a suitable warning).

[digant73]

PID cannot be stopped (no other gcodes can be sent to the printer). For that reason a timeout is used to trigger the message that the process is taking a long time and that it could be failed/aborted without any notification to the TFT. So you can decide to leave the black screen and/or the PID menu but you have two possible scenarios: 1) you cannot submit other tasks to the printer in case the PID process is simply taking more time than expected. 2) the printer aborted the PID without any notification to TFT so it is available for other tasks

The PID timeout is a warning message for the above scenarios. If the PID process is simply taking more time than the timeout value then you should receive the success or failed notifications from the printer.

[Wombat37]

An emergency Stop (or reset) will stop the PID won't it? That's what I use if I want to stop a print. You will only want to abort the process if things have gone wrong anyway.

[digant73]

it's up to user to choose. He can wait (hope) the printer is not stuck. He can consider the printer is stuck and restart or shutdown the printed

[Wombat37]

OK - I understand, but you are putting up a "Process Aborted" message when in fact (as you say above) it's not.

[digant73]

I see also "Timeout reached!". We always try to recycle the existing labels as much as possible instead of providing new ones (more specific). There is no label such as "PID process timeout reached. Process could be still running. Wait or restart the printer"

[digant73]

Abort message in Timeout dialog box converted to ""Timeout reached!. Busy processing, please wait..." in my current PR

[Wombat37]

I understand you have a lot of constraints but I'm giving you (I hope) reasonable user input. Your Timeout Reached message is much better than Process Aborted but I still think it's going to be confusing to a lot of users - but perhaps only for the first time it happens.

[pfn]

Thanks for following up @Wombat37

So, in summary :

1. Performing a Nozzle tune followed by a Bed tune causes the Nozzle to be retuned and a Process Aborted message to appear on the TFT

Dunno about this issue, probably also occurs on Marlin?

2. Successive nozzle retunes seem to work
3. Although the Bed appeared to start tuning correctly, it failed on the TFT with a TimeOut error after 15 minutes. This tuning continued in the background

Yep, that's the current and expected behavior of the implementation.

4. The PID autotune in progress screen reappears after the successful tune confirmation screen is cleared. It required a manual click to clear it.. I don't know if the time-out logic would still be active.

The TFT still listens to PID success messages even though the timeout message occurs.

5. The PID autotune in progress message refers to a green LED that is probably on some board somewhere and hidden. Mention of the green LED is not needed as there is a confirmation message to say that the tune has been successful.

This is from other printers, such as the Artillery Genius and Sidewinder, they have an LED that turns green when PID is complete.

6. An apparent tune failure on the TFT doesn't stop the active tuning which continues until it's complete. The tune screen becomes active even though that tune is still proceeding in the background allowing conflicting tune activities to occur.

The TFT doesn't really know status of tuning from RRF, it's just guessing, the timeout message is innocuous, really.

The TFT also doesn't know about PID tuning started outside of the TFT: if you PID tune from DWC or any other gcode input, the TFT always responds with "process aborted" on completion. It is successful, however.

Bottom line - if you just tune the nozzle, all seems to work well. Try and do anything else and it just seems to fall apart.

Overall, this is behavior of the PID menu in general.

There are some improvements that can be made here, especially now that I added RRF-specific status queries, the TFT can know that there is a PID tune occurring and show the status accordingly. It's lowish on my totem pole tho.

[Wombat37]

Thanks @pfn - it appears that much of this behavior is as expected. I think many people performing a PID tune would first tune the nozzle and then the bed - so they will come across the issue of the wrong zone being tuned. That's probably the most serious issue.

The rest is messaging and understanding what's going on.

It would be great to have a user manual that documents all this behavior. I may even offer to write it (but I may need some help).

[bttguy]

@Wombat37 and @pfn Thanks for the input and the answer, hope it will get sorted one day, if that much effort went in this function/menu already.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Wombat37]

Please keep this open - it's not fully fixed.

[oldman4U]

So you expect someone to pick it up after 2 months of nothing?

[Wombat37]

So you expect someone to pick it up after 2 months of nothing?

Not a very nice reply!

You seem to be saying that, because nothing has happened for 2 months, nobody cares any more, so let's dump it!

I really appreciate all the time and effort the team puts into developing and maintaining this software - it has transitioned into a very usable and attractive product.

However, in this case, I too put in a lot of time and effort into investigating, testing and reporting this issue - some of it requested by you personally. If there was no intention of fixing this issue, why did we all waste that time?

Who makes the decision to make a fix?

• Me? I don't think so, but thank you for asking
• You? I don't know, perhaps you can tell me?
• Someone else? Who?
• The stale bot? Apparently this seems to be where you want the decision to be made

In this case, I think the fix should be straightforward. The wrong zone is PID tuned and things get screwed up.

In any event, making a decision early on whether to proceed with a fix or not would be a better approach than letting the clock do it for us. It would also prevent us from wasting a lot of time and effort.

Finally, to answer the question you asked, given the amount of effort already put in, yes, I do feel the issue should be fixed - but not necessarily now - which is why I kept the issue open.

Again, thank you for your efforts - I do appreciate them. Also, I hope you put value on user input.

[oldman4U]

Users of the community are investigating their spare time to improve the firmware based on their own priority.

Let's keep it open and see what will happen the next 2 months.

[Wombat37]

Thanks - I think we're good :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.