Serial Communication

[Matthias Müller]

Hello,
I'm new to LabView and try to write a library, that lets me control a
spectrometer using the serial port.
I've done this already and anything works fine as long as I am in the
dubigging step by step mode. When I want to run my program in the normal
execution mose all the serial data get mixed up and are not synchronized
anymore (that's what I guess it is).
The communication is following:
5-byte data-word written on the serial port --> the word is reflected
immediately.
then it depends,.. maybe a handshake byte and the aquired data can be
read from the port.
So I do following:

I write the word on the port, put the error-output of the serial write
on a while loop without condition and put a serial read vi in there,
with the byt
es to read=5. then i compare the sent string and the
received and if true go to send to handshaking byte.

i think it should work,... but i tried it with the
GetNumberOfBytesAtSerialPort.vi too, but in execution mode it says ,
that there are no bytes at the port....
So i wondered if there could be a timing problem and tried out some
delay-timers, without access,...

I would be very glad, if you could give me some advices...
Thanks in advance...
Matthias

[Johannes Niess]

Matthias Müller writes:

> Hello,
> I'm new to LabView and try to write a library, that lets me control a
> spectrometer using the serial port.

[...]

> I would be very glad, if you could give me some advices...
> Thanks in advance...
> Matthias

Matthias,

I always use VISA communication. This way you just change the device
address from ASRL1 to GPIB1::1 (or something like that) and you can
use the GPIB port of your device. Sending and recieving data is a lot
easier and on a higher level: E. g. Under some common circumstances
you can set up a recieve buffer of 100 bytes and read messages of
different length.

All users of the old serial.vi's need some kind of black magic. I
don't want to care about polling the device byte for byte. I
want to
wire to my message string and let the VISA drivers do the rest.

There are other people with other oppinions. I'm the kind of
fundamentalist that hates anything against data flow: local/global
variables and low level programming.

Johannes Nieß

[Matthias Müller]

Thank you for your posting, but....

Johannes Niess wrote:
> Matthias,
>
> I always use VISA communication. This way you just change the device
> address from ASRL1 to GPIB1::1 (or something like that) and you can
> use the GPIB port of your device. Sending and recieving data is a lot
> easier and on a higher level: E. g. Under some common circumstances
> you can set up a recieve buffer of 100 bytes and read messages of
> different length.

Hmmm, sounds really right, but unfortunately i don't have a VISA driver
for my device and i can communicate with it only over the serial port.
So i have to use the low level communication i guess. VISA is just an
API, that calls other low-level libraries, isn't it? or can i use VISA
calls to communicate with my device?


> All users of the old serial.vi's need some kind of black magic. I
> don't want to care about polling the device byte for byte. I want to
> wire to my message string and let the VISA drivers do the rest.

i don't want too, believe me, but it looks like i have to, because i
have no VISA driver for my device. maybe i should joind a course in
black magic, does someone knows where one is held??

> There are other people with other oppinions. I'm the kind of
> fundamentalist that hates anything against data flow: local/global
> variables and low level programming.

of course, but there have to be some who do this, so you can profit of
their work and use just the VISA drivers, or do you think they create
themselves? oh,... i forgot the black magic. :))

> Johannes Nieß

[Johannes Niess]

Matthias Müller writes:

> Thank you for your posting, but....
>
> Johannes Niess wrote:
> > Matthias,
> >
> > I always use VISA communication. This way you just change the device
> > address from ASRL1 to GPIB1::1 (or something like that) and you can
> > use the GPIB port of your device. Sending and recieving data is a lot
> > easier and on a higher level: E. g. Under some common circumstances
> > you can set up a recieve buffer of 100 bytes and read messages of
> > different length.
>
> Hmmm, sounds really right, but unfortunately i don't have a VISA driver
> for my device and i can communicate with it only over the serial port.
> So i have to use the low level communication i guess. VISA is just an
> API, that ca
lls other low-level libraries, isn't it? or can i use VISA
> calls to communicate with my device?

VISA is easier than old serial I/O. Look at the examples that come
with labview. Of course VISA is an API, but for all kinds of I/O.

>
> > All users of the old serial.vi's need some kind of black magic. I
> > don't want to care about polling the device byte for byte. I want to
> > wire to my message string and let the VISA drivers do the rest.
>
> i don't want too, believe me, but it looks like i have to, because i
> have no VISA driver for my device. maybe i should joind a course in
> black magic, does someone knows where one is held??

Other people call the black magic real time programming...
Polling byte for byte _is_ real time programming.

I've seen two methods of black magic:

1) Reading back the bytes from the serial port to decide when to
switch to application specific "listen mode".

2) Using occurrences to syncronize parts.


Johannes Nieß

[Matthias Müller]

Johannes Niess wrote:
>
> Matthias M�ller writes:
>
> > Thank you for your posting, but....
> >
> > Johannes Niess wrote:
> > > Matthias,
> > >
> > > I always use VISA communication. This way you just change the device
> > > address from ASRL1 to GPIB1::1 (or something like that) and you can
> > > use the GPIB port of your device. Sending and recieving data is a lot
> > > easier and on a higher level: E. g. Under some common circumstances
> > > you can set up a recieve buffer of 100 bytes and read messages of
> > > different length.
> >
> > Hmmm, sounds really right, but unfortunately i don't have a VISA driver
> > for my device and i can communicate with it only over the serial port.
> > So i have to use the low level communication i guess. VISA is just an
> > API, that calls other low-level libraries, isn't it? or can i use VISA
> > calls to communicate with my device?
>
> VISA is easier than old serial I/O. Look at the examples that come
> with labview. Of course VISA is an API, but for all kinds of I/O.
>
> >
> > > All users of the old serial.vi's need some kind of black magic. I
> > > don't want to care about polling the device byte for byte. I want to
> > > wire to my message string and let the VISA drivers do the rest.
> >
> > i don't want too, believe me, but it looks like i have to, because i
> > have no VISA driver for my device. maybe i should joind a course in
> > black magic, does someone knows where one is held??
>
> Other people call the black magic real time programming...
> Polling byte for byte _is_ real time programming.
>
> I've seen two methods of black magic:
>
> 1) Reading back the bytes from the serial port to decide when to
> switch to application specific "listen mode".
>
> 2) Using occurrences to syncronize parts.
>
> Johannes Nie�

Thank you very much for your answers, but maybe i don't really realize
what VISA is good for. I think it is so, that someone writes a low level
device driver for a specific device and then includes standard VISA
interfaces to use this driver with VISA calls. Maybe it's totally
diferent and i can access the serial port directly using VISA. if so, i
haven't found out how to do it. if i connect my device to the serial
port and create a VISA-find instruments vi, it comes out, that there is
no device, so i assume, I can't access it directly with the VISA
commands that are provided with LabView.... is that wrong!?

Matthias

[abrause]

When I'm setting up to talk to a new instrument I use a set of sub vis I
have
created. These sub vis have in and out connectors for ComPort, Errors and
messages so they utilize dataflow to determine when they operate.
The first vi initializes the port, the second builds the message string,
(including
CRC, if necessary) the third vi writes the message to the serial port.
Usually you have to wait here for some milliseconds so the reply can come
back.
The Read vi sits in a loop and reads the bytes at the port. It has a
timeout
so if no bytes are read it can continue.
Once I have the reply, I check it for errors.

Perhaps this type of data flow is what you are enforcing when you step
through your program now. Try breaking apart the code into sub vis and
let LV's dataflow handle each step.

When you are happy with basic comms with the instrument, the sub vis
you have created can be used in a state machine (a case statement in
a while loop) to build your program.

Regards,

Alan Brause







