Bug Reports and Feedback for Snapmaker-GD32Base-2.X


#22

Strang behaviour with firmware 2.7:
M140 S80
M190 S79
leads to:
Warming up the bed and waiting for 80° and then start printing with 79°
Did you mix up M140 and M190?

Since my heated bed is to weak for 80°, I changed M190 manually to S79 in all gcode files. It worked with 2.4. But not with 2.7.


Calibration alignment
#23

Firmware Version 2.7

Hi All, just updated to Cura 3.6 and the latest Snapmaker firmware v 2.7 and they are not playing nicely on my W10 system and I cannot print via USB cable. Placing the print file on a USB stick works OK. I will investigate further, has anyone else experienced this? BTW SnapmakerJS and Simplify3D work OK across the USB cable.

Doug


#24

I just restored the firmware to the 2.6 version and all is working well again; this was my plan if all else failed. Reminder to everyone to re-calibrate after changing firmware.

Doug


#25

Got my new snapmaker today together with the enclosure. After putting it together I also updated to 2.7. I made some adjustments to the profile to increase adhesion, all fine. I use direct USB connection. It starts to print the brim, first layers look good. Then I close the front door of the enclosure (left door was already closed) and the printer goes bonkers. The heatbed suddenly moves a lot towards me, the printing module tries to go deeper, motors make strange noises. I open the door and stop the print. I recheck calibration, all fine. I close the door from the beginning and restart the print. This time the module tries to start printing ca. 5 cm above the bed and the bed moves completely towards the door again. I stop it again and now print with the front door open and it seems to work just fine.
Before I try more troubleshooting with the risk of damaging my printer: Is this a known bug? Any hints?


#26

My enclosure has finally arrived but I’ve yet to pick it up from the post-office.
I think you need to deselect door detection from the setup and/or maybe disconnect the door sensor from the controller for the time being.
This is apparently a known issue, and others have rolled back to the previous version of the SW/FW.
I will be waiting for a fix before updating.


#27

An update of my found problem with y-axis shift with 2.6 code…
As the problem has re-appeared, I started to think what could be happening, as I did not see any skidmarks on the printed material, and besides, my magnetic surface would have been ripped off in case of a collission, not the axis shifted, as that will take quite a lot of force, normally impossible to do by hand.
EXCEPT for the Z-axis, that one is not powered when doing x-y moves, as I found out when running a self-written G-code
G0 X0 Y0
G0 X125 Y125
G0 X0 Y0
<repeat 1000 times>
while running this code, I was able to move the Z-axis up and down quite easily by hand, so the motor is powered down when not needed. This is definitely unwanted, as the motor is required to hold the axis.
Further I know I used Z-hop in my failed prints, to reduce drag and collision-danger with complex shapes and supports. So maybe you should take a look at the motor power states during printing so they will be powered unless explicitly switched off with M18.
Or do we need to specify an M17 in the startup-code for all motors to be powered all the time?

I will also inspect my controlboard to see it there may be a heat-problem.

Edit: the problem is really some hang while moving. I did now print several times the same print, and it does hang on the same spots every time today.
At layer 23/24 there is a 4mm jump on Y, and 6 layers above that, the X takes a jump of 25mm.


RightArrow2b.gcode (2.1 MB)


Randomly x-y-offset while printing
#28

Try use slower speed (30mm/s) to see if axes shift. Slower speed can reduce the resistance of linear module to make it work slightly smooth. Another suggestion is to change the position of the model on platform to diagnose which part of linear module goes wrong. And please contact support@snapmaker.com to get further support.


#29

Firmware bug!
Look there:


#30

You are right Alfred,

In V2.7 the firmware, you can choose to use the Door Detection feature or not in Snapmakerjs instead of choosing firmware files.


#31

