LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Recording from multiple serial ports causes slowdown

Hi,

I've written a VI that records from 2 serial ports in parallel. The program elements to write and then read both ports are all contained within a while loop. I'm using this VI to communicate with a basic force transducer and translation transducer. Every iteration, the vi sends a write command to both com ports, then reads a specific number of bytes from the com port. Using only one com port at a time I can read data from a device just fine. However, when I try and record from both com1 and com2 simultaneously, my VI slows way down (running at only a fraction of the speed it should run at). Is there anything I can do to make my VI run smoothly?

Thanks in advance.
0 Kudos
Message 1 of 8
(3,501 Views)
Hello-
You should put a small wait in your loops and read more bytes at a time. The loops are probably using up too much processor time because they are running continuously.
Ray K
NI Applications Engineer
0 Kudos
Message 2 of 8
(3,501 Views)
Thanks,

I'll give the wait a try. Is that just using a time function (i.e. Wait until next...)? However, I don't think that the vi is taking up too much system resources. I checked the Win2K task manager and at most there is 25% of the system resources being used during the running of my vi. I'm not that familiar with what goes on in the serial bus, but is that a serious data bottleneck?
0 Kudos
Message 3 of 8
(3,501 Views)
Four suggestions, ignore any you you want.

1)Use VISA.

2) Make sure have the latest and greatest VISA. There was VISA speed a while back.

3) Check the # of byte waititng only read that amount. Otherwise the read op continues to run until the bytes show up.

4) Make sure VISA read is done asyncronously. (over-simplification of rason is; syncronous calls stall each other. I THINK!)

Additional thought;
Make sure multi-threading is enabled.
Run reads in different threads (?).
If you are using sub-VI's that are not re-entrant, they will hang each other.
Violating 3 & 4 together is bad.

I hope some of this helps,

Ben

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 8
(3,501 Views)
Thanks Ben,

I'm pretty sure that I'm collecting only the bytes I need to read.
I am using VISA. I will check to see if the VISA reads are running asynchronously. I think they are. Can you explain to me what multi-threading is all about?

Thanks,

Jason
0 Kudos
Message 5 of 8
(3,501 Views)
What I meant by the read only those byte that are waiting, I meant that your code should loop checking how many bytes are at the port, and then read only that count in each call to the read function.

RE: Multithreading.

This warrants a study of its own.

LV can be set to run single or multi-threaded.

In single thread, the code behave as if it single sequence of steps where only one tasks is performed at a time.

In multi-threaded mode, the LC compiler will determine (based on data dependecies) what pieces of code can execute at the same time.

If your diagram has two serial port inits sitting one above the other, and they are not forced to execute( due to wires or structures) in any specific order (relative to each other) multi-threading c
an start up the init on one port and then sleep while the hardware responds. Meanwhile, the same init can be taking place on hte other port.

If single-threaded or if data dependencies exist, the first port would init, sleep waiting for hardware, then init second port sleep...

This explanation is far from complete.

I suggest a search or a formal question posted to this site will be more helpfull.

Trying to help,

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 8
(3,501 Views)
The info here was pretty loose, so I'll try to add some more data.

> RE: Multithreading.
>
> LV can be set to run single or multi-threaded.
>
> In single thread, the code behave as if it single sequence of steps
> where only one tasks is performed at a time.
>
> In multi-threaded mode, the LC compiler will determine (based on data
> dependecies) what pieces of code can execute at the same time.

Actually, switching from single to multithreaded doesn't cause the VI to
be recompiled, as the exact same code will be genereated either way.
The difference is in how the code is executed. In the single threaded
execution system, there is only one OS thread that is running diagrams.
It does coroutine between tasks, but only at prede
termined locations,
and only cooperatively. In a multithreaded execution system, there are
potentially multiple OS threads that can carry out diagram execution at
the same time. The threads can preempt one another at pretty much any
time and the OSes priority scheduler chooses which are active at any
given time. There is still cooperative scheduling going on as well in
case the multithreaded system only has one thread active.

For more information, you might try to find the NIWeek presentation on
the LV execution system by either Steve Rogers or Joel Sumner.

Greg McKaskle
0 Kudos
Message 7 of 8
(3,501 Views)
Thank you Greg!

Your clarifications and corrections are always welcome.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 8
(3,501 Views)