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

Reply to
Armin Steinhoff
Loading thread data ...

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

2^16 different ports per device. This is huge overkill when the packetlength is shorter than 250 bytes, to less than 255 devices.

Rene

Reply to
Rene Tschaggelar

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

Reply to
Rene Tschaggelar

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.

Reply to
Nico Coesel

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

Reply to
Armin Steinhoff

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

1500 something bytes, no ports, no retransmit, no reassembly. It may depend from which platform you look, from an 8bit micro TCP/IP is a heavy burden. I'd possibly prefer UDP if it had to be. The random transmissions have to be controlled somehow to reduce collisions. But a master- slave setup should do that nicely.

Rene

Reply to
Rene Tschaggelar

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

Reply to
Fred Bloggs

...

Best advice so far!

Jerry

Reply to
Jerry Avins

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

Reply to
Rene Tschaggelar

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

formatting link
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

Reply to
Jerry Avins

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.

Reply to
Nico Coesel

protocol will

level,

married to

address and

project

inexpensive

limitation,

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

Reply to
Chris

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

Reply to
John Larkin

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

Reply to
keith

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

Reply to
Jerry Avins

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

Reply to
Jerry Avins

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

Reply to
keith

Reply to
Armin Steinhoff

If a strict master / slave relation ship is OK ... why not.

Oh ... I just hit the wrong key. RS485 is the correct one.

8 bytes of data ... there is room for are 32 input and 32 output signals and this is more than requested.

Longer messages are handled by CANopen ...

No ... there is a real confusing set of incompatible layer 7 protocols used by the car industry.

Reply to
Armin Steinhoff

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.

formatting link

Reply to
Fred Bloggs

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.