CHEAP Serial bus, control 200 devices, 50 meters

I need PC control/automation of: 200 machines Each machine needs 16 logic inputs and 16 outputs Line lengths may be 50 meters
I want a serial bus to connect the i/o devices at each machine with the PC. This is to reduce the wires needed, lower costs and simplify design.
It is not a noisy environment. No welding, for example. I don't need more than 100kHz speed, and might get by with even less. I don't need environment protection. The devices can be just a circuit board. It's indoors, not a washdown area. I don't need super high reliability. It's not a life support system. Cost is a major concern.
I've been looking at some industrial bus options. Either they cannot handle 200 devices, cannot handle 50 meters, or are very expensive (x200). But, there are so many, I don't know them all, and maybe some can be modified to do what I need that I'm not aware of.
Can anyone offer a suggestion or alternative?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Brook Stevens wrote:

the PC.

circuit
handle
But,
modified to

Hi, Mr. Stevens. First, you've got a problematic description of what you want.
* What do you mean by 100KHz speed? Does that mean you have to sense or control 100KHz inputs/outputs, or that you feel your serial communications speed should be that fast? If so, why? What are you doing?
* You're saying you need to control 200 machines with modules that have 16 in and 16 out. What kinds of I/O do you need? Logic level, isolated, DC, relay, or AC output, opto input, what?
* You need to give more information about your environment. Do you need something that's enclosed? What kind of power do you have available?
* Is this supposed to be a "store-bought" solution, or do you have or want latitude to roll your own stuff? Are you willing to be married to this forever? Are your employers willing to let you be married to your project forever? Or are they your machines (in which case, you do what you want, unless you ever want to sell your business).
* Obviously we all want to spend a minimum amount, but you have to give some information as to what kind of price range you're looking for. That is dependent, on other things, on the rest of your project definition.
So it goes. Just as a conversation starter, I would purchase a multi-port serial card which would give you eight double twisted pair RS-485 outputs. You can realistically expect 31 receivers for each master from the computer, which would give you the potential for 248 machines.
On the receiver (machine) end, I would start out with an inexpensive 16I/16O programmable Logic Controller (PLC) which has RS-485 capability. As a low end solution, you might want to look at the Koyo/Automation Direct D0-06DR which has 20 isolated DC inputs, 16 relay outputs, works directly off line voltage, has RS-485 comm built in, and is off-the-shelf (meaning that you won't be married to it when it's done). That goes for $215 USD per point, which gets you to around $43,000 for 200 machines. I would also purchase separate 24VDC power supplies, small line filters, and cheap NEMA1 enclosures for each unit. Leaving some wiggle room, it would look like you're talking about around 50K to 55K for the project hardware.
OK. How about calling Automation Direct, talking to their apps engineers (they are helpful and will answer questions like this), firming up whether the D0-06DR will work for you, and what kind of programming you will require for the PC, as well as whether any of the industrial busses will help your project, or whether it would be better to do home brew software for comm and control (dependent on your PC programming ability). At some point, if there's a major limitation, you'll have a starting point for discussion. Or if this post is way off base, possibly you could follow up with more information. Good luck Chris
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Chris on 1/31/05 wrote:

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 $100/machine.

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?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Tue, 01 Feb 2005 13:47:03 -0600, Brook Stevens wrote:

Then, of course, the question becomes, what exactly _are_ these machines?
Sewing machines? Bird feeders? Looms? Punch presses? Chinese Typewriters?
What's the layout of your plant? What are you making there?
Have you decided what you actually want communicated, or are you even looking for suggestions for that?
We thirst for more information, like what's this 16-input, 16-output device? A ROM? A PLC? A Kiln?
Thanks, Rich
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Brook Stevens wrote:

