ANYCUBIC-3D / Vyper

Firmware of Anycubic 3D printer Vyper
GNU General Public License v3.0
106 stars 60 forks source link

Unable to resume print on "Pause at height" or "Filament Change" #16

Open BlackBoxThe opened 2 years ago

BlackBoxThe commented 2 years ago

Description

On Anycubic Vyper firmware 2.4.5, try to change the filament during the print.

In Cura 4.12.1, try to use "Pause at height" or "Filament Change". The printer stop, but next it would not resume because there is no resume function on screen.

Steps to Reproduce

  1. In Cura, slice a STL file

  2. Go to Extensions -> Post Processing -> Modify G-Code Add Post processing script either "Pause at height" or "Filament Change" (choose the wanted layer to paused)

  3. Save to SD Card

  4. Start the print

  5. The printer paused at the layer

Expected behavior: When the printer go to "paused", we can do what we want (like change filament) and we can resume the print.

Actual behavior: When the printer paused, it is impossible to resume the print.

eboule commented 2 years ago

I can confirm the issue using Anycubic Vyper firmware 2.4.5.

Dominik-1980 commented 2 years ago

If you have the printer connected to a PC you can send M108 over the terminal. It would be great if there will be a button on the LCD in the next Vyper Firmware!

igrowing commented 2 years ago

Same here. @Dominik-1980 thanks for the workaround. It would be great to have "M108" feature implemented into the next firmware release.

svcru commented 2 years ago

I can confirm the problem too. Using Anycubic Vyper Firmware 2.3.9. (firmware installed by the manufacturer)

fordmaxson commented 2 years ago

I can confirm 2.4.5 too. Help us out Anycubic.

GuhPires commented 2 years ago

Spoke with the Anycubic team and that was the response about the "Pause at Height" feature:

Sorry, our printer currently does not support the "Pause at height" plugin in the slicing software and the G code to pause the printer.

You can try pausing the printer manually on the display and changing the filament of a different color.

In addition, we have feedback your email to the product engineer. Future firmware may be compatible with these plugins. Stay tuned.

Have a nice day

regards

Anycubic Team/BELL

As far as I know, the slicers use M600 GCode command in order to perform the filament change feature, and there's indeed a file here that has such feature, so I am not sure why it's not working. My guess is that you should enable that manually into some config file directly at the firmware code, then update the printer with the changes.

GuhPires commented 2 years ago

If you use some GCode serial sender app (like Pronterface) you can send a M600 code and the printer will understand and do everything BUT moving the head out of the printing area, the issue is that no message is sent to the display and you cannot continue the print unless you manually send a M108

hbertsch commented 1 year ago

It's a shame that this command is working only "partially". I guess it is only an UI problem (?) where they did not implement a button that can be pressed if the printer received an M600. Maybe someone already created a fork and fixed this but I can not find something. Imo without the M600 support a lot of value is lost here, since it makes color change very cumbersome.

hbertsch commented 1 year ago

If you have the printer connected to a PC you can send M108 over the terminal.

@Dominik-1980 as it seems this is not working. Started the print via Pronterface and tried to resume it with M108 but the printer does not continue:

echo:Insert filament and send M108
>>> M108
SENDING:M108
Disconnected.
Connecting...
Printer is now online.
line: 208 func: process_injected_command_P
echo:Unknown command: "M10M105"
<<< do_homing_move  X125.84 Y222.96 Z4.00

The only working way for me is, to export the G-code and then cut it into pieces ( at the ;LAYER_CHANGE flags) where I only print layers in one color and switch the color in between.

GuhPires commented 1 year ago

It's a shame that this command is working only "partially". I guess it is only an UI problem (?) where they did not implement a button that can be pressed if the printer received an M600. Maybe someone already created a fork and fixed this but I can not find something. Imo without the M600 support a lot of value is lost here, since it makes color change very cumbersome.

I guess... But I never found the code for the LCD screen, otherwise I could see if I can add such button when the processor reads the M600. Another weird thing is that the printer head just go up, it doesn't home the X and Y axis as it supposed to do 🙃 (to not mess up the print)

GuhPires commented 1 year ago

The only working way for me is, to export the G-code and then cut it into pieces ( at the ;LAYER_CHANGE flags) where I only print layers in one color and switch the color in between.

@hbertsch I actually slice 2 different bodies and set a z-offset for the one on top, the issue is to correctly align those pieces on a slicer like Prusaslicer - I have to export a full body and then split the bottom half and save, then cmd + Z and split the top part and configure the z-offset. This is the only way I can switch colors, as if they were 2 separate prints

hbertsch commented 1 year ago

Thanks for the mention @GuhPires. I also asked the Anycubic Support about the issue and this was the response:

Hi,Thank you for your letter. I am Abel, after-sales technical engineer.(Due to the time difference and occasional vacation, sometimes the communication is not very timely, I hope you can understand, thank you)Tip: Please do not change the subject of the email. Otherwise, the system will not capture your E-mail to the engineer's account. thank youWe officially have no support for the M600 order. You can modify it in the source code if you want.Have a nice day!Kind RegardsANYCUBIC/Abel

So no implementation is planend. I also tried to send the continue command to the printer via USB, but it seems it is not supported at all :/

