I have a machine that produces anywhere from 2000 to 5000 products per hour.
Depending on settings, adjustments and stops the actual hourly rate can vary.
I want to place a sensor on the out feed of this machine that will count each product as it exits the machine.
I then want to use that count and some very [clever maths and code] to continuously recalculate the new speed as quickly as possible after stops and settings changes.
Can anyone help me with the [clever maths and code] part?
If you want someone to write the code for you, you are going to need to provide the details of exactly what controller you plan to use, the development environment used to develop and a clear list of the inputs and outputs.
I have already provide the math and how to at a high level and anything lower needs working to the chips in use.
e.g. will the controller have the ability to have an accurate time of day clock ?
What language will it be coded in?
How fast will the sensor get triggered (if the controller is too slow of busy it could miss the triggers, in which chase more advanced code is needed to deal with that and/or a different chip.
Hi Larry
An idea for you. This could work and would not be as coding heavy as trying to count in 5 second or whatever blocks.Would probably require a bit of enterprising coding ut I will ave to leave that to the experts.
Would be interesting to see the results.
Hi Larry
Just another idea. Do you know what the sensor pulse looks like. If it is a reasonable square wave there might be a simple way to measure items per unit time. If it is not much of a square you might be able to clean it up with a Schmidt Trigger.
Can we assume in normal operation these items travel as a steady stream with a gap between them.
Arduino has a function called “PuseIn_HIGH” and “PulseIn_LOW” where it returns the duration of the HIGH period ad the LOW period. Add the 2 together will give you the period. From this the frequency and thus the items per unit time can be calculated. This can be displayed on a 1602 display continuously if required.
I tried to use this some time ago when fiddling with a pulse generator. My idea was to generate the pulses in hardware then measure them. Failed a bit as there was a bit of jitter which was no good when measuring µSec. Your application would be relatively very slow and measure in mSec which should swallow up the few µSec jitter I had.
I don’t know off hand if you can stipulate the measurement unit in µSec or mSec I would have to look it up. Unfortunately don’t have time at the moment but will leave it to you to ponder. µSec would give better resolution and accuracy. Just some bigger numbers to crunch.
Maybe Michael might have some idea.
Cheers Bob
Messaged a friend over the weekend. His response is so me. The over thinker.
–
Haha I think you’re overthinking this…
If you want the current production rate, you can simply take one-minute samples and multiply the result by 60. As long as you’re comfortable waiting a minute for the data, this method is accurate enough. You don’t need to account for short stops, since they have a minimal impact as long as the machine runs at a consistent speed afterward.
1. If sensor goes high Capture Timestamp
2. Count Timestamps from last minute * 60
3. Display on screen
I still think I’m missing a step though. Because the actual hourly production rate would be different because I’d effectively be counting * 60 but if the machine stops for 2mins it should be * 58
Something like this maybe…
1. If sensor goes high Capture Timestamp
2. If sensor does not go high for (max gap between products). Start Timer.
2a. Stop Timer when sensor goes High again. Store timer count in minutes.
3. Count Timestamps from last minute * (60 - timer)
4. Display on screen
But then do I need to store the timer as a timestamp as well and only retrieve the last 60minutes of data??
And you can get our latest projects and tips straight away by following us on:
