Yes im very thankful for this 
Would have cost some time with the support! What do you mean by tramming or tram? 
If you don’t mind elaborating, what changed that allows this to be possible now.
The step, direction, and enable lines are duplicated in the splitter. Without adding some additional functionality somewhere individually controlling the stepper motors would not be possible.
Is this new functionality on the next generation of rails that does not apply to the current generation? Or has there been a firmware update for the current rails that somehow makes this work? I didn’t think the stepper drivers were tied to the controller inside the rails so any additional functionality could be added.
Do you have any reference that supports your claim? I don’t see any change in the controller source code that supports this.
Ok, done. They move in the exact same way. I even deliberately pushed them in such a way that they weren’t aligned, and surprise, they stay that way.
(Thanks now I get to tram them again)
So no, both z-axis are not controlled separately.
And yes, I’m on the latest firmware version.
So please remove your claim that tramming is bad, it’s not correct.
2 Likes
@Somnium tramming is making sure that the x-axis is parallel with the plane of the bed (note not necessarily the bed itself, because that can woble a bit) So typically the Y-modules. Making sure those are well aligned. If you search the forum you can find some pictures on how you can do it, this is the first one I found: Milling the cnc wasteboard flat (or so I thought): mis-aligned z-axis modules - #16 by brent113
I don’t have 1-2-3 blocks as @brent113 is using in that post, but I use cans of soup or something like that. Probably not as precise as 1-2-3 blocks, but still rather adequate. And to validate I pull them out of their position and swap their position, they should slide under nicely again. (that way you also validate both cans are the same height.
Works good enough for me.
If you don’t have a problem with it, you usually don’t really have to worry about it too much. You would see it if your bed has a slope along the x-axis. I encountered it the first time after violently crashing the cnc module in the bed that caused it to get unaligned. (and mess up my cnc project at the time)
2 Likes
ooh i better check if my head crash messed up my alignment
i tightened all my heated bed screws to 1.2Nm torque and calibration shows my .9mm slope increased to 1.5m slope - should have thought about my X rail after the head crash.
Ok so the snapmaker can now controlling if the z axes are alined and adjust them separately and probe the positions? Sry didnt got the time to try if my left limitswitch is working.
No
The device can not do that automatically. Tramming is a manual action. (to do when the device is turned off). see above.
I spoke about that what he said
So i tested it now and both of my limit switches are working properly
1 Like
@brvdboss deleted my original comment, I just woke up but my brain hasn’t and I realized what I said was stupid lol.
For the machine to automatically tram each rail, the rails would have to tell the machine what each rails adjustment is in relation to each other. They are mechanical switches so not completely accurate. I don’t think the rails have any computational sets to tell the machine what their individual adjustments are. Forewarning, I’m still not awake so this could be idiotic too. 
2 Likes
Update to this topic! The support and i didnt solved the problem yet. I updated to the new version 1.12.2 and there was something new normaly the top position coordinates should be 334mm somehow after calibration and homing the touchscreen showed 335.7mm as highest position!
But after powering the maschine off and on again it all gone back to the start that my printhead stops 9 mm above the bed. It seems like the lrinter cannot save the calibration datas and go to a default value
Also the command m851 shows Z1.00 and thats not right says Potter from support.
1 Like
@Somnium honestly it’s starting to sound like something got screwed up inside your z rails. It got caught the first time and broke the sensor housing, refresh my memory, was the sensor verified to still be working?
The second time it got caught it affected both the z and x axes correct? To me it sounds like one or both of the z rails are screwed up beyond hope of fixing without opening them up to see wtf is going on. It also sounds like your sensor is no longer working, I wonder if the crash has caused it to become intermittent and constantly has issues sending signal to the head and subsequently the controller, making it impossible to save the leveling data.
If it has become intermittent, like how a bad cable constantly connects and disconnects if you wiggle it (only an example, not saying that’s what’s happening), I wonder if something similar going on with the sensor would cause the machine to not save leveling data. Like maybe once it goes intermittent it causes the machine to reset the data or go to a weird default because it thinks no sensor is connected.
I wonder if both of these theoretical issues could cause the problems you’re experiencing.
That’s easy to test, hold any piece of metal, aluminum or steel, and see if the light comes on.
@brent113 I know, I just don’t know if it’s been verified to still work or not. Though putting a piece of metal underneath it might not eliminate the possibility that it’s got a shorting issue unless it’s extremely bad and obvious, but at that point it would’ve been noticed by now I would think, and I could’ve missed something posted that did say it’s been verified to work or not.
There could be some other unknown factors causing it to go awol. I’m not trying to guess what the problem is, It’s more like I’m just asking myself questions out loud of what possible causes could be. Not really trying to figure it out, just taking mental notes, it’s far enough down the rabbit hole that support needs to and is involved in this and are going to be the ones to figure it out. I’m just running scenarios in my head is all.
What are your thoughts on it? What could possibly make the machine not store leveling data after the mishap?
Then issue a G30 from high up, like Z=300 and trigger with the removable build plate. If it doesn’t stop kill power, it moves slow. The sensor detects the spring steel in the removable build surface.
I guess I don’t really care about the method used specifically. There is a way to test the sensor, regardless.
I still run v1.10.1 because I have heard many stories of the controller not storing calibrations properly, or settings not being in effect. I haven’t looked into the cause, I’m assuming Gremlins.
I’m happy with 1.10.1 still. 1.12.2 and everything in between is basically a public beta at this point, it’s clear insufficient testing was done.
1 Like
Isn’t that the case with all their firmware updates? I never recall them actually testing it before they release it with the exception of new features like color change. I don’t think they actually test the “fixes”, it’s like they just say “this should work, if it doesn’t oh well” on a lot of their releases. I was forced to upgrade because of rotary module, otherwise I’d still be on 1.9.
1 Like
Yea, sadly. Just so happened that 1.10.1 worked pretty well for me.
I did just browse through every piece of code that touched configuration_store.cpp in the last year and nothing seems like it would break anything. It’s all abstract changes. It’s a bizarre bug.
1 Like
@brent113 trying to stay on topic as I think the following may be relevant, i browsed through all the code the other day, every single one. I took a ton of screenshots of code that seemed strange, redundant, and outright bad. There are intentionally misspelled definitions, and there’s only two reasons to ever do that, if the accidentally misspelled it in the beginning and didn’t want to go fix it, or the correct spelling definition already exists elsewhere and they intentionally misspelled it to avoid coding conflict (this is where I’m really suspicious that they are sidestepping Marlins failsafes).
I have a sneaky feeling that they aren’t letting us see the source code for the touchscreen because it would bring all their errors in the code to light. I’m very suspicious that they are intentionally sidestepping a bunch of Marlins failsafe measures that are intended to prevent problems, and because of that we are seeing all these strange gremlins. I’m pretty confident that there is something wrong with the code that they aren’t letting us see because they coded it to where there are a ton of issues and causing the machine to perform in such a way that no other printer performs that way. And I think a lot of it has a ton to do with leveling data and how it reads gcode from slicer engines. @MooseJuice’s issues with simplify3D(I think that was the one) is one that comes to mind, though I forgot what the verdict about it was.
There has to be something in the firmware that they are making the machine do all wonky, and might be why there’s so many odd code in the source code we DO have access to at the moment. Something is wrong with how the machine’s firmware is coded and until we see the touchscreen code it won’t get solved.