feedmultiply decreases during printing

[neildarlow]

I have a forked Marlin_v1 at neildarlow/Marlin and am running my Marlin_v1_Mendel90 branch which contains customizations for nophead's Mendel90 and various Panelolu2 related changes. These changes are nothing major and as part of my testing I have spent some time watching the Panelolu2 display during printing.

What I am observing is, as printing progresses, the display of "feedmultiply" on the Panelolu2 is monotonically decreasing. After starting at a value of 100%, it has decreased to 68% after 4 hours 30 minutes of printing. I believe this is a real effect as the printing moves are noticeably slower also.

Looking at the code, feedmultiply does not appear to be modified in any way other than by specific GCode or Panelolu2 value editing - neither of which have been done.

This suggests that something is erroneously affecting feedmultiply and bears further investigation. I am looking for other incidences of this being observed.

[mattsch]

I've seen this as well recently on my dibond Mendel90 w/Panelolu2 (my own fork of Marlin tho), I've tried increasing BLOCK_BUFFER_SIZE to 64 but it hasn't seemed to help. The only thing I changed prior to noticing this was enabling firmware retraction but I can't say for sure if it was happening previously and I haven't tried disabling it yet. It doesn't seem to be related to the print complexity, even simple geometric shape prints trigger this.

Using slic3r and printing at a constant 45 or 50mm/s, with both .20mm and .10mm layers.

[neildarlow]

I don't have firmware retraction enabled so we might be able to eliminate that.

What I find interesting is that feedmultiply appears to be a setting which can be modified by GCode or via an LCD panel but I see several instances in the code where its value is saved and restored before/after some operations.

If this is required then it is possible that feedmultiply is being modified somewhere else that requires such special save/restore treatment.

What I don't know is whether this problem occurs as a result of having the Panelolu2 connected or whether it happens all the time but it is not visible without a display. I would have thought that the degree of slowdown measured on a long duration print would be obvious even without a display connected.

Something worth testing is to increase feedmultiply back to 100% after it has reduced. I have an idea that when this has been done it might stay at 100%. This is based on an observation from one print. I would appreciate feedback on whether this is actually the case.

[mattsch]

Hard to say about panel vs. no panel, but I'm just 3.5mm into a print[1] and it's already decided to slow down to 99%. I'm not seeing anything with the print that would make me think it should be slowing down, and my minsegment time is at the default of 20000ms. I suppose perhaps the infill segments might be part of the problem since they're printing at 45mm/s, but I've been using these speeds for quite some time and only recently noticed this slowdown hitting me.

Looking in planner.cpp, the code responsible for the slowdown doesn't seem to have changed in ages and looks pretty straightforward. Really not sure why/what has changed, starting to wonder if Slic3r is somehow responsible. Easy "fix" is to either disable slowdown or reduce minsegmenttime via m205 (just set to 10000ms for this print), but I'm not sure if that will fix things or just band-aide further and increase risk of stalling if the buffer empties.

[1] https://drive.google.com/file/d/0B25LBca0qlnuNVN0a3Z5b09xYTQ/edit?usp=sharing

[neildarlow]

I don't think this is slicer related (I use Skeinforge).

[mattsch]

Heh, well, good to rule that out at least then.

[mattsch]

Slowed down again to 99% at around the 23mm mark. Bumped it back up via LCD and we'll see if it continues to insist it should go slower.

[scotty1024]

Have y'all checked for noise on the encoder pins?

Or perhaps add a tick sound for feedback that the encoder is perceived as rotating?

I'm assuming y'all are using the short cables and not the long ones.

Scotty

On Mar 9, 2014, at 3:07 PM, Matthew Schick notifications@github.com wrote:

Slowed down again to 99% at around the 23mm mark. Bumped it back up via LCD and we'll see if it continues to insist it should go slower.

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

[orcinus]

Was just about to post the same thing. Set the encoder pins to -1 in pins.h to eliminate the encoder from the equation.

[mattsch]

