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.

Sign up for GitHub

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

Jump to bottom

Bug / Incompatability with 3.5.1 on Sidewinder X1 #15

Closed
ColinBathe opened this issue Apr 1, 2021 · 16 comments
Closed

Bug / Incompatability with 3.5.1 on Sidewinder X1 #15

ColinBathe opened this issue Apr 1, 2021 · 16 comments

Comments

@ColinBathe
Copy link

I've been using ArcWelder a lot and version 3.5.0 has worked great for me. Unfortunately 3.5.1 has all sorts of problems.

Best shown from an example:

This is Cura. The model is a single layer ring and it has a two loop skirt around it.
image

If I print using 3.5.0 then I get this:
image

If I switch over to 3.5.1 then I get this:
image
image

The first one and a third loops of the skirt print fine but the last two thirds of the skirt and part of the central ring get converted into an arc with great extrusion output.

Gcode created with 3.5.0, 3.5.1 and with ArcWelder switched off are here:
bug.zip

Slight variations in the model cause different effects. I produced this when I first hit the problem though I don't have the files for this one.
image

Printer in use is the Sidewinder X1 v4 with stock firmware. I'm guessing the issue is with the G2 / G3 firmware support within the Sidewinder but as 3.5.0 works so well, it would be great if this could be sorted within the plugin.

Big thanks to you and all those working on ArcWelder. It has significantly improved the quality of my prints and I have it permanently switched on.
@fieldOfView
Copy link
Owner

Could you post a saved gcode file from both the 3.5.0 and 3.5.1 version of the plugin?

What I think may be happening is that the 3.5.0 version is not actually working on your system. IE: it may do nothing to the gcode, and the improvement that you see may just be your wishful thinking. The 3.5.0 version of the plugin shipped with a version of the ArcWelder tool that required a runtime dependency that may be missing on your system, resulting in the tool not being able to run and thus not changing the gcode from the original. The version of ArcWelder that comes with the 3.5.1 does not require said dependency (it is statically linked), so it may be the first time the plugin is actually making changes to your gcode.

I'm not 100% sure. If you post gcode samples from both versions of the plugin I'll be able to tell what is going on.

@ColinBathe
Copy link
Author

Hi Aldo,

Thanks for looking into this.

You will find some gcode examples in the zip in the first post. Get back to me if these aren't suitable.

3.5.0 definitely works on my machine as the gcode in the zip shows. Comparing the two files, the 3.5.1 version includes trailing zeros were as the 3.5.0 doesn't. This isn't the issue though as I tried removing them but it made no difference.

@fieldOfView
Copy link
Owner

Sorry, I missed the link (too many pretty pictures to look at ;-).
I'll have a closer look.

@5axes
Copy link
Contributor

5axes commented Apr 2, 2021

3.5.0 definitely works on my machine as the gcode in the zip shows. Comparing the two files, the 3.5.1 version includes trailing zeros were as the 3.5.0 doesn't. This isn't the issue though as I tried removing them but it made no difference.

On my point of view it's not trailing zeros but in 3.5.0 You have a small line before the G3
image

3.5.0
image

3.5.1

image

If you have an issue this is certainly due to this difference.

And not in 3.5.1 But this is a question for @FormerLurker

@ColinBathe
Copy link
Author

Ok, I've been investigating this further my end. I'm almost 100% that this is a firmware issue in the Sidewinder.

Line 69 is the first problem with the Test Ring 3.5.1.gcode. With it in place, it causes the bad parameters message.
image
G3 X167.287 Y153.518 I-16.787 J5.383 E7.96528

Now I'm not an expert on gcode but this line looks entirely sensible to me.

If I edit it though and replace it with:
G3 X167.287 Y153.518 I-16.7 J5.3 E7.9
That line now works and prints successfully up to and including that instruction with no bad parameter message produced.

Unfortunately, there is some issue with the rest of the ring (next 8 lines) as well and doing the same rounding trick doesn't work with them. I did get some interesting shaped prints though. Minor changes to the numbers produced dramatic changes to the output.

Your gcode viewer seems to think the 3.5.1 file is fine as does this viewer here: https://nraynaud.github.io/webgcode/
My conclusion is therefore that it is a Sidewinder firmware issue. The only strange thing is that I've never hit the issue with 3.5.0 where as I have seen similar issues all of the time with 3.5.1.

It would be useful if anyone could work out why my Sidewinder has issues with 3.5.1 but not with 3.5.0 but I guess this is a low priority.

It would also be nice if there was an easy way for users to swap between 3.5.0 and 3.5.1 that I could pass on to other Sidewinder users. I couldn't find an easy way so I've been using Git to do the swap. This is likely beyond most people.

I've been putting off upgrading my firmware but I think that is going to be my next trick and we will see if that sorts this issue.

@seantapscott
Copy link

seantapscott commented Apr 3, 2021 via email

@fieldOfView
Copy link
Owner

One thing to try is to see what the ArcWelder executable included with the 3.5.1 does with the 3.5.0 plugin (see the bin filder). The 3.5.1 version of the plugin adds two settings that should be optional but isn't. The next version of the plugin will fix that. Perhaps not having these settings set fixes your problem.

@ColinBathe
Copy link
Author

@seantapscott I'm running stock firmware which is a version of Marlin.
https://github.com/artillery3d/sidewinder-x1-firmware
#define SHORT_BUILD_VERSION "1.1.9"

@fieldOfView
3.5.0 with the 3.5.1 binary goes wrong
image

3.5.1 with the 3.5.0 binary works ok.
image

@seantapscott
Copy link

seantapscott commented Apr 3, 2021 via email

@ColinBathe
Copy link
Author

Arc Support does look enabled, but ArcWelder utilizes features from the newer Marlin. You'll probably want to compile a newer version of your firmware.

Yes. That is my thought also to sort the issue and I'm looking into that now.
What is weird though is V3.5.0 of ArcWelder appears to be compatible (I've never had an issue) were as V3.5.1 fails repeatedly. Something in V3.5.1 triggers the fault in the firmware though what it is, is not obvious.

@ColinBathe
Copy link
Author

Well this has been fun....

I decided to go down the compile your own firmware route so I took the Marlin 2.0.7.2 source, modified the configuration files for the Sidewinder and dumped it into my unit. It took a few attempts to get right but is now working fine.

Time to try my V3.5.1 test print again ...
... and it failed again in exactly the same way again. It is therefore not an old firmware issue.

After a bit of head scratching, I decided that the issue has to be something else that I hadn't explored yet. One possibility was the USB stick that I was printing the file from as it was the one supplied by Artillery and has a reputation of being a bit iffy.

So I switched to a µSD card and exactly the same file printed absolutely fine.

I then repeated the print by placing this µSD card into a µSD USB card reader and printed using this in the USB slot. This time the print failed.

Overview:

  • Test Ring 3.5.1.gcode printed from Artillery USB stick in USB slot failed.
  • Test Ring 3.5.1.gcode printed from µSD card in µSD slot printed fine.
  • Test Ring 3.5.1.gcode printed from µSD card in µSD USB reader in USB slot failed.
    (All failures are identical and are the same as the failures seen above. Results are also repeatable.)

My current conclusion is that my test print fails if generated with ArcWelder 3.5.1 AND printed from the USB slot in the Sidewinder. If it is generated with ArcWelder 3.5.0 OR if it is printed from the µSD slot then it prints fine.

I can't imagine what sort of weird bug is causing that nor how it could be investigated. However there are two work arounds, use 3.5.0 or use the µSD slot, so I'm going to stop investigating this end unless someone can come up with something useful I could do.

I'm happy for this to be closed if everyone else is as I think it unlikely the issue is in the plugin.

@FormerLurker
Copy link

Have you tried the latest bugfix branch? There are a few edge cases that were fixed since the last stable release of marlin.

@seantapscott
Copy link

seantapscott commented Apr 7, 2021 via email

@ColinBathe ColinBathe mentioned this issue Apr 23, 2021
Open
@ColinBathe
Copy link
Author

Ok, more investigation and another fix.

State of play:
Mainboard: Marlin 2.0.7.2
LCD: Stock firmware
Cura: 4.8
ArcWelder: 3.5.1

Test file in ­µSD slot I get an expected print.
image

Moving the same µSD card into a USB reader in the USB slot,
image

I then get this failure.
image

The above is repeatable.

The problem seems to be associated with the USB slot so I upgraded the LCD firmware to see if that would help. I used the firmware given here: https://www.thingiverse.com/thing:4294049

This solved the problem and the file now prints successfully from both µSD card and the USB card slot.

I'm going to close this bug report as I think the problem is historic and solved by upgrading to latest firmware on both the main board and the LCD. I don't believe there is a problem with ArcWelder. Weird bug though!

@fieldOfView
Copy link
Owner

Thanks for persisting with your tests, finding a solution and letting us know!

@FormerLurker
Copy link

Wow @ColinBathe, that was some clever sleuthing! Bravo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@fieldOfView @5axes @seantapscott @ColinBathe @FormerLurker