Activating tulip passport (GPIB) in MAX makes serial buffer flush fail?

[SteKo]

Hi,

I apologize for my english, it is not my native language.

My situation:
I use labview, and I want to measure voltage using a HP 34401A Multimeter with GPIB (using a agilent USB-GPIB adapter). Furthermore, I want to control a motor using the RS232 interface (ISEL motor control unit).
Therefore, I use the RS232 of the computer (on the Mainboard). Both tasks were developed separatly and work quite fine independly. My task is to join both parts and thats were I have the problems.


Problem:
Case 1:
In MAX, I activate the serial (NiViAsrl.dll) VISA passport (deactivate all others)
-> In Labview: all serial SubVI work fine.

Case 2:
In MAX, I activate the GPIB (NiVisaTulip.dll) VISA passport (deactivate all others)
-> In Labview: all GPIB SubVI work fine.

Case 3:
In MAX: I activate both at the same time
-> In Labview: the GPIB works well, but the serial SubVI not. The "VISA I/O Flush" VI says Error -1073807299 (invalid buffer mask).
Here's a link to that error: http://digital.ni.com/public.nsf/allkb/AD03F1520934D67F86256D4B001DC2CE
 
Of course I checked the mask and it is like it should be (16). And it is working again as soon as I deactivate the Tulip passport in MAX.


More Informations:
- It is only related to this GPIB passport in MAX, the GPIB device doesn't even has to be connected.
- The settings of the serial connection are default and as specified for the motor control unit.
- The effect also occures in minimal examples (init the device and directly try to flush)
- I tried a different computer with the setup and it fails too (same software involved, including any passports/drivers).
- I tried to reinstall labview and passports/driver, still the same.
- The Computer: Its a 64bit windows 7 enterprise, but a 32bit Labview 2014.


My guess:
The tulip passport messes around with the buffers and I am failing to find the option to change that.

I tried to search the forum as well as the internet but I wasn't able to find a solution. Any Ideas?

Best regards
SteKo

[Albert.Geven]

the deactivation of all other passports is fatal for what you want and is not needed at all.

Only when two passports want the same interface the other passport neeeds to be disabled.

I have now 20 years all passports enabled.

[SteKo]

Deactivating the passports were part of my troubleshooting. It doesn't work with all passports active either. 😕

[SteKo]

I've tried some more:

I used the VISA Test Panel (in MAX) on the COM1-Port to have a look if settings are changing when activating the GPIB passport.

I clicked on "View Attributes" and compared the values:

With Tulip passport deactivated: no errors

With all passports active: Several attributes show "Invalid Property Value" (Hex 0xBFFF001D), for example:
VI_ATTR_ASRL_DISCARD_NULL
VI_ATTR_ASRL_BREAK_LEN
VI_ATTR_ASRL_ALLOW_TRANSMIT
VI_ATTR_ASRL_WIRE_MODE
VI_ATTR_ASRL_BREAK_STATE

It seems like activating Tulip (GPIB) changes the attributes of the serial connection. I tried to set them manually in Labview (Property Node) but I get the error "Hex 0xBFFF001D" (something like resource doesn't support attributes). The errors disappear in Labview if I deactivate Tulip in MAX.


I don't even unterstand why tulib affect the serial interface at all.

[Albert.Geven]

you are right the tulip passport seems to mess up the serial settings. I'll check if there is another option. I always used an ni gpib card so I did not have this problem.
my native language is dutch

[SteKo]

I have done some more research:
the installation of the agilent GPIB passport (tulip) comes with the keysight IO library suit. There you have an IO Monitor and I watched whats going on:

It turns out, the commands for failing the RS232 connection have "Keysight VISA" as Source.

As far as I unterstand, the RS232 commands should have NI VISA as Source? I deactivated tulip, but the IO Monitor doesn't show anything now, I think its because this keysight IO Monitor is just for Keysight VISA. My conclusion so far: looks like this GPIB software has taken over control of the RS232 interface.

There are options for that in NI VISA (MAX) as "Conflict Manager". But there "ASRL1::INSTR" is already "National Instruments VISA" and "GPIB0::INTFC" is "Agilent VISA". I think thats how it should be? I also changed this options back and forth but it doesn't make any difference.

The "keysight connection expert" software (used to configure the GPIB-connection) recognizes the RS232 interface too; and there is a VISA conflict Manager as well. I set up the same settings there as well "VISA for ASRL1 is National Instruments VISA" and "VISA for GPIB0 is Keysight VISA". Makes no difference either.

Is there another setting somewhere to choose NI-Visa for the RS232 interface?

[Albert.Geven]

maybe the cheapest option is to use a usb to serial adapter and hope that the tulip does not interfere with that one.

I use the FTDI chip interfaces as they have been proven to work almost perfect, but I don't have the tulip software in use.

Even more I don't have the aglent keysight names conflicting, I still call them HP.

[SteKo]

I used an usb-rs232 adapter at the second computer I tried. Same problem. But it was a Prolific chip interface. It worked without tulip (so the adapter is working I guess). I will try to find a FTDI adapter on monday even if I think it won't be the solution.

The names are confusing, thats right. It took me some time to unterstand why I have to download keysight software to setup an agilent VISA passport for my HP multimeter. But do you think it could be a name conflicting in software? I am also surprised the keysight software call it keysight VISA while MAX called is agilent VISA.

[Albert.Geven]

that is a naming issue.
also the old agilent machines nnow have keysight stickers on it but depending on the firmware the still greet you from Agilent.

[David.Holst · Accepted solution]

hello @ all,

as a follow up to what we just did on site:

the problem appeared because the Agilent IO Suite caused some kind of driver issues. It seemed that it is not a LabVIEW problem but an Agilent problem. Instead of using the newest version, we switched to the "Agilent IO Libraries Suite v 16.2.15823.0". The valid question would be: why this version? Because this one was often used by me in other projects without any problems and the installer was available...

If someone is interested in digging deeper into the problem, feel free. For now, it seems that the older version gets the job done.

greetings from Berlin.

David