Would it be possible to add a run time hour meter to the software for maintenance?
Would be nice to have a set number of hours that maintenance needs to be done with out guessing the hours in between.
5 Likes
I don’t have my machine yet, but after seeing some pics of the sawdust build up, I’ve been looking at digital hour meters like you see on riding lawnmowers, etc. Some of them have re-settable maintenance timers.
There are some inexpensive hour meters intended for use on equipment with small gas motors. They sense the vibration of the machine and run the clock based off that. Close enough for tracking maintenance hours like oil and other filter changes. Might work for what you want to do. Battery operated there is nothing to do as far as powering them which also frees up where you can place them. Should be less than $25. We used to use them at a place I worked but I didn’t remember where we bought them from or the manufacturers name. Probably available from Amazon, Grainger, McMaster-Carr, and a bunch of other sources.
1 Like
I’ve been thinking about getting one of these. [Watt meter](BN-LINK LCD Plug in Power Energy Meter Voltage Amps Electricity Usage Monitor Digital LCD Display Wall Socket Outlet,Power Consumption Monitor, 7 Display Modes for Energy Saving, Watt Meter https://www.amazon.com/dp/B06XH73LJB/ref=cm_sw_r_cp_api_glt_fabc_E71E2PQJN1RHVVQ4QC60?_encoding=UTF8&psc=1) I have not yet bought it so I cannot comment on how good the product is or if it works as intended. It’s only made it as far as a medium priority in my ever-growing cnc list on Amazon.
I use an hour meter on my controller for on time and also on my vacuum for run time. A software meter would be nice.
1 Like
A pass-through device such as the Kill-A-Watt or some other plug-in meter that could blindly clock ON hours do not to me seem to be the way to go and could result in performing excessive maintenance which increases down time and operating costs. I don’t believe the Kill-A-Watt or similar meters can actually track ON hours anyway.
Here is an hourmeter that may work. I say may because I have no firsthand experience with this brand or model. I was searching for a meter that would work with AC motors. The model I had used in the past had pickups triggered by vibration created by a diesel motor powering a pump and those probably would not work well on a CNC.
Tracking hours of use for a machine like the CNC for the purpose of performing PMs (periodic maintenance) seems difficult to me. You can accumulate a high number of ON hours with the machine idling while you set up and position your work and between jobs because no one is likely to shut the machine down multiple times per day or session. It’s going to come on and stay on until you’re done for the day would be my bet.
Tracking spindle run time seems a better indicator of actual movement that would equate to requiring maintenance such as cleaning and oiling. IF the controller had a couple internal registers running to track hours of use or actual distance traveled for X, Y, and Z that might be helpful. Popup reminders and alarms could then be set to alert users to approaching maintenance intervals. This solution is all software, no external hardware or interface required.
Everyone will use their machine differently. My X travel might be 10x my Y axis or someone else’s could be completely different.
There are a number of places selling this device. I found this one on DigiKey and downloaded the product datasheet which I have attached to this post. No doubt there are other make/models which will work also. This is only one possible solution but ultimately I think adding this capability to the controller software is better. I am sure someone will disagree so feel free to post your solution or ideas.
MT10R AC Motor Hourmeter.pdf (214.1 KB)
Hey Bob, hey all,
good VFDs like Omron MX2 / Hitachi WJ200 record how many hours the VFD has been in “RUN” mode (=spindle runs) (monitor parameter “d016”). Power on hours are recorded as well (“d017”).
On a unixoid system like the Raspbian-based Onefinity Controller, you could write a script that records and collects uptime into a log file when shutting down and compute a total runtime, maybe with triggering warning events when reaching a certain time. But this would apply to controller uptime only, not stepper motors running time.
Inside application, there also could be anchors to implement recording runtimes. That’s the place where it should be implemented in my opinion. A feature request could also be made upstream.
1 Like
Since the Onefinity controller is a fork off the original Buildbotics design will that really help Onefinity users?
Possibly they will implement a solution that could be copied over to the Onefinity.
Hey Bob,
features or fixes added upstream are usually inherited downstream. That’s why it’s often better to make feature requests or bug reports upstream, e.g. it’s often better to report to chromium instead of vivaldi which uses the chromium code. Downstream maintainers often forward bug reports upstream anyway. In the case a fix or feature is added downstream, upstream maintainers can adopt it.
Also sometimes it is the case that upstream maintainers are more responsive 
1 Like
OK, just going by what I’ve seen here that the current Onefinity controller has little resemblance to the current BB controller and also the obvious that changes to the BB controller after the split mean nothing to Onefinity.
Hence my comment asking how making an upstream request could possibly benefit Onefinity users. They share some root DNA but have both morphed to evolve along parallel lines.
Hey Bob,
Little resemblance? I would not say that. If I look at schematics vs. schematics, pcb vs. pcb, code vs. code, I do not come to this conclusion (notabene without downplaying Onefinity’s adaptation work).
You mean e.g. one might wonder when or whether at all the macros feature which buildbotics implemented will become available on Onefinity. I count at least three threads started in “Feature Requests” asking for this. I don’t know if they are responsive to this.
Of course, everybody who makes a fork has the option to ignore improvements that are made upstream. But if sometimes such seems to be the case, it’s often because maintaining a fork and keep up with upstream fixes and improvements really is work.
I would say if it is a feature that has nothing to do with the modifications that the forker applies to forked code, and especially in this case according to the amount of code that is originary from buildbotics, I would address such a feature request upstream. I also see more chances for implementing something new there, and I also feel it is the right way to go. In my eyes making clear to the manufacturer of an entire CNC machine that customers want something from controller upstream is a second step. Of course you can request that feature from Onefinity, I’m not opposing to this, if you find it more probable to succeed this way.
Yes please! do replies bump posts in this forum?