VISA Write differs between TS Development System and LV Run-Time Engine

[JPLO]

Hi all

I made an application on LabVIEW to test BERs (Bit Error Rates), and I used VISA Write between two COM ports to exchange data.

Everything works fine using just LabVIEW.

Afterwards, I used TestStand to call my application (VI). The LabVIEW adapters from TestStand were set to Development System by default, and everything works OK!!

Finally, I needed to disable the development system, and set the LabVIEW adapters from TestStand to LabVIEW Run-Time Engine and I notice that the speed of the data exchange between the two COM ports decreased dramatically.

The only difference was the speed...because all the data (changed slowly in this case) arrived correctly on the other COM port too.

The symptom was the same as decreasing the baud rate...but the baud rate and all the other configurations remained the same. The only difference was the change between Develpment System to Run-Time Engine to notice this decreased speed between the exchanged data using VISA Write.

Any solutions for this?

Thanks in advance

Joao

[ChristopheS.]

Hi Joao, 

The test you have done is very interresting. Now it's important to determine if the issue is on the execustion of the differents TestStand step or in LabVIEW. 

For this can you said me if you have disable the step tracing on the station option :

Can you post a simple project (sequence and VI), with the entire project I can try to reproduce the issue.

Best regards,

[Norbert_B]

Joao,

you state that using the LV Developement System as execution platform for your LV code modules result in faster datatransfer between the COM ports than using the LV Run-Time Engine.

So i am pondering: Does this refer to TS at all?

Please check the following:

Run you communication using a sole LV application in LV Developement System. This should be fast. Now build an executable of this application and run that one. Do you see the same behavior?

If there is no difference in a sole LV approach, there have to be some settings in the TS approach making this slow. So please let us know:

Are there different modules involved in that data transfer (which in fact points to the reply Christophe made)?

What about loading/unloading options of the modules?

How big is the hierarchy of the modules, e.g. is it necessary for the RTE to load stuff the Dev Env has already in memory due to loading a lvproj.......?

Could you provide a simple example sequence+modules showing this behavior?

What versions of LV and TS are you using?

hope this helps,

Norbert

[JPLO]

Hi Norbert and Christophe!!

Thank you both for your answers and suggestions! 🙂

I didn't said anything earlier because I'm still running a few tests regarding this subject. Tests like you said, using an executable instead of using TS with LV.

I will test an executable called by TS too, and check if the same behaviour happens.

Norbert, I have set TS to load up to memory only the VIs from LV that are going to be called, not the entiry project (all the VIs). Therefore, I think that there will be not too much VIs in memory...

But the hierarchy of the modules is quite big...and the test ifself (B.E.R.) takes a little while (about 15/20min).

I'm using LV 2009 Service Pack 1 and TestStand 4.2.1.

Cristophe, on Station Options I have enable tracing TRUE, and the speed set to FAST.

Thank you again,

João

[ChristopheS.]

Hi,

So could you test to disable tracing option.

Regards,

[JPLO]

Ok Christophe!

I will!! Thank you!

[JPLO · Accepted solution]

Hello all!

I'm sorry, i forgot to answer this thread...

The solution was changing the VISA WRITE mode from "asynchronous" to "synchronous" to reserve a thread just for VISA WRITE.

The problem here, was something like this (?): TestStand was using all the available threads, and when we wanted to use VISA WRITE, the thread was busy and VISA would wait until the thread gets free. After changing to syncrhonous, there was a dedicated thread for this process (?).

Now, everything works the same using LabVIEW Run-Time Engine or Deployment System.

Thanks for the help Christophe and Norbert 🙂

João