Set Retract/Load Amount(F.I.N.D.A. to MMU2Parked)? Loading fail from F.I.N.D.A. not triggered.

[AbeFM]

When loading filament, too much is going in, there's always a blob on the first extrusion (on tower). This could be due to some retract that is unretracting incorrectly.

When loading filament (after the first time) everything needs a ~cm of shoving towards the drum to get it to catch - it is being unloaded too far as best I can tell.

What would I change to set these distances?

[TheZeroBeast]

Hi AbeFM,

Sounds like your ball bearing isn't dropping as it should. the unload takes measurement from the drop to place filament for next load. I'll testing a magnet assisted solution at the moment which is working well for the times a small string is holding it up.

It takes an 8mm did 3mm high neodymium magnet in the front before the front plate is installed.

mmu2-selector-finda.stl.zip

[AbeFM]

I can say that changing the parking steps from -650 to 450 made it work half the time. Further dropping it to -250 made it work 100% motion.cpp lines 20-21 ` /2/ { 755, 830, 755}, //Abe was /2/ { 300, 330, 300},

/*3*/  {-250,  -250, -250}, //Abe was /*3*/  {-610,  -610, -610}, (450 too high)

`

[TheZeroBeast]

The firmware has 610 as standard which is also used in the feed filament method, did you also have issues with that unloading too far?

On mine -250 would still be in selector

[AbeFM]

Assuming the steps are the same used as loading, I need ~755 steps to get me roughly 28 mm from sensor to gears.

I measure ~29 mm from ball to passthrough selector.

So.... You're right, except, why is 650 too far for me and 250 working? Are the step sizes not the same in the two cases?

[TheZeroBeast]

Yes, interesting, I still think the ball is staying up .1s or so longer somehow

[AbeFM]

Editing like 5 posts down to one or two: Things had been working fine with V214-228. My tips aren't anything crazy. I raised the sensor a mm and didn’t see a difference. I pushed down on the ball with some filament, didn’t see a difference. ~It was fine on Load/Unload, but would overshoot when printing most times. So then I used the bowden calibration to get a consistent high speed unload. ~28 mm extra pretty repeatably. Didn’t matter when I did all those things listed above. I also tried turning down Top Unload Speed (4600-3000) and accel (some similar percentage) and no difference. Picking up the dropped thought: I’d set that 610 eject steps down all the way to 25 with no effect, but it wouldn’t do a load/unload because it wasn’t ejecting enough.

So now I’m thinking there’s extra unloading going on for some reason. So then I took some videos. https://photos.app.goo.gl/KLS7XDsEsLe2dryc7 Watch the two, one is the load/unload cycle and one is two filament calibrations. It’s harder to see the roller than intended, but you can tell there’s plenty of time for the ball to fall, the filament essentially stops, but then unloads an amount about the same as the desired one, slowly, afterwards.

I don’t know how or why, but no sir, I don’t like it. One last thing:

(line 54 motion.cpp) const int IDLER_PARKING_STEPS = (IDLER_STEPS / 2) + 60; // 237 Not sure that's relevant.

Old comments/Deleted Posts:

I can say that basically every filament change, I have to go bump the filament forward a CM or so. I've tweaked some numbers but keep having to do that. My tips are reasonable.

Anyway, I'll have to find a way to tune this to get reliable filament changes (what numbers effect this? How can I test them?) or else I'll just have to go back to build 214-228 which was working without issue if I actually want to print. I'd really like something like "Try changing these three numbers and tell me if ____ changes". :-)

I set the value down to 25, and after a "load" the filament doesn't even pull back out of the selector. However, it still works fine when doing a bowden calibration. In short, I don't think that number is used (or used as is) in actual filament changes. I saw something like "distance / 2 + 60" (line 54 motion.cpp) const int IDLER_PARKING_STEPS = (IDLER_STEPS / 2) + 60; // 237 Not sure that's relevant. Trying a print now with distance set to -25. ` // public variables: int8_t filament_type[EXTRUDERS] = { 0, 0, 0, 0, 0}; const int filament_lookup_table[8][3] = /0/ {{4600, 400, 2800},

/1/ {4000, 100, 1500},

/2/ { 725, 830, 755}, //Abe was {300,330,300}. 755 maybe too much?

/3/ {-350, -25, -25}, //Abe was /3/ {-610, -610, -610}, (450 too high)

/4/ {6000, 10000, 6500},

/5/ { 600, 300, 550},

/6/ { 350, 200, 385},

/7/ { 400, 200, 455}

};` First (couple of) filament changes worked just fine, it pulled back partway into PTFE tube and out of selector. In other words, I don't think I'm modifying the variable used during printing, only what is used in calibration and other non-printing activities. Please advise.

Ok, that;s just the wrong thing,. 610 is like 1/3 of the way into the tube, probably perfect.

But it's not happening when I print. I believe you're right that it;s about the speed, though I'm unsure if its the ball or just momentum in the filament?

Either way, on the calibration unload it overshoots by ~25mm from where it does on a normal load cycle (with your 610).

I haven't yet printed your part, I've tried prying the ball down and backing off on the sensor but I get the same retract every time. Not conclusive

[TheZeroBeast]

IDLER_PARKING_STEPS

const int IDLER_PARKING_STEPS = (IDLER_STEPS / 2) + 60; // 237 This is used as the steps the IDLER takes when engaging and disengaging with filament. It plays no part in extrusion distances.

FILAMENT_PARKING_STEPS

The left side of this matrix is for hard plastics only, modifying the right two columns will have no effect until you slice flex or PVA in Slic3r. This is used every time each filament is parked so you're modifying it globally.

FEED_SPEED_PUL

Also, max speed is not going to effect the ball as all of the moves past the F.I.N.D.A. for sensing are done as per FEED_SPEED_PUL variable in the type matrix.

All I can suggest is as earlier regarding ensuring the ball bearing is dropping. You can either clean the channel for the ball of burrs & or print a mag mod selector.

I just checked and unload is done exactly the same, unload until F.I.N.D.A clear so that shouldn't change the result.

[AbeFM]

Why did the previous version work then?

              Thanks!
                      -Abe.

Sent from my "smart"phone, please excuse brevity and Swype-oes

On Wed, Dec 12, 2018, 2:27 AM TheZeroBeast <notifications@github.com wrote:

IDLER_PARKING_STEPS

const int IDLER_PARKING_STEPS = (IDLER_STEPS / 2) + 60; // 237 This is used as the steps the IDLER takes when engaging and disengaging with filament. It plays no part in extrusion distances. FILAMENT_PARKING_STEPS

The left side of this matrix is for hard plastics only, modifying the right two columns will have no effect until you slice flex or PVA in Slic3r. This is used every time each filament is parked so you're modifying it globally. FEED_SPEED_PUL

Also, max speed is not going to effect the ball as all of the moves past the F.I.N.D.A. for sensing are done as per FEED_SPEED_PUL variable in the type matrix.

All I can suggest is as earlier regarding ensuring the ball bearing is dropping. You can either clean the channel for the ball of burrs & or print a mag mod selector.

I just checked and unload is done exactly the same, unload until F.I.N.D.A clear so that shouldn't change the result.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/TheZeroBeast/MM-control-01/issues/44#issuecomment-446538183, or mute the thread https://github.com/notifications/unsubscribe-auth/AAClkXE-k-kAdcTtUmQ01kuAtzMCzsCwks5u4Nn3gaJpZM4ZOUPb .

[TheZeroBeast]

Try the latest code, there seams to of been some idler offset that may have affected the unload 👍

[AbeFM]

The new stuff (215-257) has some other errors (going in and out of calibration mode during normal use, feeding wrong filament) covered in another topic.

But I'm getting the same unload behavior as on 215-255, going to the same exact spot. Will try Finda speed Pull value much lower.

[AbeFM]

I dropped filament speed pull, which only seemed to effect the parking manuever - it would retract at full speed till the ball dropped, then very slowly pull back the same amount as always.

I tried setting L2ExStage1/2 both to 5, with no difference.

So I set max speed from 4600 to like 300, which makes the bowden calibration feed/unfeed take a LONG time (~25 seconds).

I get the EXACT same position as before, and there is no way to ball took too long to fall at that time scale. I'll add the video to the gallery, it's the 43 second video currently first.

[AbeFM]

At full speed (4600) but with the filament parking steps set from 610 to 0, the parking position is advanced, as expected. It still retracts too far, but less by the altered amount.

The same 0 setting, coupled with 300 speed gives a final position the same as the high speed case, within a mm. I've checked this several times with marks on filament.

Perhaps it works something like "if you don't see ball drop, go another 2cm, check again"? If not, there's some distance that's getting tacked on after ball falls, but I do not think it's time/momentum.

[AbeFM]

` if (digitalRead(A1)) { tmc2130_init_axis(AX_PUL, tmc2130_mode); tmc2130_init_axis(AX_IDL, tmc2130_mode); engage_filament_pulley(true); // get in contact with filament moveSmooth(AX_PUL, ((BOWDEN_LENGTH + filament_lookup_table[3][filament_type[extruder]]) * -1),//abe [2]-[3] filament_lookup_table[0][filament_type[extruder]], false, false, filament_lookup_table[1][filament_type[extruder]]); if (moveSmooth(AX_PUL, -3000, filament_lookup_table[5][filament_type[extruder]], false, false, ACC_NORMAL, true) == MR_Success) { // move to trigger FINDA moveSmooth(AX_PUL, filament_lookup_table[3][filament_type[extruder]], filament_lookup_table[5][filament_type[extruder]], false, false, ACC_NORMAL); // move to filament parking position

` Switching the element from 2 to 3 gives a better position.

Removing that entirely: moveSmooth(AX_PUL, ((BOWDEN_LENGTH) * -1),//abe

Gives nice results, with the filament ending up where it should, same as on a load/unload. I'm not sure this is where/how it should be fixed, but it does help.

I suspect you're not noticing the sensor on the retract, at least, not on calibration. I tied a print and it worked for several layers until notched filament started preventing feeds.

[TheZeroBeast]

This is directly due to your Bowden cal being invalid.

All that code was as it was supposed to be, if you re-instate the element 2 of the matrix and that line.

Do a BOWDEN cal to end of removed tube and then try again.

As mentioned in another issue ticket you calibrated to middle of bond tech gears, and the unload uses that number and distance from bondtech & sensor before doing FINDA checking.

Also note FINDA checking is done every step over the last 10cm so it's not a 2cm thing or single check.

[AbeFM]

AH! Thanks. It's working better now that I have that fixed.

I'd change "bowden tube length" to "sensor distance" or similar?

If you're not measuring to the gears, I don't see why I'm in the loop at all. You can make the filament eject, you can run it back and forth and find the sensor on your own. ("You" being the firmware). You need a person to tell you where the filament is everywhere except for the sensor.

I imagine a calibration routine that does a CM forward and 5 mm back over and over until it sees the sensor trigger. Or something like.

Working much better now, thanks!