Hi,
in an older project we used a DLL containing the function SetPriorityClass.
This DLL works fine with NT. It was no problem to set VEE to "Realtime"
before the measurement starts and set it back to "Normal" after the
measurement. But don't forget to set it back.
Best regards
M. Bernhardt
-----Ursprngliche Nachricht-----
Von: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Gesendet: Mittwoch, 3. Dezember 2003 10:32
An: VRF
Betreff: [vrf] AW: RE: CPU Usage (was: Vee program sources)
> Stupid physicist I am, thought - better: hoped - that there might be a
> way to cheat any thread-handle or whatever is inside the f*... OS to
> disable the graphical engine for a short period of time or to claim
> full system resources for VEE while executing a well-defined piece of
> code.
Ahh, but being a physicist you have hit the nail exactly on the head and
somehow divined exactly the correct solution. There are two such functions
in kernel32:
int __stdcall SetPriorityClass(int hProcess, long dwPriorityClass);
REALTIME_PRIORITY_CLASS = 0x00000100
HIGH_PRIORITY_CLASS = 0x00000080
ABOVE_NORMAL_PRIORITY_CLASS = ?
NORMAL_PRIORITY_CLASS = 0x00000020
BELOW_NORMAL_PRIORITY_CLASS = ?
IDLE_PRIORITY_CLASS = 0x00000040
In NT, the handle must have PROCESS_SET_INFORMATION access (when using
OpenProcess to get the handle, specify at least PROCESS_SET_INFORMATION
access).
int __stdcall SetThreadPriority(int hThread, int iPriority);
THREAD_PRIORITY_TIME_CRITICAL = 15
THREAD_PRIORITY_HIGHEST = 2
THREAD_PRIORITY_ABOVE_NORMAL = 1
THREAD_PRIORITY_NORMAL = 0
THREAD_PRIORITY_BELOW_NORMAL = -1
THREAD_PRIORITY_LOWEST = -2
THREAD_PRIORITY_IDLE = -15
In NT, the handle must have THREAD_SET_INFORMATION access (when using
OpenThread to get the handle, specify at least THREAD_SET_INFORMATION
access).
Beyond the documentation of these functions, I don't know much about it. The
task scheduler is bizarre in the extreme to say the very least. I do know
from personal experience though that you should really think twice about
using REALTIME in either call. It can take a LONG time to do anything else
at all with the computer once these are in effect. That was on a mere 40MHz
processor though.
-SHAWN-
---
You are currently subscribed to vrf as: Bernhardt@somatec.de
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
in an older project we used a DLL containing the function SetPriorityClass.
This DLL works fine with NT. It was no problem to set VEE to "Realtime"
before the measurement starts and set it back to "Normal" after the
measurement. But don't forget to set it back.
Best regards
M. Bernhardt
-----Ursprngliche Nachricht-----
Von: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Gesendet: Mittwoch, 3. Dezember 2003 10:32
An: VRF
Betreff: [vrf] AW: RE: CPU Usage (was: Vee program sources)
> Stupid physicist I am, thought - better: hoped - that there might be a
> way to cheat any thread-handle or whatever is inside the f*... OS to
> disable the graphical engine for a short period of time or to claim
> full system resources for VEE while executing a well-defined piece of
> code.
Ahh, but being a physicist you have hit the nail exactly on the head and
somehow divined exactly the correct solution. There are two such functions
in kernel32:
int __stdcall SetPriorityClass(int hProcess, long dwPriorityClass);
REALTIME_PRIORITY_CLASS = 0x00000100
HIGH_PRIORITY_CLASS = 0x00000080
ABOVE_NORMAL_PRIORITY_CLASS = ?
NORMAL_PRIORITY_CLASS = 0x00000020
BELOW_NORMAL_PRIORITY_CLASS = ?
IDLE_PRIORITY_CLASS = 0x00000040
In NT, the handle must have PROCESS_SET_INFORMATION access (when using
OpenProcess to get the handle, specify at least PROCESS_SET_INFORMATION
access).
int __stdcall SetThreadPriority(int hThread, int iPriority);
THREAD_PRIORITY_TIME_CRITICAL = 15
THREAD_PRIORITY_HIGHEST = 2
THREAD_PRIORITY_ABOVE_NORMAL = 1
THREAD_PRIORITY_NORMAL = 0
THREAD_PRIORITY_BELOW_NORMAL = -1
THREAD_PRIORITY_LOWEST = -2
THREAD_PRIORITY_IDLE = -15
In NT, the handle must have THREAD_SET_INFORMATION access (when using
OpenThread to get the handle, specify at least THREAD_SET_INFORMATION
access).
Beyond the documentation of these functions, I don't know much about it. The
task scheduler is bizarre in the extreme to say the very least. I do know
from personal experience though that you should really think twice about
using REALTIME in either call. It can take a LONG time to do anything else
at all with the computer once these are in effect. That was on a mere 40MHz
processor though.
-SHAWN-
---
You are currently subscribed to vrf as: Bernhardt@somatec.de
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Not really- just set up the computer as the gateway. IO libraries
makes this very simple - no special code at all.
Stan
-snip-
Not Quite. When I was testing remote gateways using HP and NI GPIB cards,
only the HP/Agilent Cards supported the remote LAN feature, I go no response
from the NI Card. Could have been a function of the IO Libs(Rev G/H) at
that time. I have not revisited this since then. Otherwise, this is a
great way to share a GPIB network interface.
Mike
***********************************************************
Michael N. Asbery (202)404-3014, DSN 754
US Naval Research Laboratory fax (202)404-7661
Code 5733.20 michael.asbery@nrl.navy.mil
4555 Overlook Ave SW
Washington DC 20375
***********************************************************
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".