-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request : Usage counters #4444
Comments
We already have the main counter that should be used for maintenance: total print time. We could add more counters but 1) not every printer is the same, it will be a #ifdef nightmare 2) the usefulness is rather limited. |
re: #ifdef nightmare.. I don't see it. Counters are at a higher level than the board's port mapping. Every printer has one or more steppers. Counts for each actual stepper. #ifdef seems not relevant or trivial at worst. At least not any more problematic than the recent PRINTCOUNTER PR, it would seem. That all being said, I will defer to the experts. Besides tracking of maintenance, the statistical failure rate of components is very useful to identify steppers, and heaters that have poor quality. Just because a component has a higher cost doesn't mean it is actually better quality or more reliable. I see this data has having tremendous value and usefulness both statistically speaking and for tracking maintenance on heavily used machines. |
Right, on a hobby grade printer.. using a 10€ stepper. Nevertheless we'll add it to the feature request list and check for more people interested, thanks for the suggestion. |
Not every machine running Marlin is considered Hobby Grade and many use expensive hardware. |
@adamfilip do you have some examples ? |
What about Ultimakers forks f.e they are aimed for professional too, at least according to their website:
|
Aren't they menwhile in? |
I means cumulative usage counters Counter of total fed filament since forever per hot end. Counter of total thousand steps per stepper motor since forever. Not just counters per print. That way when a failure occurs the count can be monitored and reliability factors can be measured. If you replaced a head after 6 months ago and you just replaced that one, it would be great to know how much usage the original head had on it before failure and how much usage the current one had on it. That way you can judge durability of different kind of heads or different manufactures of heads. Same with steppers, or extruders, or any other operating part on your printer. |
Have a look at |
I'm surprised no one has submitted code for it. It just needs to save the counter(s) into the EEPROM at a well-specified location and at configurable intervals, and keep adding onto it with every move. Then there needs to be a GCode to get a report, set, and reset it. And an LCD menu item to do the same. I'm sure it could be thrown together in a few hours. |
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. |
Most industrial machines maintain usage counters which are used for the purpose of documenting maintenance tasks and failure rates. A feature like this will be useful in school labs where the printer is used by everyone.
I suggest usage counters for the system and all major components including: power on time (seconds) for the system, hot end, and heated bed; steppers (total steps per unit), end stops (count of switch change). Obviously for these counters to be of use, they would need to be saved in EEPROM. These counters should be an unsigned long and non-resettable (at least as much as possible given the fact that EEPROM can just be edited, i.e. no special code created to reset them). As 32-bit unsigned integers, the counters could accumulate 4,294,967,295 mm of motion for each stepper motor before rolling over.
So some sanity checks... based on a print size of 18,000 mm of filament. The extruder counter would accumulate over 100,000 prints before rolling over. XYZ steppers roll-over will depend on the efficiency of the slicer, but will clearly be several thousands of prints. Using unsigned long for the total time counters (seconds) is a bit overkill (seeing that it would roll over after 136 years of use) and for counting end stop activations is exceedingly overkill. But I like the simplicity of making all the usage counters the same type.
The implementation would only require one new code to report total lifetime usage.
The text was updated successfully, but these errors were encountered: