improve RRF

[Msq001]

Requirements

• Filling out this template is required. Pull Requests without a clear description may be closed at the maintainers' discretion.

Description

Benefits

Related Issues

fix #1856 M303 Auto tune PID for RRF
fix #1867 Auto query status to get fan speed
fix #1909 Set relative/absolute mode after startup.

[bttguy]

@bigtreetech @Msq001 I wrote my testing results to the related issues. Thank you for this PR :)

[bigtreetech]

@bttguy Hello, Please recompile and test the source code after ea8bb4e, It disabled the feature of setting fan speed on RRF

[bttguy]

@bttguy Hello, Please recompile and test the source code after ea8bb4e, It disabled the feature of setting fan speed on RRF

@bigtreetech All working now, thaks for the fix. The fan was off, until phase 5 when it supposed to be turned on.
You can merge this PR to let the other users test too. Only M500 at the end seems a bit odd. If I click save, it wont saved to config-override, but an M500 from DWC console will save it.

[Wombat37]

As I raised all three of the linked issues, should I be testing these fixes, too?

[bttguy]

As I raised all three of the linked issues, should I be testing these fixes, too?

@Wombat37 Yeah, sure, more feedback is welcomed! You need to compile your own from Msq'repo, let us know hows it working!

[Wombat37]

As I raised all three of the linked issues, should I be testing these fixes, too?

@Wombat37 Yeah, sure, more feedback is welcomed! You need to compile your own from Msq'repo, let us know hows it working!

OK - perhaps not, I can't work out which files to compile in the msq repo :(

[bttguy]

As I raised all three of the linked issues, should I be testing these fixes, too?

@Wombat37 Yeah, sure, more feedback is welcomed! You need to compile your own from Msq'repo, let us know hows it working!

OK - perhaps not, I can't work out which files to compile in the msq repo :(

Just download msq's repo, open it in Vs code and compile it for your TFT in the platformio.ini. you don't have to change anything or look for anything specific.

[Wombat37]

My apologies - I'm still learning my way around all this stuff and I'm totally unfamiliar with it - but learning well.

I have now compiled the Msq001 repo and have been able to load and run it on my BTT-E3-RRF/TFT35-E3 system so I can test the new changes.

In the first instance, I tested the PID tuning functions on the TFT under RRF and, while I can say that they now mostly work, there are still some fairly serious issues with the implementation. I can post a fairly detailed report (with screen shots etc.). Should I post that here, in my original issue posting or somewhere else? It will be several pages long.

[bttguy]

Post it regardless the place, just let us know if there any issues present :)

[Wombat37]

Msq001 BigTreeTech Touch Screen Firmware Build Downloaded 06/10/2021

Functional Testing of Heater PID Autotune Functions

I've included a lot of details in the following posting and I hope these make sense. I will go on to test the other functions tomorrow.

For ease of reading I summarize my main take-outs from these initial tests on the newly developed PID tuning page on the TFT:

1. Following system powerup (and reset?) both the nozzle and the heated bed PID autotuning seem to work
2. Better guidance on the need to apply the M501 command in the config.g file would be helpful. Without this, the results of the PID tuning on the TFT are not going to be applied.
3. At the end of a successful PID tune operation, the still tuning message is left on the TFT screen - this is confusing
4. The active tuning message refers to a green LED - what is this?
5. If a second tuning is attempted the tune will abort with a time-out and the wrong heater can be tuned.
6. A feature enhancement would be to indicate which heater is currently being tuned

And now the gory details...

Platform
• BTT-E3-RRF v1.1 RepRap 3.2.2
• BTT-TFT35-E3 v3.0 Msq001 Development Firmware downloaded 06/10/2021

The development firmware was downloaded and compiled from https://github.com/Msq001/BIGTREETECH-TouchScreenFirmware/tree/RRF

The BIN file, the config_rrf.ini and font and icon files were installed on the TFT from an SD card.
There were no problems with the compilation, installation or running of this development firmware.

On power-up, the PID tuning screen was accessed on the TFT and a Nozzle PID tune at 220°C was initiated from the TFT.
All seemed to perform well and I captured the following screens on the TFT

FIGURE 1

FIGURE 2

FIGURE 3

FIGURE 4

FIGURE 5

FIGURE 6

While the tuning was in progress, I monitored the status on the RRF DWC screen which is copied below:

FIGURE 7

This was a good start!

However, there are a few points I'd like to highlight:

1. The screen in FIGURE 5 was a bit cryptic but I managed to sort out what was going on. With RRF, the results of the PID tuning are stored as a M307 statement in the config-override.g file when a M500 command is issued as I assume the TFT will do at the end of tuning. Inspection of config-override.g confirms this as shown in FIGURE 8.

FIGURE 8

I understand that the config-override.g is only called if there is a M501 command entered into the RRF config.g file (normally at the end). This doesn't happen by default and I think the message in FIGURE 5 is trying to tell me that. I assume that this message comes from the RRF system which obviously has the intelligence to know that the PID tuning just conducted (by the TFT) is not going to work unless the M501 code is put into the config.g file. When I add the M501 code to the RRF config.g file, the message in FIGURE 5 no longer appears when I rerun the PID tuning.

2. The second issue I want to mention is why does the screen in FIGURE 7 reappear once the tuning has finished? Surely when the PID tuning has finished, we don't want to display a message that tuning is still in progress?

3. The final issue with this initial test is what on earth is the green LED mentioned in the message - I can't find one!

Following the first semi-successful test of the Nozzle PID tuning, I next attempted to tune the bed heater. This was a total disaster! The following screens summarize what happened:

FIGURE 9

FIGURE 10

FIGURE 11

FIGURE 12

This second tuning was monitored on the DWC as shown in FIGURE 13.

FIGURE 13

There were some serious concerns with this PID tuning of the bed heater:

4. Although the TFT was set up for PID tuning of the bed heater as shown in FIGURES 9 and 10, it was actually the Nozzle that was tuned!!! This nozzle tuning was successful as shown in FIGURE 13.

5. This second tuning (of the wrong heater) timed out on the TFT with the error message shown in FIGURE 12.

The system was powered down and then powered up and this time the bed heater was correctly tuned with the same issues listed for the nozzle tuning under points 1, 2 and 3.

Now PID tuning of the nozzle was immediately attempted following the semi-successful bed tuning. This time it did tune the right heater (the nozzle) but timed out again with an abort message as shown in FIGURE 12. Recycling the power enabled the nozzle to be retuned correctly.

[bigtreetech]

@Wombat37 Hello,

For 2. The requirement of adding M501 in config.g will be added in readme document。
3. It will be easier to change the logic, and I'll let you know when I finish
4. The green LED means that if there are led on the printer, the TFT will send M150 to set the LED color to green after PID autotune finished. Just ignore it if there is no led on printer.
5. OK, I'll test and fix it accordingly
6. OK, I'll try to achieve it

Thank you very much for your time. The test results and steps are very detailed and helpful

[Wombat37]

Thank you for your response (and kind words) I'm very pleased that you feel you can address a lot of what I'm suggesting.

I had one idea which may provide a quick fix to most of the above issues - why not do a system reset after PID tuning is completed (perhaps with a suitable "PID Tuning Complete, Now Rebooting" message)?

This would achieve the following:

• Clear the workspace so that the weird behavior seen with a follow-on tune wouldn't occur
• Call config.g and hence config-override.g to apply the new M307 settings (I don't know if your code already issues a M307 command at the end of tuning)
• Eliminate the still tuning screen after tuning has finished

Just a thought :)

In the meantime, I've started to check the Fan Speed status on the front page - looks great! I want to finish testing with an active print today.

[jaysuk]

```Call config.g and hence config-override.g to apply the new M307 settings (I don't know if your code already issues a M307 command at the end of tuning)``` This shouldn't be needed as its handled by RRF and whatever is the outcome of the tuning process is automatically applied

…

On Fri, 11 Jun 2021 at 15:47, Wombat37 ***@***.***> wrote: Thank you for your response (and kind words) I'm very pleased that you feel you can address a lot of what I'm suggesting. I had one idea which may provide a quick fix to most of the above issues - why not do a system reset after PID tuning is completed (perhaps with a suitable "PID Tuning Complete, Now Rebooting" message)? This would achieve the following: - Clear the workspace so that the weird behavior seen with a follow-on tune wouldn't occur - Call config.g and hence config-override.g to apply the new M307 settings (I don't know if your code already issues a M307 command at the end of tuning) - Eliminate the still tuning screen after tuning has finished Just a thought :) In the meantime, I've started to check the Fan Speed status on the front page - looks great! I want to finish testing with an active print today. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1962 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATUSBQM2DY3L2ZPTBSXQQLTSIOXXANCNFSM454DCPHA> .

[Wombat37]

OK - thanks for the clarification.

I've now finished testing the fixes for the other two issues I raised:

Part fan speed display on main screen

This now appears to work perfectly and will track changes to the fan speed made in the print method, from the DWC and from explicit M106 commands from a terminal. I had understood from initial feedback on this site that this would not be possible to fix, so thank you so much for your work on this. This feature is important to me as I like to see the fan speed to check on the method being correct and to assess bridging performance etc.

Load/Unload Extruder Movement

This too looks like it's now working perfectly and is a real joy to use! My BMG extruder is a real pig to get filament loaded manually. It needs about 450mm of filament to be pushed through to reach the nozzle from the extruder. With the current firmware Extruder Load/Unload functions, it was almost impossible to load filament into my printer - with this fix, it now it takes just a few seconds.

I would also like to make the observation that with fixes like these, the use of RFF on BTT products is becoming much more robust and user friendly and I'm becoming a lot more comfortable that I've bought a finished and usable product rather than a complex experimental test bed :) Also, if any problems are revealed, it looks like there is an opportunity for them to be reviewed and possibly fixed. Thank you again for your efforts, they are really appreciated!

Should I close the two original issues I posted (I think the PID tuning is still open)?

[bigtreetech]

Should I close the two original issues I posted (I think the PID tuning is still open)?

I will merge this PR first and close the two original issues , and then submit a new PR to fix PID related problems