OpenG PortIO throws error with no description

[Eric.Craaybeek]

A co-worker and I have been porting some drivers for a custom controller that uses a special protocol on a LPT port.

We have the port working on one PC using the OpenG PortIO library. Previously we used "Out Port.vi" and "In Port.vi" drivers which I believe are no longer supported.

When we try to run the same code on a different PC the OpenG library throws an error 1275. But it doesn't give a description of the error. This makes it very hard for us to determine what is causing the error and how we should correct it.

Is there a description of error codes from this library? If not does anyone know what error code 1275 means when coming from the OpenG port IO library.

The error is specifically generated when we try to use both "PORT IO Enable Range" and "Port IO Write Byte"

 

Any help would be greatly appreciated. Thank you!

[dadreamer]

I'm sure, Rolf as the original author of this library will definitely give you a detailed answer about this issue. I would just ask, whether it's the case of calling the library in 64-bit LabVIEW or on 64-bit Windows. Because if yes, then it's not going to work - both ogportio.dll and ogportio.sys are 32-bit in the 4.x release dated 2011 and I don't see anything freshier.

As to 1275 error - if it is a WinAPI error code, then its description should be something like this (according to MSDN) :

Quote

ERROR_DRIVER_BLOCKED

1275 (0x4FB)

This driver has been blocked from loading.

You might try disabling driver signature enforcement to overcome this.

Edited January 19, 2021 by dadreamer

[Eric.Craaybeek]

It is indeed calling the library from 64-bit LabVIEW on 64-bit windows.

I'll assume this driver won't work in this case.

Thank you for your help!

 

Just out of curiosity do you know of any other libraries that would allow register level access to a LPT port on 64-bit windows?

[dadreamer]

Just now, Eric.Craaybeek said:

Just out of curiosity do you know of any other libraries that would allow register level access to a LPT port on 64-bit windows?

I used InpOut32 / InpOutx64 few times in the past. It's very simple to use, because the sys driver is already integrated into the dll and is extracted automatically upon a call, so the user has nothing to do besides calling the functions. But I have never tested it in Windows 10 and absolutely unsure, whether it will work or not. I see that the authour has obsoleted that project due to the need of signing, so no guarantee here. Also see the known issues in red. Moreover you might give a try to WinIo or NTPort , even though they are not so convenient to use. I did use WinIo before InpOut and it is signed with a self-signed certificate and can only be used when Windows is running in a "test" mode (when driver signature enforcement is disabled). I did not have any experience with NTPort, because it's rather old and shareware.

upd:

By the way, I've found my old speaker test, based on InpOut library. It still appears to work even on Windows 10 and LabVIEW 2020 (both 32- and 64-bit). I'm attaching it "as is" - for 32-bit LabVIEW currently, but you may easily switch to 64 bits by changing the CLFNs to inpoutx64.dll and placing this dll into data folder. If you have a motherboard built-in speaker, you'll hear the beeps, when pressing the gray button (excuse me for non-English UI).

Speaker_lv8.6.rar

Edited January 19, 2021 by dadreamer
attached InpOut example

[Rolf Kalbermatter]

18 hours ago, dadreamer said:

I used InpOut32 / InpOutx64 few times in the past. It's very simple to use, because the sys driver is already integrated into the dll and is extracted automatically upon a call, so the user has nothing to do besides calling the functions. But I have never tested it in Windows 10 and absolutely unsure, whether it will work or not. I see that the authour has obsoleted that project due to the need of signing, so no guarantee here. Also see the known issues in red. Moreover you might give a try to WinIo or NTPort , even though they are not so convenient to use. I did use WinIo before InpOut and it is signed with a self-signed certificate and can only be used when Windows is running in a "test" mode (when driver signature enforcement is disabled). I did not have any experience with NTPort, because it's rather old and shareware.

upd:

By the way, I've found my old speaker test, based on InpOut library. It still appears to work even on Windows 10 and LabVIEW 2020 (both 32- and 64-bit). I'm attaching it "as is" - for 32-bit LabVIEW currently, but you may easily switch to 64 bits by changing the CLFNs to inpoutx64.dll and placing this dll into data folder. If you have a motherboard built-in speaker, you'll hear the beeps, when pressing the gray button (excuse me for non-English UI).

Speaker_lv8.6.rar 54.26 kB · 2 downloads

The internal kernel APIs used by the OpenG PortIO kernel driver were discontinued by Microsoft in 64-bit Windows. By the time I looked into this Microsoft also had started to require signing for kernel drivers to be installable. I have no interest to buy a public certificate for something like 100$ a year just to be able to sign an open source driver.

That extraction of the kernel driver from the DLL is in theory a neat idea but in practice will only work if the user executing that function has elevated mode. Otherwise kernel driver installation is impossible.