InsanityAutomation / Marlin

Optimized firmware for RepRap 3D printers based on the Arduino platform.
http://www.marlinfw.org/
GNU General Public License v3.0
449 stars 220 forks source link

CR-10S Pro various UI/UX issues - 10SPro_BLT_BIL_DW7.4 #219

Open alzeebum opened 3 years ago

alzeebum commented 3 years ago

I've recently added a BLTouch to my CR-10S Pro (v1) and installed the latest stable 2.0 firmware using the 10SPro_BLT_BIL_DW7.4 hex file from the CrealityDwin_2.0 branch. After a few days of using it I've encountered numerous issues that were not present in Marlin 1.1.x when using the official firmware (Creality v1.70.1). I'm putting them in this single ticket to avoid spamming the issue tracker with a bunch of issues at the same time in case one or more of these are already known. Once the known issues are marked I'll happily close this and create individual tickets for the items that remain.

Before I continue please understand that while I'm a developer myself and fairly familiar with my machine, I do not know which of these issues come from the upstream Marlin release vs. TM3Ds changes vs. InsanityAutomation's changes.

  1. Unintended movements. Occasionally the firmware sends various commands to the printer without the user directly requesting them through the UI or g-code. For example after a print is complete, the hot end moves upwards a small amount when you tap "finish". I saw a previous about this here and believe the behavior is intentional, but in my opinion, it should be removed and left to users to add to their post-print g-code in their slicer. It only provides the intended behavior (moving the nozzle away while it cools) when the user is right there to tap the "finish" button, in which case, they could also enter the move menu and move the hot end themselves. Another example is the leveling screen -- simply entering that screen to view your current values causes the printer to home, which may not be what you want. The printer already homes (again) when you press "measure" and there is a home button on this screen, so I believe this action should be removed.

  2. When clicking "measure" in the leveling screen, a completely different screen is briefly flashed onto the display. The other screen displayed has what looks like a 5x5 leveling grid on the left side and the right side says "auto leveling, please wait.."

  3. The ABL behaves differently depending on if you have a PC connected to the USB port or not. When leveling the printer without a PC connected, after measurement is complete and the hot end is heated, the hot end is moved to a location somewhere around 50,50,0 and the message "Set Z Offset" is displayed and no information is given on how to proceed. The message remains if you hit the 'back' button on the LCD. I don't understand what I'm intended to do at this point, or what the purpose is.

If you issue a measurement with a PC connected, instead of showing this message and moving, a popup window is shown that says "Click to resume..." with a yes/no box displaying the message "No Filament,click Yes to change filament or No to cancel." There are two problems with this message. First, it displays when filament is in fact loaded and the light is on on the factory supplied filament sensor. Second, clicking either yes or no does nothing except play different sounds. The message remains on the screen and the printer must be reset (power cycled, disconnect/reconnect with pronterface, etc) to continue. Pronterface shows "RTS_HandleData" and "waitway = 7" when either button is pressed and the sound played.

  1. Upon bootup with the BIL firmware, the progress bar only displays for a moment, and the startup sounds are interrupted by the "ok" or "yes" sound. This doesn't happen with the UBL firmware, where the progress bar takes much longer, presumably because the interpolated mesh is being rebuilt from the stored probe values. Minor issue but still startling to a new user of the firmware.

  2. In several screens the firmware appears to fight with itself for control of different display areas:

    • When moving, if you tap an arrow quicker than the printer moves, the current position will flash between the new value, the old, and back to the new.
    • When heating during a print, the upper left status area quickly flashes between "3d printer ready" and "heating..."
  3. When canceling a print, you're taken back to the "home" screen for 1-2 seconds. It's just long enough for you to start tapping to enter other menus, before you're suddenly sent to the print confirmation screen just to click the finish button and have the printer move as described in the first issue.

I'm willing to try different firmware versions to see if any/all of these issues are fixed, and have forked the project so I can try building my own version -- though to be candid, my intention in forking was mainly to try to add BLTouch support to the 1.1.x branch so that I can go back; 2.x seems a little too rough around the edges at present with these issues.

Tasmedic commented 3 years ago

Sorry I can't help but I thought I would just sympathize with you as I'm sure I'm not the only one reading your message and waiting to see what they say, as I have exactly the same issues with that HEX file. I also tried to compile my own version of CrealityMarlinDwin_2.0 using the provided marlin.ino, and couldn't get it to compile, even with associated files left at defaults. Hence I have put my own issue in, and will wait and see what happens. It sounds like you've been compiling your own firmware, too. If you're managing to get it to compile, I'd appreciate any tips. I also gather there are social media sites associated with this firmware but I'm not sure where they are. They might be an option for us. Best wishes from Tasmania Chris

InsanityAutomation commented 3 years ago

I've recently added a BLTouch to my CR-10S Pro (v1) and installed the latest stable 2.0 firmware using the 10SPro_BLT_BIL_DW7.4 hex file from the CrealityDwin_2.0 branch. After a few days of using it I've encountered numerous issues that were not present in Marlin 1.1.x when using the official firmware (Creality v1.70.1). I'm putting them in this single ticket to avoid spamming the issue tracker with a bunch of issues at the same time in case one or more of these are already known. Once the known issues are marked I'll happily close this and create individual tickets for the items that remain.

