Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

5.7.0 gcode hangs Sidewinder X1, where v5.6 gcode works fine. #18814

Closed
frozentimeimages opened this issue Apr 4, 2024 · 4 comments
Closed
Labels
Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. Type: Bug The code does not produce the intended behavior.

Comments

@frozentimeimages
Copy link

Cura Version

5.7.0

Operating System

MacOS

Printer

Artillery Sidewinder X1, stock

Reproduction steps

Sliced simple STL file.
Tried to run on Sidewinder X1 printer.
(I then sliced with v5.6, and everything went fine. This was reproducible with other models: v5.6 OK, v5.7 hangs)

Actual results

The Sidewinder hung, the clock on the display kept running, but no attempt to print was made. Response to buttons was also sluggish. Felt like processor was in a tight loop.
This state continued for 20 minutes when I turned off the machine. Same result with different STLs.
Printer still runs fine with v5.6 files, new and old.

Expected results

The printer should have started printing...
Buttons should have responded quicker.

Add your .zip and screenshots here ⬇️

ASX1_Waste pipe collar small.3mf.zip

@frozentimeimages frozentimeimages added Status: Triage This ticket requires input from someone of the Cura team Type: Bug The code does not produce the intended behavior. labels Apr 4, 2024
@GregValiant GregValiant added the Status: Needs Info Needs more information before action can be taken. label Apr 4, 2024
@GregValiant
Copy link
Collaborator

Thanks for the report.
I generated a gcode of the project and it looked fine. The gcode shows the nozzle and bed heating and the print starts.

Post an "old gcode" and a "new gcode". Maybe they will show a difference. (You will need to zip them.)

@frozentimeimages
Copy link
Author

frozentimeimages commented Apr 4, 2024

Hi,
and thanks for the rapid response !
So I did my first ever gcode debugging today, and found that these two lines were at the beginning of the old, good file, but not the v5.7:
M73 P0
M117 Time Left 0h00m06s
They look like rather uninteresting display instructions, but by including EITHER of them into the 5.7 code, the print now starts correctly. Now the end of the print is a minor problem, in that it again hangs, when it should be parking and closing down. It moves to the side, but no more, and I have to manually kill the job. I tried some changes there, but didn't find the problem.

However, it seems clear that the hanging on start is related to the new display handling software.
It seems that the X1 hangs if it doesn't see some sort of old display instruction at the beginning.
I don't see the new display instructions though. Is the X1 not supported for it ?

Normally the touch screen is very responsive, but when it hangs, I have to hold the button for a few seconds to get a response, so it seems that the processor is very busy doing something, rather than stopped.

I include 5 files:
56 is v5.6 that works.
57 is v5.7 that fails.
57a has both M73 and M117 added, and works.
57b has M73 added, and works.
57c has M117 added and works.

Does this help you ?

Mark

CuraX1_test.zip

@github-actions github-actions bot removed the Status: Needs Info Needs more information before action can be taken. label Apr 4, 2024
@GregValiant GregValiant added Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. and removed Status: Triage This ticket requires input from someone of the Cura team labels Apr 4, 2024
@GregValiant
Copy link
Collaborator

Yes it does help
For some reason, the Artillery printers rely on post processing to be able to print. That is really dumb. If you put "M73 P0" into your startup gcode it may work. The "print percentage" on the LCD won't change, but it should print.

This bug goes on me because I obsoleted "Display Progress On LCD" and "Display Filename on LCD" and included them in "Display Info On LCD" which is new for 5.7.0.

Looking at your gcode, you can see the M73 line goes in as the second line in the gcode. That is actually not allowed because other post processors will look for the Time line and it has been pushed down. Printers like Creality don't like that.

If you load the post processor "Display Info On LCD" and have it set to "Display Progress" you will see that the M73 line is available to be inserted. With the "P" parameter it starts the percentage counting up...maybe.
M75 and M77 might also be involved. There is no way to tell what the Artillery people were thinking when they did this.

If you are using Octo-Print you might also have to add the M118 line with the A and P parameters.

This problem was brought up previously in bug report #18766 and I have made the changes to the file but not in time for 5.7.
I'll mark this as a duplicate.

It is really odd that the printer won't run unless the Print Time Clock is turned on and neither your definition file nor your printer do it as a matter of course.
If you continue to have a problem let me know. I don't have one of those printers and debugging from afar isn't easy, but I can give it a shot.

@frozentimeimages
Copy link
Author

Hi,
And thanks again for your rapid and thorough response. It's amazing that you guys manage to keep this code supporting so many, and such old printers.
It turns out that all I needed to do was activate the new DisplayProgress extension, with M73 checked.
Running the 5.7 beta with that enabled, everything works fine, including showing progress, and shutting down.
So case closed from my perspective.
Thanks again, and keep up the good work.
Mark

@Vandresc Vandresc closed this as completed Apr 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. Type: Bug The code does not produce the intended behavior.
Projects
None yet
Development

No branches or pull requests

3 participants