Ooohhhh, nooooooo. Never attempt to control a process with a PC. A PC is not reliable enough. Nor can a timing be guaranteed. A floting point error in some unimportant display routine can stop the application. You always have to consider the PC stops working. The motors running keep running. The heaters keep heating. Leave the process control to embedded devices and feed them from the PC. Such a system has to be and stay in a safe state when the PC fails. Whenever that may happen. This means the PC tells a controller to do something and then leaves this device. You may also have to design failsafe states, meaning when the controller was not updated for however long, it goes to a certain state. EG heater off.
Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rene Tschaggelar wrote:
...

Best advice so far!
Jerry
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

If you hired the wrong programmer... If you separate the control processes and the user interface, there is not much which can go wrong. If you can tolerate 100ms response time, a professional PC running Windows will do fine for controlling processes.

This goes any control system. You'll need electromechanical fail safes for any critical system.
--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Brook Stevens wrote:

sense
you
protocol will

lot
feeder. The

different
level,
you
would run

or
married to

your
what
that
the work

will it

like I

address and

project
for
pair
248
inexpensive
built
when
around
power
unit.
the
better
limitation,
way
I was

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Brook Stevens wrote:

I'd go for RS422, a bidirectional bus with one leading in each direction. Physically identical to the RS485, it doesn't require you to switch direction at the cost of an additional line pair. There are input impedances that limit the number of devices to 32 or 128, depending on the receivers. So after the number of devices is reached, just add a repeater. I'd use 6 wires for the bus. 4 wires for the signal plus one for GND and +5V. This would enable you to have the local RS422_to_CMOS plus perhaps isolators powered from the bus.
Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rene Tschaggelar wrote:

Thanks Rene. RS-422 seems like a good option for the bus. But, then what protocol should the devices use to communicate with the PC? The PC needs to address one out of 200 devices and tell it to set it's outputs, or to send it's inputs.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Brook Stevens wrote:

A master slave protocol. This means the master (= PC) sends a command and only the adressed device on the bus replies. This means there is an adress byte included in each message. A CRC is recommended. and if the length is variable, a length byte (word).
Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Brook Stevens wrote:

RS-422 is not the right choice for a BUS. RS-422 can be used for a one-to-one (or one to many) communication structure.
Use RS-484 ... or simply CAN and you go with a standard.
Armin

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Armin Steinhoff wrote:

What's the matter with industrial ethernet, using that cheap 8051 Rabbit thing with TCP/IP stack- proprietary boards should come in at <$10 in quantity- just tell the nodes to shut up unless spoken to- no crashes/clashes or whatever they're called- cheap UTP cabling.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Fred Bloggs wrote:

Please differenciate between the production costs (<10$ ??) and the end user price ... or do you are tkinking about GPLed hardware? :)
Armin
in

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Armin Steinhoff wrote:

It looks like the "Rabbit" line is overpriced at $31ea qty 100 just for the controller. Forget them. Microchip has flash PICs and freeware for developing TCP/IP applications, and they have several app notes on developing an SNMP which should work well for this network where everything centers around a 16-bit status and single bit control commands. http://www.microchip.com/stellent/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId 08
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

for
for
I may be biased working for Rabbit, but I say don't forget it.
A PIC doesn't have enough flash or RAM on chip for a robust implementation of a TCP/IP stack and SNMP to boot, so the external flash and RAM already on the Rabbit Core Modules will be needed for the PIC too.
By the time he puts together the HW, tools, stack, and SNMP and starts writing his application for a PIC-based product, he could have the Rabbit version on the shelf. SNMP is already implemented on top of a mature, robust, royalty-free TCP/IP stack. Support for the HW, development tools, stack and RTOS (if one is used) all come from the same place.
If he wants to move into higher volume he can incorporate the core module design and just buy Rabbit chips and use the same SW. If he wants a web server and browser interface for the app, a rapid application development system for web interfaces will save weeks of complex CGI programming: http://www.rabbitsemiconductor.com/products/dc/DC9/modules.shtml#RabbitWeb If he wants to add higher security to it, SSL/HTTPS is also implemented and takes advantage of special Rabbit instructions to make it fast, which it won't be on the PIC.
A full version of the development tools with the TCP/IP stack and over 700 sample programs and applications come with the inexpensive development kits:
http://www.rabbitsemiconductor.com/products/rcm3700 /
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Armin Steinhoff wrote:

What is wrong with implementing a master/slave system onto a one-to-many bus ? RS422 doesn't require switching the direction. An RS232-to-RS422 converter takes 3 chips and fits onto a square inch. I'm not familiar with RS484, a search turned up only fluff. CAN is a fast bus but is limited to 6 byte messages or so. The last time I looked at it, there was no provision for longer packets. The command set has to be designed to fit the application in question. I doubt the car industry has a fixed commandset and all CAN subsystems are compatible across the maufacturers. Just guessing...
Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rene Tschaggelar wrote:

Years ago, I implemented an RS-422 multidrop system for Siemens Energy and Automation, complete with a proprietary signaling protocol designed for robustness in an industrial environment. The arrangement used a star of buses, with repeaters to extend buses as necessary. Each transmitter signaled to as many as 24 receivers, all of which listened for its unique address. The selected device signaled back full duplex by making its normally tri-stated transmitter active.
The signal protocol sacrificed efficiency for generality. Each message included a preamble to guard against framing errors, a length byte that didn't count these overhead bytes, a CRC-8 "checksum" for the address and length, and a CRC-16 "checksum" for the message. Messages could be from zero to 255 bytes. Byte parity was not used, so all 8 bits were significant.
Messages were composed in ASCII to simplify analysis of data traffic. Logging was as simple as letting a printer eavesdrop. I strongly recommend the practice when time permits. There's a simple routine at the end of http://users.erols.com/jyavins/tantrum.htm for outputting hex data in ASCII. (68HC11 assembly code)
The prototype system was logging trouble-free hours in a power plant when I was detached from the project. I know that the product line that the signaling system was developed for didn't go into production, but I heard that the system was under consideration for another application. My guess is that they used Profibus instead.
Jerry
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

DDJ didn't publish that? I now remember (I haven't even though of this in years!) that I wrote and DDJ published a semicoherent rant about the C language (I had the bad luck of learning C just before the ANSI standard came out), and once I saw where my published letter took most of a page, I wished I'd submitted it as a "guest editorial" or some such and gotten paid for it! About your code, there's a routine in the Apple ][ ROM (source listing in the "Red Book" included with early ]['s) to do the same thing with a 6502 (its branch and call instructions are almost identical to the HC11), and the code looks almost identical to yours. I'm not accusing you of plagiarism or any such, just pointing out that several people doing the most efficient implementation of a fairly simple task like this are likely to come up with the same solution.

----- http://mindspring.com/~benbradley
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ben Bradley wrote:

...
I strongly believe that the only way for most of us to become good writers is reading the works of good writers. In that sense, written programs are much like other literature. My assembly code style developed when I was writing code for 1802 (with no role model) and in the 6502, where I had the excellent monitor ROMs of the KIM-1 and the AIM-65 to serve as models of style and repositories of neat ideas. I read them to learn how to use their functions, but to do that, I needed to understand what the code did, and the details were enlightening.
I first encountered the "trick" of one function calling another just after it with no RETURN statement in order to repeat an action in the AIM-65 monitor. In outline, it looks like this:
DBLSP: CALL CRLF CRLF: <code to output $0A $0D> RETURN
When DBLSP (doublespace) is called, CRLF (Carriage-Return/Line-Feed) executes twice, then returns to the original caller. You don't forget lines like that any sooner than you forget "Jenny kissed me when we met"* if you happen to come across it.
I guess that my point is that writing in the same style often creates similar works. (It's no wonder that some early Mozart sounds rather like Haydn.) There's no plagiarism, but no coincidence, either.
Jerry ____________________________________________ * Jenny Kissed Me by Leigh Hunt
Jenny kissed me when we met, Jumping from the chair she sat in. Time, you thief! who love to get Sweets into your list, put that in. Say I'm weary, say I'm sad; Say that health and wealth have missed me; Say I'm growing old, but add- Jenny kissed me!
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.