Houston, we have a problem.... or a warning. This is a long one!
Time for an uppdate.
On Saturday the rest of the parts where installed.
The gantry was squared and tuned in. Belt where tensionen and over to the klicky.
Here we found the first challenge. The klicky-NG.
During installation I always do testing. We can call it unit testing as done in software development.
I noticed that the probe attached perfectly but no connection!
If measured it works so after a lot of investigation I found that when attached I was a little play between the probe and mount which ment that probe where attached but with an angle so that the magnets didn't have metal to metal contact .
To fix that I had to use some capton tape to put the probe at the correct angle when attaching it. That will be addressed when I can print ABS.
Ok, fixed that and got the assembly done so next electronics and wiring.
Everything went without any hassle went to bed quite late but happy.
The only little thing I did change was that the compartment fan was configured as a heater_fan in printer.cfg and turned on only when the bed got to 45C or higher.
Thought that was a little bit stupid because its main job is to keep the electronics cool and it the printer is on without the bed the temperature in the compartment could still be too hot as it is quite a closed space.
Also the mcu do have a temperature sensor, so changed the config so that the fan is defined as a temperature_fan and will work to keep the mcu temperature at 35C maximum.
New day and boy today did we get a challenge.
As the CAN tool head didn't arrive I decided to temporarily wire up the regular PCB so we could do the initial setup and pid tuning and rotation distance tuning.
So started following the Initial startup documentation on Voron docs the motors got buzzed. CHECK.
Homing, did finalised sensorless homing setup with threshold tuning, CHECK.
Z-endstop CHECK.
Perfect, Goldie can now home his axis.
Next, setup Klicky configuration. While doing that I used for sort of "stress testing" I homed the axis in between. Old habit, it takes some more time but usually pays off in the end.
During one of those homing sequences, instead of homing the carriage did a very strange move.
I flipped the emergency stop and wondered "what the hell....?"
I used the emergency button on the display and the Linux box had no communication with the board.
Reboot and a G28. Works!
Many people would probably be happy and carry on with life.... well I didn't.
The whole situation tingled that damn spot I my gut telling me something is wrong.
I skimmed the logs, nothing. I buzzed the motors just to recheck. I issued G28 X, G28 Y, G28 Z... Works.
G28 again. Works.
Well decided to carry on but for every test I also did a homing. And finally, when klicky was up and running and I had done a Quad Gantry Level I issued G28 and BOOM I triggered the error again.
The carriage did a perfect homing on X but when trying Y it just wiggled and then started with Z homing, like if it was homed or that the threshold was wrong.
Hm, checked the rails, belts, tensions etc just to be sure, but it seems this is an electronical problem and not mechanical.
Did a threshold calibration again, nothing changed and worked like a charm.
Did G28, works so let's continue with Auto Z calibration and the stress testing. Issued a lot of G32 and G28 and randomly got the errors but no message or clue to what caused it.
I did found in the sensorless homing configuration a delay time so that the driver could get time to do what ever it needs to do. It was set to 1000. Thought, as looked like the Y was failing directlyr maybe the driver was in a strange state and not done with its work... let's test and pushed that to 2000. Nope. Same issue, only difference it waited longer after a homing X before it started to home Y.
Being distracted with reading and googling as well as testing, one time I was a little slow on the emergency button so I used the one in Mainsail, and not the hardware one on the screen and that actually produced the an ERROR MESSAGE! Yeay, finally.
The log said - Undervoltage.
OK, I did tune the PSU as it was really high.
Could that be wrong? No, had exactly 24V under load but raised it to 24.5 just in case, as it was not spinning any motors just powering the electronics and fans.
The comparment fan did a fantastic job keeping the temperature below 35C even with the bed at 100C during pid tuning and heat soaking before tensioning the screws, so couldn't be that either.
Googled and found one guys talking about the current and Vref. But, as we use TMC2209 and UART, you do control the current via software and it shouldn't be needed to tune the Vref as it has dependency on the current, or maybe I got it wrong?
Well, checked the current settings for the driver and no, everything looked as it should.
I didn't do a Vref test though.
Hm, so managed to get the error message produced one more time, and this time I googled the WHOLE error message (don't ask why I didn't from start
) and found links pointing at the driver. It said Stepper X - Undervoltage along with the usual other stuff we put into the messages.
So swapping the X (B) stepper driver for the E stepper which was attached but unused and Voila! It seems to work.
More stresstesting while setting up the last part of G32 and PRINT_START macros the error popped up again but without any error messages, however this time the carriage after homing X tried in the wrong Y direction and started to Z home. No message but could it be the Y (A) stepper this time?
A couple more stress tests and I got the error message and surely it stated Stepper Y - Undervoltage.
Hm, what to do. I don't have any spare driver and all the others we in use for Z1-4 or X?
Well, let's put it on Z1 (Z) and if that one fails I know the reason.
So turned of power, flipped Goldie on the side and swapped the drivers and started to do really heavy stress testing.
So far, nothing!
I test with heated bed, heated nozzle and bed - PRINT_START after PRINT_START - meaning the following
G32 # homing XYZ, QBL, homing XYZ again after gantry calibration, AUTO Z and finalising with a bed mesh calibration.
PARK # put the head in the center of bed
Very late last night, after I don't know how many print starts, I turned Goldie off. Time for some rest.
Hopefully I found the reason.
The suspected faulty driver that I had to put in Z didn't glitch at all even though I pushed the printer to go up and down fast and long travels.
Looking at Fysetc home page you can't buy any TMC 2209 V3.1 drivers only V3.0 (which has different pinout on the board it seems) and V4.0.
When ordering the CAN bus stuff, I wanted to buy one extra and got a "hello stupid" answer that I could buy a bundle of five V4.0.
When popping the questions about it, no answer what so ever...
Of course, looking through their GITHUB and other places - no information what so ever about the differences between V3.1 and V4.0 and if you could use then interchangeably.
I haven't ask on discord yet, so will pop the question there later on.
For now, I have an almost working printer - at least I do know that Goldie knows how to do sensorless homing, klicky-probe, auto z and bed mesh calibration under stress.
Fysetc SB Can Toolhead v1.3B says to have a jumper for the 120 Ohm resistor. The board I got was a newer version of the v1.3 but didn't have any jumper or onboard resistor.
