Total hours of operation/printing feature.

mwolter

@dc42 Maybe the total time on could be a reoccurring job that increments a counter instead of something that is recorded at the end of or during a print job? For instance, every minute a job kicks off that increments the counter? This way the most that could be lost is a minute when the printer is turned off.

Knowing the total on-time and total distance traveled for each of the axis would be very helpful for maintenance purposes. Then if this "usage" data is included in a rr_status JSON response, an external PC (Raspberry Pi with Nodered) can be set up to produce reports and alerts to notify when preventative maintenance should be performed. This would be very helpful for the lubrication of linear rails, bearings and guides and/or replacement of consumables such as belts. Would also be helpful if these counters can be reset once the maintenance is performed.

A Former User

@mwolter said in Total hours of operation/printing feature.:

Would also be helpful if these counters can be reset once the maintenance is performed.

I'd say keep the running total like the odometer for a car; you can have different service intervals for different parts. On the other hand being able to reset counters if hardware is replaced could be usefull, but looking back to cars you can find cars with 400.000km on the clock and new engine at 300.000km that only had 100.000km on it f.ex. Still possible to work out the intervals for maintenance with a running total; top level systems could deal with the rest.

Having a task to record run time only write to flash every so often to prevent premature flash failure is acceptable with respect to power loss, best efforts to write on a power failure would be nice, but not critical.

TLAS

@dc42
FYI, I think filament used per nozzle would be a great feature, although an easy implementation would be with the web server. From a UI perspective it would be great to be able to click ‘zero counter’ if a nozzle is replaced or a new filament spool is changed out. Digital spool management would be awesome. :). On the Duet side, a simple timer function that runs once a second should be adequate (checks if extruding a nozzle, or printing, etc... and just up the counter. Add a gcode command to reset a given timer.

Main application would be nozzles that wear out often with abrasive filament.

Also makes a good business opportunity for maintenance (everyone paranoid about privacy and open market please look away now...) Imagine a notification “your Duet board (or smart effector /etc) is nearing 1000 hours of use, please click here for a free discount on a replacement board...” And embed in the web request the number of operating hours. You then start collecting reliability data for the various Duet products, offer the end user a ‘convience click’ and discount for replacement parts, and drive up sales and advertising at specific vendors for new products... Not that I’m normally in favor of this kind of thing but I would wholeheartedly support it if it’s creating data leading to better products.

deckingman

I see now why this feature hasn't been implemented. Whenever the topic comes up, lots of users jump in and ask for something different. If we could agree that a simple "hour meter" or "distance meter" would be useful, then David is more likely to implement it. As for being targeted by some sort of "pop up" telling me to check a "special offer", please God NO!

samlogan87

I agree with @deckingman

Whilst all of the other counters would be nice to have, as a mvp, run hours and axis travel distance would be more than sufficient.

My 2c worth

Sam

A Former User

As I have said before

A simple "hour" meter would be easy to install, print time is already logged which anyone using a printer for making money can log those hours into their accounting software anything else is just "fluffing"

timcurtis67

I vote for a simple hour meter.

toskium

I'd like a simple "Work Hours Meter", whenever gcode is processed it should log time.

I can see how this can be a problem for initial setup where gcode is executed, as well on boot time, but from my point of view this can be neglected. Its not like it has any serious effect when it logs 65min additional time...

For easier implementation the "start gcode" could hold some Mxxx gcode and "end gcode" as well. I don't have any special needs for additional calculation.

However: only counting hours is too simple. My prints often start over night, I leave them in the morning, then I go to work, etc. After the print has finished the machine is idling happily for many hours which then would be counted as "work hours".

IMHO it would also suffice to read the currently logged hours via some gcode command, no need for DWC integration or whatsoever. I solely need this for maintenance purposes. The counter can optionally be reset using some gcode parameter or so.

My 2ct on this topic.

jlipavsky79

Has any progress been made on this subject?
@dc42 ?

Topher

@dc42 The ideas in this thread are really good, has there been any implementation? I really like the idea of a total filament extruded, help to nip the clogged nozzles BEFORE they clog!

iff7378

I'd love to see this implemented. I have a Modix printer that uses Duet hardware and prints are regularly 24 hours or longer. Being able to set up preventive maintenance based on clocked print hours would be extremely useful. All of our other printers have this feature! (Craftbot, Flashforge, Stratasys)

chrisqwertz

Hi!

I think I have a solution to the problem:

create sys/runtime.g and add

global runtime = 0

in sys/config.g add

; init print time logging
if !exists(global.runtime)
  M98 P"runtime.g"

create sys/daemon.g if it doesn't already exist and add

if state.status == "processing"
  if exists(global.runtime)
    set global.runtime = {global.runtime + 10}
    echo > "runtime.g" "global runtime = " ^ {global.runtime} ^ " ; AUTO GENERATED by daemon.g"

This will increment the global variable "runtime" every time daemon.g is called by 10 and write the new value into runtime.g. This should be correct as daemon.g is called every 10 secs as of RRF 3.3

Let me know if it doesn't work for you.

T3P3Tony

@chrisqwertz

I like this solution, however its not good practice to use deamon.g in that way:

https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands#daemong

It is recommended to use a while loop inside the daemon.g file if you are using it to prevent the firmware having to open it every 10 seconds.

Better to put the loop inside daemon.g itself

while true
    if state.status == "processing"
        if exists(global.runtime)
            set global.runtime = {global.runtime + 10}
            echo > "runtime.g" "global runtime = " ^ {global.runtime} ^ " ; AUTO GENERATED by daemon.g"
    G4 S10 ;wait 10 seconds.

This will provide approximately 10 second increments to the run time log file.

You may be able to get a more accurate log by exploiting the object model "state.time" value.

chrisqwertz

@t3p3tony Ah i see, that makes sense. Thank you, your feedback is very much appreciated!

RogerPodacter

when i try to implement this function and add a daemon.g file, i get the following error. using RRF 3.4.2 and DWC 3.4.2.

Error: in file macro line 5 column 19: meta command: expected string expression

My daemon file is:

while true
    if state.status == "processing"
        if exists(global.runtime)
            set global.runtime = {global.runtime + 10}
            echo > "runtime.g" "global runtime = " ^ {global.runtime} ^ " ; AUTO GENERATED by daemon.g"
    G4 S10 ;wait 10 seconds.

also, i dont understand why its calling it a macro.

RogerPodacter

@RogerPodacter nevermind, i solved the issue by looking at the latest documentation: Gcode Meta

the echo command cannot have a space after the >.

Fixed code:

while true
    if state.status == "processing"
        if exists(global.runtime)
            set global.runtime = {global.runtime + 10}
            echo >"runtime.g" "global runtime = " ^ {global.runtime} ^ " ; AUTO GENERATED by daemon.g"
    G4 S10 ;wait 10 seconds.

justus2342

I like the idea of using the daemon.g. But what about the wear of the sd card? How smart can the controller of the sd card expected to be? Is it writing the exact same blocks over and over again? How bad is it for the card?

RogerPodacter

@justus2342 i dont know the answer, but i am not worried about it since 8gb SD cards are so cheap and common now, even if it accelerates the shelf life, i can live with replacing the SD card once every 2 years.

but its a good question. @dc42 may know.