serial

[daniel]

Hello,
I'am trying to implement a control with labwiew that does the following:
A microcontroller writes asynchronously data packets of the following type
A0B, A256B. (a 8 bit dec number between the delimiters A and B).
This occurs about 10 times a second.
These should be read by labview and displayed on a waveform chart.
I tried the serial read vi with timeout of the examples section which works
as far as tha data is correct.
The problem is that the microcontroller itself permanently recieves signals
of the form A\nB\nC\n... from the computer via
the serial port.
If I integrate the serial read function this process slows down drastically
(up to 5 sec from pressing the panel switch to the signal being
recieved by the controller) this is not accept
able.


Many thanks for your help in advance


Daniel

[Sergey Krasnishov]

daniel wrote:

> Hello,
> I'am trying to implement a control with labwiew that does the following:
> A microcontroller writes asynchronously data packets of the following type
> A0B, A256B. (a 8 bit dec number between the delimiters A and B).
> This occurs about 10 times a second.
> These should be read by labview and displayed on a waveform chart.
> I tried the serial read vi with timeout of the examples section which works
> as far as tha data is correct.
> The problem is that the microcontroller itself permanently recieves signals
> of the form A\nB\nC\n... from the computer via
> the serial port.
> If I integrate the serial read function this process slows down drastically
> (up to 5 sec from pressing the panel switch to the signal being
> recieved by the
controller) this is not acceptable.
>
>
> Many thanks for your help in advance
>
>
> Daniel

Daniel,

Try to use VISA instead. There you'll find options for setting COM
driver not to send end bytes like \n (new line). It seems the problem is
here.
Try to set flow control to NONE when initializing com port, which means
the same.

--
Sergey Krasnishov
____________________________________
Automated Control Systems
National Instruments Alliance Member
Moscow, Russia
sergey_acs@levsha.ru
http://acs.levsha.ru

[daniel]

Hello Sergey,
changed flow control to none but still have the problem.
I think I didn�t descibe properly what I�m doing :
I have 6 channels driven by the computer which the following structure:
A bolean button switches a case structure in which sits a "visa write" with
the string "A" for true and "B" for false.
So if the button a is pressed the computer continuously sends "A"s if it is
switched off "B"s.
The reason for this is that I want the microcontroller to by synchronized
even after a temporary shutdown.
If I have only these 6 channels running it takes about 0.5s from the
keystroke to the microcontroller recieving the command, this
seems a bit long but is the utmost acceptable delay (The 6 case structures
are in a while box, I put them in a sequnce structure
, too, but without any improvement.)
Now I want to read the date from the microcontroller.
I tried the following:
1) "visa read" with n bytes to read ant timeout, the string passes through
"decimal string to number" to the waveform chart
This works with respect to data integrety but totally blocks the 6 write
processes
2) "visa read" which reads all the "bytes at serial port" and then scans for
the bytes between A and B by means of two
"match pattern" boxes.
This works a bit faster (10sec from keystroke to action) but is still not
acceptable.


This is my first LV project, my time schedule is very stringent and there is
noone here who knows about LV
I would be very thankful to anyone giving feedback, maybe I could post the
vi, I`am sure you`ll know immediately
know what I did wrong.

Yours Daniel

Sergey Krasnishov schrieb in im Newsbeitrag:
3B0BE356.4080006@levsha.ru...
> daniel wrote:
>
> > Hello,
> > I'am trying to implement a control with labwiew that does the following:
> > A microcontroller writes asynchronously data packets of the following
type
> > A0B, A256B. (a 8 bit dec number between the delimiters A and B).
> > This occurs about 10 times a second.
> > These should be read by labview and displayed on a waveform chart.
> > I tried the serial read vi with timeout of the examples section which
works
> > as far as tha data is correct.
> > The problem is that the microcontroller itself permanently recieves
signals
> > of the form A\nB\nC\n... from the computer via
> > the serial port.
> > If I integrate the serial read function this process slows down
drastically
> > (up to 5 sec from pressing the panel switch to the signal being
> > recieved by the controller) this is not acceptable.
> >
> >
> > Many thanks for your help in advance
> >
> >
> > Daniel
>
> Daniel,
>
> Try to use VISA instead. There you'll find options for setting COM
> driver not to send end bytes like \n (new line). It seems the problem is
> here.
> Try to set flow control to NONE when initializing com port, which means
> the same.
>
> --
> Sergey Krasnishov
> ____________________________________
> Automated Control Systems
> National Instruments Alliance Member
> Moscow, Russia
> sergey_acs@levsha.ru
> http://acs.levsha.ru
>

[shoneill]

Hallo all,

I had similar problems before, but moving to VISA and flushing the buffers
before every read / after every write solved almost all of my problems. I
presume the time delay is a buffering done by the operating system.