ReverendRhyme commented 1 year ago

So, yet one more reason to go with a custom firmware. Since they don't care or plan to care. smh

GuhPires commented 1 year ago

So, yet one more reason to go with a custom firmware. Since they don't care or plan to care. smh

@ReverendRhyme seems like that's the only option, or maybe to hack the hell out of the firmware, which I think that could be easily done if Anycubic provided the source code for the screen - and also documented how to communicate with the machine - this way the community could build workarounds to things like this.

The main issue is that, if you use your printer to work (a.k.a. sell prints) you cannot risk installing a "bad" firmware, so not having features such as this one can be a decisive topic when choosing the printer (but I am guessing that they don't really care about Vyper anymore)

ReverendRhyme commented 1 year ago

So, yet one more reason to go with a custom firmware. Since they don't care or plan to care. smh

@ReverendRhyme seems like that's the only option, or maybe to hack the hell out of the firmware, which I think that could be easily done if Anycubic provided the source code for the screen - and also documented how to communicate with the machine - this way the community could build workarounds to things like this.

The main issue is that, if you use your printer to work (a.k.a. sell prints) you cannot risk installing a "bad" firmware, so not having features such as this one can be a decisive topic when choosing the printer (but I am guessing that they don't really care about Vyper anymore)

I've been running Community Firmware 6.1d now for about 4-5 months. Best decision I ever made. This should have been the stock firmware, to begin with. But as you say, they don't care about the Vyper anymore. I couldn't agree more with that statement. They have moved on.

GuhPires commented 1 year ago

@ReverendRhyme yep, they clearly moved on. And I will say more: with this new heated up market + companies moving on to other firmwares such as Klipper, I bet that even their latest printer will suffer from abandoning the users in terms of code maintenance - I don't think they have planned any LTS version for those new printers too (and they probably run the very same firmware as Vyper 🤷‍♂️)

hbertsch commented 1 year ago

That is really unfortunate. But ok... at least it was a cheap printer. Next time I will get me a Prusa. Had one before and they had Firmware Updates every other month.

@ReverendRhyme does the Community Firmware solve the layer change issue? Did you have any issues flashing it or any advice for us what we should be aware of? And would you be so kind to share the link to the project? Many thanks in advance!

Khaladan commented 1 year ago

You can resume a print on latest stock firmware after filament change. You have to send the M108 command using a terminal window via octoprint or similar usb connected device.

ReverendRhyme commented 1 year ago

I've been using CE 6.1d and Octoprint. I can resume after a filament change via the LCD screen or octo. I did not have any issues flashing. Others have had problems, but those have always seemed to come down to the understanding that the SDCards need to be FAT32 4096 or the SD Cards are bad.

Adjusting your Z offset while printing from the screen is also great for leveling and getting that perfect first layer.

https://pasha4ur.org.ua/articles/anycubic-vyper-overviews-guides-adjustments-settings-tips-modifications-upgrades-and-custom-firmwares/8

v6.1d firmware for Anycubic Vyper v0.0.6[(board] (https://github.com/rommulaner/Anycubic_Vyper_MB_CE_6.1d/blob/main/Anycubic_Vyper_MB_CE_6.1d.zip) and display) Source and description on github Fixed Z-offset problems.

hbertsch commented 1 year ago

@ReverendRhyme I finally had the time to flash the firmware and it went through smoothly. Thank you for the links and hints. I haven't tested it yet but will do so in the next days :)

Maybe the following is usefull for other mac users. In order to correctly fomat the mini SD card for flashing the display use your terminal:

# find out the name of your card (e.g. /dev/disk2)
diskutil list

# unmount the card (required before formatting)
diskutil unmountDisk /dev/disk2

# format it using 4096 cluster size
sudo newfs_msdos -F 32 -c 8 /dev/disk2

# re-mount your card in order to copy the required files to it (the DWIN_SET folder)
 diskutil mountDisk /dev/disk2

Notice: after flashing the display the touch input did not work any longer. I found a working solution on Redit (I will link it here and also place the config file and description in here):

This was confirmed to work on the Vyper screen (PN: DMG80480C043_02WTRZ07 as seen on back with case popped off). I do not know if it works on others. Someone tried a Kobra once and it didnt help but I can't be for certain they had the same issue. Try at YOUR OWN RISk!

If you have another screen model you can try finding the manual on it, finding which line of hex data in your .cfg enables the touch calibration, and use a program like UltraEdit to open, edit, and save the .cfg....

INSTRUCTIONS: FAT32 allocation of 4096 on microSD. Add the .cfg file on the SD card under a DWIN_SET folder. This must be the ONLY file in that folder, and the ONLY folder on the card. Make sure of this. Plug in the SD and boot on the machine. The blue screen will only show a 001 next to the cfg line, no other numbers will be shown. Once you see that and the "end!", touch the corners of the screen in this order (clockwise circle really) top left top right bottom right bottom left

Power off and unmount the microSD. I hope this helps!!

Config File for touch re-calibration: Vyper Touchscreen Recalibration CFG-20230205T184334Z-001.zip

Update: I just tried out the resume function and it is working like a charm! So good to have this option now :)

vyper_community_fw