Printing direct to LPT1

[Anonymous]

I've been playing with printing options trying to see if I can print direct to LPT1 and bypass printing through notepad.

In the past to enable printing from a legacy app to a USB or network printer I've always shared the printer and done a NET USE LPT1. Then the legacy app can write to LPT1 as if it was a physical port and never know the difference.

However, I'm having trouble doing the same in PC-BASIC. If I use --lpt1=parport:lpt1 I always get an exception on the WIDTH statement:

EXCEPTION
49 WIDTH "lpt1:",80
pcbasic.run:66, run_once
None
pcbasic.statements:132, parse_statement
None
pcbasic.statements:2483, exec_width
None
AttributeError: 'NoneType' object has no attribute 'set_width'

The documentation for --lpt1 suggests this should be possible, but I can't seem to get it to work. I'm running on Win10-64 with version 15.08.9.

[Rob Hagemans]

Hi, it looks like the connection to the port has not been initialised somehow. Could you run pcbasic with --logfile=log.txt to see if any messages appear in the log file?

Also, could you please run pcbasic --debug -v and post the result here - it sould give some more detail on the setup.

[Mitch McHenry]

LPT1 is mapped to a shared printer with NET USE and I confimed I can print a text file from the command line with:
print /d:lpt1 test.txt

Here's the command line from the shortcut I've setup:
"C:\Program Files (x86)\PC-BASIC\pcbasic.exe" kfmenu.bas -s=890 -f=9 --map-drives --lpt1=parport:lpt1 --print-trigger=page --dimensions=800,500 --logfile=c:\temp\log.txt

The working folder is set to the folder containing kfmenu.bas.

Here's the log:
WARNING: Parallel module not found. Parallel port communication not available.
ERROR: Traceback (most recent call last):
File "E:\branch1508\packaging\windows\build\installer\out00-PYZ.pyz\pcbasic.run", line 66, in run_once
File "E:\branch1508\packaging\windows\build\installer\out00-PYZ.pyz\pcbasic.statements", line 132, in parse_statement
File "E:\branch1508\packaging\windows\build\installer\out00-PYZ.pyz\pcbasic.statements", line 2480, in exec_width
AttributeError: 'NoneType' object has no attribute 'set_width'

PC-BASIC doesn't launch when I include -v and doesn't seem to echo anything to the console. But when I just have --debug it launches and displays:
PC-BASIC 15.08.9 [DEBUG mode]
(C) Copyright 2013--2016 Rob Hagemans.
60300 Bytes free
Ok 

[Rob Hagemans]

Hi Mitch, thanks for the extra info!

1 - It looks like I haven't included the parallel module with the Windows package, which is needed to access the LPT1: port. If I build a version including it and post it here - would you be able to check if it works? There may be issues as that module appears to be discontinued by its developer and moreover I don't currently have a parallel port myself to test it.

2 - All this assumes you're wrining to a physical parallel port and I don't actually know whether that really is the interface NET USE LPT1 simulates. It may well be the case that it's more like a character device/named pipe sort of thing, in which case it might be possible that --lpt1=FILE:LPT1: does the job- it would result in raw bytes being sent to LPT1, which sounds like what you describe you are successfully doing in other programs. But I’m not sure of this - I'm not familiar with the print command on Windows. Would something like copy myfile.txt LPT1: work in your setup? If so, then the FILE approach should work as well.

As an aside: the reason you're not getting console messages is that you're using the GUI binary pcbasic.exe to run from the command line - nothing wrong with that in pricnciple but if you use the console binary pcbasic.com you should be able to see the warnings and the output of the -v --debug option. The latter option does indeed not start PC-BASIC but if run with the console binary it should print a version string and the versions of the modules included to the console. Alternatively you could run with -v --debug --logfile=c:\temp\log.txt to output the version and module information to the log file.

Cheers
Rob

[Rob Hagemans]

Actually, the option in (2) should probably be --lpt1=FILE:LPT1 (without trailing colon) and the other command line may have to be type myfile.txt > LPT1 or copy /b myfile.txt LPT1.

[Mitch McHenry]

Ah, I didn't even notice pc-basic.com. Here's the output:

pcbasic.com --debug -v
1
5P.L0A8T.F9O
RM
os: Windows Intel64 Family 6 Model 58 Stepping 9, GenuineIntel 6.2.9200
python: 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] 32bit WindowsPE

MODULES
numpy: 1.8.0
available

pygame: 1.9.2pre
curses: --
pexpect: 2.3
serial: 2.7
parallel: --

Sure, I'd be happy to test a build with the parrallel module included. If you're running Windows and have a local USB printer, you can just share it and then NET USE LPT1 \mypc\myprinter to try it yourself. Or obvioulsy do the same with a printer shared from another machine on your network.

And yes, copy /b myfile.txt LPT1 works, but unfortunately, --lpt1=FILE:LPT1 doesn't. I tired it with and without the trailing colon just to be sure.

