Circuit Designs

"James Sherlock" wrote in news:ZHFMe.18721$ snipped-for-privacy@fe2.news.blueyonder.co.uk:

You need to be much more specific. What do you want the circuits to do? What will the input be? What will the output be? What will the circuit be driving?

Hey Scott,

Thanks for the reply. The circuit will have to use the input from two dials; how much is fed, and the hourly intervals of the feeding. The output would be a motor being activated.

Regards,

James

"James Sherlock" wrote in news:yLGMe.10815$ snipped-for-privacy@fe1.news.blueyonder.co.uk:

Even more specifics are required. What kind of relationship do you need between the input and the output? What kind of signal does the motor need to see? How does the motor need to move? What is the mechanism of the feeding? Is it a cam that's pushing out food at intervals, or is it some sort of screw drive?

Be very specific about the type of signals you need to provide. Do you need a pulse for each feeding interval that gets wider as you require more food?

Frankly, it sounds like you don't really know what the input/output relationships need to be, and its very hard to design a circuit when you don't know EXACTLY what you need it to do. You'd be much better off designing the feeding mechanism and testing it with a function generator before you try to build a circuit to drive it.

How would you respond to "I just bought a vehicle and I need to equip it. Can you offer helpful suggestions?"

What do the circuits supposed to accomplish? (Be specific.) What are they made out of? (Discrete components? ICs? PLC? Microcontroller? Other?) Jerry

Scott is right on. If my newsreader had shown his first response, I wouldn't have joined the thread. I might suggest a design and pitfalls of the design of a mechanical feeder, but that's another thread. One point is worth while now, though. The design should make it possible to determine that food was actually dispensed. It would be most unfortunate for the machine go through its motions with the hopper is clogged and no one the wiser.

Jerry

Hi guys,

I much appreciate the time and help you're giving me with this.

The motor will be controlled by a PIC chip embedded in the circuit. The motor will have to rotate in order to pull a spring loaded hatch back. The volume of feed released will be calculated from dimensions of the hole and so when the required feed (set by a rotary dial switch on the front of the unit) has been expelled the motor will reverse (transistor, DPDT relay+PIC chip?) thus closing the hatch. The rest of the journey for the food is down to gravity.

Bearing in mind that these circuit designs will be preliminary - my teacher will check and refine them so no need to worry about mistakes. I just need a general idea of what the circuit should contain.

I agree with Jerry about the feedback system - possibly a pressure sensor on the transporting tray or an infra-red sensor by the hatch.

I hope this provides enough info - please ask if more is needed.

Many thanks again,

James

It's hard to dispense a consistent amount that way. (I can think of simple designs that don't have that problem) You will need to know when to stop the motor in each of its directions. That requires a sensor. If a few chunks lodge in the hole and block it, what will happen? If you are feeding a live hamster, instrumentation is at least as important as actuation. Theoretical hamsters don't starve.

Before you commit to treating pelletized food as if it were a liquid, mock up a test out of cardboard or balsa wood. If you can't control the amount dispensed, use a different design. A good mechanical design can minimize the sensing requirement and simplify the control requirements.

Quantize. Use a fixed-volume dispensing chamber and count the number of volumes dispensed. That is much more certain than assuming a flow rate and inferring volume from time.

Avoid slides; they tend to stick unless carefully machined. Food will get onto the slideway. (Do the drawers in your dresser always move easily?)

I can think of a simple dispenser that embodies these principles, but I leave the final design to you unless you ask for more guidance. If the dispensing motion is a complete circle, only one end-point sensor is needed, and it can be the dose counter also. Moreover, with that action, the need to reverse the motor can be avoided, allowing a cheaper motor and a simpler circuit.

Jerry

"James Sherlock" wrote in news:NcJMe.19289 $ snipped-for-privacy@fe2.news.blueyonder.co.uk:

Then what is the signal the PIC needs to see? Is that firmware already existing, or will it be programmed for this application. If its going to be custom, you don't need any circuitry at all-- Just two potentiometers going between Vcc and ground, with the wipers going to analog inputs on the PIC.

Keep the pots fairly small, like 2kiloohms. The input impedance of the PIC A/D modules isn't great.

Use the PIC w/ A/D input pots to control a Power MOS driver chip that turns a low speed DC gearmotor ( like in vending machines ) to drive a screw in a tube to feed the feed from an over the tube hopper and out the other end to the feed tray.

The control could also be a 556 dual timer, where the pots control the duty cycles of the cascaded one-shot timers. Do a google search for circuits.

Time delay relays would also work.

A varible speed gearmotor driven disc with a hole to control a shot of feed from bottom of hopper would also work. Faster = more fixed shots of feed.

Dennis

James Sherlock wrote:

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

A rather unfortunate choice of words, but thanks for the laugh first thing in the morning!! ... (thinking hopper and pneumatic conveyor with all these little hamsters being fed into some process lemming-like)

P'raps I've been working too hard.. ;-)

Cameron:-)

You should be starting to see how defining the problem actually leads you to the solution.

I suggest that you think incrementally, ie. what are the basic elements that you have to build for starters. They should be things that work by themselves, or in conjunction with stuff that you've built previously. The basic input/output elements are good first candidates. In the process of building these basic elements, you'll come across things that you didn't think of, and that need to be addressed. That's fine, it's better to do it that way, and achieve solid basic elements of your system, rather than to build the whold thing and find there are deficiencies in the fundamental elements. Engineering is littered with failures caused by not addressing problems thoroughly when they were first encountered, often in the interests of 'the schedule'.

Another useful mindset I apply sometimes is something I call 'support structure'. You think of all the support functions that you need, and create them. Then it's just a matter of linking them together, if you do it right, that can be a simple exercise.