Makes sense, might be this weekend before I can test again tho. Thanks!

[mattsch]

That seems to have sorted it. I tried setting the encoder pins to -1 in pins.h but it wouldn't compile so I just commented out the relevant code in ultralcd.cpp and I'm now 10.5 hrs into a print with no signs of slowdown. I submitted pull request #833 to make the feed multiplier controls optional as well.

Really not sure where this noise is coming from or why it's seemed to have popped up recently. I'm using the stock cables that came with the kit and nothing significant has changed hardware-wise. For now I'm just going to leave the controls disabled I think.

[scotty1024]

Now that you have the issue identified there are several solutions available to you.

A suggested root to start your research from for a solution you would like to use.

http://en.wikipedia.org/wiki/Active_EMI_reduction

A small value capacitor would be my first choice if this was happening to my encoder.

Scotty

On Mar 12, 2014, at 5:18 PM, Matthew Schick notifications@github.com wrote:

That seems to have sorted it. I tried setting the encoder pins to -1 in pins.h but it wouldn't compile so I just commented out the relevant code in ultralcd.cpp and I'm now 10.5 hrs into a print with no signs of slowdown. I submitted pull request #833 to make the feed multiplier controls optional as well.

Really not sure where this noise is coming from or why it's seemed to have popped up recently. I'm using the stock cables that came with the kit and nothing significant has changed hardware-wise. For now I'm just going to leave the controls disabled I think.

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

[neildarlow]

It might not be noise per.se. but jitter around a signal transition. The firmware performs no filtering of the encoder inputs (although reading the encoder pins via I2C rather than directly might help here) so there might be some scope to fix this in software.

[orcinus]

That's the encoder equivalent of a bounce, not jitter. 1) i'm not sure how it could happen, except if you consistently leave the encoder shaft in an "inconvenient" position (i.e. right on the edge of a "click"), and 2) i'm not sure how you'd discern between an unwanted and a wanted transition - the duty cycle isn't fixed in either case.

You could filter so that you require two transitions within a certain timeframe to accept the input, but that would make the encoder seem unresponsive and finicky (you'd need to quickly move it two detents then back one from an "idle" position).

Also, all of this is typically irrelevant when adjusting values in the menus and traversing the menu system. It's only an issue on the status screen, because of the highly dubious UI decision of making it control the feedrate multiplier from there.

[nophead]

If it's a quadrature encoder noise on either line should only make it deviate by +1 or -1 and return back again. Hard to see how it could progress in one direction only unless mechanical vibration is actually rotating the encoder.

On 13 March 2014 13:26, Ante Vukorepa notifications@github.com wrote:

That's the encoder equivalent of a bounce, not jitter. 1) i'm not sure how it could happen, except if you consistently leave the encoder shaft in an "inconvenient" position (i.e. right on the edge of a "click"), and 2) i'm not sure how you'd discern between an unwanted and a wanted transition - the duty cycle isn't fixed in either case.

