[BUG]on fysetec clone Mini FW 4.3.0 does not properly go trough the XYZ selftest

[okpail]

Printer type - [MINI Fystec Clone]

Printer firmware version- [ 4.3.0]

Original or Custom firmware [Original]

Optional upgrades - [Filament Runout Sensor]

USB drive Please let us know if you print via USB flash drive or USB/Octoprint

Describe the bug on fysetec clone Mini FW 4.3.0 does not properly trough the XYZ selftest

How to reproduce take latest fysetec clone Mini and reboot on usb with FW 4.3.0

Expected behavior Same fysetek mini clone goes trough XYZ selftest fine with 4.2.1 Firmware

G-code Please attach the G-code you had trouble with. This will make it easier for us to replicate the error.

Crash dump file Please attach the crash dump file. This will make it easier for us to investigate the bug.

Video https://youtu.be/flCk77IpWZI

[LAP87]

I can also attest to this, i built my first prusa mini last night and was greeted by this error (i updated the buddy board before trying it out fully, so i don't know what firmware it came with or if it would have worked well) Seeing this issue here makes me feel calm again, i'll try the lower firmware.

My recording of the issue. https://www.youtube.com/watch?v=_hIrbSu03Uk

[murk-sy]

Duplicate of #1182

Also, to resolve X axis failing test (or causing layer shifts), you might have to lower the tension by disassembling the hotend and moving the belt one tooth back and retighteing using the screws at the end of the axis

[LAP87]

Duplicate of #1182

Also, to resolve X axis failing test (or causing layer shifts), you might have to lower the tension by disassembling the hotend and moving the belt one tooth back and retighteing using the screws at the end of the axis

Nothing wrong with the tension, i flashed the 4.2.1 and everything works like a charm, too bad that the 4.3 didn't work :I

[Turro75]

as reported in the release note the axis test fails because the measured travel is too long or too short.

[LAP87]

as reported in the release note the axis test fails because the measured travel is too long or too short.

What is the exact measurement needed between the "endstops"?

[Turro75]

according to selftest_MINI.cpp:

178mm < X < 188mm 179mm < Y < 189mm
181mm < Z < 191mm

[LAP87]

according to selftest_MINI.cpp:

178mm < X < 188mm 179mm < Y < 189mm 181mm < Z < 191mm

I have pretty much exact 210mm between the two ends on X axis, do i subtract the width of the hotend-assembly from that number? Otherwise i'm somehow way over the selftest specs lol

[okpail]

Questions: So can we change these values? Why being exact when the drivers can detect ends? Can the real values of a printer be measured and stored?

How is the test done in the previous firmware?

kind regards

Onno

[Turro75]

Z : simply measure the z carriage distance to the top once the nozzle tip hits the print bed. X: place the x carriage at one end and measure the length of the exposed rod. Y: measure the distance of the front of the carriage from a fixed point at both limits to get the travel

In my diy self assembled mini clone I had both X and Z failures. both because too long travel.

I fixed X by reassembling the axis pushing the rods a little out of zcarriage (be careful to don't reach the 3030 alu bar) and by reducing the belt loop length shifting one or two teeth in the x carriage belt lock.
I fixed Z by adjusting the distance between heatblock and the heatsink (from 1 to 4mm). in this way the nozzle tip reach the print bed earlier than before so I reduced the Z travel.

[DRracer]

@okpail previous FW (4.2.1 and below) didn't check the axis thoroughly, i.e. didn't catch failing bearings. The new FW makes multiple runs at different speeds measuring stallguard as well. If there is a problem in the bearings anywhere on the axes, the test fails. That includes also the correct axis sizes.

However - the FW is open source, you can always modify it to suit your modded printer.

[m3mike]

I'm having the exact same issue with my Original Prusa MIni (literally looks identical to videos posted above).

My C++ is a bit rusty, but since mine also fails at the beginning of the x-axis test, right when the hotend gets to the end stop, I'm guessing the x-axis length test is failing. Would that be correct, or am I misreading the test order?

I measured from the hotend x-axis bearing along the exposed x-axis rod and I get almost 188mm exactly.

Is there any way to get a report on the specific failure? Would downgrading to the 4.3.0 RC1 release which had the USB logging be helpful, or no?

[murk-sy]

My C++ is a bit rusty, but since mine also fails at the beginning of the x-axis test, right when the hotend gets to the end stop, I'm guessing the x-axis length test is failing. Would that be correct, or am I misreading the test order?

I've had this same failure but the issue was overtightened X belt. It appeared in the form of the x carriage having bumps every 30 mm or so - but it wasn't an issue when the printer was out of the box, it only appeared later. I had to loosen the belt by moving it 1 tooth and use the screws to get it tightened correctly.

[m3mike]

I tried loosening the belt, and also validated the belt tension with https://www.prusaprinters.org/prints/46639-tension-meter-for-the-gt2-belts-of-i3-mk3s-or-prus, and it looked perfect. I haven't perceived any bumps in the x carriage, either during the self test or when printing. Now that your test passes have you checked the belt tension with the tool? Curious if the tool might be off and actually needs to be even lower tension than the min.

[murk-sy]

I can't for sure say what your specific issue is, I just know I had overtightened belts that was basically "discovered" after Z gantry crash as a result of this bug. As far as I know, belt tension is tested by checking stepper power draw (or something along the lines of that) and I believe RC versions output a report at the end of the test with the values saved on the USB stick. I suppose technically you could check those values and find some recommended ones?

As far as belt tension goes, I wouldn't trust a printed tool to be accurate, you're basically relying on a lot of planets aligning to reproduce some accurate value.

Of course, it would be best if the self test reported the issue in more detail since there's multiple failure conditions.

[Turro75]

only RC1 was able to save on the usb the result of the last test only.

while using these gcode files (renamed to txt to get them uploaded) to test axes noise and other stuff such as Iref adjustment, I got motor stopped when overconstraining belts so I confirm belt tension can be the cause of test failure as even if the belts aren't overconstrained enough to stop the motor it can be enough to miss steps so the board believes the axis is longer than how is actually.

axes_test.txt Y_axis_test.txt X_axis_test.txt

[m3mike]

Just an FYI in case it helps anyone. My Mini (original, not clone) was failing the X-axis test because the pulley on the X axis motor came loose and was pushing against the motor. After resetting the pulley to the correct position and tightening everything, it now passes the XYZ axis as expected.

[Prusa-Support]

Hello! Sorry for intervening on this so late. Removed the "bug" label based on the fact that it was related with the improved self test procedure starting from FW 4.3.0. I'd have to confirm that the resolution for the custom printer would need a custom firmware modification. I can confirm of course the points on the previous comments on the possible causes of self test fail:

• actual length being "out of the range"
• belt tension
• pulley (alignment one set screw against flat part of motor shaft + the other set screw also sufficiently tight) + small space between pulley and motor
• general bad movement, which can depend apart from the above causes on bearings, their lubrication, possible dust on smooth rods, etc.

Closing the issue for now given all this info.

Alessandro Pantaleo Prusa Research