NI-488.2 v2.5, v2.6 and Windows Vista Power Management

[Sebastian1516]

National Instruments has dropped support for power management in NI-488.2 v2.5 and up. This is causing major problems for us since after system resumes from standby, most of our legacy applications have to be restarted and reconfigured. We do not have a source code for NI-488.2 handling in those applications and we can not reopen handle after system resumes. I do not understand why handle to NI-488.2 has to be dropped. Agilent IO libraries support new Windows Vista power management model without dropping the handle. I would like to use NI GPIB cards as NI provides more complete implementation of VISA. But power management issue is a deal breaker. If system is suspended while there is an active data transfer, last function call should return an error after system resumes. However the handle should not be dropped. Here is what NI-488.2 v2.5 readme file states:NI-488.2 for Windows, Versions 2.2 through 2.4.x, attempt to prevent the system from going to standby or hibernate if there is an application with an open NI-488.2 handle. To satisfy Windows Vista requirements, this has changed to no longer prevent the system from going to standby or hibernate. After the system returns from standby or hibernate, take the handle offline and open a new handle, because any subsequent calls from the previously opened handle will return the EPWR error code, except for ibonl 0. Can NI fix this issue? Thanks, Sebastian

[JasonSmith]

Sebastian1516,

I believe the basis of this decision was that ultimately it seemed unlikely that a user would want their computer to enter a low-power state while they were in the middle of controlling an instrument, because presumably the running application was doing something important that should not be interrupted. Were you happy with NI's solution to power management prior to version 2.5? If so, you can replicate this behavior by configuring the system to never go to standby or hibernate.

I would like to be able to understand your use case further. Could you take a moment to describe what type of application this is used in that is appropriate for standy or hibernation to occur while communicating with you instrument? Also, could you tell me which type of NI GPIB controller you are using (PCI-GPIB, GPIB-USB-HS, etc...)?

Thanks for your input,

Jason S.

NI GPIB Software

Message Edited by JasonS on 10-23-2008 08:42 AM

[Sebastian1516]

Jason,

Thanks for the quick reply.

Ultimately this is not about putting computer into standby while there is an active transfer in progress but rather doing so while application is idle and has an active session opened to NI-488.2. Our legacy application opens session to NI-488.2 when it starts and closes session when it shuts down. This application is no longer able to communicate with GPIB instruments after suspend/resume cycle and must be restarted.

Agilent’s SICL API and even their implementation of 488.2 API do not have this issue. Handle is maintained through suspend/resume cycle (I verified this with their 82350B PCI card).

In previous revisions, NI’s API just blocked suspend. I think this was actually a worse solution. Apparently, so did Microsoft by eliminating QUERY_SUSPEND.

The legacy application is HP Basic 6.33. It has GPIB drivers for either HP/Agilent SICL or NI-488.2. Once the driver is loaded it opens session to the selected API. There is no way to reopen session without restarting whole application. HP Basic is being phased out but we have hundreds of programs written for it and we need to maintain compatibility. These programs require some time to configure and input all the data. It is therefore inconvenient to restart program every morning. Using standby alleviates this problem. We would like to avoid leaving computers on overnight.

We have NI GPIB-USB-HS, PCMCIA-GPIB, and PCI-GPIB cards.

I would like to use more of your hardware but this power management issue has to be resolved first.

Thanks.

[JasonSmith]

Thanks for your input. We have had many discussions regarding power management, and I can see that in a situation such as yours it would probably be safe to allow the same handle to be used after a power resume. Unforunately there are many cases with GPIB where it would be extremely difficult if not impossible to allow such a solution to work seamlessly with customer applications.

Given that a low-power state may be entered at any time, we would need to ensure proper operation if a suspend occurred for any GPIB configuration during any type of operation. This is really not possible, because there is no way for us to know if the sudden interruption of the driver could leave attached instruments and devices in an unnown state which could prevent proper continuation of the application.

In the case where you can guarantee that the application is absolutely idle when standby is entered, the resume would be safe. In any other case, the proper approach would be for your application to detect that the system has temporarily lost communication with the bus (through detecting the EPWR command), and re-initialize all components of the system.

I know that this is not an option for you at this time, but your use-case is somewhat unique in that you want to enter a power managed state while your application is running. As I have previously mentioned, for most use cases this is not practical or desireable. For now I would recommend that you avoid placing the system into standby or hibernation, and instead leverage the less intrusive options to turn off your monitors and hard disks after a period of inactivity. I would also welcome you to submit your suggestion to our online suggestion center so that it can be logged for future consideration.

Thanks,

Jason S.