RS232/422/485 enabled sensors

[ChristofferB]

You see an awful lot of gear, like sensors, pressure gauges, etc. that has RS232 or 422/485 interfaces, to hook up to some digital control system, and I've looked at some datasheets for these, specifically vacuum gauges, without much hints about how the interfaces are designed.

Getting any sensor to talk to a computer or terminal via some flavor of serial is of course pretty trivial, what I'm talking about is how the interface itself is made, might there be a standardized way of doing things like this?

-Does a sensor just spew endless readings through serial one-way?
-Do they require a "get reading" character/command rx'd to respond?
-Is it common that they just have a menu, with setup options, get reading, and such?

See, if you have this sorta thing hooked to a datalogger, just getting data sprayed (or timed every n sec/min/day) would sound the most logical.

But if the data system is a terminal, that would hardly let you read anything, so a two-way thing would be preferred. Though that would suck for a datalogger sorta thing.

Is there a standardized way of doing this, or is it just whatever the equipment manufacturer chooses?

[suicidaleggroll]

In my experience, most sensors that have an async serial interface just stream data on their own, and will accept specific commands if you want to change behavior (data rates, etc).  They're not designed for you to connect to them in a terminal, they're designed for you to write a logging program that will handle the data they're spewing out, and can send the necessary commands (if any).

[Eternauta]

if you have more than one sensor to interface one of the serial protocol more used and simple is Modbus RTU. The sensors could be modbus slave and the PC is the modbus master. If the master polls the slaves at periodic interval and store the reading in a dbase you could built your datalogger on the pc with data from several sensors.

[rstofer]

I would suggest reading the datasheet for a specific family of sensors.  RS485 can incorporate collision recovery so it is possible to have multiple sensors on a single cable but I would expect the sensors to be able to send data only on demand.

Here is the OMEGA Communications Manual and if you look on page 10, you will see where the devices supporting this protocol can operate in either 'on demand' or 'continuous' mode:

http://www.omega.com/Manuals/manualpdf/M3397.pdf

[ChristofferB]

Hey thanks for the answers! That's pretty much what i needed to know.

[exmadscientist]

Also, no matter what you see other people suggesting or doing, be very, very careful about what sensors you put on any kind of multidrop line. Anything which uses a non-checksummed protocol, even if it's addressed, is likely to start talking when it shouldn't. (This goes quadruple if the bloody thing uses an ASCII protocol, since -- surprise, surprise! -- long sequences of ASCII characters are commonly transmitted by lots of stuff.) The resulting bus conflicts can be quite a mess.

Sensors which speak sane protocols, such as Modbus, are usually quite robust and reliable.