Subject: Re: process analyzer communications - qanl_pa.asc [01/01]
From: DRIEDGEW@cal.cybersurf.net (Walter Driedger)
Date: 7 Dec 1996 06:40:53 GMT
I am a user. From time to time I have to connect a
chromatograph to a DCS (distributed control system).
There is no way I can get involved in the details of
communications systems. My specs are simple:
a) signal type must be RS-232 or 485(?)
b) protocol must be Modbus.
period. I don't run a driver training school.
This applies to both the DCS, PLC, chromatograph,
whatever. Some of the vendors, i.e. non-Modicon
PLCs with their own in-house solution, don't like this,
but they always comply since they know that if
they don't, they're not on the bid list.
Even so, during system testing, I can usually
allow for a full week with the assistance of the
analyzer vendor to get communications working
properly. One common problem is that the
vendor tells us something like, "Word 13 gives
the error flag." It turns out that word 13 is a
composit of 16 bits. Some combinations
indicate errors, others indicate which channel
is scanning. I have to disassemble this in the DCS.
I might add that a DCS is not intended for bit
slicing. Another silly problem is that the vendor
arranges the stream components in a different
order than he said he would. The computer
types think that when the bits come through,
communications is established. Like the post
office thinks that if the letter is put in the right
mailbox, communications is done. Unfortunately
both the sender and the receive speak different
dialects of a foreign tongue.
To test these, I ask the vendor something like,
"Give me 123 ppm of ethylene." What happens
next is that the methane indicator jumps to 24%.
"Oops!" says the vendor rep. "I think Bob switched
the channels here. Let me show the real sequence."
And so the week goes by.
I suppose the problemn is that when everything
is progammable, it is impossible to know in
advance what the supplier is going to do. They
make it up at the last minute because it is easy.
I, on the other hand, must have my recieving
equipment pre-programmed to accept the signals
from analyzers, vibration monitors, SCADA systems, PLCs
of half a dozen vendors. Every time I do this, I have
a different mix of vendors. From one job to the
next, their technology changes. They make it up
as they go along and their documentation is
incomplete and often in error. "Oh, we've changed that.
Let me FAX you the new stuff." Since they work with
one piece of equipment full time, they cannot
understand that what they are doing is not at all
obvious to someone who is seeing it for the first time
in his life. In the meantime I am at a DCS staging
center 1000 miles from home living on expense account.
Steak dinners, drinks, etc. are wearing me down.
Its a rough life but somebody has to live it. Thats why
they pay me the big bucks.
By the way, you mention PC, Mac, etc. Big plants still
use DCS and PLCs.
Walter C. Driedger, P. Eng.
403-234-4955
In article , 7397@mne.net says...
>
>I am writing an article on process analyzer communications.
>The focus of the article is communications between the analytical
>instrument (process GCs, mass specs, photodiode array, FT IR, etc.,),
>the analyzer data, the plantwide data highway, system, and the
>process control computers.
>Whether you are a vendor or user, could you share your experiences
>with the magazine's readers by answering the questions below?
>1. What is the problem with analyzer communications right
>now?
>2. How is the analyzer communications issue relate to
>standard
>analyzer outputs, ie, analytical signal and signals related to
>instrument operation?
>3. What different communications protocols are out there?
>4. Why are they different? Is there a standard?
>5. What do these protocols do/attemtpt to do?
>6. Why choose one over the other?
>7. What kinds of devices are necessary to utilize these
> protocols?
>8. What kinds of analyzers can be interfaced to these
>devices?
>9. What kinds of output do these devices accept from the
> analyzer?
>10. What kind of output do they transmit and to where?
>11. What benefits can users expect for each device/protocol?
>
>14. What are the computing requirements for using t hese devices,
>ie, PC/Mac, Unix, or some othe proprietary architecture?
>15. Are these devices/protocols plug and play?
>16. Who is using? Names and phone numbers? (Please provide your
>name phone and fax numbers, corporate affiliation, and title so I can
>contact for more information or if I have questions. Please let me
>know if I can quote you, too.
>Thanks for your help.
> Mark Weiss
