I guess it would be much better to use Device::ParallelPort than to try some lowlevel ways. Windows usualy do not like treating serial or parallel ports as normal files.
Jenda
Always code as if the guy who ends up maintaining your code
will be a violent psychopath who knows where you live.
-- Rick Osborne
Edit by castaway: Closed small tag in signature | [reply] |
What is connected to the ports in question?
Are either or both bound to printer drivers? The same or different printer drivers?
What happens if you check the return codes from the syswrite calls? Are they actually succeeding?
As a guess, I think that you may have a device driver, if not an actual device responding COM1, which is accepting the data, but nothing connected to LPT1, so the write to the latter is failing after several retrys and/or a timeout period.
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
| [reply] |
| [reply] |
Under Win32, or most OS's, you need a device driver in order to write to or read from parallel ports. In the case of NT/2000/XP this has to be a kernel DD. By default, there is probably a generic Printer DD attached to the parallel port, IO port 378h/888d, which is suffucient to allow raw output to a printer, but before it will accept data and make it available on the port, it will check for the existance of a printer being attached. If theis no printer attached it will timeout and fail your attempts to read or write it.
You might get away with strapping back the various control pins at the port to fool the dd into believing a printer is attached. The usual thing is to tie pin 15 high and pins 11 & 12 low. As a very first test to convince yourself you might use the command mode LPT1:=COMn: where n is whatever com port you have a printer attached to, to verify that the output is making it to the PP DD, as it should then be printed.
Of course this is just bypassing the port, and once you are convinced that your output from Perl is reaching the PPDD, you have then moved beyond the scope of Perl itself (and this forum:).
There is a Device::ParallelPort package on CPAN, however this requires a driver package named Device::ParallelPort:drv::win32 which can find mention of, but not the actual package, nor a record or the author (PAUSE:SCOTT) who proposed to upload it. That said, it's quite possible I missed it.
You might look here for a large amount of authoratative information on accessing and using parallel port from Win32.
Good luck.
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
| [reply] [d/l] [select] |
I'm a bit blind here, but remember that you must set the speed/parity/etc on serial ports. This might be the cause of the delay...
Best regards
-lem, but some call me fokat
| [reply] |