reading sensor RS-232/485 output

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

reading sensor RS-232/485 output

Jacob Yocom-Piatt
i am planning on pulling live rate data from some manufacturing equipment using
a red lion rate meter with RS-232 or 485 interface

http://www.redlion.net/Products/DigitalandAnalog/Counters/CounterRate/CUB5.html

what is the best way to pull this data, using base OS utilities if possible? if
coding this is most expedient, handing me a pointer to a useful information
address is sufficient.

i'm under the impression that openbsd doesn't support RS-485 interface cards. do
correct me if i'm wrong here.

cheers,
jake

Reply | Threaded
Open this post in threaded view
|

Re: reading sensor RS-232/485 output

Marc Balmer-2
* Jacob Yocom-Piatt wrote:
> i am planning on pulling live rate data from some manufacturing equipment using
> a red lion rate meter with RS-232 or 485 interface
>
> http://www.redlion.net/Products/DigitalandAnalog/Counters/CounterRate/CUB5.html
>
> what is the best way to pull this data, using base OS utilities if possible? if
> coding this is most expedient, handing me a pointer to a useful information
> address is sufficient.

write a userland application that opens the cua device and reads in data
frpm the serial port.  at the moment there is no way to make the data
show up as a sensor value.

>
> i'm under the impression that openbsd doesn't support RS-485 interface cards. do
> correct me if i'm wrong here.
>
> cheers,
> jake

Reply | Threaded
Open this post in threaded view
|

Re: reading sensor RS-232/485 output

Per-Erik Persson
In reply to this post by Jacob Yocom-Piatt
I don't have any webpages to throw at you but converters from rs232 to
rs485 exists.
Also plugins cards to soekris that I would assume to be working.

I have a lot of stuff I plan too hook up to OpenBSD, but have not found
a good way to get the data out without writing to much code.
It feels like reinventing the wheel each time.

If anyone knows of an easy way to add hooks to sysctl that can be
monitored by the sensorsd framework without hacking the kernel I would
be really happy to know.

Jacob Yocom-Piatt wrote:

>i am planning on pulling live rate data from some manufacturing equipment using
>a red lion rate meter with RS-232 or 485 interface
>
>http://www.redlion.net/Products/DigitalandAnalog/Counters/CounterRate/CUB5.html
>
>what is the best way to pull this data, using base OS utilities if possible? if
>coding this is most expedient, handing me a pointer to a useful information
>address is sufficient.
>
>i'm under the impression that openbsd doesn't support RS-485 interface cards. do
>correct me if i'm wrong here.
>
>cheers,
>jake

Reply | Threaded
Open this post in threaded view
|

Re: reading sensor RS-232/485 output

Marc Balmer-2
* Per-Erik Persson wrote:

> I don't have any webpages to throw at you but converters from rs232 to
> rs485 exists.
> Also plugins cards to soekris that I would assume to be working.
>
> I have a lot of stuff I plan too hook up to OpenBSD, but have not found
> a good way to get the data out without writing to much code.
> It feels like reinventing the wheel each time.
>
> If anyone knows of an easy way to add hooks to sysctl that can be
> monitored by the sensorsd framework without hacking the kernel I would
> be really happy to know.

technically, this can be done with a line discipline that decodes the
data stream and provides the sensor.  but then there are zillions of
serial protocols and supporting them in this way would just blowup the
kernel.

>
> Jacob Yocom-Piatt wrote:
>
> >i am planning on pulling live rate data from some manufacturing equipment
> >using
> >a red lion rate meter with RS-232 or 485 interface
> >
> >http://www.redlion.net/Products/DigitalandAnalog/Counters/CounterRate/CUB5.html
> >
> >what is the best way to pull this data, using base OS utilities if
> >possible? if
> >coding this is most expedient, handing me a pointer to a useful information
> >address is sufficient.
> >
> >i'm under the impression that openbsd doesn't support RS-485 interface
> >cards. do
> >correct me if i'm wrong here.
> >
> >cheers,
> >jake

Reply | Threaded
Open this post in threaded view
|

Re: reading sensor RS-232/485 output

J.C. Roberts
In reply to this post by Jacob Yocom-Piatt
On Wednesday 10 January 2007 21:51, Jacob Yocom-Piatt wrote:

> i am planning on pulling live rate data from some manufacturing
> equipment using a red lion rate meter with RS-232 or 485 interface
>
> http://www.redlion.net/Products/DigitalandAnalog/Counters/CounterRate
>/CUB5.html
>
> what is the best way to pull this data, using base OS utilities if
> possible? if coding this is most expedient, handing me a pointer to a
> useful information address is sufficient.
>
> i'm under the impression that openbsd doesn't support RS-485
> interface cards. do correct me if i'm wrong here.
>
> cheers,
> jake

Hi Jake,

I looked over the datasheet/manual for the RS-232/RS-485 interface.
http://www.redlion.net/Products/Groups/Counter/Rate/CUB5/Docs/12039.pdf

The format of the command strings looks strikingly similar to SCPI,
which is often (if not usually) used on IEEE-488/GPIB/HPIB interfaces.

http://en.wikipedia.org/wiki/SCPI
http://en.wikipedia.org/wiki/IEEE-488

A lot of equipment that has (or supports) SCPI over GPIB will also
support the command set over serial. As always, you never get plain
vanillia SCPI since every device and every device mfg has their own
"good" ideas tossed in as "special" commands.

Though it seems like you can talk to the CUB5 with nothing more than a
terminal emulator and some typing, doing it manually is really only
useful for figuring out which commands you want/need to run.

You could automate everything as a shell script using only the utilities
in the base install, in short telnet over serial.