just my thoughts on the subject

Shane

daniel <6.6e-34@gmx.de> schrieb in Nachricht
<9elheh$4ha$1@mamenchi.zrz.TU-Berlin.DE>...
>Hello Sergey,
>changed flow control to none but still have the problem.
>I think I didn�t descibe properly what I�m doing :
>I have 6 channels driven by the computer which the following structure:
>A bolean button switches a case structure in which sits a "visa write" with
>the string "A" for true and "B" for false.
>So if the button a is pressed the computer continuously sends "A"s if it is
>switched off "B"s.
>The reason for this is that I want the microcontroller to by synchronized
>even after a temporary shutdown.
>If I have only these 6 channels running it takes about 0.5s from the
>keystroke to the microcontroller recieving the command, this
>seems a bit long but is the utmost acceptable delay (The 6 case structures
>are in a while box, I put them in a sequnce structure
>, too, but without any improvement.)
>Now I want to read the date from the microcontroller.
>I tried the following:
>1) "visa read" with n bytes to read ant timeout, the string passes through
>"decimal string to number" to the waveform chart
>This works with respect to data integrety but totally blocks the 6 write
>processes
>2) "visa read" which reads all the "bytes at serial port" and then scans
for
>the bytes between A and B by means of two
>"match pattern" boxes.
>This works a bit faster (10sec from keystroke to action) but is still not
>acceptable.
>
>
>This is my first LV project, my time schedule is very stringent and there
is
>noone here who knows about LV
>I would be very thankful to anyone giving feedback, maybe I could post the
>vi, I`am sure you`ll know immediately
>know what I did wrong.
>
>Yours Daniel
>
>Sergey Krasnishov schrieb in im Newsbeitrag:
>3B0BE356.4080006@levsha.ru...
>> daniel wrote:
>>
>> > Hello,
>> > I'am trying to implement a control with labwiew that does the
following:
>> > A microcontroller writes asynchronously data packets of the following
>type
>> > A0B, A256B. (a 8 bit dec number between the delimiters A and B).
>> > This occurs about 10 times a second.
>> > These should be read by labview and displayed on a waveform chart.
>> > I tried the serial read vi with timeout of the examples section which
>works
>> > as far as tha data is correct.
>> > The problem is that the microcontroller itself permanently recieves
>signals
>> > of the form A\nB\nC\n... from the computer via
>> > the serial port.
>> > If I integrate the serial read function this process slows down
>drastically
>> > (up to 5 sec from pressing the panel switch to the signal being
>> > recieved by the controller) this is not acceptable.
>> >
>> >
>> > Many thanks for your help in advance
>> >
>> >
>> > Daniel
>>
>> Daniel,
>>
>> Try to use VISA instead. There you'll find options for setting COM
>> driver not to send end bytes like \n (new line). It seems the problem is
>> here.
>> Try to set flow control to NONE when initializing com port, which means
>> the same.
>>
>> --
>> Sergey Krasnishov
>> ____________________________________
>> Automated Control Systems
>> National Instruments Alliance Member
>> Moscow, Russia
>> sergey_acs@levsha.ru
>> http://acs.levsha.ru
>>
>
>

[Doug (CapeFl)]

Daniel,
After reading all the attached comments, etc., I can empathize with your situation. I have seen similar symptoms with some Read/Write functions, where the delays put to the reading and writing often conflict with other delays such as loops, updating graphs, etc. - when on the same VI. One simple trick to consider is simply break up the 1 large VI into separate VIs (1 for Read/Write and 1 for other misc.). Run both VIs at the same time and share data through globals or files - but not allow one VI to have to wait on the other. With each VI not affected by delays in the other VI, you might see greatly improved speed. I don't have Labview 6 yet, which may offer other options to get around the data-flow processes. Just an idea - Doug.

[daniel]

Hello,
I replaced the visa functions by the ones in the serial compatibility and
now it works.
Does anybody know what the error codes 36 and 37 mean, they are not
mentioned in the error code list in the manual.

Yours

Daniel
CapeFl schrieb in im Newsbeitrag:
506500000005000000852A0000-986697009000@quiq.com...
> Daniel,
> After reading all the attached comments, etc., I can empathize with
> your situation. I have seen similar symptoms with some Read/Write
> functions, where the delays put to the reading and writing often
> conflict with other delays such as loops, updating graphs, etc. - when
> on the same VI. One simple trick to consider is simply break up the 1
> large VI into separate VIs (1 for Read/Write and 1 for other misc.).
> Run both VIs at
the same time and share data through globals or files
> - but not allow one VI to have to wait on the other. With each VI not
> affected by delays in the other VI, you might see greatly improved
> speed. I don't have Labview 6 yet, which may offer other options to
> get around the data-flow processes. Just an idea - Doug.