[BUG] Step Loss due to Printcounter (SKR1.3 & Possibly Similar Boards) #20785
Comments
ConstantijnCrijnen
changed the title
|
At the first, thank you for exhaustive information about your issue. I have just went through you config and have some ideas you can try:
🤞 |
sjasonsmith
added
Bug: Potential ?
Needs: More Data
|
Thanks for your suggestions! I'm not sure if my new data set is significant enough, but if it is, then Something seems to have fixed the problem now; let me explain. Temperatures Voltage Stability Testing
On printer 1 I first tested disabling Since I now had four successful pucks from two printers with two different sets of settings I was kind of sceptical, so I did one more control print with my original settings on printer 2, which also succeeded. With my current understanding, that would make sense if there was indeed some garbage in the eeprom, but the build with the disabled eeprom settings never touched printer 1, yet those pucks also finished without any issues. While the printers were printing the pucks with
So at this point I'd say that there was indeed something with the eeprom settings. But I'm still confused why printer 1 suddenly started printing well. As I said, I had always selected Anyway, I'm really grateful for your help. I will do some more "real-world" prints to see if it is really fixed, but at this point it seems that it is. |
I just went through the code again to make 100% sure that I reverted all the settings correctly and realised that I had forgotten to turn I now enabled |
|
It seems like there is something wrong with
|
|
Do they fail at the one hour mark? |
Not really... If I squint really hard, they do seem to accumulate a bit around the full hours though. |
|
I think the default interval for PRINTCOUNTER to store stats is one hour. On boards that store “EEPROM” contents in flash it has to write the entire EEPROM contents. It can’t update only the bytes needed for print stats. My guess is that is interfering with the print. One detail that might be throwing off your testing is that the flash sector is divided into 8 “eeprom slots” on this board. After storing to eeprom 8 times, the ninth has to perform a full erase of the sector, which will take much longer that a normal store. |
|
Yes that seems to be the case: if (ELAPSED(now, eeprom_next)) {
eeprom_next = now + saveInterval * 1000;
saveStats();
}with /**
* @brief Interval in seconds between EEPROM saves
* @details This const value defines what will be the time between each
* EEPROM save cycle, the development team recommends to set this value
* no lower than 3600 secs (1 hour).
*/
static constexpr uint16_t saveInterval = 3600;I just tested using So knowing that that is an issue with at least the SKR1.3 boards, could we just dismiss this query for all affected boards if (ELAPSED(now, eeprom_next)) {
eeprom_next = now + saveInterval * 1000;
saveStats();
}and just rely on bool PrintCounter::stop() {
TERN_(DEBUG_PRINTCOUNTER, debug(PSTR("stop")));
if (super::stop()) {
data.finishedPrints++;
data.printTime += deltaDuration();
if (duration() > data.longestPrint)
data.longestPrint = duration();
saveStats();
return true;
}
else return false;
}to do the job? Or is there a specific reason why you'd want to save the stats to EEPROM on a regular basis? |
|
I like the idea to still allow print stats but only at the end of each print. That seems like a good compromise. I think we would want to apply that to any board using FLASH_EEPROM_EMULATION. |
|
VSCode is telling me that |
|
Actually you are right. The E3 Mini V2 and probably MX have actual eeprom chips. Older do not. Maybe the problem is wider spread than I thought. |
|
Unfortunately I know too little about microcontrollers and marlin for that matter to know what exactly is going on 😕 |
ConstantijnCrijnen
changed the title
I did some more experimenting and found that this second issue I was having was also related to the printcounter, as the board would save the stats to eeprom as soon as I stopped the print. Unfortunately I can't do a pull request on my fix as it's always showing me the unicorn. I've never done this before... Am I doing something wrong? |
|
@ConstantijnCrijnen That happens to me too. Make sure you are doing a PR against the |
https://github.com/ConstantijnCrijnen/Marlin into Printcounter-Fix-(issue-MarlinFirmware#20785)" This reverts commit a5571df, reversing changes made to 977eaa0.
|
#20856 was merged. Closing. |
|
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. |
Bug Description
As already stated in my comment on issue 20645, I'm having a problem wich I've been trying to hunt down for over a year. I always thought that it was a mechanical issue, but after a year of tinkering and observing I'm now pretty sure that it's a software problem.
Issue 20645 states a knocking noise which seems to be coming from the use of SoftwareSerial when
MONITOR_DRIVER_STATUSis enabled. I thought that my issue was related, but after doing some more testing I'm now confident that it's not.There are two different issues, which are so similar that I think there might be a common issue between both of them.
1. [MAIN ISSUE] Step loss during SD Print
The drivers will randomly give a loud knock and and skip a couple of steps (around 0.5 to 2mm with GT2 20T pulleys and 1.8deg motors). It doesn't happen often and its occurrence seems to correlate with the feedrate. At 30mm/s max. speed the issue will occur around once per week with 24/7 printing. At 60mm/s about every two days, at 100mm/s 1-2 times per day and at 150mm/s every 1-2 hours.
The step loss always seems to occur in both X and Y simultaneously and without any kind of unexpected mechanical load such as collisions with boogers or warped prints.
2. SD Abort stops print but then continues for a bit more
Here's a video of what happens when I stop the SD print via LCD screen. The print stops immediately, then continues for a short moment and then proceeds with
EVENT_GCODE_SD_ABORTas expected. During the short move after the initial stop, the axes sometimes seem to move in a different direction as they otherwise should have if the print wasn't stopped.As @thinkyhead commented on issue 5982, this shouldn't be happening since the command queue should have been cleared and blocked.
Configuration Files
Configuration.zip
In trinamic.cpp under
#if HAS_DRIVER(TMC2209)I changed the following blank time from 1 to 3 since I'm running quite high-inductance motors (6mH per phase)chopconf.tbl = 0b11; // blank_time = 40.The version I'm using is the bugfix from around a week ago. Unfortunately I can't just upload and experiment with new bugfixes because the printers are running at my university and it's nearing the end of the semester so the printers have to printing non-stop.
Steps to Reproduce
I'm not entirely sure what it takes to reproduce. As I said, it seems to correlate with feedrate. My current solution is throttling the FR to max. 30mm/s. That way there is a step loss of around once per week. If I increase the FR, the time till failure (step loss) decreases.
Testing
As stated before, I did some testing to see if the issue is related to
MONITOR_DRIVER_STATUS. I printed solid 100mm diameter cylinders without perimeters and 190mm/s print speed. The print was aborted as soon as steps were lost, after which the TTF (Time Till Failure) was noted and a picture of the top surface was taken.As a control I tested with
MONITOR_DRIVER_STATUSenabled andSQUARE_WAVE_STEPPINGdisabled.To test issue 20645, I first disabled
MONITOR_DRIVER_STATUSand then enabledSQUARE_WAVE_STEPPING(see pictures).All tests combined. Green arrow: step loss, orange arrow: initiation of SD abort, red arrow: initiation of
EVENT_GCODE_SD_ABORT.Close-up. Green arrow: step loss, orange arrow: initiation of SD abort, red arrow: initiation of
EVENT_GCODE_SD_ABORT.Discussion
At least with this small sample size, I didn't see any improvement by disabling
MONITOR_DRIVER_STATUSand enablingSQUARE_WAVE_STEPPING. In fact, the TTF was worse with those prints. The data is of course not significant enough to make any quantitative statements, but qualitatively, the step loss-issue did persist.I didn't capture the step loss-issue on video, but it sounds identical to the video I shared above when aborting via LCD. The movement pattern of both the step loss and SD abort also looks very similar. This leads me to believe that there might be an issue where an error state is triggered which calls one of the functions from the SD abort routine. That's a wild guess of course.
Other than that, I'm a bit out of ideas unfortunately. I do want to optimise the chopper parameters according to Trinamic's datasheet in the future, but I'll need to get a current probe for that. My current chopper settings are all theoretical and based on Trinamic's formulas. Maybe those are just wrong. But I can confirm that the stock chopper settings gave the same issue and made my specific motors sound worse.
Additional Information
M122 after losing steps and SD abort:
The text was updated successfully, but these errors were encountered: