CHEAP Serial bus, control 200 devices, 50 meters

.... and you mean realy "200 devices in a range of 50m" ?

Must some kind of NANO technology :)

Armin

If you use a standard ethernet chip, it will do most of it for you at high speed using standard cabling, standard hubs / switches, etc. Besides, the more advanced IP stacks will collect a number of packets (nagle algorithm) for a given target and send them as one packet to reduce overhead. If you send a lot of short messages to a target from

-let's say a PC- in a short period, the target will receive 1 or more long packets.

Very efficient ? TCP/IP allows to transmit block of 2^32bits in random packet order. To as many as 2^32 devices. It adresses

Rene

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

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

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

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

Yes, the ethernet chip does up to the IP level. Meaning

Rene

What's the matter with industrial ethernet, using that cheap 8051 Rabbit thing with TCP/IP stack- proprietary boards should come in at

I'd suggest either...

RS485 in reasonable local clusters, with a tree structure of repeaters to localize faults and keep the fanout legal.

or

Ethernet, using the Lantronix Xport modules talking serial to a small local uP, or a Rabbit module to do the whole thing on one little board. The Ethernet hubs and cabling are dirt cheap, and it would be fast and very fault tolerant. You could do the whole thing for well under $100 per node.

John

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

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

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

What's wrong with having 200 devices withing 50 meters?

RS422 is current loop and therefore only usefull for peer-to-peer connections. RS485 is a differential interface which may be implemented as a half duplex bus or a separate transmit and receive pair for a full duplex peer to-peer connection.

Let's see ... 200 drops in 50 meters ... on average, the drops are 25 centimeters apart. If the controller is in the middle and the bus goes out in several directions, the drops may get as far apart as a meter on average. That's still a pretty tight cluster of machinery/

Jerry

Both RS-422 and -485 are differential voltage. A transmitter enable is optional with RS-422, but required on RS-485. I wrote of RS-422; that's how the project started. We switched to RS-485 when we built the prototypes.

Jerry

Not nano, though. I wuz thinking more "within" 50m.

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:

A full version of the development tools with the TCP/IP stack and over

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.