LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Direct port accessing Win9x

I have a proprietary PC IO card for which I was able to obtain
programming information from the manufacturer. However, how do I gain
direct access to an IO port under Win9x? Are there any standard dlls to
do this?

TIA,

Rudolf
0 Kudos
Message 1 of 12
(3,910 Views)
in win9x you have inport and outport available. They should work, if your card is not addressed via memory locations.
In winnt and win2k you have extra troubles because there the default in/outport don't work
greetings from the Netherlands
0 Kudos
Message 2 of 12
(3,910 Views)
I have the same issue but my card needs to run on XP.  Tried using InPort & OutPort vis in LV 8.5 but it does seem to work.  Anyone know how to do this?
Message Edited by Gripster on 03-11-2009 08:02 AM
0 Kudos
Message 3 of 12
(3,639 Views)
You should start here: Accessing Hardware Registers and Physical Memory in Windows NT/2000/XP with LabVIEW. You should also perform a search for "accesshw" or "accesshw.dll".
0 Kudos
Message 4 of 12
(3,629 Views)
Another option is to use NI-VISA.
0 Kudos
Message 5 of 12
(3,626 Views)
Ok, I'll try these. OBTW I have tried openG's portIO.llb w/o success.
0 Kudos
Message 6 of 12
(3,615 Views)
Tried NI-VISA driver wizard.  It created an .inf & .PNF.  XPe does not see the h/w nor seems to do anything with the .PNF.  I can't find any way to locate it with MAX either. Smiley Sad
0 Kudos
Message 7 of 12
(3,603 Views)

Gripster wrote:
I have the same issue but my card needs to run on XP.  Tried using InPort & OutPort vis in LV 8.5 but it does seem to work.  Anyone know how to do this?
Message Edited by Gripster on 03-11-2009 08:02 AM

The inport/outport VIs in LabVIEW 8.x and even 7.x should simply work in NT based systems since they access a device driver that gets installed with LabVIEW. The OpenG VIs work similar. If it does not seem to work there are two possibilities.

 

Either you have a card that is using port IO addresses above 0x1000. While it should work with the methods used in inport/outport as well as the OpenG VIs, there seems to be a problem in accessing port addresses above that limit for some reason.

 

Or there is a kernel device driver already installed that controls and virtualizes those addresses. A kernel driver can grab access to certain port addresses and request Windows to always call the driver instead of trying to access those addresses directly. This can be for instance used to virtualize a COM port that is really residing in an USB device and therefore does not physically map into the standard port addresses for COM1 or COM2. A nice idea in theory but in practice it often does not work since emulating the operation logically is often not enough and the delays caused by emulation can mess up timings that programs accessing registers directly, usually are very critical about.

 

Rolf Kalbermatter

Rolf Kalbermatter
My Blog
Message 8 of 12
(3,602 Views)

Thanks Rolf,

More about this board;  I use I/O memory from 300h to 340h w/o using any interrupts.  It is a board I designed back in the good old days on a W95 PC104 embedded PC.  The board decodes I/O memory address (A0 thru A9), via IORD & IOWR using a PLD byte reads & writes. Now trying to run on an XPembedded PC104 PC.  When I view the IO resources in device manager I see nothing mapped in this range.  If you think the OpenG VIs should be working I start looking more closely at the h/w if I can dig out the old schematics.

 

About your OpenG 'port io' VIs and since I'm using XPe.  Is there any chance I don't have the proper windows driver(s) included in the OS build.  I've tried the port IO enable to enable 300-340, port io get version,  install driver (but I don't know what it's doing),  port io write & port io write byte (which looks like the same thing as port io write?).

 

Any ideas?

0 Kudos
Message 9 of 12
(3,589 Views)

Gripster wrote:

Thanks Rolf,

More about this board;  I use I/O memory from 300h to 340h w/o using any interrupts.  It is a board I designed back in the good old days on a W95 PC104 embedded PC.  The board decodes I/O memory address (A0 thru A9), via IORD & IOWR using a PLD byte reads & writes. Now trying to run on an XPembedded PC104 PC.  When I view the IO resources in device manager I see nothing mapped in this range.  If you think the OpenG VIs should be working I start looking more closely at the h/w if I can dig out the old schematics.

 

About your OpenG 'port io' VIs and since I'm using XPe.  Is there any chance I don't have the proper windows driver(s) included in the OS build.  I've tried the port IO enable to enable 300-340, port io get version,  install driver (but I don't know what it's doing),  port io write & port io write byte (which looks like the same thing as port io write?).

 

Any ideas?


How would you suppose the Windows device manager to know about your hardware? Since it is self built and for the ISA bus (PC104 is simply ISA) I doubt you have implemented any ISA PnP circuitry in that device. Windows does have some auto detection built in for non PnP devices but your self made device obviously can't be autodetected since there is no way for Windows to know that there is something.

I'm not sure about XP but in older versions of Windows you could add custom resources to the device manager to be considered used by non-PnP compatible devices. In XP the only way to do that might be by creating an INF file.

 

I'm not sure if it is possible under XP to access hardware resource that the system might not know about. It could very well be that it employs some protection scheme that filters any access to unknown system resources as suspicious activity and simply denies it without any error.

 

The OpenG Port IO VI's come with their own device driver that should be compatible for all Windows versions up to XP and possibly even Vista. This driver has to be installed, which the user space DLL will attempt to do on first run if it can't detect the driver in the system. For this to work you do have to be logged in with administrator privileges as otherwise the device driver installation will fail. Install driver does the same but explicitedly but as I said the other functions should attempt to install it automatically if they can't detect it.

 

The Port IO Write is the polymorphic wrapper around the various Port IO Write (<type>) functions. If you open it it will usually come up with the first polymorphic version which happens to be Byte. Place the Port IO Write (without type indication) on a diagram and right click it. There you see a Select Type entry in the pop-up menu. Here you can select which datatype access you want to execute. This can be handy if you happen to read word registers and such.

 

Rolf Kalbermatter

Rolf Kalbermatter
My Blog
0 Kudos
Message 10 of 12
(3,574 Views)