Go Down

Topic: Labor (time) Monitoring (Read 347 times) previous topic - next topic


Hello all!

      I hope that this question is posed in the correct sub-forum.  I am wishing to construct in the simplest way possible, a device that can track time spent on a job by workers.

To give some background objective for the project:

    I own a body shop and have trouble getting my workers to record their hours spent on each car - it can be tough when working between a few different vehicles during the day.  I would like to have a device that I can essentially tie onto the clipboards, which contain the workorders for each car, that would allow the employee to press a button to "start" working, and the device will count hours in 0.1 increments (6 minutes) until it is "stopped" by the same button. It should be able to tally up the total hours spent across multiple start/stops and save the basic data to be uploaded into my management software.  I would have one device per car and as the jobs and workorders roll through the shop, each person would start/stop the device with the simple button.  At the end I upload the info and check out what was spent in total on that job. 

    There are a lot of specifics that will go into this as far as the actual data it saves and the format that it's in needing to match my management software, the possibility of multiple start/stop buttons on one device that are set to each employee (for situations where more than one person is working on the same vehicle)but I am mainly interested in finding out if such a device possible with arduino....or is this a raspberry pi situation?

     I'm hoping arduino will work, given the ruggedness compared to pi as far as booting/power loss goes, but I am very green with all of this and am hoping for some basic insight.

Any help is greatly appreciated by this n00b, thank you!!


Split it into smaller problems. You've posted in the "Product design" forum which suggests that you need help with the physical design of the product, not the programming or interfacing with the other software.

So, you've proposed a device like a clipboard that can be carried around the shop. First question: does it link to your WiFi for real-time data updates or will you bring it back to the office at the end of every shift to download? (and recharge the battery)

Second question: how are you expecting to identify the employees? You do need to know that it was Fred the specialist electrician who worked on that car? Or are all your shop guys charged out at the same $/hr to the customer so you only need to tell the customer total man-hours? This question will drive the design of the keyboard on the device. Often a 3 or 4 digit idenitity number would need to be typed in to identify the person.

Third, have you looked at RFID? The kind of reader used as a door lock can be used to read the worker's tags. I'm imagining a system where there's a reader at each car bay. There's a small bucket in front of the reader and each worker drops their tag in the bucket when they start work. If they move away, they find their tag in the bucket and take it with them. Or maybe a row of hooks, so it's more obvious if Fred steals my tag for a joke. Doing it this way means the "clipboard" device doesn't get dropped on the floor and it can be wired for power. You could even have a number of these readers near the exit of the workshop: "Clocked out" "offsite callout" "attending customer in carpark."

Do you have any apprentices in your shop? Give them the job of designing the device's outer case, once you've worked out what keyboard and screen you want. Give them some supplies of bondo and fibreglass. Make it a competition between them.
GoForSmoke: "What GShield? You never mentioned a shield."


Thanks for the reply!

Yes, I posted in the product design forum, mainly to find out whether the general design I have is possible with Arduino or not.

I think you have some good ideas regarding RFID, I have thought about scanning in/out being a great way to have separate ID's for sure - but want to start with the basic idea as proof of concept and then dial in the software, so starting with one button and working up from there gradually adding features as we start to use it.  The idea of fixed ones in the bays has crossed my mind as well because it takes out the ruggednesss needed for a handheld design and eliminates any battery concern in one move.  But to get the functionality I'm hoping to achieve I think will require a good amount of time coding....So, to zero back in on the basic idea, would this essentially work with an Arduino? If so, what other peripherals would I need? I suppose a battery, switch/button, SD card slot for memory.....what else?


I don't think an SD card is necessary. Every Arduino has EEPROM memory which holds values when the power is off. Your data will probably fit in the EEPROM.

An RTC (real time clock) might be necessary. Otherwise you need to be able to contact the central server to get the time.

Does the handheld need a screen, to show how many people are logged in to that job? Does the screen show the job name?

It is certainly a good project for Arduino. I would call it relatively complex, which is why I suggest breaking it down into small chunks. Like first get an Arduino and some buttons and an RTC and start small.

There must be commercial systems out there. They probably cost thousands but it is always worth doing the research to find out how other people have solved the same problem.
GoForSmoke: "What GShield? You never mentioned a shield."


Great feedback.

To address a few of the questions:

1) There are not actually any systems out there like I am proposing.  The company who produces the software I want to pump the data into does have a "shop clock" but its just software.  Guys have to go over to the shop computer (or everyone has to have one) locate the job they will work on in the list, click "on" and repeat reverse steps to end the job.  A small separate issue is that many body men/painters/mechanics aren't super good with computers so they take a long time to check in and out or need extensive training just to click a few buttons - and having accurate labor tracking on a job is only helpful when everyone can do it all the time every time.  I'm looking to reduce complexity, and ultimately reduce the time it takes to record this info.

2) I don't think it will need a screen, at least at this point.  The paper work order sheet (which the device will ideally tag along with) identifys which car it belongs to and what needs to be done to that car.  I may have to "set" the device to be workorder #123 when I send out the device with the workorder at the start of the job so that when the labor total is tally'd by the device it has the corresponding WO number embedded in it already.  But the workers will not need to know which number is which - only that the workorder has an accompanying clock they need to punch in and out from.

3) Looking into RTC and internal timer, will millis() be accurate enough you think? I only need to dial into the nearest 0.1 of an hour (6 minutes) its not entirely necessary that it date stamps the real calendar date onto the labor data.   An RTC may be helpful, but I really only want to add up total time regardless of calendar date or extreme accuracy. Being able to round up or down to the nearest 0.1 of an hour is as deep as industry pay rates go.  No one bills out 1.567558 hours or anything crazy, its always like 1.5, 1.6 hours etc.

4)EEPROM I had not thought of, I suppose the ultimate file will not be that large given what I'm trying to do.

I do need to break it into chunks for sure.  My Arduinos, breadboards and components arrived today, so I'm open to any suggestions regarding best places to start or any info on where to begin sketching some code for this purpose.  Really appreciate the discussion and ideas you have - thank you.


Hi Jim:
You have described pretty much exactly a product I've been thinking about for a long time except I was targetting a different industry. The main difference is I was planning to use cheap tablets/old phones to do this instead of Arduino. It can be done with Arduinos, but a $50 tablet has a lot more useful features.

Would you mind at all if I PM'd you to get some more feedback about how it should work?
Electronics and firmware/software design and assistance. No project too small


Hi Jim:
You have described pretty much exactly a product I've been thinking about for a long time except I was targetting a different industry. The main difference is I was planning to use cheap tablets/old phones to do this instead of Arduino. It can be done with Arduinos, but a $50 tablet has a lot more useful features.

Would you mind at all if I PM'd you to get some more feedback about how it should work?

Feel free to message me :)


If it wasn't for the "uploading to your computer" bit, I would suggest a basket full of cheap electronic stopwatches.


This is certainly possible and arduino, or even better a bare atmega328/attiny, would be a rather cheap solution.

As mentioned before, you really need to break down your problem into smaller tasks that you want to accomplish.

Just one out of head solution could be creating a wireless button network with one main gate connected to a "server", lets say an arduino uno with NRF24l01 in receiver mode getting data from wireless buttons and feeding it to a pc via Serial communication. The wireless buttons could be based off a simple Attiny85&NRF24l01 each with its own unique ID, powered by coin cell. When a worker presses the button, the attiny85 will register it and send it to the main gate, where all the processing like timing and linking the button event to specific job id will happen.
Such a solution will cost you around 5$ per button node and will work for years from a coin cell.

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131