Skip to content
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

Closed
mjmeans opened this issue Jul 28, 2016 · 12 comments
Closed

Feature Request : Usage counters #4444

mjmeans opened this issue Jul 28, 2016 · 12 comments
Labels
T: Feature Request Features requested by users.

Comments

@mjmeans
Copy link

mjmeans commented Jul 28, 2016

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.

@petrzjunior
Copy link
Contributor

Some of the features are already included in RCBugFix branch such as #3625, #4298, #4312 etc. System uptime (for instance) sounds interesting, but do we really need it?

@jbrazio
Copy link
Contributor

jbrazio commented Jul 28, 2016

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.

@mjmeans
Copy link
Author

mjmeans commented Jul 28, 2016

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.

@jbrazio
Copy link
Contributor

jbrazio commented Jul 28, 2016

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.

@jbrazio jbrazio added the T: Feature Request Features requested by users. label Jul 28, 2016
@adamfilip
Copy link

Not every machine running Marlin is considered Hobby Grade and many use expensive hardware.

@jbrazio
Copy link
Contributor

jbrazio commented Jul 29, 2016

@adamfilip do you have some examples ?
I would love to add them to our website as "use cases".

@Maaajaaa
Copy link

Maaajaaa commented Dec 4, 2016

What about Ultimakers forks f.e they are aimed for professional too, at least according to their website:

Professional 3D printing made accessible

Accurate, consistent results - tailored to your business. Highly complex 3D prints, industrial-grade materials, maximum performance, and future-ready 3D printing experience. With ultimate accessibility.

@Blue-Marlin
Copy link
Contributor

Blue-Marlin commented Dec 4, 2016

'Usage counters'

Aren't they menwhile in?
Should be closed.

@mjmeans
Copy link
Author

mjmeans commented Dec 5, 2016

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.

@Blue-Marlin
Copy link
Contributor

Have a look at PRINTCOUNTER and extend to your needs.

@thinkyhead
Copy link
Member

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.

@github-actions
Copy link

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.

@github-actions github-actions bot locked and limited conversation to collaborators Mar 20, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
T: Feature Request Features requested by users.
Projects
None yet
Development

No branches or pull requests

7 participants