FR: ulticontroller: Flow tuning steps

[jgeerds-zz]

Please change the e steps/flow tuning steps in the ulticontroller from 1/100 steps to 1/10, or even better 1/1 steps. to compensate changing diameters on the ultimaker, i.e. from 2.85 to 2.70 requires about 50 units change in the e steps, and it takes about 2 ages to get there with 1/100 encoder steps.

[jgeerds-zz]

nothing?

[gwelchc]

I may be wrong, but that sounds like something you do while calibrating the machine (and the firmware).

[jgeerds-zz]

much of the filament available on the market has some variation in diameter, and the easiest way to adjust the print volume is the flow rate, which is painful at 1/100 steps.

[MoonCactus]

I usually add a simple inertia to such encoders, so that slow turning = fine adjustment, fast turning = coarse adjustment, and faster= even coarser.

This is easily done with time-based inertia. Turning the encoder adds or subtract a costant to a scalar A. Then independently of the event A is regularly added to the value to be set (if possible, normalized by time). Additionally, A is multiplied by 0.9 each second (e.g. and here again, normalized whenever possible).

The best is when a time ticker is available, or at least when the polling occurs at somehow regular interval. It would be harder if it's an interrupt and non time is available

We see this on microwave ovens for example (though they usually adopt thresholds instead, which may be an alternative: the number of clicks per second defines the amount)

[RedwoodForest]

I would definitely like to see this as well. This also applies to other things like moving the head around the bed.

My original post to the Ultimaker Google Group on the subject: https://groups.google.com/forum/?fromgroups=#!topic/ultimaker/8fAUX_wfb9o

[daid]

I'm currently re-designing all of the LCD menu code to make it easier to change and increase flexibility and increasing consistency.

[bkubicek]

On 11/13/2012 11:22 AM, daid wrote:

I'm currently re-designing all of the LCD menu code to make it easier to change and increase flexibility and increasing consistency.

I think it would be a good thing if you say first what you want to change, and it can be discussed before you do it. I personally rewrote the thing three times from scratch. And know quite some dead ends...

greetings, bernhard

[daid]

Functional I want mostly the same thing as it does right now. But with a cleaner code structure. Better separation of menu logic and LCD logic. I know some of the troubles you went trough while making the original code, and I have short lines with Joris.

[bkubicek]

On 11/13/2012 11:54 AM, daid wrote:

Functional I want mostly the same thing as it does right now. But with a cleaner code structure. Better separation of menu logic and LCD logic. I know some of the troubles you went trough while making the original code, and I have short lines with Joris.

I know that. And I trust you. The question is how do you want to have cleaner code? I am not angry or guarding or anything, I really would like to know... I had originally a nice in code approach with classes. It failed, because then most parts are stored in RAM and it lead to memory overflow. Also I am currently investigating to add the LCD to the 4pi firmware. greetings, bernhard

[daid]

I'm still working on the details. I'll let you know as soon as I have something functional that I like enough. As always, minimizing RAM usage is important. And I'm not using classes, because classes cause "this" pointer references everywhere, which inflates code a lot.

[jgeerds-zz]

while you are completely redesigning the LCD menu (which is a great thing), can you just make this small fix with the flow steps, as a quick stop-gap measure until the new menu is done?

[daid]

I could do a:

if DEFAULT_STEPS_PER_E > 100

do whole steps

else

do 0.01 steps

endif

?

[ZetaPhoenix]

I suggest replacing it with a "Flow overide" percentage. I'd adjust that by .5% each click?

-Jon

Sent from my iPhone

On Nov 13, 2012, at 5:55 AM, daid notifications@github.com wrote:

I could do a:

if DEFAULT_STEPS_PER_E > 100

do whole steps

else

do 0.01 steps

endif

?

— Reply to this email directly or view it on GitHub.

[jgeerds-zz]

yes, half-percent steps are acceptable

[daid]

Currently there is an "extrudemultiply" which is done in whole percentages, you can set it with "M221 Sxxx", we could bind this to the flow menu item?

[bkubicek]

no, because its not the same. Flow is just filament thickness corrections, not build speed correction.

Bernhard

On Wed, Nov 14, 2012 at 10:52 AM, daid notifications@github.com wrote:

Currently there is an "extrudemultiply" which is done in whole percentages, you can set it with "M221 Sxxx", we could bind this to the flow menu item?

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/224#issuecomment-10360568.

[daid]

M221 not M220 Bernard.

[jgeerds-zz]

I think M221 and modifying the E steps are more or less equivalent, there might be a small difference with the retraction speed, and how the system reacts to speed changes via M220, but overall I think those would be negligible.

So yes, can we have flow control via percentages?

[jgeerds-zz]

David: any word on the fix for this issue, or even the new LCD menu code?

[daid]

The good news first, my new menu code is working, VERY nicely. It feels more consistent, and it has a few bug fixes (like the problem where you move too fast trough the SD menu and it messes up) More good news, I'm currently testing it on a few Ultimakers at Ultimaker HQ. Even more good news, I've already started to merge a few of the changes that I did to cleanup code this to prepare my other changes.

Now, for the "bad" news. I've also changed the temperature measurement code to clean it up. And my new LCD code depends on this. But temperature measurement is a very critical piece of code, so I want to test is a lot as it's also safety critical.

And in more good news, it's prepared to support more display types, graphical LCDs for example. As the "visual" implementation and the menu structure are separated. It's also easier to customize, for example, the prepare menu looks like this:

    START_MENU();
    MENU_ITEM(back, MSG_MAIN, lcd_main_menu);
    MENU_ITEM(gcode, MSG_DISABLE_STEPPERS, PSTR("M84"));
    MENU_ITEM(gcode, MSG_AUTO_HOME, PSTR("G28"));
    //MENU_ITEM(gcode, MSG_SET_ORIGIN, PSTR("G92 X0 Y0 Z0"));
    MENU_ITEM(function, MSG_PREHEAT_PLA, lcd_preheat_pla);
    MENU_ITEM(function, MSG_PREHEAT_ABS, lcd_preheat_abs);
    MENU_ITEM(gcode, MSG_COOLDOWN, PSTR("M104 S0\nM140 S0"));
    MENU_ITEM(submenu, MSG_MOVE_AXIS, lcd_move_menu);
    END_MENU();

Or another example, some settings to configure:

    MENU_ITEM_EDIT(float3, MSG_VMAX MSG_X, &max_feedrate[X_AXIS], 1, 999);
    MENU_ITEM_EDIT(float3, MSG_VMAX MSG_Y, &max_feedrate[Y_AXIS], 1, 999);
    MENU_ITEM_EDIT(float3, MSG_VMAX MSG_Z, &max_feedrate[Z_AXIS], 1, 999);
    MENU_ITEM_EDIT(float3, MSG_VMAX MSG_E, &max_feedrate[E_AXIS], 1, 999);

If you want, I can send you a copy of this code. I'm confident it works without problems. But to be sure, I'm merging it in as small steps as possible. But there are 2 large merges incoming, first being the new temperature code. Then the new LCD code.

[daid]

Oh, and yes, it adjust flow in percentages, and the "stop SD print" acts instantly instead of waiting for a while.

[MoonCactus]

gcode: nice feature to add a M81 to shut the printer off if/when it has a suicide mode

[daid]

Problem with the suicide mode is that the current code doesn't know for sure if you have it. Many motherboard settings define a pin for it, but that doesn't mean it's actually implemented on the rest of the hardware.

But you could easily add it yourself with this new code.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.