You could filter so that you require two transitions within a certain timeframe to accept the input, but that would make the encoder seem unresponsive and finicky (you'd need to quickly move it two detents then back one from an "idle" position).

Also, all of this is typically irrelevant when adjusting values in the menus and traversing the menu system. It's only an issue on the status screen, because of the highly dubious UI decision of making it control the feedrate multiplier from there.

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

[orcinus]

Who said it has to be on a single line? If it's induced, it might be both.

[scotty1024]

As has been pointed out multiple times about these panels there is no proper ESD/EMI protection on any of these signals running through these flat cables.

Resisters caps chokes shielding all tweak the edges of the signals and discussing this large topic here seemed inappropriate to the other list members that are expecting to just track git pull request issues.

In software terms these circuits work by the Grace of the Happy Path and are fragile due to a lack of respect for corner cases and good exception handling.

Very likely the unknown actor that disturbed this particular person's panel off its previous happy path is an all to likely ESD strike to the encoder shaft (it gets plenty of operator walks over and makes first contact with it touches after all) that was transferred into the MCU and lightly damaged the MOSFETs throwing off their thresholds enough to make that input pin more susceptible to the already present noise.

ESD's occur at levels less than "static shock" and cause damage to unprotected circuits. This damage is generally of the lighter form I suggest above eg Zombie not corpse causing.

Small value capacitors, like I hinted I would use, help protect from this form of EMI/ESD.

The new MakiBox board and apparently Erik's off the radar ARM board are two examples of boards that claim to be addressing this long ignored issue. But doing so runs up the board BOM, PCB size and cost as well as assembly time for hobbyists.

If you pop open a Stratasys or 3D Systems $60,000+ 3D printer you will not find rotary optical encoder input devices touched by the operator hooked bare to the MCU. In fact you won't find any pin running off one board unprotected. Passing FCC/CE testing requires making sure you've knocked the hard corners off those square digital signals running into those nice little antennas hooked to the boards.

I'm pretty sure the "easiest fix" here is to replace the AVR chip with a fresh new one. The best fix, adding some components by scabing them on, would help limp the AVR along as well as help keep it from getting further damage.

Scotty

P.S. Erik, when is your board shipping??? :-)

On Mar 13, 2014, at 6:26 AM, Ante Vukorepa notifications@github.com wrote:

That's the encoder equivalent of a bounce, not jitter. 1) i'm not sure how it could happen, except if you consistently leave the encoder shaft in an "inconvenient" position (i.e. right on the edge of a "click"), and 2) i'm not sure how you'd discern between an unwanted and a wanted transition - the duty cycle isn't fixed in either case.

You could filter so that you require two transitions within a certain timeframe to accept the input, but that would make the encoder seem unresponsive and finicky (you'd need to quickly move it two detents then back one from an "idle" position).

Also, all of this is typically irrelevant when adjusting values in the menus and traversing the menu system. It's only an issue on the status screen, because of the highly dubious UI decision of making it control the feedrate multiplier from there.

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

[mattsch]

I'm also wondering if this has anything to do with the ENCODER_PULSES_PER_STEP changing to 4 in commit 8d162e5b, that timing lines up with when I started noticing the issue. Tho that change did make using the encoder much better for everything else so I wouldn't want to revert it, but my best guess is that plus noise is what got us here.

[T3P3]

It would surprise me if this was a hardware only issue given the number of encoder/screen controllers out there (Panelolu2 and others). If it's a quadrature encoder noise on either line should only make it deviate by +1 or -1 and return back again. Hard to see how it could progress in one direction only unless mechanical vibration is actually rotating the encoder.

On 13 March 2014 13:26, Ante Vukorepa notifications@github.com wrote:

That's the encoder equivalent of a bounce, not jitter. 1) i'm not sure how it could happen, except if you consistently leave the encoder shaft in an "inconvenient" position (i.e. right on the edge of a "click"), and 2) i'm not sure how you'd discern between an unwanted and a wanted transition - the duty cycle isn't fixed in either case.

You could filter so that you require two transitions within a certain timeframe to accept the input, but that would make the encoder seem unresponsive and finicky (you'd need to quickly move it two detents then back one from an "idle" position).

Also, all of this is typically irrelevant when adjusting values in the menus and traversing the menu system. It's only an issue on the status screen, because of the highly dubious UI decision of making it control the feedrate multiplier from there.

Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/825#issuecomment-37532045> .

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

[boelle]

has this one been solved? maybe it has been fixed but not tested?

[neildarlow]

Hi Bo,

I think it is an environmental thing. A couple of us observed the problem but I have not seen it recently. I guess it can be closed.

Regards, Neil Darlow

has this one been solved? maybe it has been fixed but not tested?

---

Reply to this email directly or view it on GitHub: https://github.com/ErikZalm/Marlin/issues/825#issuecomment-67680162

[boelle]

ok will close... issue can always be reopened.... we have about 200 open issues that i'm going through at the moment....

[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.