I understand the idea you’re communicating, but I don’t agree.
I think you would be surprised at how little the touchscreen is doing. I have operated the machine without the touchscreen plugged in (via USB).
I think the gremlins are more likely tied to FreeRTOS. There are reasons Marlin dropped support for it, not all of which apply here. But I recall it was a struggle to keep maintaining.
Slicers are not the issue here. MJs issue was not a quirk of the machine as much as a fault in the slicing I thought.
I think sonmiums issue is best solved by support, and I’m buckled in, ready.
The probe sensor on the head works fine the mesh datas right after the calibration are „good“ too. The limit switches in the z axes working properly both of them. So it has to be a software/firmware bug
So - on the particular example for me, a slicing section which was felt problematic was recognized (albeit there were several varying opinions about it, some of which seemed more logical than others).
I was satisfied when a specific line was pointed out and the reasoning behind why it would fail on this line, although i can’t really say for sure it ever actually failed on that line. Once some kind of logical reasoning as to why the machine would not execute the slice properly, it made me feel better. prior to that it was “use luban” and “its too fast” even when i was running very slow.
I don’t think I would feel comfortable in stating the machine is without issues like this, because I have had many similar scenarios and not necessarily tied to that slicer.
Also, the linear modules themselves were in fact failing, i have one that is really bad, others that are “kinda bad”. swapping them out solved the problems in most cases.
Beyond that - I still feel the firmware has some kinks in it (i dont think anyone can argue this) and i still feel like they “rigged” things to work in a controlled fashion and didn’t anticipate people wanting to do more with the machine than they put out (luban).
Is it a fair statement to make that Snapmaker is still not using the public branch in the github? i know the last time there was an update that was the case and they said “it was going to be the last one”. I don’t know MUCH about what all that means, i but i do know several people who had added fixes and improvements that were continuing to not be rolled out, and dont know if this is still the case or not.
it seems like after all this time the userbase have identified and rectified so many problems, be it firmware or hardware, that at this point i dont even know what i have and dont have.
Sure would be cool if the versioning used in the controller could be matched with the bundled firmware versions. V1.12.2 vs 4.2.3. Is the public repo being used? Who knows?!
Release notes would be great in the form of: RELEASE 1.13.X
- Controller build 4.2.3
- Module build 1.39.420
- Touchscreen build 1492
So its been a while and want to give some update so the support and i tested a lot of things but nothing of it made it to a solution so the support suggests to swap out hardware components starting with the controller that arrived yesterday and today i will test if this helps! My suggestion was maybe the controller got a little overvoltage due to the fact that the printhead got stuck and the stepper motors continued to work/move and permanently damaging the memory of it
@Somnium i was thinking possible over voltage but had no way to test it as it hasn’t happened to me. Those motors generate their own voltage on power up, I think it getting stuck mimicked that situation and killed itself.
@Somnium thats what I would bet. It’s also possible the splitters are somehow compromised, anything within that line between the rails and the controller could’ve been overloaded. Thinking of it that way, it makes sense that the controller didn’t get zapped if something earlier in the line got zapped first.
I once blew a motherboard because of a thumbscrew that got lodged between the mount tray and the board and shorted it out, blowing a transistor which actually protected all other components from damage. Thinking of it like that, it makes sense.
I have a quick-change laser bed which is 6mm higher than the normal laser offset. I got the laser calibrated (which is a story in itself) and then changed back to the 3D printer.
I sent the 3D printer home, which first reported to Luban that Z = 334.00mm and then when the homing process completed, Luban showed the Z axis at home changed to 325.00mm, which is a full 9mm too high. The 325mm is the default uncalibrated value put there by the firmware. When displaying the mesh data with M420, all the values show 9.00mm.
I told Luban (via USB serial) to go to the work-origin (0,0,0) and it did, but the Z axis is 9mm above the bed and won’t go further down when jogged… just as you found on your machine. The auto-calibration fails with the message in Luban console that the proximity sensor failed. The only way to set this Z axis offset is to do either a manual or auto calibration. It can’t be set any other way (as far as I know).
So I switched to manual bed levelling calibration. I used the M502 to reset the machine, which resets the Z axis at home to 334.00mm, and that allows manual calibration because the head can be moved down to the bed surface. I still can’t do an auto-calibration though.
In your case, I don’t think you damaged anything when it crashed, I think changing from glass bed to normal heated bed reduced the height, and you can’t get the correct Z axis offset to allow your head to meet the bed because the software still has the higher Z offset.
In my case, I have had to abandon the laser for now, and just use the manually calibrated 3D printer. I wondered if recalibrating the laser or CNC would reset the Z axis, but haven’t been able to do that because I need the printer more than the others, and don’t want to risk losing the manually calibrated bed figures.
Take a backup of your M503 output. It’s valid gcode and and be copy/pasted into a macro to be run to setup the printer the same way again, including your mesh values. You’ll notice M503 contains all of your mesh calibration points in the form of G29 W commands
Your laser/3DP Z heights is a weird one, they shouldn’t be affecting each other as they don’t even use the same coordinate system - 3DP is done in native machine space G53 and lasering is done in work coordinate system 1 G54 to apply the laser focus offset.
Thanks Brent,
I have backed up my settings… I only get to play with the machine every Friday as part of on-the-job training. Do I need only the G29 W commands or do I need all the commands from that output?
The 3DP auto-calibration worked, then I changed to the laser and got it calibrated with the work-origin raised by 6mm. On going back to 3DP, the head was too high up above the bed. I assumed it was due to setting the higher work origin in the laser.
If you are only interested in the mesh then you only need the G29 W commands. There are other settings you should consider calibrating including eSteps, acceleration, and linear advance, so it’s always safe to just take a full backup.
Yeah, I feel like that’s a good assumption to make, however I think that’s not how it works in this case and something else has happened.
I don’t really know where to start with troubleshooting this. You made a comment about the mesh was reset to the factory default. That should never happen unless you issued a reset. Any idea how that happened? I have seen other people on here comments that settings are sometimes not saved between power cycles, I’m wondering if you have a faulty controller that has some bad memory or something.
You might be best served by just directly creating a support ticket with snapmaker because in the event you need any replacement parts you’re going to have to repeat all of this to support anyways.
Update time
Seems like im not the only one with strange issues!
So the support is not answering anymore since almost a week and im starting to get realy annoyed by this! I ordered a creality printer bc i think im not reaching my goals with the snapmakers ability of 3d printing with is sad had high hopes for it! I didnt tried it but can i still use laser and cnc with this issue?
@Somnium they haven’t been answering much of anything within the last couple weeks, don’t know what’s going on but people are getting really frustrated. As for your issue at hand, as it was caused by a physical obstacle, I don’t think it’s happened to anyone else at all, ever. Refresh my memory, are the y rails operating normally? X rail? It was the z rails and mesh calibration having issues right? I’m wondering if maybe the head got over volted. Also, has a factory reset been attempted? I have a suspicion of late that the memory isn’t completely flashed because of certain odd issues persist that started with 1.13.1 and rolling back doesn’t fix it, but factory resetting does, no clue what’s going on with that.
No he definitely broke something, it happened once, very quickly again a second time, broke the sensor housing and the print head got caught on a clip and tried to do a freaking autopsy on itself by attempting a bed dismemberment. I switch between glass and magnetic sheet sometimes, it’s not because of the difference in height, mine works perfectly fine.
Ok but i write with him over skype and he saw my messages and just not answered
Everything operates normal its the z rails that are effected. Maybe its something with the probe sensor he is working but maybe not fully. The switch between glass and normal schould not be a problem i switch between them befor and it worked fine back then but not after the crash.
ready.
