LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Visa read 0 bytes

Solved!
Go to solution

Hi,

 

I have a six channel linear power supply (Multilinearnetzteilrack MLNG 6x 120W 60V 2A) and my colleague made a VI to control those channels. The thing is, when we switched from windows 7 to windows 10 the VI stopped working. The error we are getting is "1073807339 (0xbfff0015) Timeout Expired Before Operation Completed".

 

I tried VISA Interactive Control communication and it seems fine, see fig. 1. I checked all the setting, such as baud rate, parity, termination character (also in fig. 1). It is the same in the VI. The command "type?\r" gives a proper answer in Visa Control but not when I use it in VISA write and read in Labview. 

 

I made a clearer version of a VI to not bother you with unnecessary stuff, it is included in the attachments. The effect is the same. 

 

For me, it looks like there is a problem with the amount of bytes. Visa write is never the problem but Visa read is. I browsed the forum and I found hints, that there might be a problem with number of bytes expected by visa read. There is no difference when varying the timeout parameter. 

 

Thanks for any suggestion. 

 

 

Download All
0 Kudos
Message 1 of 12
(1,479 Views)

Changing from Win 7 to Win 10 does not change anything about your instrument's communications protocol.  But it very well *might* change COM port assignments away from what you expect.

 

And sure enough, your code shows a default value of COM9 while your VISA panel shows you using ASRL5 (which usually, but not always, will also be known as COM5).

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 12
(1,431 Views)

What Kevin said about checking your com port assignments.  Unplug your USB-serial converter.  Pull up MAX and expand the devices.  Plug in your device then refresh MAX (View -> refresh) and it should show up.

 

My guess is that you updated the computer at the same time as you did windows and the new one is faster.  . . Another thing that might have happened was that your computer is looking for a response before it is ready.  An easy way to see if this is happening is to click the light bulb to highlight operations.  That will slow down the program enough that if you need a delay it will work.  Alternately you can go to

 

Programming -> Timing -> StallDataFlow.vim and wire it in the middle of the error wire between the write command and read response.  Start with 1000 ms and slow it down until stuff doesn't work.  I am in the habit of putting either a 10 ms or 50 ms wait between write and read on serial devices.

 

PS Your init vi was missing try using a .llb file for posting software and thank you for not using LV2021 as I am still on 2019.

Message 3 of 12
(1,423 Views)

@Tom_Powers wrote:
I am in the habit of putting either a 10 ms or 50 ms wait between write and read on serial devices.

That is not necessary if the VISA timeout is long enough (in conjunction with the use of a termination character or you know exactly how many bytes are coming back).  However, the OP could be running into issues with the device not being able to process commands as fast as they are going in.  This is where a wait could be necessary (between VISA Writes).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 12
(1,412 Views)

@Tom_Powers wrote:

What Kevin said about checking your com port assignments.  Unplug your USB-serial converter.  Pull up MAX and expand the devices.  Plug in your device then refresh MAX (View -> refresh) and it should show up.

 


The printscreen shows COM9, but before every try I change it to COM5. It is a wrong default value. I checked it even with MAX and confirmed, that it is shown as COM5. 


@Tom_Powers wrote:

My guess is that you updated the computer at the same time as you did windows and the new one is faster.  . . Another thing that might have happened was that your computer is looking for a response before it is ready.  An easy way to see if this is happening is to click the light bulb to highlight operations.  That will slow down the program enough that if you need a delay it will work.  Alternately you can go to

 

Programming -> Timing -> StallDataFlow.vim and wire it in the middle of the error wire between the write command and read response.  Start with 1000 ms and slow it down until stuff doesn't work.  I am in the habit of putting either a 10 ms or 50 ms wait between write and read on serial devices.

 


I tried slowing it down with VISA instr. timeout and even when I set it to 10000 ms it still get stuck on VISA read. Even the lightbulb shows, that VISA write is ok but VISA read is not. 

 

Im adding here the init vi, sorry I forgot to include it. 

 

UPDATE: I tried deleting the init sub VI (which sets parameters before operation, such as maximal current, turn on/off channels and stuff) and set a 5000 ms instr. timeout for VISA read and write and the VI is working (see figure). 

 

I dont understand that. Is it bcs the init file includes a lot of Visa writes and the power supply does not manage to process all of them? 

 

Download All
0 Kudos
Message 5 of 12
(1,378 Views)

Just an idea - when initializing the VISA connection you have a termination character enabled - 13, i.e. carriage return. In the initalization VI in the library you add another carriage return "manually" for every command sent, i.e. one carriage return too many. Try disabling the termination character when initializing and see whether it will work then.

"Good judgment comes from experience; experience comes from bad judgment." Frederick Brooks
0 Kudos
Message 6 of 12
(1,349 Views)
Solution
Accepted by topic author Hirumaredx

 

I dont understand that. Is it bcs the init file includes a lot of Visa writes and the power supply does not manage to process all of them? 

 


This is indeed what happens, probably. You are sending 24 commands with no delay between each other.

It's weird that the device does not send any confirmation for those commands, but I guess it's so, since the code worked in the past.

Dont' forget that LabVIEW features arrays. Instead of dropping 24 times a Write, you could simply create an array of commands and send them in a very compact code, see below an example for the first three commands. This would make much easier to introduce a delay between them if needed.

 

loop.png



Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
Message 7 of 12
(1,346 Views)

@Dobrinov  ha scritto:

Just an idea - when initializing the VISA connection you have a termination character enabled - 13, i.e. carriage return. In the initalization VI in the library you add another carriage return "manually" for every command sent, i.e. one carriage return too many. Try disabling the termination character when initializing and see whether it will work then.


The termination character does not add anything on Write. It only instructs VISA that an input packet is complete when the character is received on Read.

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 8 of 12
(1,343 Views)

Hi, 

 

so after a short pause I experimented with larger delays in init VI and it solved the problem. I changed the old initialization VI with a new one where I set 100 ms after every write and now its working without problems. PC got a lot faster but the power supply did not and that caused problems. Thats why when I tried VISA Interactive Control and sent just one command I got a reply without problems but when I launched initialization of every channel with multiple parameters it went all south. 

 

I thank you guys all for trying to help me and for your insight!

 

0 Kudos
Message 9 of 12
(1,278 Views)

"It's weird that the device does not send any confirmation for those commands, but I guess it's so, since the code worked in the past."

 

This is not uncommon at all with serial devices.  For example MKS vacuum controllers all work this way.  There is no way of knowing if you selected the correct serial port, etc. without doing a read. It is not like GPIB were you get a talker no listener errors when something is not plugged in or you use the incorrect address.  I am pretty sure that this happens with GPIB because there is a two way handshake in the communication protocol where there is not with serial.

 

Also many of serial devices as well as way-old GPIB devices, etc. do not support the standard *IDN? command. 

0 Kudos
Message 10 of 12
(1,261 Views)