Erroneous control of extrusion distance on TFT movement screen with RepRap #2557
Comments
|
I'll start to investigate which version it started to fail in. |
|
Check if PR #2560 fixes the issue you have. |
|
Many thanks - I will test this later today. |
|
OK - I tested it. It still doesn't work - the extruder moves by the total displayed rather than the incremental adjustment. This applies when both pressing buttons and rotating the knob. |
|
I made a little change, can you please try again? |
|
OK, tried again but it's still not working. Am I using the right link to get the test build? https://github.com/kisslorand/BIGTREETECH-TFT/tree/G90/91-Fix |
|
Did I need to recompile the code for this test? |
Yes |
|
OK - sorry. I'm a user not a development programmer and sometimes I need to be given directions. Anyway, I compiled your latest code with the 'little change' and ran it on my RRF system. The extrusion distance was still not working properly from the TFT display.. |
|
@kisslorand, many thanks for your help with this - it's much appreciated. What else can I do to help get this fixed? |
|
I didn't give up just had no time for it. I made a little fix again to PR #2560, maybe you can check it again. |
|
Yes - the M82 entered beforehand made it work properly. |
|
I'll compile and try your new code |
|
Sorry - that latest version didn't work properly either. I'm assuming that I am compiling the code correctly in VSCode. Perhaps to make absolutely sure, you could just compile this latest version for me for the TFT35-E3-V3.0? |
|
Sure. I attach 2 test files, please test both. |
|
Thank you for your continuing efforts to get this fixed :) OK, I just tested both of these new versions on my E3-RRF V1.1/TFT35-E3-V3.0 system and neither works as it should. They still extrude the filament according to the total on the display rather than the incremental movement expected. This gives two main problems:
Looks like I was probably compiling the code correctly So, we still haven't found a fix. Hopefully the M82 result is a big clue? |
|
Yes, the |
|
There was no external device connected during these tests (apart from the E3-RRF main board). DWC was not active.
…Sent from my iPad
On Jul 23, 2022, at 9:53 AM, kisslorand ***@***.***> wrote:
Yes, the M82 result and the results of those 2 binaries you tested are a big clue. It means to me that although the TFT upon startup sets the extruder to absolute mode, something (probably external) sets it back to relative.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
|
|
I do not have a single clue what sets your printer's extruder to relative mode without the TFT knowing it. In the meantime I made another file for your TFT. It's not supposed to fix anything, it is just a test to check if the extruder is really set to absolute or not when the TFT boots up. With this FW (Test3) upon booting your printer is supposed to home X and Y and than Z. Please test it and report back. |
|
Ok - will do. However, it’s 36C here at the moment and we have no AC - operating a 3D printer is quite a challenge😀
I will check the new code you sent me very soon but it may take a day or two to find out which version broke it.
Thanks
…Sent from my iPad
On Jul 23, 2022, at 12:39 PM, kisslorand ***@***.***> wrote:
I do not have a single clue what sets your printer's extruder to relative mode without the TFT knowing it.
Can you find which commit broke it?
In the meantime I made another file for your TFT. It's not supposed to fix anything, it is just a test to check if the extruder is really set to absolute or not when the TFT boots up. With this FW (Test3) upon booting your printer is supposed to home X and Y and than Z. Please test it and report back.
https://mega.nz/file/ygo1gaaC#br2_vdNEU3mVLTcOxf0g4ODMVjOLvte4HWFeD5b-jjc
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
|
|
OK, loaded the new code (Test3). On boot, there is no homing occurring. |
|
PROBLEM SOURCE MAY HAVE BEEN FOUND! I'm trying to understand how this relative versus absolute manual extrusion should work. Surely, we want relative extrusions to apply when using the load and unload functions. The RRF config.g file sets M83 in the second line of the config.g file to do this. M82 will set the extruder to absolute mode - so why did the earlier experiment setting M82 make the TFT driven extrusions work (properly) in relative mode? I also checked to see how DWC controlled manual extrusion with the latest master build (July 12th) - and this worked well, so the RRF code is still working as it should. Have we got the M82 and M83 functions somehow reversed? For reasons I don't fully understand, I changed the M83 (relative extrusion) to M82 (absolute extrusion) in the RRF config.g file. Now everything worked for manual extrusion - the TFT knob, the TFT buttons and DWC. So, it would appear that DWC doesn't seem to care whether M82 or M83 is set in the config.g file and the TFT seems to care but has things backwards. I don't understand what's going on here but perhaps this makes more sense to you. Note that M83 has always been set in my system and, at one time, this worked with the TFT. Hopefully, somewhere in all this, there's a good solution. I think we are homing in on it and it looks like there's no point in testing further code. Is there ever a need for absolute extrusion control? Does this work properly with Marlin? |
|
Note also that RRF handles the G90 and G91 commands differently from Marlin (they don't affect the extruder). |
|
@Wombat37 Test 4: https://mega.nz/file/mwADySqJ#L6qHjny5Mqmapgqwa65KDGSRvxEKzAq92HaWcoU_7pk
This commit does exactly that.
It was so because when you sent M82 from the TFT it made the TFT aware that your extrusion is in absolute mode. Before the Note: The TFT will override G90/91, M82/83 settings from the "config.g" file. It sets the coordinates and the extruder to absolute mode. |
|
Yes!!! Test 4 appears to work very well - the TFT rotary encoder and the load/unload buttons now control the manual extrusion properly. DWC continues to work properly, too. Looks like you've cracked it! Many thanks for your efforts. Do I need to test any other functions or is the impact of the change you're making, localized? P.S. If, in future, you need to check out any other RRF-related changes on a working system, I will be pleased to help if I can. |
As I said, I am not familiar with RRF. This fix also makes the RRF motherboard to report to the TFT the settings from "config.g". I do not know what does it bring to the table, if it fixes any other issues or not. Maybe check the progress bar issue... (#2547) |
|
Yes - I'll check the progress bar issue. It would be wonderful if your changes fixes other stuff, too. I'll report back in both threads if it does. |
|
This did not fix the progress display/bar issue (#2547). However, I can confirm that printings still worked as expected. |
|
Does #1962 offer any clues?
…Sent from my iPad
On Jul 23, 2022, at 9:53 AM, kisslorand ***@***.***> wrote:
Yes, the M82 result and the results of those 2 binaries you tested are a big clue. It means to me that although the TFT upon startup sets the extruder to absolute mode, something (probably external) sets it back to relative.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
|
|
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. |
This was a bug reported and fixed as #1909 - it seems to have returned in the current version.
I believe that it's an issue with absolute versus relative extrusion from the TFT extrusion screen.
The text was updated successfully, but these errors were encountered: