Complete newbie so be gentle as I learn my way around.
I have a product I need to package in three lots of fifty parts into plastic ziplock bags; a bolt, washer and nut. I'm going to use funnels with sensors to detect the (plastic) parts as they travel down the chute. This part I'm very comfortable doing.
Why bother with a count display? Why not a red-green led to show ready/filling/done status? RG led can be red, amber or green, or between. What do you plan to do with the numbers displayed? See that it reached 50 ea? One status light is all you need.
Why a button? How about a sensor that tells if a bag is in place to be filled? You know, like the way that ice dispensers work?
Like your ideas, especially the bag sensor. That makes sense! Initially I'll need the counter just to confirm everything is working OK but then I could just have a LED. Let me know if you can assist with tweaking the code in the posted zip file.
Counting accurately strikes me as the hard part. Are you going to do it by weight, or have some scheme to move the components individually past a sensor of some sort?
PeterH:
Counting accurately strikes me as the hard part. Are you going to do it by weight, or have some scheme to move the components individually past a sensor of some sort?
Yes, this will be the hard part but something I can tackle. I have an optical sensor that should do the trick.
Assistance with the right LED display would also be appreciated. Looking around Mr Google, looks like a serial 7 segment LED display would be my best bet? If someone could look at the code posted here http://missionduke.com/sourcecode/arduino/arduino_button_press_counter.zip and let me know what LED display matches the code, that would allow me to get under-way the quickest?
GoForSmoke:
I was thinking: incorporate his count-code into a state machine.
Sorry, what is a 'State Machine'?
It is a way to code for real-time events that involves breaking all tasks into very small, fast-run pieces and controlling which piece(s) is(are) run in any given pass through loop().
The control is done through changing the value(s) one or more variables used to track the state/progress of events as the task is done to ensure that the proper code pieces are run and not any others.
In practice this can be very simple or very complicated depending on if the task is simple or complicated +and+ how much unnecessary complication the programmer adds, which is usually some even if it is at some boss's or customer's insistence.
Since this is going to be your code, you da boss of what comes out. Ask for help is fine but the decisions are yours.
BEFORE any code for -this- sketch is written, you need to determine a number of things not just at the "that looks right" level but at the "this works using this code" level. That means doing pre-projects of every substantial step.
You can take the first things that work without question or you can check each piece for final suitability and improve or redo what klunks. Wheels made of solid stone, solid wood, or go with spokes? Every step just to find out what the step is takes more work than you'd believe at the start but hey you get what you make.
I would start with the parts-counters. Without those the rest is empty.
Thank you, understood. I already have the part count working reliably and triggering a LED as items pass by. Now ready to move on to adding the counting function and display. Help with the right serial display to match Duke's code would be appreciated.
Okay, trot out your parts-counting code as that's the most important part.
BTW, did you actually pay 25 bucks for a 4 digit display? For that much money, it had better clean carpets or windows besides show digits before I'd buy one.
You want digits to test it out with? Then use Serial Monitor or another terminal emulator on your PC. That would be practical since you're not going to need the number display in practice, are you? Or at least I had the impression you wanted something industrial.
Also using Serial Monitor will cut down on the time as well as cost to get this project working.
You do realize that the display may take your power requirements up to needing external power? Each segment is a led that could be lit and the parts counters will be drawing current too. Arduino pins can supply 200mA total.
If the idea was to vary the # of parts ... display and keypad or buttons would be called for but for parts-fill operations you want to streamline and cut equipment costs rather than bloat them. The extra $25 for a freaking bull-teats display ... how many bags of screws will you have to sell to pay for that?
While I sincerely appreciate your advice, the $25 (NZD) display is neither here-nor-there for me as to have a machine made to count/weight my parts for production is $44,000 NZD! I'm needing to fill 500 bags a day.
I've tried uploading MissionDukes code this morning to check out the serial monitor but it appears the code is out-of-date and not supported in 1.0.4 as I'm getting "The BYTE keyword is no longer supported". Stuck now.
That code should be a minor concern. But you should make a separate project out of getting a digital display working, and a separate project counting parts for first one source then three, before merging them.
You should do that to get the concepts for each part down solid and debugged with fewer complications per sketch rather than trying to throw everything together at once and -then- trying to figure out what's going on let alone what should be going on.
to have a machine made to count/weight my parts for production is $44,000 NZD!
That's not the price of the machine. It's the price to have one made right. Very different. One is materials and assembly while the other is professional engineering. That's why the new computers/cars/etc have a premium price, the maker is trying to recoup development costs.
I found an Auckland based Robot shop that has offered to assist. They've already updated missionduke's code to work with 1.0.4 and the counter is now working. I've engaged them to assist with completion of my project so you can close this thread now.