Anyone else have the problem of latest update not working? Gcodes load but when I go to start my print the file doesn’t load to touch screen. I went back to 4.2.3 and everything works great.
Hi There,
I’m new here and saw your post.
I recently got the latest firmware and since then it has been having problems with the nozzle heating up when starting a print job.
The target temperature says 0C while the G code says 205C.
I already created a support ticket, but the autoreply said it will probably take a week.
Who can help me with this problem?
I also have problems with Luban since the update. When I select the 10W laser, the program goes to home and it keeps the 1.6W selected.
2 Likes
Brace yourself for the possibility that things might take longer, since Chinese New Year is coming up in roughly a week (so if they don’t get to it in the next few days, it might end up waiting until after the holiday).
In general, about all you can do is report the bug and then either wait for them to fix it, or do what @wrencher did and roll back to a version of the software that you know works. You’ll need a USB key to roll back the firmware, if that’s what you want to do.
I have 2 A350T, neither is working with any new file sent from Luban 4.5.
That will work for downgrading Luban. I was replying to someone who was talking about the firmware on the Snapmaker itself, and unless something has changed recently, you can’t downgrade that over wireless.
Hi there. Just received my A350T along with the 10W laser, and before setting it up, I was wondering as this thread sounds like the automatic update process may create a bad situation. Can anyone positively confirm that they could work with the latest Luban (preferably on Linux) and latest firmware, using A350 and 10W laser? Or should I play safe and install 4.2.3 straight away?
I’ve got the same problem.
I will try to inspect the G-code. There should be something to find…
In 4.5.0 there are 6 lines in the G-code that haven’t been there before. After changing these lines to comment, SM is working again.
2 Likes
After this update…I am now done with Luban for 3D printing. I have had my SM2 for literally just over a year, and whilst Luban seemed to be ok for the first 6 months (as I was a noob) and I built up profiles and materials settings with a lot of trial and error and felt reasonably comfortable. But then as the updates came, more and more things started to hose themselves, and it seemed to get worse and worse (eg. odd slicing, lack of config, time estimates wildly incorrect, odd layer change things, UI glitches, wireless connectivity).
Now with 4.5 the time estimates are so far out, the nozzle and bed temps do odd things at the start, and reverting back to 4.4.0, I have superfluous menu items in the config profiles and weird layer change pauses.
People in this forum have always said “go to Cura”, but I have resisted as I thought Luban was actually “OK” for my noobiness. Well, the UI, is different for sure…but it only took about 5 mins to start printing with the Snapmaker addin, which works a treat. So…the part I was attempting to print, Luban said “1hr5mins”, and it actually took 38 mins. With Cura, it said “7 mins” and took… 7 mins and I swear the quality is far better too…even using default material and print setting.
I guess I should be thankful that Luban updated, and forced me to move !
2 Likes
I made some further investigations. Don’t worry. 4.5.0 will work. It’s just a change in the workflow.
After startup, the system waits until the bed reaches the setpoint temperature. Then the nozzel will be heated. After reaching the setpoint temperature, the print will be started.
I don’t know why they changed it. Now the startup procedure goes some minutes longer then before…
I have noticed that the print times have nearly doubled since the new update. I had a print that was 26 hours now upto 41 hours, whats going on?
It wasn’t simply that the items would not print on my machines, they also gave vague error messages from one attempt to print and no error message on a different attempt with the same file along with other odd behavior, like moving the tables and print heads (Both machines) to the absolute farthest extent the machine will allow. Further, the beds and the printheads would not “Home” prior to the print attempt and upon cancelling, there are unusual unexpected movements in the printhead on both machines. I have experienced self destructive behavior such as the printheads crashing into the laser bed and losing its default work origin forever and this seems like that self destructive behavior, just not as dramatic. I really do appreciate your investigation into the issue.
We confirmed the problem. A machine configuration update caused bed heating and nozzle heating to not start at the same time when printing started, will fix it in v4.5.1.
1 Like
Modify in the settings and modify 1.6W-> 10W again, if the Case Library shows that these cases are not successful. We found a display bug, but actually switched to 10w successfully
The problem you have encountered seems to be more complicated. If you can please contact our support(support@snapmaker.com) and provide more information.
I saw the issue with unexpected movement during printing later. Not very nice!
But at the end I can go on until SM will fix these issues.
I have a problem importing SVG files in Luban since the upgrade to 4.5.0. In the previous version, when I created an SVG in CorelDraw, Luban imported it just fine. In the new version, the dimensions are just wrong. In the following example svg, the dimensions of the polygon should be 5 x 10 mm. , and that was how it woirked in the previous Luban version. With version 4.5, Luban displays the polygon as 202 x 405 mm. Obviously, the relation of the viewbox to width/height is no more taken into account.
<?xml version="1.0" encoding="UTF-8"?><svg xmlns="http://www.w3.org/2000/svg" xml:space="preserve" width="5mm" height="10mm" version="1.1" shape-rendering="geometricPrecision" text-rendering="geometricPrecision" image-rendering="optimizeQuality" fill-rule="evenodd" clip-rule="evenodd"viewBox=“0 0 202 405” < polygon fill=“#ffffff” points="0,0 202,0 202,405 0,405 " />
I guess I’m just gonna stick with the older version until they fix this.