MM-control-01
MM-control-01 copied to clipboard
prusa3d
Loud Startup Sequence
I often print at night but having mmu2 plugged in, it is so noisy during its startup sequence, it will do twice idler alignment then another homing sequence when moving the selector or loading filament via lcd menu.
I had a case where the screws to fasten the idler to the motor gotten loose due to the vibration during the startup sequence. I don't know what driver that mmu2 board uses, I'm assuming that it uses the same tmc2130 (I think) as the selector motor as well.
My suggestion is that to reduce the idler motor crashing/homing duration and thus reduce risks of loosen screws as well as reduce loud noises
If the duration of the clicking was reduced, the idler might not make it back to the home position. EX: If the idler and selector are in filament 5 position and you reboot the printer, the clicking is only for a very short period of time. If it's in the filament 1 position and you reboot, the clicking lasts for the entire time the idler would take to move into the F1 position if it were in the F5 position. I'm not sure that makes a lot of sense there, but I'm trying to explain it in a way that does...
Basically, if the idler moved for a shorter period of time, and it was in the furthest position from "home" it wouldn't make it home in a lot of cases.
I have no idea how hard it would be to implement, but I don't understand why the stall detection isn't being used for the idler assembly, preventing the clicking noise all together? I suspect getting the stall detection going would solve the issue you are bringing up here.
I suspect as much that the reply would be about the idler not having enough time to reset its position.
It is true that im asking about stall detection for the idler motor to prevent those crashing noises. X and y uses it, z axis uses it when it is not leveled, selector uses it as well.
On 2:29pm, Tue, Mar 5, 2019 FaultyLine [email protected] wrote:
If the duration of the clicking was reduced, the idler might not make it back to the home position. EX: If the idler and selector are in filament 5 position and you reboot the printer, the clicking is only for a very short period of time. If it's in the filament 1 position and you reboot, the clicking lasts for the entire time the idler would take to move into the F1 position if it were in the F5 position. I'm not sure that makes a lot of sense there, but I'm trying to explain it in a way that does...
Basically, if the idler moved for a shorter period of time, and it was in the furthest position from "home" it wouldn't make it home in a lot of cases.
I have no idea how hard it would be to implement, but I don't understand why the stall detection isn't being used for the idler assembly, preventing the clicking noise all together? I suspect getting the stall detection going would solve the issue you are bringing up here.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/MM-control-01/issues/124#issuecomment-469556835, or mute the thread https://github.com/notifications/unsubscribe-auth/AJKMeYNzTo7oZV4n0MWimJHq5lhHvPhPks5vTg7mgaJpZM4baSWq .
Hi, the stall detection is not implemented on the idler , because it doesnt work with the current settings. to get stall detection working with the 2130 you need to speed up the axis. also it is tricky because it depends on the user (screws/springs tension). On each filament position you get a high load to the idler motor. so if it stalls you cant really be sure its in the home position. The homing sequence should be ...move in the opposite direction until stall... move in the home position until stall and count the steps.. if your in the right range your home ;-)
I am sure that this can be implemented by fine tuning the sensitivities. Last year we had issues of the mk3's random false positive crash detection during prints and now that problem has been addressed by adjusting its sensitivities for stall guard detection.
Even the selector motor may have triggered the stall detection during the startup sequence when the selector is at F1 position before going all the way to the right side.
I am sure that there will be a function that will validates that if the axis for selector and idler has homed or not, which is by checking the finda probe if its triggered or not first.
@sarf2k4 I agree with you about the horrific cacophony the MMU2 makes to wake up my family. It ruins the MK3. I stopped using it altogether. @chriswal I assume there are problems with trying to speed up the idler axis sufficiently to utilize stallguard? I understand the load increases as it passes each filament, but the bearing should smooth that some. The endstop is a hard limit. Surprised those two events can't be distinguished. Won't your proposed sequence have the same issue? I'd be ok with it if it just hit once versus slamming a dozen times loudly. Reading the firmware, it tries to move 2000 steps even if it is already homed, with stall guard disabled. So annoying.
the sequence i proposed makes only sense if stallguard is working. its working on the selector. i made a lot of tests with stallguard also with different speeds . yes you get it to work. but you cant get it to work reliable on different machines. and perhaps it changes if the temperature of the motor changes too much. here is a video of my test version (21 second video ) https://photos.app.goo.gl/VGtwNQ3AxHh5Q1zW8 the other one is a fix for the hc525 problem and has also the loud homing. perhaps we should include a command that the user can tune the sg parameter for the idler in stealth mode or we can auto tune it somehow / or both also i saw that i need to change the stallguard also with the direction of the motor. on the video you can see it stalling on the last bearing
also ther is a bug in the firmware that if you once loaded a filament it never unloads in the eeprom and you get the idler homing on power on and then again with the normal homing.
Ok, I just saw your fork and pull request. Nice! video looks promising. I will give yours a test. Let me know if I can help with coding or testing. I'm not familiar with hc525, will search...
my pull request has the same loud startup sequence .....sorry 74hc595 thats a shift register and it used for the leds and the enable and direction signals for the stepper. and if you have flickering leds in idle mode ...or a humming motor there is a power problem with this ICs (random outputs on change) .. they need buffer capacitors on the power pins of the ICs. my fix is only for the people who cant install this. it doesnt make updates on the leds while moving the motor in homing.
What stall guard value worked for you with your machine before you disabled it? I will try it just to see. BTW, what is polarity of sg? Does higher mean takes more load to trigger? comments I found in code are confusing.
sg=0 highest load (stall) i used 0 to disable it you can use 1 if it doesnt work try changing #define TMC2130_SG_THR_2 10 in config.h lower value means more sensitive... so if it crashes lower the value if it stalls on the gears set it higher
you can also set the trials on the selector to 1 int _c = 0; shr16_set_led(2 << 2 * 2); for (int c = 5; c > 0; c--) // not really functional, let's do it rather more times to be sure { move(0, c * -18, 0);
the for ( int c =1 in stepper.cpp in selector homing
you have to test it with filaments in each input, because the load is higher. you can use a short piece for testing.
you should change stepper.cpp
to this
if (_idler > 0 && _acc <2) {sg_idler= tmc2130_read_sg(AX_IDL);}
if (_selector > 0 && _acc <2) {sg_selector= tmc2130_read_sg(AX_SEL);}
if (_pulley > 0 && _acc <2) {sg_pulley= tmc2130_read_sg(AX_PUL);}
_acc<34 to <2 then the acceleration phase is over
this is the video with the software in the pull request and the mentioned changes. https://photos.app.goo.gl/icbQXJ3NB7PxKTZs9
I tried move_with_stallguard(2000, 0,0,100); and it works even with filament in all channels! Nice work! will play more to see if reliable or need to lower.
What does the TMC2130_SG_THR_2 do? I see it written to a register in tmc2130, but when does that kick in? Your software routine:
if((sg_selector <= _sg || sg_idler <= _sg || sg_pulley <= _sg) && _sg > 0){break;}
does what I thought the tmc was supposed to do, i.e. trigger when threshold crossed. OR do interrupts need to be enabled? not familiar with this chipset.
thats the threshold for the stallguard . the chip has a register where you can read the value of the load on the motor ..0 is the highest load without load it should be 1023 i think. with more load it will be lower. which value you get depends on the threshold if its lower its more sensitiv.
no only value read from a register
Hmm, sounds more like a (negative) gain control than a threshold. reading app sheet for tmc2130 now.
I just turned it off for debug since data sheet said to tune SGT first. I've turned it back on and still works fine. So, only changes I made to your routine, other than 100 sg for home_idler, is in move_with_stallguard: if (_idler > 0) { idler_step_pin_reset(); _idler--; delayMicroseconds(800); } // increase velocity for stall detection, was 1000 I was trying to get closer to 50 RPM (see fig 14.2). This is still slow, maybe 25 RPM, but should help. Note that I did NOT implement your changes to home_selector function, just home_idler. Two more change I like that you can try are: in move_proportional: if (delay > 600 && _selector > _start) { delay -= 10; } // increase change speed, was 900 in move: if (_selector > 0) { selector_step_pin_reset(); _selector--; delayMicroseconds(500); } // increase homing speed, was 800 let me know if it works for you.
i tried also different speeds .down to delayMicroseconds(100); but i didnt recognize much difference. the changes i made are mostly for the problem if you have flickering leds and homing problems with the selector, and shouldnt change the normal behavior if you dont suffer from this ..it doesnt matter. you could change the original code. stallguard is partly implemented there also.
@sarf2k4 in addition to above, comment out from setup() in main: // motion_set_idler(filament); it appears completely superfluous and saves an unnecessary homing on startup/reset. Because s_selector_homed = false; you will always get a proper homing anyway to get things positioned correctly again. The one in setup is not needed and just adds noise.
@chriswal another data point: sg very sensitive to motor temp. They recently increased holding current for some reason. This causes idler to get quite warm over a long time. Warm works with the 100 setting I used, but when I let cool it is too low and idler clicks when hitting endstop. A higher setting would work better when cold. If there was a temp reading available, could adjust sg level until it warmed up. But will have to live with fixed value.
@jltx1 the motion_set_idler(filament) is used for error handling ....if you have loaded filament and not unloaded it.. and you turn of power--you loose the home position of idler and selector ....you cannot move the selector.. so they home the idler and move it to the last loaded filament that you can unload it. there is a bug in the firmware that the loaded filament is not removed in eeprom when unloaded .. its an easy fix ...there is a commit in my pull request for this.... fix it in the code...load and unload filament.. and the initial idler homing is gone...
@jltx1 This is also my finding. And this was the problem with The zero beast's version. That is the reason why I'm trying to figure out a a gearbox solution (3.5x copied from skele). Yesterday, I tried for first time, but there are some more changes needed for the steps and speeds. It was the most consequent till now. The gearbox will also increase the torque, so the current could be lowered.
@chriswal So that is there for power recovery. Too bad. Was hoping to remove it. I saw your fix and included it.
@Panayiotis-git Interesting idea. I'll follow that development.
that would be a better answer, but are there any spare pins left, and are they ported out somewhere accessible?
It looks like D7 on the SPI Plug is free. Thats the one plug that is free on the board. This plug has also +5V and GND.
They used a plug with one pin less.. so it is free but its on the board and not on the plug. And its pin 7 in arduino (pin1 of the cpu) already tried it with a pinda probe (and it works) ..need to find a place to mount it