Matthias M�ller wrote in message
news:385534A6.2062F565@rz.uni-karlsruhe.de...
> Hello,
> I'm new to LabView and try to write a library, that lets me control a
> spectrometer using the serial port.
> I've done this already and anything works fine as long as I am in the
> dubigging step by step mode. When I want to run my program in the normal
> execution mose all the serial data get mixed up and are not synchronized
> anymore (that's what I guess it is).
> The communication is following:
> 5-byte data-word written on the serial port --> the word is reflected
> immediately.
> then it depends,.. maybe a handshake byte and the aquired data can be
> read from the port.
> So I do following:
>
> I write the word on the port, put the error-output of the serial write
> on a while loop without condition and put a serial read vi in there,
> with the bytes to read=5. then i compare the sent string and the
> received and if true go to send to handshaking byte.
>
> i think it should work,... but i tried it with the
> GetNumberOfBytesAtSerialPort.vi too, but in execution mode it says ,
> that there are no bytes at the port....
> So i wondered if there could be a timing problem and tried out some
> delay-timers, without access,...
>
> I would be very glad, if you could give me some advices...
> Thanks in advance...
> Matthias
>

[Matthias Müller]

Alan Brause wrote:
>
> When I'm setting up to talk to a new instrument I use a set of sub vis I
> have
> created. These sub vis have in and out connectors for ComPort, Errors and
> messages so they utilize dataflow to determine when they operate.
> The first vi initializes the port, the second builds the message string,
> (including
> CRC, if necessary) the third vi writes the message to the serial port.
> Usually you have to wait here for some milliseconds so the reply can come
> back.
> The Read vi sits in a loop and reads the bytes at the port. It has a
> timeout
> so if no bytes are read it can continue.
> Once I have the reply, I check it for errors.
>
> Perhaps this type of data flow is what you are enforcing when you step
> through your program n
ow. Try breaking apart the code into sub vis and
> let LV's dataflow handle each step.
>
> When you are happy with basic comms with the instrument, the sub vis
> you have created can be used in a state machine (a case statement in
> a while loop) to build your program.
>
> Regards,
>
> Alan Brause
>

That sounds to be the thing i had in mind when i began. maybe i have to
try out with a serial read vi with timeout.
I hope it will work then 🙂

Matthias

[rcdon]

Alan Brause wrote:

> When I'm setting up to talk to a new instrument I use a set of sub vis I
> have
> created. These sub vis have in and out connectors for ComPort, Errors and
> messages so they utilize dataflow to determine when they operate.
> The first vi initializes the port, the second builds the message string,
> (including
> CRC, if necessary) the third vi writes the message to the serial port.
> Usually you have to wait here for some milliseconds so the reply can come
> back.
> The Read vi sits in a loop and reads the bytes at the port. It has a
> timeout
> so if no bytes are read it can continue.
> Once I have the reply, I check it for errors.
>
> Perhaps this type of data flow is what you are enforcing when you step
> through your program now. Try breaking apart the code into sub vis and
> let LV's dataflow handle each step.
>
> When you are happy with basic comms with the instrument, the sub vis
> you have created can be used in a state machine (a case statement in
> a while loop) to build your program.
>
> Regards,
>
> Alan Brause
>
> Matthias M�ller wrote in message
> news:385534A6.2062F565@rz.uni-karlsruhe.de...
> > Hello,
> > I'm new to LabView and try to write a library, that lets me control a
> > spectrometer using the serial port.
> > I've done this already and anything works fine as long as I am in the
> > dubigging step by step mode. When I want to run my program in the normal
> > execution mose all the serial data get mixed up and are not synchronized
> > anymore (that's what I guess it is).
> > The communication is following:
> > 5-byte data-word written on the serial port --> the word is reflected
> > immediately.
> > then it depends,.. maybe a handshake byte and the aquired data can be
> > read from the port.
> > So I do following:
> >
> > I write the word on the port, put the error-output of the serial write
> > on a while loop without condition and put a serial read vi in there,
> > with the bytes to read=5. then i compare the sent string and the
> > received and if true go to send to handshaking byte.
> >
> > i think it should work,... but i tried it with the
> > GetNumberOfBytesAtSerialPort.vi too, but in execution mode it says ,
> > that there are no bytes at the port....
> > So i wondered if there could be a timing problem and tried out some
> > delay-timers, without access,...
> >
> > I would be very glad, if you could give me some advices...
> > Thanks in advance...
> > Matthias
> >

Alan's advice is excellent, the only thing I would add is to use VISA. It
allows setting and enabling a termination character on reads, which for
situations where there are a variable number of bytes returned is a real
convenience - no need to build in a pause and to read the bytes available in
the serial buffer. You can also change the termination character on the fly
if needed (I do).
VISA also allows locking of its "sessions", which has worked out well for me
with a setup where I have a variable number of devices attached to each
serial port in daisy chain fashion (both RS-232 and -485). So I have parallel
loops to handle communication with each device, and lock and unlock the
shared port/session as needed to prevent communication mix-ups.

Rod
--
Roderic Don
Research Associate II
University of Delaware
Center for Composite Materials
302-831-8352
302-831-8525 (FAX)
---------------------------------------------
"Stressed would mean that the pandemonium can be measured!"
- Scott "Scooter" Holmes

[abrause]

I agree totally, Don. VISA is the way to go. I use serial port vis to
keep the size of my .EXE smaller so I can distribute my app over
the net. It's another layer of complexity for my end user to have to
install the VISA components. (as well as a much larger download)

I can hardly wait until LV comes out with a single driver to include
with an .EXE so I can use VISA also. (like serpdrv)

Or has anyone figured out how to distribute the VISA driver
without the installation disks from NI?

Alan


Roderic Don wrote in message
news:3857A880.91863E02@ccm.udel.edu...
> Alan Brause wrote:
>
> > When I'm setting up to talk to a new instrument I use a set of sub vis I
> > have
> > created. These sub vis have in and out connectors for ComPort, Errors
and
> > messages so they utilize dataflow to determine when they operate.
> > The first vi initializes the port, the second builds the message string,
> > (including
> > CRC, if necessary) the third vi writes the message to the serial port.
> > Usually you have to wait here for some milliseconds so the reply can
come
> > back.
> > The Read vi sits in a loop and reads the bytes at the port. It has a
> > timeout
> > so if no bytes are read it can continue.
> > Once I have the reply, I check it for errors.
> >
> > Perhaps this type of data flow is what you are enforcing when you step
> > through your program now. Try breaking apart the code into sub vis and
> > let LV's dataflow handle each step.
> >
> > When you are happy with basic comms with the instrument, the sub vis
> > you have created can be used in a state machine (a case statement in
> > a while loop) to build your program.
> >
> > Regards,
> >
> > Alan Brause
> >
> > Matthias M�ller wrote in message
> > news:385534A6.2062F565@rz.uni-karlsruhe.de...
> > > Hello,
> > > I'm new to LabView and try to write a library, that lets me control a
> > > spectrometer using the serial port.
> > > I've done this already and anything works fine as long as I am in the
> > > dubigging step by step mode. When I want to run my program in the
normal
> > > execution mose all the serial data get mixed up and are not
synchronized
> > > anymore (that's what I guess it is).
> > > The communication is following:
> > > 5-byte data-word written on the serial port --> the word is reflected
> > > immediately.
> > > then it depends,.. maybe a handshake byte and the aquired data can be
> > > read from the port.
> > > So I do following:
> > >
> > > I write the word on the port, put the error-output of the serial write
> > > on a while loop without condition and put a serial read vi in there,
> > > with the bytes to read=5. then i compare the sent string and the
> > > received and if true go to send to handshaking byte.
> > >
> > > i think it should work,... but i tried it with the
> > > GetNumberOfBytesAtSerialPort.vi too, but in execution mode it says ,
> > > that there are no bytes at the port....
> > > So i wondered if there could be a timing problem and tried out some
> > > delay-timers, without access,...
> > >
> > > I would be very glad, if you could give me some advices...
> > > Thanks in advance...
> > > Matthias
> > >
>
> Alan's advice is excellent, the only thing I would add is to use VISA. It
> allows setting and enabling a termination character on reads, which for
> situations where there are a variable number of bytes returned is a real
> convenience - no need to build in a pause and to read the bytes available
in
> the serial buffer. You can also change the termination character on the
fly
> if needed (I do).
> VISA also allows locking of its "sessions", which has worked out well for
me
> with a setup where I have a variable number of devices attached to each
> serial port in daisy chain fashion (both RS-232 and -485). So I have
parallel
> loops to handle communication with each device, and lock and unlock the
> shared port/session as needed to prevent communication mix-ups.
>
> Rod
> --
> Roderic Don
> Research Associate II
> University of Delaware
> Center for Composite Materials
> 302-831-8352
> 302-831-8525 (FAX)
> ---------------------------------------------
> "Stressed would mean that the pandemonium can be measured!"
> - Scott "Scooter" Holmes
>
>

[abrause]

I agree totally Roderic, there are many good reasons to use VISA over
the serial port vis. In my situation I use serial port vis to keep the size
of my distributed .exe smaller. It's an additional layer of complexity
for my end users to have to download and install the VISA components.

I can hardly wait until LV comes out with a single driver for VISA like
serpdrv. I'll go to VISA in a heartbeat.

Or has anyone figured out how to distribute a VISA .exe app with a single
driver????

Alan


Roderic Don wrote in message
news:3857A880.91863E02@ccm.udel.edu...
> Alan Brause wrote:
> snip snip....
> Alan's advice is excellent, the only thing I would add is to use VISA. It
> allows setting and enabling a termination character on read
s, which for
> situations where there are a variable number of bytes returned is a real
> convenience - no need to build in a pause and to read the bytes available
in
> the serial buffer. You can also change the termination character on the
fly
> if needed (I do).
> VISA also allows locking of its "sessions", which has worked out well for
me
> with a setup where I have a variable number of devices attached to each
> serial port in daisy chain fashion (both RS-232 and -485). So I have
parallel
> loops to handle communication with each device, and lock and unlock the
> shared port/session as needed to prevent communication mix-ups.
>
> Rod
> --
> Roderic Don
> Research Associate II
> University of Delaware
> Center for Composite Materials
> 302-831-8352
> 302-831-8525 (FAX)
> ---------------------------------------------
> "Stressed would mean that the pandemonium can be measured!"
> - Scott "Scooter" Holmes
>
>