LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Aeroflex 2975 driver for LabVIEW 8.0

Is there a way to convert the Aeroflex IFR 2975 driver for LabVIEW CVI for use in LabVIEW 8.0?  OR, is there a driver already developed for this? 
0 Kudos
Message 1 of 6
(2,978 Views)
Yes you can directly convert the CVI driver to a LabView driver which basically creates a wrapper around it. I did convert this very same driver in LabView 7.1 and have up converted it to 8.0.  In 7.1 it was under tools>>instrumentation>>Import CVI driver. I could not find this tool in LabView 8.0 but if you search help for convert LabWindows driver it states "Download the LabVIEW Interface Generator for LabWindowsTM/CVITM Instrument Drivers tool to obtain this functionality." Just a note here if you are planning on controlling this instrument using GPIB. It does not seem it is 488.2 compliant. I've been using this driver for 3 years now and I still get errors because there is no handshaking between the instrument and the controlling computer. I have been in contact with this company trying to get this resolved (I just sent them alot of info about this yesterday). Even though some progress has been made on these problems they are not included in that driver. I have been working to create a new driver using the TCL command set but am having problem with the MAV(Message Available) bit. They finally asserted (logic hi) it when the data buffer is ready to be read but did not provide a way to deassert it(logic lo).So once it goes hi it stays hi. Not very useful for handshaking. They should have at least included a *CLS command to clear the it but have not. As you can tell I am not very happy with this company. When they say in their ads that the instrument is 488.2 compliant I expect it to be. If you want more details on how I got this driver to work at all post back and I'll fill you in.
Now Using LabVIEW 2019SP1 and TestStand 2019
Message 2 of 6
(2,973 Views)
Thanks GovBob.  I tried to use the LabVIEW Interface Generator for LabWindows/CVI Instrment Drivers, but it did not work.  The message said the version of the file is too low.
Additionally, I have tried to work with Aeroflex about getting something that will work with GPIB, but I have not received very helpful information.  I'll keep looking for something that will work.
0 Kudos
Message 3 of 6
(2,956 Views)

Frank,

 I am using the LV 7.1.1 version of this CVI driver in an application I wrote. We should be able to recompile this for 8.0. Basically as I explained with no handshaking the instrument falls out of sync with the controlling computer. Basically the only GPIB command that is supported in that driver is *IDN?. So what I have done is after other  calls I use this command and compare the return string to see if it is what I expected. If not I use a popup telling the operator that a GPIB error occurred and to reboot the IFR to clear the bus. I also have instructed the operator to run NI Spy in the background...this seems to cut down the occurance of these errors. Another way to clear the bus that is faster and usually works is to stop the application, and read the bus using MAX until you see a timeout when there is no more data available( usually twice). Then rerun the application. Depending on the application this might be a work around though not an elegant one.

 Since the driver was converted from a CVI driver it uses the call library function node. This does not allow us to control the timing between the Write functions and Read functions. If you are doing something that is relatively simple you could use the TCL command set and VISA to write a driver. Just put a wait function between the Write and Read function and experiment with the timing until it looks like it won't fail. I've considered doing this myself but have been hoping that they will actually make the instrument 488.2 compliant. I am assuming that the actual error is that the data buffer is being read by the controller before the instrument is finished writing to it. The other scenario is that the data buffer might not actually be getting flushed every time it is read. I'm hoping my first assumption is correct or they have even more problems with the instrument.

 In January of '05' they actually enabled the following commands *SRE xx, *SRE? and *STB?. I recently wrote a simple vi to see what happens to the Status Byte after using IDN? command and reading the data buffer. The MAV bit begins logic low, then goes hi when the data is available. After reading the data (i.e. "IFR Systems, 2975.....) I again query the Status Byte. The MAV bit is still in a logic hi state. I sent screenshots of the front panel and block diagram as well as the .spy files to them. All was heavily notated and they said they were going to look at it. If anyone is interested in this I can post this code as well.

Now Using LabVIEW 2019SP1 and TestStand 2019
0 Kudos
Message 4 of 6
(2,949 Views)
Is there a copy of the driver converted to LabVIEW 7.1 available, or do I need  to see if I can get a copy of 7.1 for the first conversion? 
0 Kudos
Message 5 of 6
(2,927 Views)

Here is a copy of the driver which I beleive is in 7.1. It contains the dlls from the LabWindows CVI which the VI's depend on.

I have been in contact with the manufacturer of this instrument and are in negotiations to get them to comply with 488.2. If I receive any good news I'll let you know.

Now Using LabVIEW 2019SP1 and TestStand 2019
0 Kudos
Message 6 of 6
(2,922 Views)