Brook said:
You're right, that was unclear. I meant 100Kbps. I realize the protocol will
have some overhead, and that's fine. And I could maybe get by with a lot
less. For example, I have to feed a powder from a loss-in-weight feeder. The
PC has to control the feeder motor and monitor the weight. I have different
options for controlling the motor. If I use stepper motors and try to
control every step from the PC, I need more speed. If I just tell it
start/stop, then I don't need nearly as much speed.
Logic level.
I don't need it enclosed. I have 120v AC, but I expect the devices would run
on 5-12v DC.
Good question.
I can be married to it. I would roll my own, but that
depends on how easy it is. If the chips exist that will do most of the work
for me, then I would roll my own. Then it depends on how much money will it
save me over the store-bought alternatives. Looking at the prices I'm
finding, and the prices you listed below, it's looking more and more like I
should build my own.
If I roll my own, I also need not just a bus, but a protocol to address and
communicate with the i/o modules.
I just wanted some suggestions. But, I wonder if I can't roll my own for
Thanks Chris. That's a good suggestion. That's just the type of info I was
looking for - a low-end solution. Now I wonder if there is a lower
end?
Hi, Mr. Stevens. Stirred up a hornet's nest here, I guess. Thanks for
providing some more information on your project.
Altogether, I'm still wondering if the Stalinized total centralized
control model is the way to go, particularly with a PC. Some posts
below have commented on the issues connected with doing things that
way.
What I'm wondering is, if you are going to need some intelligence to
send and receive serial communications, why not also put that
intelligence to work doing some of the programmed sequence of events
you're running on each machine? Using your example of the powder
feeder with scale that has TTL output, why can't you just tell your
distributed intelligence to start the cycle? It then turns on a relay,
and then accepts data from the scale until the weight comes to a
certain amount or timeout, then turns the relay off. That way, the PC
can just periodically poll the distributed controller to ask how things
are going. And given the fact that most scales only give a couple of
readings a second, it shouldn't be that hard for your distributed
intelligence to keep up.
Anyway, that's the way it's commonly done. Frequently, that
distributed controller will be a PLC in an industrial environment.
That's because the programming is straightforward, all I/O are
electrically isolated from the PLC as well as the comm port (which does
wonders for reliability), and PLC manufacturers are committed to
keeping a model in the market for a long time (otherwise they lose
market share). That makes pop&swap maintenance possible by
non-technical people. In other words, the project designer isn't
married to the project for the rest of his life.
If you want all TTL I/O, the PLC becomes a little problematic. You can
purchase add-on modules which will give you that, but it will increase
the cost more. They're not made that way. That would tend to lead you
in the direction of a Single Board Computer, which does have TTL I/O
built in.
Whether you decide to go with distributed or centralized control, a
good inexpensive choice might be the Rabbit RCM2020 Rabbit Core Module.
It gives you up to 40 I/O, and has good serial comm capabilities.
Best of all, they're $31 each in 100 quantity. You could make a small
surfboard with sockets for the RCM2020, and put a good 5V regulator and
isolated RS-485-to-TTL converter on the board. That will fill your
minimum system definition without breaking the $100 per station barrier
(after the first working unit).
Either way, you should start out with the RCM2000 development kit for
$169 USD. It gives you everything you need to get started programming,
including a development board, power supply, cables, and Dynamic C
software for free. Dynamic C is optimized for realtime control, and
might work well for your application. Actually, the free software that
comes with the development kit is the best part of the package.
That will go well with the multi-port PC RS-485 serial board I
mentioned in a prior post. If I had to do just this, I would get a
board that has timers and DOS drivers with Turbo C++ 3.0 for DOS
examples, and do the PC program in Turbo C++ for DOS and Greenleaf
CommLib for DOS. DOS is helpful because you don't have to worry about
most of the other things that are going on with a Window$-based PC. It
isn't easier when you add in a user interface, but you get better
control over what's happening.
You've got a good amount of work ahead of you if you choose this route.
Be careful about ground loops in large systems -- they're a major
cause of those dreaded system anomalies that keep you up late at night.
Try to keep your RCM2020 or whatever controller as electrically
isolated from the rest of the world as possible, use the best power
supply you can afford, and be careful with switching inductive loads.
They can cause EMI-RFI problems which can upset the apple cart, too.
Good luck (which is the residue of hard work)
Chris
