Milling the cnc wasteboard flat (or so I thought): mis-aligned z-axis modules

Hello,

in an attempt to get a perfectly flat wasteboard I wanted to do what all the big boys with big cnc machines do. Mill the bed flat so you have a nice and level wasteboard. Nothing to difficult you would assume. Just draw a big square in Luban, set it to fill and mill away. So was the plan, so it started. Loaded the biggest mill I had (3.175mm) and of it went.

And it went great. Nice surface finish and everything was looking good. I didn’t adjust the default Luban settings and as it was only just scratching the surface I could up the speed to 500% Yay. It would be done in about an hour. Everything going well, So I decided to go do something else and come back in an hour.

Then it happend. In stead of flipping of the light switch, I flipped the switch of the outlet where my SM is plugged in. No worries I thought. We have this nice power lost recovery feature! Let’s test it out! And it looked good. SM asked me nicely if I wanted to recover and obviously I said yes. But then 2 minutes in the job I noticed that it was milling in a different plane than before. Uhm? What was going on?
Something went wrong with the recovery of the job? Let’s start it again. No big deal!

But there it happened again:

After some debugging This is what I think happened:

  • In my previous experimenbts with the cnc I may have made some mistakes. Let’s say I have run the cnc into the bed. mistaking 1mm movements with 10mm etc.
  • At that time, the linear modules have been skipping some steps. And probably not both the same amount of steps.
  • from now on I’m making assumptions.
  • When homing, they stop at the limit switch, but I think they only look at the first limit switch they hit. Not necessarily both
  • So if both vertical modules aren’t perfectly aligned, they stay that way…
  • I guess something with the power recovery must have triggered some kind of difference.
  • from here on factual data again
  • When trying to measure the offset I dug into the bed again. (Why would I make the same mistake twice, right)
  • When homing I could now clearly see that the two z-axis modules were no longer aligned.
  • I turned of the power, pulled them both up as high as possible (and again noticed one was higher then the other. So by pulling them both up they were aligned again.
  • turn on the machine and now when homing it looks like everything is going well again.

It’s about halfway through the job now and everything seems to be going ok so far.

Anyone else has experienced this?
I would expect I’m not the only one who has had this problem. Or maybe you haven’t noticed it yet.

Either way, I hope this experience helps someone else.
No real harm done in my case, except that I’m definitely taking of at least 1mm too much of my wasteboard now. So I’m really wasting it :sweat_smile:

1 Like

Yup, its not a CNC issue, its an open-loop motion system, and the fact that the controller stops both rails on a single limit switch. I have started the habit of pulling both Y modules as far forward as they will go when I change the bed, and both Z towers as high as they will go when I change the toolhead.

Its quite a stupid system, it shouldnt be so hard for the main controller to continue to issue movement commands until both limit switches trigger, and have the rail that hits the limit switch first simply refuse to move past it. At which point the homing will ensure that both rails hit the limit switch.

But alas, it is what it is. If SM released the source code for the module firmware the community could attempt to fix this.

2 Likes

To make the developers aware of this @buzzplop, I’d recommend that you create an issue on the GitHub page here: https://github.com/Snapmaker/Snapmaker2-Controller

As an update.

The bed has been milled (yay). Unfortunately you can’t get all the way to the border, I solved that partially by mounting the cnc module a bit off center or by mounting it wit a spacer. not perfect, but close enough. The board is actually ssoft enough to just cut the last little rim off with a sharp knife. (the last 3mm won’t matter that much anyway.

Anyway, I am rather pleased with the result. I’ve done some measurements with a dial indicator and the difference between highest and lowest point while doing samples across the board didn’t seem to exceed 0.16mm.

I tried doing an autocalibration with the magnetic bed on top but that was far from perfect as its not fixed to the bed. Depending on how I turn or flip it I did got some different measurements. But it looks rather promising and seems to confirm the small manual test I did with the dial indicator.
result
Using the print-bed the difference between min and max was 0.85mm

When I get my silicone baking mat to put in between I’ll try using this as a base for the heated bed and then with the magnets the curves in the magnetic bed should be less of a problem.

I have submitted the issue: https://github.com/Snapmaker/Snapmaker2-Controller/issues/24
Thanks for reminding me to do so.

It’s also possible the power loss might have caused something. Power loss isn’t exactly an all-or-nothing proposition. It’s a process with a finite duration, some finite number of milliseconds. What happens during this is that the voltage supply drops from all to nothing during that time, so during the process modules can be partially powered. Partially powered digital circuits misbehave, sometimes very badly, and certainly not consistently. I’d not be surprised if you had differential motion during power loss somehow.

This would have its own problems. Traditionally on large mills limit switches are not measuring devices but rather safety devices. When the limit switch is hit, it’s considered out of bounds and the machine halts. This is the origin of the “stop on first limit” policy of the SM. Insofar as that prevents module damage, fine. (It only prevents module damage on one end, though; there’s no limit switch on the far end, and there ought to be for safety.)

The problem arises because they’re putting a second function onto it, homing. In practice what that means is that you can’t validate continued synchrony of motion on the two axes. You want both limit switches, ideally, to trigger on the same step. Given the various inaccuracies that always creep in, that would mean you need limit switches that can be adjusted for calibration. And you need a switch that will hold that calibration over time; the mechanical switches in these machines won’t do that. An optical interrupter would work much better as a homing sensor.

Further complicating this is what happens when you get a sensor failure. It’s easy to find a scenario for the obvious ways of recovering from stepper skew that cause machine damage when one of the sensors fails. What you really want is two sensors, one for each function. The sensor for safety is fixed and non-adjustable and generates a hardware fault and local shutdown when triggered. The sensor for homing to zero is adjustable and lockable for calibration and sends a position message to the controller when triggered.

1 Like

The controller “talks” with the power supply (via input pin PE0), and when a power loss event occurs a “power panic” is initiated, which is a function that performs a quick stop of all motion, and dumps recovery data to flash.

I just mention this because it appears some of the points you mention are addressed already.

Regarding a finer point in the endstops - manufacturing tolerance means the two endstops will not be parallel with the bed. Perhaps the sensor on the 3D tool should be used to traverse across X and recommend a manual user correction after disabling the stepper motors.

With the splitter, obviously nothing can be done from the controller to control the individual modules.

2 Likes

Hello @eh9, @brent113;

Thanks very much for both your very valuable feedback again. (and commenting to the github issue)

That could definitely be true. However it was also repeatable without the power loss scenario. After driving the head in to the bed the second time it did happen again and without the power loss. And alignment was a bit off to the initial alignment (at the first start).
Repeating the procedure of turning of power, pulling it to the end and homing again did result in a rather stable offset to the bed.

I’m not knowledgeable enough about the capabilities of the device to identify the possible solution. But indeed, if it would be possible to perform some kind of validation/warning routing that would be great and good enough for me!

As a quick and dirty manual way, touch off with a sheet of paper between the tool and platform on each side and note Z. That’s the tram error. M17 and M18 will enable and disable the steppers. You could see if anything is to be gained manually. Make sure to home each time after M17 using G28.

I am not sure I understand exactly how that helps? That assumes the platform (on y-axis) is actually parallel to the bottom plate.

Assuming the bottom plate of the device is the base reference. The y-axis is 90° to those. So I would assume you would want to do that touch-off to the bottom plate. (but then you need some kind of accurate jig to enable that)

I meant to address this and forgot.

There’s a signal wire from the power supply, and there’s some code to do something about it. I have low confidence that it’s reliable. It’s hard to test exhaustively by it’s nature, if only because each testing cycle takes a while if done manually, and isn’t quick even if you were to make a device that could generate fault signals under software control. On top of that you need to ensure that the test triggers at all relevant machine states, in particular during the various point of processing an ISR.

There’s a whole class of automatic tests that can be used to do some of this, but they require that the code be written for automatic testing in mind. That’s a totally lost cause because there’s no unit tests anywhere in the code, at least not that I could find. Marlin doesn’t have any, neither does the Snapmaker-specific code.

As an overexaggerated example so it’s visible, here’s what I’m describing, as viewed from the front
image

You would want the X axis to match the left to right tilt of the work surface, which hopefully is actually much more level than shown.

You can’t do anything about front to back without shimming the mounts.

@eh9 Sure, that’s true. I think there are simpler explanations for @brvdboss’s issue before we need to invoke non-repeatable power loss behavior.

1 Like

OK, then I did understand what you were saying. However that doesn’t really look desirable in the way it would put extra stress on the z-axis modules.

In that scenario shimming the platform plate sounds like a better plan to me.

Anyway. I am rather happy with the result so far after milling the surface area.

I am thinking about making a second wasteboard from stronger wood as a permanent base for the printing surface. (my silicone soldering mat arrived today and will try to get it tested that way this weekend, as it is somewhat compressible I could actually use it as a shim by tightening the screws more or less. To be continued)

If the platform is so far out of level that aligning the X axis parallel with it puts excessive stress on the Z modules that would be a manufacturing defect requiring replacement of the platform, in my opinion. Shimming would be an equivalent fix.

1 Like

I wasn’t saying that was what happened. I was saying that it was a possibility.

The real lesson here is that it should be considered ordinary practice to recheck squareness of the axes after any extraordinary event. That includes power loss, but there’s far more than that.

1 Like

I’ve started doing it regularly, in fact. Every week or two using 1-2-3 blocks as parallels

2 Likes

@brent113, when you were tramming your SM, were the Z-axis vertical from the factory?

One is leaning forward a little, the other backwards more, haven’t yet actually measured the angle, but enough to be visible as a gap against my machinist square resting on the base plate.

Haven’t yet checked side to side alignment, mainly because only just now did your post remind me that you’re using the Y-axis rails as a reference :wink:

Posted this previously: