Searching \ for 'Network Question' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=network+question
Search entire site for: 'Network Question'.

Truncated match.
PICList Thread
'Network Question'
1998\05\19@040636 by Peter Neubert

flavicon
face
Hi All

I need to build (With a PIC) a small device capable of monitoring equipment
in a factory. Each device shall be networked and connected to a central PC.

The PC will then poll every device for information and status of the
equipment, and if necessary send orders to them (ON/OF, UP, Down, Increase
Temp, Open valve etc). It is possible/probable that as many as 500 devices
shall be connected to the same PC.

My problem and questions are related to which network topology and what
protocol I should select:
I have looked at RS-485 and RS422 but I am really not sure at all?

As far as I see, I will only need half duplex so I choose RS485, however I
must be able to poll the devices and return commands as fast as possible.
The response time is very important, as the equipment to monitor is very
valuable and could break down, if proper action is not taken immediately.

I looked at the Maxim web site, and with the MAX1486, they promise Data
rates up to 12 Mbit and possible 256 transceivers per bus. I would then need
2 segments to reach my 500 nodes, but that seems acceptable.

My questions are, apart from any comments to the above:

1.   Is RS484 a good choice
2.   What kind of protocol should I select
3.   What about buffering  - Will I need a uart of some sort
4.   Is it possible to achieve data rates of 12 Mbit with a PIC 16F84
5.   What else should I look out for?

Any help in any form would be greatly appreciated

Cheers
Peter Neubert
spam_OUTneubertTakeThisOuTspambow.intnet.mu

1998\05\19@053550 by g.daniel.invent.design

flavicon
face
Peter, some answers appended below:

Peter Neubert wrote:
{Quote hidden}

A: it is designed for noisy environments, keep it shielded though if in
a factory.

> 2.   What kind of protocol should I select
A: the motorola 68hc11 series would be very easy for you to work with as
it has an address mark wakeup feature + parity detect/generate inbuilt
to the hardware usart.
You will need to consider your PC software, it must be cabable of
driving the port at your required speed.        You should try to compact all
data and general broadcast or "subgroup broadcast" where ever possible.


> 3.   What about buffering  - Will I need a uart of some sort
> 4.   Is it possible to achieve data rates of 12 Mbit with a PIC 16F84
A: if you REALY need this speed then go for the pic 17c752/6 series, or
another manufacturers RISC based chip with hardware UART, a "bit banging
routine" on a PIC16F84 is probably good only up to about 50k baud range,
even then it will have virtually no time for other things.   Also,
asynchronous recieve typically splits recieved bits into smaller
sampling periods which could raise the generating frequency from 12 Mbit
to perhaps 96 Megahertz !

> 5.   What else should I look out for?

The PIC or other chip of your choice has as much intelligence as you put
into it. Rather than spending lots of time programming the PC to COMMAND
ALL PICs, instead delagate time critical decisions to the PICs(make this
bit work !).   The PICs may be attached to more than one piece of
equipment, thus saving on network addresses.

Have you got a plan of action for WHEN these sensors or linking cable
goes off line ?

( Make the local addresses as autonomous as possible ! )

>
> Any help in any form would be greatly appreciated
>
> Cheers
> Peter Neubert
> .....neubertKILLspamspam@spam@bow.intnet.mu

1998\05\19@063144 by Keith Howell

flavicon
face
Peter Neubert wrote:
>
> I need to build (With a PIC) a small device capable of
> monitoring equipment in a factory.
> Each device shall be networked and connected to a central PC.
>
> The PC will then poll every device for information and status of the
> equipment, and if necessary send orders to them (ON/OF, UP, Down,
> Increase Temp, Open valve etc).
> It is possible/probable that as many as 500 devices
> shall be connected to the same PC.

You are re-inventing a wheel.
There are factory automation networks, generically called field buses.
There are far too many of them already, about a dozen.
It is a senseless waste of human life to invent another one.
It takes many man years to develop a decent one.
Take a look at the spec for one and see just how much detail
you need.

I beg you to look around first. If you have spent heaps on a factory,
it makes no sense to pay all the R&D costs of developing a custom
system when adequate ones already exist.

> The equipment to monitor is very valuable So why gamble on the reliability of
a home-made system?
Would you invent your own PC?
In 1984 could have designed a better computer than say the Acorn Atom,
but technology is way beyond that now. Field buses are way ahead
of home-brew systems today. Don't do it!

> SpeedTry Profibus. That's around the 10's of Mbps I think.

> 1.   Is RS484 a good choiceProfibus uses RS485.

> 2.   What kind of protocol should I selectAn existing one.

> 3.   What about buffering  - Will I need a uart of some sortWhat else can cope
with 12 Mbps traffic?
Siemens have done ASICs for a high-speed fieldbus.
Can't recall which one. Around 5UKP they hoped.

> 4.   Is it possible to achieve data rates of 12 Mbit with a PIC 16F84I'd be ve
ry surprised!

> 5.   What else should I look out for?
> Any help in any form would be greatly appreciated

I used to design field bus hardware.
Even if you get in an off the shelf system, you'll have plenty to do.

For a start, check out http://www.profibus.com/
or Honeywell's SDS (Smart Distributed Sensor) system.

1998\05\19@075620 by Steve Baldwin

flavicon
face
> You are re-inventing a wheel.
> There are factory automation networks, generically called field buses.
> There are far too many of them already

I'd second that opinion.
Many of them are vastly over-spec'd to cater for every situation.
RS-485 is a good physical level i/f but is restricted to a
master/slave protocol.

With all the nodes you are talking of,  I would suggest something
like CAN that has the ability to interrupt. Then you can use an
affordable cable and still get an acceptable response rate.

Steve.

======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680, New Lynn      http://www.tla.co.nz
Auckland, New Zealand        ph  +64 9 820-2221
email: stevebspamKILLspamtla.co.nz      fax +64 9 820-1929
======================================================

1998\05\19@084020 by Keith Howell

flavicon
face
re. field buses.

> Many of them are vastly over-spec'd to cater for every situation.

As I often say, a covered arse gathers no dick.
Designing it to cope with every situation means everyone can commit to using it.

There's always the possibility that your pointy-haired-boss will ask for more
and if the net _you_ chose runs out of capacity before your competitors,
_you'll_ be blamed.

> RS-485 is a good physical level i/f  but is restricted to a master/slave proto
col.

Profibus uses it well. Protocols are not as simple to cook up as they can appear
.
There's far more than "how to pass a message". There's "what to put in the messa
ges,
when to send them, which device to send them to, bus termination, fault handling
etc"
You have to think of every possible way to f*** it up, and a way to handle it.
What if a node fails to respond? How do you fail-safe? If a new node appears,
when does the system look for it?

> I would suggest something like CAN that has the ability to interrupt.

CAN is okay, it has a robust arbitration scheme.
It's a _bit_ like I2C, in that arbitration is done bit by bit.
A key word is Deterministic.
You can guarantee that every collision will be arbitrated
and resolved. No unknown number of backoffs and retries.
You don't want that kind of shit happening in your BMW
on the autobahn, or aircraft, or car building robot factory.

CAN is a foundation protocol. You still have to build on top of it,
just as Honeywell's SDS DeviceNet does. SDS has neat features:
you can ask sensors for their maker's name, program a physical
location label into its EEPROM, etc.

"Interrupts" and "Determinism" don't go well together.
Remember, you have got to be damn sure that things will happen in
a guaranteeable sequence. Someone's life or livelihood
may depend on it. Maybe yours.

> Then you can use an affordable cable and still get an acceptable response rate
.

The message rate may be lower, but the bits may still be at very high baud
so you will need good cable and terminations.
Termination is as essential for CANbus as pullups are to the I2C bus.

1998\05\19@101746 by Keith Howell

flavicon
face
In fact, I'd go as far as to say you'd be very unwise to entrust
automation of your expensive plant to anyone with a seriously big name
(Honeywell, Mitsubishi, Motorola, Intel, etc).

Nobody in their right mind should buy this kind of kit from some tiny
start-up company. One company I know was/is run by a slick-haired wide
boy (who was a combination of Del Boy and Mr. Brittas for UK TV watchers)
and his wife.

The punters saw the big double page ads in the trade journal,
a nice modern industrial/office unit, the Mercedes, the suits,
the surface trappings of a business.

They didn't see the 9 out of 10 engineers supposed to work there,
the landlord wanting 6 months rent, most of the staff working weekends,
late wages, 24-hr soak tests that lasted 5 minutes,
the stuff  in the post' being used for demos at the next punter,
and more stuff than I have time to describe.

The most that these people can do for you is send off an order to their
suppliers, and lie to you about availability.

The last straw was when he illegally withheld my last months salary
while I was on holiday! I eventually got it out of the b******** though!

So be warned, would you want to do business with outfits like that? :-)

1998\05\19@101758 by Harrison Cooper

flavicon
face
               I agree with Keith Howell, in that there are several
types of existing products.  A new one out is called LOGO by Siemans,
and I believe one model has an interface to some sort of bus.

               Think about it.  Design and develop the software for
this application.  PC board, with PIC and relays. Enclosure.
Documentation.  Can you afford $100 per node.  If yes, buy something off
the shelf.  If you have unlimited time, money and resources, might be
fun to build.  And this doesn't even talk about the PC side of things.
I suggest FieldBus, and the PC software that supports it.

               BTW, who else out here is doing industrial controls (PLC
and the like).  Might be nice to have a list of those so we can compare
notes and problems away from the list.

1998\05\19@103300 by Ray Gardiner

flavicon
face
Hi Peter,

  As far as I can see there are two 'very difficult' requirements in your
  request, these are:-
  1. The need to poll 500 devices.

>Temp, Open valve etc). It is possible/probable that as many as 500 devices
>shall be connected to the same PC.
----------<Snip>

  2. The need to minimize response time in an emergency.
  ( you haven't defined what is an acceptable response time.)

>The response time is very important, as the equipment to monitor is very
>valuable and could break down, if proper action is not taken immediately.
----------<Snip>

  These, taken together could amount to a 'deal breaker' I would (politely)
  suggest that you would be very unwise to walk into this potentially litigous
  situation with a home-brewed protocol.
  Translation := 'Go and study the existing protocols like FieldBus etc.'


>1.   Is RS484 a good choice
  No HDX RS485 is better! :-)

>2.   What kind of protocol should I select
  Good question, I doubt that there is an definitive answer, without
  knowing more of the detail.

>3.   What about buffering  - Will I need a uart of some sort
  Yes.

>4.   Is it possible to achieve data rates of 12 Mbit with a PIC 16F84
  This is a crucial question and I suspect that the answer is no.
  I would think a 16c74 as a minimum starting point. With a fair
  effort 1Mbit might be possible, more likely to be less than this.

>5.   What else should I look out for?
  Don't underestimate the difficulty of this task.
  You are potentially exposed to being liable for equipment damage,
  I suggest you get some legal advice. Don't let that scare you off
  however, just make sure you understand exactly what you could be
  getting into.

 On the other hand, IF the question was,
       "Can I network 10-20 PIC systems and remotely control some
       (non-critical) equipment from a PC?"

  then the answers would be somewhat different.

Ray Gardiner, .....rayKILLspamspam.....netspace.net.au

1998\05\19@184426 by Dennis Plunkett

flavicon
face
At 11:20 AM 19/05/98 +0400, you wrote:
{Quote hidden}

Although the data rate is spec'd to 12Mbit, to have up to the 256 nodes
(Receivers) the data rate will drop to an significantly small rate,
typically an RS484 receiver is around some 6Kohms input impedance, with this
in mind normal RS484 drivers can only drive 6000 feet of cable with 32
receivers. Also the length of the cable will affects the maximum data rate.
You will find that you need to terminate the cable with 120R resistors at
both the master end (Main Transmitter (PC)) and the final termination point.
With this you can then do half duplex on the same pair of wires (Omnibus)
I suggest that you use a framed packet style protocol, and to make life
easy, an async data format, so this means a UART of some sort.

Dennis

1998\05\19@184645 by Thomas J Macauley

flavicon
face
part 0 1080 bytes
I work for a comany that does industrial controls in the Boise, Idaho area.

>From Peter Neubert's questions, I would estimate that he has about a year of serious study before he can piece together what he wants.  I would recommend that he look to a major PLC supplier for a solution.  (Please don't take this as an insult -- I'm working down that road myself.)

Incidentally, microChip is supposed to be coming out with a PIC with a CAN interface.

Also, while CAN is a good networking system, there are some environments where field busses are NOT a good idea.  I'm still not sure if I like the idea of a network controlling the brakes in a car.

I'm also leery of using PC's as a controller.  Think how often your PC crashes, then decide if your factory can deal with that kind of down time.  Alos, think about the safety implications.  If a desktop PC crashes, it might take out the data on a hard drive at worst.  If an industrial control has a problem, it can take off an arm or smash someone's head.  (This is also something to consider when brewing your own control.)

1998\05\20@073644 by Keith Howell

flavicon
face
Thomas J Macauley <thomasspamspam_OUTADVANCEDCONTROL.COM> wrote:

> estimate that he has about a year of serious study before he can
> piece together what he wants.
> I would recommend that he look to a major PLC supplier for a solution.
> (Please don't take this as an insult -- I'm working down that road myself.)

I agree. I've been working on my application for a year now.

> Incidentally, Microchip is supposed to be coming out with
> a PIC with a CAN interface.

Hmm. May have enough poke to run CANbus, but I guess it would be stretched to
run the application protocols built upon CANbus.
I don't bother getting excited about chips before see a sample.
I've seen too many delivery dates redshift into the distance.

> Also, while CAN is a good networking system,
> there are some environments where field busses are NOT a good idea.

Such as?

> I'm still not sure if I like the idea of a network controlling the brakes in a
car.

You may be too late! CAN originally meant Car Area Network, developed to
reduce the kilometres of wiring in a typical car.
After so much design effort, it was adopted for use in other areas and
renamed as the more generic Control Area Network.
It may well make cars safer and cheaper, as there are less wires
to make a mistakenly connect.

> PC as a controller... Think how often your PC crashes,
> then decide if your factory can deal with that kind of down time.

Yep. Dead right!

A company called SoftPLC specialise in software to turn PCs into PLCs.
They are also aware how crappy PCs can be, even down at BIOS level.
So they use entirely their own BIOS code to do things that the native BIOS would
do.
The only time they call the native BIOS is to check the keyboard for the stop bu
tton (ESC).
They reckon if someone finds a bug in their BIOS code, they'll fix it in 24hrs.
They've found and reported bugs in other PC makers BIOS code, and the
manufacturers can't be bothered to fix it.

I managed to get their PLC software kit sewed to the Honeywell SDS DeviceNet kit
over a few caffeine-soaked days. Much quicker than inventing the whole damn lot
myself.

1998\05\20@074902 by Peter L. Peres

picon face
On Tue, 19 May 1998, Thomas J Macauley wrote:

> Also, while CAN is a good networking system, there are some environments
> where field busses are NOT a good idea.  I'm still not sure if I like
> the idea of a network controlling the brakes in a car.

The network that controls the brakes is an add-on that serves the ABS and
other refinements. If it fails, then the systems remains a pure
hydraulical brake, as in our grandfather's time ;) Moreover, it is
GUARANTEED to work if electrics fail TOTALLY. Nothing to fear about, the
people who built the car had the same idea, and they were MORE afraid than
you, believe me. From the tiniest engineer and up to the top. And of
course we are talking about cars, and not TRUCKS (which have some
pneumatical paranoia attachements for the case, and pneumatic automation
in the braking section) ;)

> I'm also leery of using PC's as a controller.  Think how often your PC
> crashes, then decide if your factory can deal with that kind of down
> time.  Alos, think about the safety implications.  If a desktop PC
> crashes, it might take out the data on a hard drive at worst.  If an
> industrial control has a problem, it can take off an arm or smash
> someone's head.  (This is also something to consider when brewing your
> own control.)

The PC desktop crashes often because the QC of the OS sux. Moreover, the
firm that mekes it has stated that it does not see an interest in removing
bugs, as this is an investment that brings no returns.

On the other hand, did you get to run something other than the usual OS on
a PC ? Such as, a UNIX flavor (pick your choice: Linux, BSD, SCO...) ? You
should, because out of that point of view (and programming), they are
better than the hardware ;)