I usually don't get the luxury of UNIX shell scripting, and often have a
cross platform requirement, so I normally do the coding in perl. The
following ports will be needed and they have win32 counterparts.

  /usr/ports/comms/p5-Device-SerialPort
  /usr/ports/net/p5-Net-Telnet

PLEASE BE WARNED: If you have strict timing requirements, particularly
machine operator safety requirements (i.e. people operating potentially
dangerous machines), the *ONLY* correct way to do machine automation is
to use a (hard/soft) real time operating system and write your code in
C to enforce your timing.

Kind Regards,
JCR

Reply | Threaded
Open this post in threaded view
|

Re: reading sensor RS-232/485 output

Jacob Yocom-Piatt
J.C. Roberts wrote:
> You could automate everything as a shell script using only the utilities
> in the base install, in short telnet over serial.
>
>  

sounds interesting, i'll see what i can do with this first. any further
info you could provide here would be nice.

> I usually don't get the luxury of UNIX shell scripting, and often have a
> cross platform requirement, so I normally do the coding in perl. The
> following ports will be needed and they have win32 counterparts.
>
>   /usr/ports/comms/p5-Device-SerialPort
>   /usr/ports/net/p5-Net-Telnet
>
>  

if i need more involved data collection, i'll do it in perl or C, thanks
for the pointers here.

> PLEASE BE WARNED: If you have strict timing requirements, particularly
> machine operator safety requirements (i.e. people operating potentially
> dangerous machines), the *ONLY* correct way to do machine automation is
> to use a (hard/soft) real time operating system and write your code in
> C to enforce your timing.
>
>  
<sarcasm>
and this whole time i thought the correct way to automate machines is to
expose them to a myriad of repeated short video clips on a television,
have them join a fraternity and put a  big ol' ladder in front of them.
i can't wait until we can code that in C.
</sarcasm>

i am well aware that running heavy machinery can be extremely dangerous.
this data is only being used for performance analysis and has no effect
on the machinery in question. your concern is appreciated.

warm regards,
jake

Reply | Threaded
Open this post in threaded view
|

Re: reading sensor RS-232/485 output

J.C. Roberts
On Thursday 11 January 2007 11:42, Jacob Yocom-Piatt wrote:
> J.C. Roberts wrote:
> > You could automate everything as a shell script using only the
> > utilities in the base install, in short telnet over serial.
> >
> >  
>
> sounds interesting, i'll see what i can do with this first. any
> further info you could provide here would be nice.
>

I always start with running the various SCPI(ish) commands manually in a
terminal emulator. If forced (by threat of death) to work in
ms-windows, then I use the typical hyperterminal, otherwise I'll go
with tip/cu or similar. You may want to note the docs for the CUB5
states it works in half-duplex mode, while tip/cu are normally full
duplex (use the -h switch on cu). After figuring out what commands
should be run, the proper order and the expected results/failures, life
gets easy.

hmmm... I did a good job of avoiding your question above. It's a mental
block, you know, the kind of subconscious "forgetting" which happens
after a really horrific trauma. Anyhow, I'm terrible at shell scripting
and always have been. I get fed up with the syntax and cross platform
bugs in a matter of minutes, give up, and go grab a "better" language
to use (where "better" simply means "the devil you know").

Since I'm probably the worst person you could ask, hopefully one of the
many shell scripting gods inhabiting this mailing list will chime in on
how do useful work in shell scripts with serial.

> > I usually don't get the luxury of UNIX shell scripting, and often
> > have a cross platform requirement, so I normally do the coding in
> > perl. The following ports will be needed and they have win32
> > counterparts.
> >
> >   /usr/ports/comms/p5-Device-SerialPort
> >   /usr/ports/net/p5-Net-Telnet
> >
> >  
>
> if i need more involved data collection, i'll do it in perl or C,
> thanks for the pointers here.
>
> > PLEASE BE WARNED: If you have strict timing requirements,
> > particularly machine operator safety requirements (i.e. people
> > operating potentially dangerous machines), the *ONLY* correct way
> > to do machine automation is to use a (hard/soft) real time
> > operating system and write your code in C to enforce your timing.
> >
> >  
>
> <sarcasm>
> and this whole time i thought the correct way to automate machines is
> to expose them to a myriad of repeated short video clips on a
> television, have them join a fraternity and put a  big ol' ladder in
> front of them. i can't wait until we can code that in C.
> </sarcasm>
>
:)
> i am well aware that running heavy machinery can be extremely
> dangerous. this data is only being used for performance analysis and
> has no effect on the machinery in question. your concern is
> appreciated.
>

Don't let the "machinery" word, heavy or otherwise, give you a false
sense of security. Little stuff like when voltage is applied, can make
a big mess in a hurry. Damaging equipment is nearly as bad as damaging
people... well, maybe that depends on the person. Let's see, a spectrum
analyzer which cost more than a house in California or that lazy
coworker which never does anything useful... -I better not complete
that thought.

Anyhow, since there is no guarantee that your process/thread/interrupt
will be serviced by the kernel within "X" amount of time, the
non-realtime operating systems should not be used when doing "time
critical" automation on dangerous or delicate equipment. The good news
is there are only a few classes of problem which are actually *that*
"time critical" so loose timing on a non-realtime OS is far more than
enough in most cases.

Kind Regards,
JCR

Reply | Threaded
Open this post in threaded view
|

Re: reading sensor RS-232/485 output

Damian Wiest
On Thu, Jan 11, 2007 at 10:23:31PM -0800, J.C. Roberts wrote:

[snip]

> Since I'm probably the worst person you could ask, hopefully one of the
> many shell scripting gods inhabiting this mailing list will chime in on
> how do useful work in shell scripts with serial.

I've typically used kermit (C-Kermit) for this sort of thing.  The man
page includes some examples of kermit based shell scripts.

You could also probably put something together with tip/cu and Expect
(or Tcl).

[snip]

-Damian