While the logic to slow the machine down is sound, it doesn’t address the issue. If a machine spec’d to run at up to 100mm/s it should be able to operate at 100mm/s, that is the point. Mine is also having the same issues with the y axis shifting after a firmware upgrade. It worked beautifully prior to this upgrade unfortunately. 10 failed prints later I am pretty frustrated with the machine.

Here you can see the properly printed parts (from a different printer) on the bed next to the failed print from the snapmaker.


#32

Yes it should be and the recommended speed is not exceed 60mm/s.

The resistance comes from the inner installation of linear module (too tight), but it’s too difficult for users to diagnose what exact problem is. Also risky. If you do have the problem and unable to fix it by yourself, I would recommend you to contact our support.


#33

Yes. And the positioning malfunction (due to the door switch) comes with 2.6 and 2.7.


#34

Straight from the website.

There are absolutely a number of other variables that could cause this to happen but the one thing that has been reported commonly from people is that it happened immediately after a firmware upgrade. I have lowered my print and travel speeds to as low as 40mm/s and my acceleration to 300mm/s^2 with no improvement in prints. I had thought at one point that potentially the linear rail on the y axis was “bad” and was causing the issue since it was limited to only that axis. The y axis is also working against the least amount of inertia during operation and should struggle the least. However before getting into flipping physical parts of the machine around, a downgrade to the 2.4 firmware (the first I could find that still supports the 1600mW laser) appears to have fixed the issue. Reprinting the exact same gcode successfully completed. Increasing speeds to 100mm/s for print and travel with acceleration back to 500mm/s^2 is yielding correct results once again as well. Anecdotally it appears to be a firmware issues as other people have also stated that a downgrade resolved their issue.


#35

Hi Snapmaker Team,

I’ve currently some issues with the current version of firmware (GD32Base 2.7). Since I’ve updated my Snapmaker to this firmware version, I’m facing issues with calibration. Usually, after an update, I needed to re-calibrate the device. But with this version, calibration is not possible anymore because of wrong positioning of the printer module. If I choose calibration position 1 the printer module will move too far left from the heating bed (around 10mm), so if try to lower the z-level the nozzle will fail to touch the heating bed.
I’ve noticed this issue even with version 2.6. But if I downgrade to version 2.5 it works fine again. So there must be a problem with the firmware version 2.6 and 2.7.

Please advise.

Best regards,
Reza


#36

Did you perform a reset first before calibration?


#37

I’m not sure anymore. I’ve tried many things. I’ll do that explicitly reset first and then try to recalibrate and hope it will work!


#38

Check out my post: bug-reports-and-feedback-for-snapmakerjs-v2-5-x


#39

@BriHar Thanks for your response. Unfortunately, reset did not help. I still have the same issue. I assume this is definitely a firmware bug since after I downgrade to 2.5 calibration works properly.


#40

Hello @Rainie,
In regard to the newest 2.8 firmware update, points 1 and 2 concern fixes for bugs which, as far as I can tell, do not affect me.

I recently updated the Firmware to 2.7, and Homing and Calibration seem to be working just fine, as they were with the original (i.e. factory installed) Version 2.5

So I am a bit apprehensive about installing an update targeted with fixing bugs that I don’t appear to have.

It strikes me odd that issues which only affect some users would be addressed in a general firmware update.

I could understand if the bugs in question are perhaps the result of undefined start values or variables, or something similar, that some might have these issues and others not. If the update simply rectifies ambiguous parameters or something comparable then I’m relieved. You can certainly understand that it would be irritating to suddenly start having issues as a result of this update.

The fix for the Laser would definitely be welcome, so I’d be grateful if you could put my mind at rest, and assure me that there should be no negative impact installing this update.

Thanks,
Brian


#41

Hello @Rainie, @parachvte, @Jade or someone there at Snapmaker.

[See previous post above…]

What exactly was wrong with the firmware that needed to be fixed considering that apart from a few people it seems to be working fine?

Looking at this from another perspective - If the firmware has bugs, why isn’t everyone affected?

Would it be possible to get some feedback on this?