WARNING: Could not attach file lpt1 to LPT device: [Errno 2] No such file or directory: 'lpt1'
ERROR: File not found

BTW, I think the print /d:lpt1 myfile.txt does the same thing as copy /b myfile.txt LPT1. The only difference is that print.exe is a Win32 executable.

As far as saving output to an actual text file and then copying to lpt1, how do I accomplish that with PC-BASIC? I guess I'd have to use the default --lpt1=printer: and change the print command in the .txt file association to copy to lpt1 instead of using notepad to print? There no way to tell PC-BASIC to run some command to print is there? That would probably be a nice option...

[Rob Hagemans]

Hm, interesting output - it seems the standard-output and standard-error get mixed up leading to that odd mix of letters (which should really be 15.08.9 and PLATFORM. Something else to fix, there, at some point.

The more I look at it the more I am convinced that parallel and PARPORT: are not what you need - a local USB printer really is not a parallel port, and parallel is meant to enable things like setting a particular output or status pin on a Centronics/DB25 port like they were used in the MS-DOS era to connect printers.

Reading up on NET USE it looks much more like NET USE LPT1 results in a special filename/pipe/character device kind of thing connected to the print spooler, that just happens to have the same name as the MS-DOS parallel device. FILE: really ought to be able to handle that, especially since you can simply copy a text file straight to LPT1.

The question thus is why FILE does not work. I'll have to experiment with that. The errors you post are not at all what I would expect so something strange is going on here. I'll need to investigate this..

I got the impression that print.exe actually used Notepad to print text files, but I may be wrong. PC-BASIC uses the printto shell verb on Windows, which does seem to route the file through Notepad (or presumably whatever program is set to handle text files). I thought this was the standard approach for Windows, but if print.exe is different I'll have to see which approach is best. If it really does exactly the same as copy /b then that kind of thing should end up being supported through FILE.

As for sending output to files - you should be able to use --lpt1=FILE:myprint.txt to send all prints to that text file. Does that work? If not, please post the error message if any - it may be related to the issue with FILE:LPT1. Similarly, --lpt1=STDIO would send the print to standard output (the console). You could then use pipes and redirection on the Windows command line to send it to a command of your choice.

Hope this helps,
Rob

[Mitch McHenry]

Print.exe is not related to printto shell verb. printto uses whatever program you've associated with the txt file extension (notepad by default). Print.exe just sends the file to the specified port umolested, bypassing the windows printer driver, like redirecting a file to LPT1.

Yeah, sending output to a file is no problem, it's just getting it copied to the printer in a way that is good for the user that is the challenge. I think that would pretty much mean creating a batch file that would launch PC-BAISC, wait for it to exit and then copy to the printer, which I don't think would be acceptable for the users.

If this isn't something that you are otherwise interested in solving, then don't knock yourself out. Like you said, you're doing this for fun. I've been messing around with vDOS and think I can put together a good solution with that. But if it's something you're interested in anyway, then I'm glad to help out if you need me to test something or do any other diagnostics.

[Rob Hagemans]

Hi Mitch, thanks for that information!

I had a look at the code and I think I should be able to make printing to a mapped LPT1 work easily with the --lpt1=FILE:LPT1; the fact that it doesn't now is just a bug. As is the fact that it crashes if you try a parallel port and it fails - it should just give a console warning and maybe a Device Unavailable error. Once these things are solved you should be able to use that option to print to a mapped printer at LPT1 and probably at a network share - anything that would work with copy /b should in principle work. There will likely be additional issues relating to character encodings, but let's take one thing at a time.

I'll also update the documentation to make it clear this is how you need to do things if you want to send raw bytes to a NET USE mapped printer, that PARPORT: is only for controlling real parallel ports and that PRINTER sends things through the OS's printer driver.

I think after doing that PC-BASIC should be able to print directly, the way you prefer it. I'm reluctant to add functionality like outputting to user-defined print commands which would add further complexity - the number of things that can go wrong grows with the number of permutations of options and getting the options we have to work as expected is clearly already a challenge :). It seems that this sort of thing is supported by the OS - I appreciate that in Windows things like redirection and pipes are a bit more difficult and unpredicatble than in Unix but I don't feel I should be reproducing that kind of OS functionality too much...

Rob

[Mitch McHenry]

Cool, glad it's not a big deal. Let me know if you want me to test anything.

Custom print commands would be nice, but if you get the direct to LPT working, then there's a lot less need for it. FILE:LPT1 and PRINTER: should cover most cases.

If you wanted to add any more flexibility, rather than custom print commands, enhancing the FILE:myfile.txt option to close the file when you're not writing to it would be nice. That would let it work with tools like WinPrint that monitor an output file and after an interval of no modification (usually like 500ms), will rename, print and delete the file. Those tools also handle a lot of DOS printing concerns like font selection, code page translation, etc.