viOpenDefaultRM command is locking up RF test system

[Papaiah K.]

In our test system we are using PXI chassis and a custom RF drawer that run on IVI driver. Test software contains a dynamic launch of a vi that has a visa reference node that talks to a com port. Launching of this VI is causing a search for all the Visa instruments then RFDrawer on the test system is resetting. following is the NISPY capture of releative area.

viOpenDefaultRM(0x5D9FF48)
viGetAttribute(0x05D9FF48,03FFF018F,VI_TRUE)
viGetAttribute(0x05D9FF48,0x3FFF0190,0)
viGetAttribute(0x05D9FF48,0x3FFF0190,4)
viFindRsrc(0x05D9FF48,"?*INSTR",0x05D9FF90,37,"COM1")
viFindNext(0x05D9FF90,"COM2")
.
.
.
.
viClose(0x05D9FF90)

I want to know why there is a search for all the instruments initiated and how o void it.

Regards,
Papaiah Kummari

[TongY]

Is the vi that talks to the COM port from your "test software" an executable? To make any changes of this vi, you will need to be able to edit it first. Is the "VISA reference node" a subvi? If so you should be able to open it and see what commands has been send to search for all the instrument and maybe take out that command.

There are different reasons that the vi does a search at the beginning, one is to make sure the devices are reset to their default states so they can be operated by the driver, also it checks to see how many supported devices are connected to the network and assign driver resources to them.

[Papaiah K.]

Hi Tony,

This VI is launched dynamically, and code is running in development enivironment. There is no command in the code that will check for all the instruments.From the visa resource, simple commands are being sent to a fan control unit. This fan control isconnected to a com Port on PXI chassis.

I read from NI's PXI related documentation, that when a visa resource session is opened, it will send the viOpenDefaultRM command. Since that command is forcing our custoom RF drawer to reset, I need to know a way to stop this command being sent.

Regards,
Papaiah Kummari

[TongY]

Well, the "viOpenDefaultRM" command creates a VISA session in the Default Resource Manager, this session is a logical identifier that will be passed to the subsequent driver vis so they know whom to operate on. That function did not send the commands to reset your device.

What's happening is in your driver, there is viWrite or viWriteAsync function that sends out the command "reset". This functions is called after all the viGetAttribute and viFindRsrc functions. You should be able to find it on the SPY capture file. This is the only way I know that will reset the device. The lines you have included from the SPY capture don't do anything to the device, they are called to gather information about the serial port and create a device descriptor.

If you have access to the source code of the driver, you should be able to find the line that does this viWrite and delete or comment out this line.

You can also take the complete SPY capture and post it here, make sure you expand the each column so we can see all the information.

[Noel]

It sounds as if you are using an IVI driver in addition to LV VISA calls to your instruments. The very first time LV encounters a VISA I/O Name Control, it calls viOpenDefaultRM() and finds instruments. As the previous responder indicated, this shouldn't cause your instrument to reset. Certainly the viOpenDefaultRM() shouldn't, but even finding the COM ports shouldn't. I'm guessing the VISA I/O Name control is wired to a VISA Open node, VISA Write, or VISA Read. Whatever it is wired might effect the COM port (if that is the resource you are interfacing with), but typically won't reset your instrument unless you are sending a reset command. Well, the IVI driver also makes similar calls, and it is possible you are resetting your instrument in the IVI driver's Initialize routine. If you indeed are mixing these calls, then you should probably Initialize your IVI driver BEFORE making any LV VISA calls.



A better approach is to only interface with your instrument through the IVI driver. If the IVI driver doesn't support all the commands you want to send to your instrument, you can still call the Write Instrument Data.vi and Read Instrument Data.vi. These are pass through VIs included in the driver to send arbitrary commands to the instrument and retrieve data from the instrument, but still within the context of the same IVI session you used to initialize the instrument.

[John F.]

Here is some additional information on the system configuration.

The IVI driver is used to interface with a device on the GPIB bus (RF drawer). The vi that is being launched dynamically uses VISA calls to interface with a serial device (fan controller).

The RF drawer session is opened first and the IVI driver does not reset the device. The vi for the fan controller is then loaded dynamically and the viOpenDefaultRM, viFindRsrc and viFindNext commands happen before any of the code inside the vi even executes. The vi has no interaction with the GPIB bus at all.

Once the fan controller vi is loaded, we return back to the IVI driver to start configuring the RF drawer. This is when the drawer resets. The only activity on the bus between the RF drawer initialize and its first configuration commands is related to the viOpenDefaultRM, viFindRsrc and viFindNext commands that LV is sending out. These are doing something funny on the bus that is causing a reset.