"Remote" state after application finishes

[Michael Heimann]

I have a problem when porting a CVI6.0-VISA-GPIB application from Windows NT to XP.
I noticed a device stays "Remote" after finishing the application under NT because REN is still asserted. With XP it swiches to "Local" automatically when the application ends. How can I prevent this?
Background: The application has a commandline interface and is only executed for certain actions, but the instrument should stay in "Remote".
Thanks for answers in advance!
Michael Heimann
Rohde & Schwarz, Germany

[Ray K]

At the end of you program, call
int board;
board = ibfind("GPIB0");
ibsre(board,1);
ibonl(board,0);

[GPIB_Guru]

From my impression, the XP behavior is the correct behavior. Once a system controller is taken offline, it should no longer assert the REN line. Once the REN line is deasserted, the device should enter Local state. I am guessing that this is a bug in the NT driver where the hardware is not properly taken offline.

If you really want your device to stay in remote mode (for the life of me, I can't figure out why since you are no longer programming it remotely), you could manually ground the REN line on the GPIB cable to keep it physically "asserted" even when the controller is no longer driving it.

Question: Once you run the application again, it should place the device back into remote state. Does it?
Question 2: Since I can't think of a reason, maybe y
ou can tell me why you want the device to stay in remote mode when you are not actively talking to it?

Thanks!

[ndiamond]

Hey, I'll take Question 2 for 10,000 yen.

> Since I can't think of a reason, maybe you can tell
> me why you want the device to stay in remote mode
> when you are not actively talking to it?

If the device is an ATM (of the banking variety) and the connection to the system controller goes down, you don't want local mode to take over and operate the cash dispensing mechanism. You might not mind too much that persons nearby might be able to turn off power to the device, and you might have already accounted for the possibility of power tools being used in order to steal the entire device, but still you don't want to make it easy for local operations to take over.

Although I'm not the original poster, I agree with your suggestion to manually ground
the REN line when desired. Such a design would make it obvious that this effect was intended, regardless of which driver is correct.

[Michael Heimann]

Hey Guru,
I don't want to start a discussion about whether a programs behavior is a bug or feature. If your used to live with a special behaviour (since WIN31..), a change is sometimes bad.
I don't like the idea of soldering a special adapter.
Another workaround (which has its disadvantages) is to start a process at windows startup that does nothing but opening a Session handle and not ending forever.
Question 1: O.K:
Question 2: There are devices (as the Radio Communication Tester R&S CMU200) that change their signal output when switching to local. As I wrote in the question, the application is a command-line tool which is called as an external process to change some settings and then returns to the calling (Non-GPIB) application.
Regards
Mi
chael

[Michael Heimann]

Thanks for your understanding!
Michael

[Michael Heimann]

Hello Ray,
sorry this seems not to help. VISA seems to release REN in the moment where all applications "release" the DLL. The trigger seems not to be the Close command. Or what am I doing wrong?
Thanks anyway.
Michael

[GPIB_Guru]

Whether a change is good or bad is generally dependent on the end users point of view :).

The workaround you mentioned would work as well, since the hardware will not be taken offline if an active session is still open.

The soldering effort is not too big of a problem. NI does sell some GPIB Adapters (http://sine.ni.com/apps/we/nioc.vp?cid=1899〈=US) that can be fitted at the end of your cable. You would just need to connect (don't take my word for it, please verify) pin 17 (REN) to pin 18 (Gnd).

If I think of any other workarounds, I will let you know, but my current thoughts are that these are the only two workarounds.

[LXforster]

NI-488.2 version 2.x resets the TNT controller ASIC when the last handle gets closed, taking the GPIB board offline. When taking the board offline, the controller will no longer drive any lines, including the REN line. This is a change from the 1.x architecture. If the board is not taken offline, it can disrupt other communication on the bus. For the bus to maintain a certain condition, a handle to the bus needs to remain open with that condition set. If you want the device to remain in remote mode when it is not controlled remotely anymore, you need to do something "special", for example, grounding the REN line or leaving a handle open.