3D printing home/calibration unstable?

I find that I need to power cycle and recalibrate between every 3D printing on my A250. The gap between the print head and print bed are not being maintained with precision. Either the home position shifts slightly, or the calibration parameter is not stored well. Trying to repeat print the same file at the console results in the extruder gap to print bed that is not the same as the print just completed. The calibration sensor is about 1mm lower than the extruder nozzle. I notice that without power cycling, sometime the z-axis motions are not perfectly concurrent during homing, leading me to suspect homing is not providing a consist home position, and therefore this is a firmware issue versus mechanical?? I am on the latest firmware (Sept 2020 version as I recall?).

So I have done some testing related to this, and if youā€™re up for it, might help answer some questions here.

So thereā€™s a gcode, G30, that will probe a single point, most useful issued over USB, not wifi. You can use it by jogging to an X/Y point and issuing a G30 in the terminal. The induction probe will go fast once to roughly find the surface, then slowly twice. The numbers of all 3 probes will be output over the serial connection to the terminal - ignore the first one.

By issuing 3 or 5 G30s in a row and comparing the last pairs or readings, this will give you an idea of the repeatability of the machine.

Then do a G28 to home the machine, then jog back to the exact same x/y, and do 3 or so more G30s. Is it the same height as before? Mine were to a few hundredths of a mm.

I even turned the machine off and back on and homed and repeated, same result.

This would fairly definitively tell you if the homing on your machine is repeatable.

Thereā€™s another issue though - the positions of the 2 Z tower mounts. I had to do this for mine, with the machine off:
image

What happened was the X axis was not actually level, and also the stops at the top of the Z axis the instruction manual tells you to use were not in the same place. I had to make a new reference off the Y axis modules to get it level. That fixed a couple issues I was having - namely, from week to week the Z heights would change slightly - I think the X axis was dropping slightly on 1 side.

When the machine homes - it stops rising when EITHER z towerā€™s end stop is triggered. It does not wait for BOTH - a critical difference.

@brent113. I will perform both of your suggested checks. Interesting that you did the Z-axis alignment from the Y-axis drives versus the bed. Thanks for the information!!

Question, have you observed non-unison movement of the Z-axis drives? I observe it at times during a Home operation. I may not be recalling correctly, but I think it may occur on upward motion, as if one z-axis drive continues to move after the other stops.

See this thread where I rant about the carriage being incredibly out of wack on my machine: Carriage Tolerances - Unusable Over Distance >75mm From Center. Thereā€™s no chance I get a successful alignment using the bed, or webbed carriage. Iā€™d have to use the Y axis module mounts, but they are hard to get to without disassembly - by using the case of the module itā€™s a quick and easy check I can do frequently without disassembly.

Never. That sounds very not good, and would explain your print issues in the other thread, also. If only 1 tower moves, that leads to all sorts of issues.

1 Like

@brent113, Thanks for the link to all the investigation on mechanical alignment issues, very interesting. I did check the left/right spacing of my X-axis drive to the two Y-axis linear drives and the alignment is very good.