Peter

1998\05\20@190234 by Thomas J Macauley

flavicon
face
part 0 2310 bytes
>Hmm. May have enough poke to run CANbus, but I guess it would be stretched to
>run the application protocols built upon CANbus.
>I don't bother getting excited about chips before see a sample.
>I've seen too many delivery dates redshift into the distance.

> Also, while CAN is a good networking system,
> there are some environments where field busses are NOT a good idea.

>Such as?


You probably already know about this, but ...

Electrically noisy environments can induce enough noise in a network cable which blocks communication.  I heard about people running DeviceNET (Allen Bradley's Fieldbus based on CAN) in the same conduit as high voltage AC.  Duh.  Another system had problems when a VFD motor was turned on.  The problem turned out to be in grounding, but for a while there was a safety problem.

Another limitation is bandwidth.  Good analysis can take care of this, but a lot of plant maintenance people just don't have what it takes to understand it.  (The salesmen tell the manager it will save money, manager buys it, maintenance installs it.  Nobody seriously looks at it in the overall system.)

So what happens if the noise problem doesn't show up for a while or comes from a system added later?  

The advantage of field busses is that connections are simplified.  The disadvantage is that all your eggs are in one basket.  Electrical codes require hardwired E-Stops and Master Control Relays.  You can't hang their output off a fieldbus.


> I'm still not sure if I like the idea of a network controlling the brakes in a car.

You may be too late! CAN originally meant Car Area Network, developed to
reduce the kilometres of wiring in a typical car.
After so much design effort, it was adopted for use in other areas and
renamed as the more generic Control Area Network.
It may well make cars safer and cheaper, as there are less wires
to make a mistakenly connect.

Yeah, I know.  I guess another part of the safety issue is the initial wiring in the system.  Of course, if you're relying on drug addicts to wire them for you, you gotta make it simple. ;-)

> PC as a controller... Think how often your PC crashes,
> then decide if your factory can deal with that kind of down time.

Yep. Dead right!

Sure wouldn't want rely on Windows 90 Something.

1998\05\20@192607 by Dennis Plunkett

flavicon
face
At 10:42 AM 20/05/98 +0000, you wrote:
>On Tue, 19 May 1998, Thomas J Macauley wrote:
>
>> Also, while CAN is a good networking system, there are some environments
>> where field busses are NOT a good idea.  I'm still not sure if I like
>> the idea of a network controlling the brakes in a car.
>
>The network that controls the brakes is an add-on that serves the ABS and
>other refinements. If it fails, then the systems remains a pure
>hydraulical brake, as in our grandfather's time ;) Moreover, it is
>GUARANTEED to work if electrics fail TOTALLY. Nothing to fear about, the
>people who built the car had the same idea, and they were MORE afraid than
>you, believe me. From the tiniest engineer and up to the top. And of
>course we are talking about cars, and not TRUCKS (which have some
>pneumatical paranoia attachements for the case, and pneumatic automation
>in the braking section) ;)

This is correct, however you will find that the network used to control the
ABS is separated from the other networks! That's right, there is more than
one network in a car these days, however looms still will exist, as the
major cost of wiring is the dashboard harness, where running (Installing)
the loom is more expensive than the loom itself. For the current time being,
looms will still exist to ancillary items such as tail lights, semiconductor
manufactures have attempted to "Sell" the idea of L.E.D tail lights to the
car makers, but alas a simple globe is cheeper.
As for the ABS, quite correct (Now, but not before*), the ABS controls a
relief bleed valve in the brake caliper.

Also there are more than one from of network protocols used by car makers,
CAN is one (European, by birth), however GM has its own as it found CAN to
be "Unsuitable".

* As for ABS, just ask one European car maker about it, they had reported
problems of ABS not working (It killed the occasional driver), turned out to
be a software problem.

As for PCs crashing, I find that most of these problems are to do with the
actual software that is running, that causes the crash problem, by doing
things such as memory overwrites, null pointers etc. Using infected code
calls to unsupported BIOS type functions etc. One could say that the
operating system should prevent this, AH!, QNX. Or should the software
company recommed a fully tested BIOS and operating system?


Dennis

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...