Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Can NI-Device 1.01 & NI-VXI 3.2 co-exist on the same VXIpc872?
Ian Roberts
Member
07-29-2002 03:17 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
NI-Device 1.01 and NI-VXI 3.2 appear to be incompatible. Is there a solution or work-around?
This incompatibility manifests itself as a failure of the CGpibDevice::Initialize() function with error NIDEVICE_ERROR_INSUFFICIENT_MEMORY if NI-VXI 3.2 is installed on the system. The same call completes successfully when NI-VXI/VISA 2.05 is present instead.
My application needs to:
- Configure the GPIB interface to multiple simultaneous GPIB addresses, hence the use of version 1.01 of NI-Device.
- Perform block moves to and from a register-based VXI instrument without the occassional 'excessive PCI retry' (reported as 'access width not supported') errors that I was seeing with NI-VXI 2.05, hence the use of NI-V
XI 3.2.
Though I'm using HLA calls from the NI-VISA API to access the VXI instrument, I assume that the PCI retry errors that I was getting from NI-VXI 2.05 originate at the VXI driver level, so switching to either LLA fns, or the NI-VXI API (and sticking with version 2.05 of NI-VXI) wouldn't help me. Is this assumption correct?
(I like the way NI-VXI 3.2 has knocked 95% off the duration of my viMoveOut16() calls, so a solution which allows me to keep NI-VXI 3.2 would be much appreciated!)
This incompatibility manifests itself as a failure of the CGpibDevice::Initialize() function with error NIDEVICE_ERROR_INSUFFICIENT_MEMORY if NI-VXI 3.2 is installed on the system. The same call completes successfully when NI-VXI/VISA 2.05 is present instead.
My application needs to:
- Configure the GPIB interface to multiple simultaneous GPIB addresses, hence the use of version 1.01 of NI-Device.
- Perform block moves to and from a register-based VXI instrument without the occassional 'excessive PCI retry' (reported as 'access width not supported') errors that I was seeing with NI-VXI 2.05, hence the use of NI-V
XI 3.2.
Though I'm using HLA calls from the NI-VISA API to access the VXI instrument, I assume that the PCI retry errors that I was getting from NI-VXI 2.05 originate at the VXI driver level, so switching to either LLA fns, or the NI-VXI API (and sticking with version 2.05 of NI-VXI) wouldn't help me. Is this assumption correct?
(I like the way NI-VXI 3.2 has knocked 95% off the duration of my viMoveOut16() calls, so a solution which allows me to keep NI-VXI 3.2 would be much appreciated!)
Rodney_Greenstr
NI Employee (retired)
08-08-2002 07:44 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Yes, there is a workaround. We recently tracked the cause of this behavior down to a bug in NI-Device version 1.0.1. The bug was caused by an invalid parameter being passed into the construction of a semaphore object. The OS platform services that NI-Device relies on are shared by most of National Instruments' components. When you installed the latest version of the VXI driver, this component was updated. As it turns out, the updated version of our OS Platform services are not as forgiving as the version that was originally released with NI-Device. The solution requires an update of the NI-Device runtime engine. These binaries can be obtained by contacting the Technical Support team of National Instruments.
