How do I get Pci Parallel Port I/O range ?

[Shako]

Hi Wally

You could use the VISA library for what you are trying doing.

You will then use viWrite() and viRead(). 

There is some topics about VISA in this forum.

But i would also like to know how to use CreateFile() and SetCommConfig() when dealing with Parallel Ports.

[wally_666]

I've no idea how to use the VISA library, I try to avoid using things that aren't likely to be available in the Linux version of CVI, so I've never used any or it.

Library->VISA->Resource-Specific Operations->Interface Specific Operations brings up USB Conrol In and Out options which  bring up viUsbControlIn() function panel but I've no idea what to use for the various parameter fields.

I have been playing around with the Win32 SDK calls.

port = CreateFile("PortName", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);

succeeds if PortName is COM1 or LPT1 ("standard" hadware that is on the motherboard) and fails if its USB001 (the "virtual" port name that appears in the Add Printer Wizard port selection dialog for a local printer).

GetCommState(port, &dcb);

The dcb structure is filled with the expected stuff for a serial port, and is all zeros except for the DCBlength and fBinary  fields for LPT1.

This approach would appear to be a dead end.

[wally_666]

Just to follow up,  I installed an old Epson printer on the USB adaptor and a test page printed fine.  So the USB001 virtual port works for whatever "Add Printer" wizzard does, but not for CreateFile().

[dummy_decoy]

the documentation for CreateFile() as well as the documentation about communication resources explicitely talks about adding "\\.\" in front of the port name (which, once escaped correctly, gives "\\\\.\\"). give this a try.

[wally_666]

---

dummy_decoy wrote:

the documentation for CreateFile() as well as the documentation about communication resources explicitly talks about adding "\\.\" in front of the port name (which, once escaped correctly, gives "\\\\.\\"). give this a try.

---

None of the MSDN examples actually used this on COM or LPT ports, and my test code clearly didn't need it;  but it was easy enough to try on the USB virtual port.  Unfortunately,

CreateFile("\\\\.\\USB001", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);

still ends up returning INVALID_HANDLE_VALUE.

I'm open to trying any other suggestions, as Google and stumbling around the MSDN docs haven't gotten me any other things to try.  A reasonably simple way of setting the eight USB parallel printer port's data lines (that doesn't filter out 0x00, or "translate" other bit patterns) and reading the five printer status lines would be generally very useful for "human speed" input and switching control tasks that are easily done using inp(0x379)  and outp(0x378, bits) functions with the legacy motherboard port (I had to search to find a printer that actually connected to the old "Centronics" LPT interface, which is why it makes sense for the port to go away as its original purpose is largely gone).  But this doesn't change the fact that a simple DIO port that one could count on being there is still tremendously useful 

These "abuses" of the LPT port have worked well for years but the parallel port hardware is going away as are PCI slots for adding them -- I'm not seeing a lot of mother boards on display at Fry's with more than two PCI slots lately!  I've some  Linux applications that absolutely require four PCI slots: two frame grabbers, A/D D/A PIO multi IO card, and an IRIG timecode board.

[dummy_decoy]

(WYPHALATM ? (Would You Please Have A Look At The Manual ?) here is the doc for Create File(), which talks about "\\.\" in the "Communications Resources" paragraph... if the sample code covered every possible cases, then we would only have 2 keys on our keyboards: ctrl+c and ctrl+v)

anyway, the printer wizard is not a good way to get the port name: the port name you are reading there comes from the usb port monitor (called usbprint). the real port name should appear in the device manager along with the onboard lpt port or the com port. the CreateFile() and WriteFile() method is fine only for data output, not for status line readback. i think you can read the status lines using a DeviceIoControl() call.

as a side note: i will repeat that a parallel port is not a dio port. and if you lack some pci port, NI makes some very good USB-DIO devices. also, there is absolutely no problem at getting a motherboard with 4 pci slots: just don't buy at Fry's  (i can even find you a motherboard with some ISA slots if you like). the same advice goes for the number of parallel ports...

[wally_666]

---

dummy_decoy wrote:

(WYPHALATM ? (Would You Please Have A Look At The Manual ?) here is the doc for Create File(), which talks about "\\.\" in the "Communications Resources" paragraph... if the sample code covered every possible cases, then we would only have 2 keys on our keyboards: ctrl+c and ctrl+v)

anyway, the printer wizard is not a good way to get the port name: the port name you are reading there comes from the usb port monitor (called usbprint). the real port name should appear in the device manager along with the onboard lpt port or the com port. the CreateFile() and WriteFile() method is fine only for data output, not for status line readback. i think you can read the status lines using a DeviceIoControl() call.

as a side note: i will repeat that a parallel port is not a dio port. and if you lack some pci port, NI makes some very good USB-DIO devices. also, there is absolutely no problem at getting a motherboard with 4 pci slots: just don't buy at Fry's  (i can even find you a motherboard with some ISA slots if you like). the same advice goes for the number of parallel ports...

---

RTFM:

lpFileName [in]

   The name of the file or device to be created or opened.

   In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the

   Unicode version of the function and prepend "\\?\" to the path

I'm using the ANSI version of this function.

more RTFM:

The CreateFile function can create a handle to a communications resource, such as the serial port COM1. For communications resources, the dwCreationDisposition parameter must be OPEN_EXISTING, the dwShareMode parameter must be zero (exclusive access), and the hTemplateFile parameter must be NULL. Read, write, or read/write access can be specified, and the handle can be opened for overlapped I/O.

To specify a COM port number greater than 9, use the following syntax: "\\.\COM10". This syntax works for all port numbers and hardware that allows COM port numbers to be specified.

I don't see any mention of LPT ports in these docs, but I have verified that the CreateFile() succeeds on the COM1 or LPT1 (without the \\.\) that exist in my device manager listing.  Unfortunately the USB parallel port adaptor I have doesn't create a device that shows in device manager.  Perhaps that is *the* show stopper.   I'd read these perls of wisdom before I posted about my attempt to use "USB001" port.

Your other comment ignores my meta-problem (which of course you had no way of knowing about), which probably doesn't affect most developers -- it takes typically eight weeks or more to buy anything, maybe two or three if I do a lot of extra work for a "RUSH" order.  The need to add a couple of extra DIO bits as a project evolves through its lifecycle is common enough I have always tried to keep the motherboard LPT port in reserve at the start.  The short life cycle of commodity PC parts is a problem for long lived "embedded PC" projects, the near extinction of the parallel port from notebook computers means its just one trick I can no longer count on using.  I'd be thrilled if we could figure out how to make these USB parallel adaptors return its viability.

Of course if money is no object, there are plenty of "industrial PC" companies that will sell you DOS era hardware at 1990's prices.  I get paid enough that eating the cost of a USB parallel port adaptor to quickly solve a lack of a few DIO bits problem would be viable if it worked .  I happen to have one left over from the "old days" and I was motivated to dig out and play with it by this thread as one of my current projects suffers the lack of a few DIO bits problem.  I'll likely solve it with an old PCMCIA DAQcard I have laying around.  OTOH, I'm not willing to eat the cost of anything National Instruments sells.

I can't  find any mention of control codes for LPT ports in the list of control codes for DeviceIoControl().   Under "Communications Control Codes" the only thing listed is: " IOCTL_SERIAL_LSRMST_INSERT Enables or disables placement of a line and modem status data into the data stream".  No mention of LPT ports in what passes for documentation for the IOCTRL_SERIAL_LSRMST_INSERT magic number.

This is supposed to be useful documantation?

Message Edited by wally_666 on 07-10-2009 04:14 PM

[Shako]

Hi

I have been trying to write and read using winapi.

Here is the functions i use:

HANDLE PortHandle;
DWORD  Error;

PortHandle=CreateFile("\\\\.\\LPT3", (GENERIC_READ | GENERIC_WRITE), 0, NULL, OPEN_EXISTING, 0, NULL);

WriteFile(PortHandle,(LPCVOID)0x02,1,NULL,NULL);

ReadFile(PortHandle,lpBuffer,1,NULL,NULL)

Error=GetLastError();

Every time i write to the port i get an error "ERROR_NOACCESS:- Invalid access to memory location".

Do you know why im getting this error and how i could sovle it ?

[jr_2005]

You are getting the error because you are not allowed to access memory address 0x00000002. What I think you are trying to do is to output a byte value of 0x02? If so, put it in a buffer first and pass the address of the buffer, like you do in your ReadFile() call.

JR

[Shako]

WriteBuf=(LPVOID)0x00;
WriteFile(PortHandle,&WriteBuf,1,NULL,NULL);//Attempt 1

I have tried the following.

This just executes but does not continue.

Do you perhaps know why ?