Before I continue please understand that while I'm a developer myself and fairly familiar with my machine, I do not know which of these issues come from the upstream Marlin release vs. TM3Ds changes vs. InsanityAutomation's changes.

The TM3D changes are the changes here, this is the code base they ship from.

1. Unintended movements.  Occasionally the firmware sends various commands to the printer without the user directly requesting them through the UI or g-code.  For example after a print is complete, the hot end moves upwards a small amount when you tap "finish".  I saw a previous about this [here](https://github.com/InsanityAutomation/Marlin/issues/121) and believe the behavior is intentional, but in my opinion, it should be removed and left to users to add to their post-print g-code in their slicer.  It only provides the intended behavior (moving the nozzle away while it cools) when the user is right there to tap the "finish" button, in which case, they could also enter the move menu and move the hot end themselves.  Another example is the leveling screen -- simply entering that screen to view your current values causes the printer to home, which may not be what you want.  The printer already homes (again) when you press "measure" and there is a home button on this screen, so I believe this action should be removed.

The motion at completion / finish button was added by demand, so that one wont be going anywhere in the precompiled. You can change the action to just M84 disable steppers in the configuration_adv with EVENT_GCODE_SD_ABORT if youd like for youre own builds. Entering the leveling screen, if my memory is correct homing there was matching the OEM functionality but its been so long since I used that I cant be certain anymore. The measuring option issues a G28O so if steppers have not yet timed out it should stick to just the necessary movement and not re-home provided that option wasnt broken upstream. I can poll a few of the long term users and see if there is a consensus on this, but many just want to use the screen to set the z offset and the preparation move at entry is useful.

2. When clicking "measure" in the leveling screen, a completely different screen is briefly flashed onto the display.  The other screen displayed has what looks like a 5x5 leveling grid on the left side and the right side says "auto leveling, please wait.."

Thats a generic processing screen while its preparing for the task. I dont really see any pro or con to it being shown briefly as its clearing data and preparing, it needs to zero out all the current mesh data shown on the screen ans invalidate the stored mesh before continuing.

3. The ABL behaves differently depending on if you have a PC connected to the USB port or not.  When leveling the printer without a PC connected, after measurement is complete and the hot end is heated, the hot end is moved to a location somewhere around 50,50,0 and the message "Set Z Offset" is displayed and no information is given on how to proceed.  The message remains if you hit the 'back' button on the LCD.  I don't understand what I'm intended to do at this point, or what the purpose is.

Purpose here is to use the z offset buttons on the right to set the nozzle distance to the bed. Its just a status message sent and ill be shown until another action overrides it.

If you issue a measurement with a PC connected, instead of showing this message and moving, a popup window is shown that says "Click to resume..." with a yes/no box displaying the message "No Filament,click Yes to change filament or No to cancel." There are two problems with this message. First, it displays when filament is in fact loaded and the light is on on the factory supplied filament sensor. Second, clicking either yes or no does nothing except play different sounds. The message remains on the screen and the printer must be reset (power cycled, disconnect/reconnect with pronterface, etc) to continue. Pronterface shows "RTS_HandleData" and "waitway = 7" when either button is pressed and the sound played.

This is a known bug in pronterface. It is injecting M0 commands.

1. Upon bootup with the BIL firmware, the progress bar only displays for a moment, and the startup sounds are interrupted by the "ok" or "yes" sound. This doesn't happen with the UBL firmware, where the progress bar takes much longer, presumably because the interpolated mesh is being rebuilt from the stored probe values.  Minor issue but still startling to a new user of the firmware.

Bilinear loads much faster so the machine is done before the original wav is 100% done.I could put an intentional delay, but honestly im not keen on making everyone wait longer just to let the wav finish playing.

2. In several screens the firmware appears to fight with itself for control of different display areas:

* When moving, if you tap an arrow quicker than the printer moves, the current position will flash between the new value, the old, and back to the new.

Thats a movement buffer limitation, unfortunately not much that can be done with that one without structural changes to the API.

* When heating during a print, the upper left status area quickly flashes between "3d printer ready" and "heating..."

This was modified recently to update more consistently and prevent cases where it got stuck, but its too sensitive when temp is out of setpoint by even 2c changing to heating / cooling. A wider limit is already set to the messages in the dev branch.

1. When canceling a print, you're taken back to the "home" screen for 1-2 seconds.  It's just long enough for you to start tapping to enter other menus, before you're suddenly sent to the print confirmation screen just to click the finish button and have the printer move as described in the first issue.

Never paid attention to this one.. Ill see if i can eliminate the call to the home screen.

I'm willing to try different firmware versions to see if any/all of these issues are fixed, and have forked the project so I can try building my own version -- though to be candid, my intention in forking was mainly to try to add BLTouch support to the 1.1.x branch so that I can go back; 2.x seems a little too rough around the edges at present with these issues.

Back on 1.1.x the screen code was heavily embedded directly into the marlin core code. The big change with 2.0 is that this screen is now 100% through an externalized API. Its a solid showing of the intention of the API where screens can be controlled as a pure library with absolutely no direct includes to Marlin internals. In 1.1.x the screen code in some cases caused poor interaction with internal functionality and on 2.0 thats totally impossible.

Rather than focusing on small cosmetic nuances, development effort has gone into functional items such as the rewritten file browser, octoprint host support, mesh editing and manual mesh functionality, offset and pid screens. Currently, advanced pause and filament runout is getting a bit of an overhaul.