09-23-2021 02:50 AM
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.
Solved! Go to Solution.
09-23-2021 06:59 AM
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
09-23-2021 07:22 AM - edited 09-23-2021 07:23 AM
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.
09-23-2021 07:58 AM
@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).
09-24-2021 12:33 AM - edited 09-24-2021 01:20 AM
@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?
09-24-2021 02:11 AM
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.
09-24-2021 02:18 AM
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.
09-24-2021 02:20 AM
@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.
10-04-2021 03:02 AM
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!
10-04-2021 07:19 AM
"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.