I just finished the ~6th print of the same two part and it printed OK (in regard to ~1mm ā€œsmeared layer in random positionā€ of my other thread today. All I did prior to printing was to remove and re-mate all the cable connections of the drives (both ends) and the cable to the controller/PSU. I did not detect any loose connections in performing this action. I did not even recalibrate the hotend to bed gap, although I have power cycled due to the cabling re-mating with power off.

Without making any other changes, I am now printing a simple 30 x 30 x 35mm cup to see if the A250 is truly printing well now including motion of the z-axis layer positioning.

Please stay tuned!..

"I spoke too soon" the test cube already is exhibiting ā€œsmearing of a layerā€ at about 5 mm up from the print bed. I will let it print a while longer to see if it corrects on subsequent layers as before.

1 Like

@brent113 do you know, are the limit switches in the duel axis directions logicaly "OR"ed together? (Meaning if either is triggered then marlin reads it as triggered)

Yes, itā€™s an OR.  

Either way that eliminate the possibility of one z axis rail continuing to move on a home after the other has stopped. At least without it sounding like its chewing nails.

Iā€™m going to try to capture a video of the non-unison Z-axis movements, hopefully in slo-mo to make sure my eyes are not just playing tricks on me.

Again this morning, the hot end to bed spacing has shifted from the last print of yesterday, after nothing more than a power cycle. I will run a USB cable to provide console commands for testing as suggested by @brent113 and @Atom.

Does it matter that a couple of homings after power up today resulted in a Z coordinate of 232.05, but then after performing calibration, a couple of homings result in a Z coordinate of 232.18?

Thatā€™s a large change. I think the largest change Iā€™ve seen on my machine is 0.03mm, normally.

We need to get to the bottom of this, it should not do that.

1 Like

@brent113, thanks for confirming the apparent ā€œZ homeā€ shift is excessive. Perhaps I will run a series of ā€œdryā€ trials with just moving and homing, along the lines of your description with G30 and G28 codes. It is as if one of the Z-linear drives or at least its home sensor is defective in some way? I think you mentioned somewhere the drives are all open driven, with no encoder position feedback to detect and/or compensate for any motion fails.

Yes, they are all open loop as you said. Which normally isnā€™t a problem - Iā€™m still not sure what the root cause of your issues is. Iā€™ve seen several things that are similar, but not the same exactly.

Good luck in your investigations - let me know what you find for the repeatability.

Consider turning backlash compensation on - itā€™s easy to do, but it wonā€™t save, youā€™ll have to put it in a macro in Luban or something.
image
image

You can measure the Z value by jogging in Luban with a custom value of 0.02mm or so. Move down onto the card until thereā€™s friction, and then send 0.02mm up commands until the friction decreases. If you had to issue 2 commands, then you have 0.02mm of backlash on Z. X and Y are measured differently, but I found all of mine were the same.

I say move in 0.02mm instead of 0.01mm because I found the controller will not move for 0.01mm, only every other time. Seems that 0.02mm is the smallest amount it will move. I think 0.015mm is actually the smallest, but thatā€™s kind of silly getting into the thousandths of a mm.

1 Like

@brent113, @Atom, Iā€™ve now captured on video the Z- towers motion during printing. In less than 60 seconds of recording, I see the left Z-tower (only) jerking motion at least 9 times, while the right Z-tower is motionless (except between layer steps). It looks like the left Z tower is not holding position, mostly ā€œjumping up briefly at timesā€? Please review, if the low res video is adequate, and comment. Kind of looks like ā€œcrosstalkā€ among the axis is impacted the Z tower??

Sorry to say, looks like youā€™re going to need a replacement module. If you donā€™t already have a support ticket youā€™ll need to create one. Email support@snapmaker.com

1 Like

@brent113. I will add more specifics to my support ticket. Hopefully, I will be a lucky one with minimal delays in the support team addressing and resolving my A250 issue. In the mean time, do you think I should try to swap the cables between the two Z-towers to confirm the issue stays with the left tower (and is not with the controller tower drivers)?

Iā€™m not sure. @atom or @sdj544 would be a better resource for that.

2 Likes

@brent113, I can also ask Snapmaker support folks if they want to endorse this level of troubleshooting before I risk warranty voiding issues. Your guidance on this issue has been timely, superb and is greatly appreciated! Iā€™ll keep you posted as this evolves further. Thanks!

2 Likes

I canā€™t add much to swapping cables to troubleshoot. @atom has more experience with that.
I wouldnā€™t worry about voiding warranty if youā€™re just swapping modules. If youā€™re opening them up, then maybe. The more info you can give on your support ticket to start with the better. I kind of have a feeling that they have someone doing a sort of triage and if you give a clear accounting they can approve it quick and if not it may get passed along to a different layer that may be more backed up just because theyā€™re having to take longer to deal with and figure out the problem.
-S

3 Likes

First i would like to say that i feel honored, i have two of the best people on this forum referring to me as having more experience. thank you both.

@sdj544, i dont think so, i wish that was the case, but i waited 4 weeks to hear back when my problem had already been diagnosed by support (litteraly i got emails up to the point that they said ā€œsend me one last pick and then we will send you a new moduleā€ then silence for 4.5 weeks -.-) but i do agree, with the idea that the more information we can provide the better.

@jmeckstroth, switching modules is a great idea. i suspect that the issue will stay with the right Z module. i also think it would be a good idea (if you havent already) to take the X axis module off, and move both the Z axis modules by hand (with the power off). see if the one on the right feels like it is harder to move.

2 Likes

@Atom, your experience with Snapmaker support is not encouraging. I can only hope they are improving their resources (people, spares, processing) faster than the rate of field failures and defects! Hopefully, I will at least get some engagement in response to my support request ticket this week.

In the mean time, I will continue to refine symptoms and root cause isolation with the guidance of this forum community, which is much appreciated!

1 Like