f



How to open & write to a USB port?

I'm trying to find a way to write a pre-generated print job file directly
to a USB printer port.

Basically, this is the same type of operation as
   print whatever.prn /d:lpt1
except instead of LPT1 it's a USB port (e.g. EPSON_8900_1).

The PRINT command evidently doesn't support USB ports with the /D 
parameter, so I suspect I'm going to have to write my own program.

Just to be clear: I don't want to go through the spooler.  I already
have a workaround which involves creating a dummy printer object using
IBMNULL with PM_Q_RAW and printing to that from REXX using the printing 
API from VROBJ.DLL... but I find this to be an ugly solution.  (For
one thing, it requires the user to create a dummy printer object, which
is seriously inconvenient for a number of reasons).  So what I want to
do is just dump the file directly to the USB port.

How can I do this?  

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/17/2011 11:04:00 AM
comp.os.os2.programmer.misc 1326 articles. 0 followers. Post Follow

68 Replies
447 Views

Similar Articles

[PageSpeed] 31

On 11/17/2011 04:04 AM, Alex Taylor wrote:
> I'm trying to find a way to write a pre-generated print job file directly
> to a USB printer port.
> 
> Basically, this is the same type of operation as
>    print whatever.prn /d:lpt1
> except instead of LPT1 it's a USB port (e.g. EPSON_8900_1).
> 
> The PRINT command evidently doesn't support USB ports with the /D 
> parameter, so I suspect I'm going to have to write my own program.
> 
  Why do you wish to bypass the spooler?
  Have you tried re-directing an LPT port to the printer object? True,
this does involve the spooler...

-- 
James Moe
jmm-list at sohnen-moe dot com
0
James
11/17/2011 5:33:55 PM
Hm,

shouldn't the USB port at least be connected to a printer driver?
And what format is the data in ? Is it printer specific, could you directly 
pass it to the printer ?

If yes, I would experiment with:
DevOpenDC with lType = OD_DIRECT (to circumvent the spooler)
DevEscape with lCode = DEV_STARTDOC, DEV_RAWDATA, DEV_ENDDOC see also the 
"Remarks" section for how to use the other parameters
(DevCloseDC)

Or you could use the API that the spooler would normally use (as far as I 
understand, see Presentation Device Driver Reference):
PrtOpen
PrtWrite
PrtClose
(again see remarks, in particular for PrtOpen).



Lars



"Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
news:mdq090pMZSKk-pn2-dZy0E0Stnrkf@localhost...
> I'm trying to find a way to write a pre-generated print job file directly
> to a USB printer port.
>
> Basically, this is the same type of operation as
>   print whatever.prn /d:lpt1
> except instead of LPT1 it's a USB port (e.g. EPSON_8900_1).
>
> The PRINT command evidently doesn't support USB ports with the /D
> parameter, so I suspect I'm going to have to write my own program.
>
> Just to be clear: I don't want to go through the spooler.  I already
> have a workaround which involves creating a dummy printer object using
> IBMNULL with PM_Q_RAW and printing to that from REXX using the printing
> API from VROBJ.DLL... but I find this to be an ugly solution.  (For
> one thing, it requires the user to create a dummy printer object, which
> is seriously inconvenient for a number of reasons).  So what I want to
> do is just dump the file directly to the USB port.
>
> How can I do this?
>
> -- 
> Alex Taylor
> Fukushima, Japan
> http://www.socis.ca/~ataylo00
>
> Please take off hat when replying. 

0
Lars
11/17/2011 9:48:27 PM
On Thu, 17 Nov 2011 17:33:55 UTC, James Moe <jimoeDESPAM@sohnen-moe.com> wrote:

> > I'm trying to find a way to write a pre-generated print job file 
> > directly to a USB printer port.
> > 
> > Basically, this is the same type of operation as
> >    print whatever.prn /d:lpt1
> > except instead of LPT1 it's a USB port (e.g. EPSON_8900_1).
> > 
> > The PRINT command evidently doesn't support USB ports with the /D 
> > parameter, so I suspect I'm going to have to write my own program.
> 
>   Why do you wish to bypass the spooler?

Because I'm hoping to write a port driver, which needs to pass the data to the 
printer (once it's done its other custom work).

At this point, the spooler has already finished its work.  The print
job is complete and in printer-native format.  The only step that remains
is to pass it to the physical printer.


>   Have you tried re-directing an LPT port to the printer object? True,
> this does involve the spooler...

Again, this takes place after the job has already passed through a
printer object.  Like I said, my current workaround is to create a
second printer object which uses IBMNULL, but if I want to pass this
off as a general solution for users, making them create double printer
objects and fiddle around with IBMNULL is a bit awkward and 
user-unfriendly.  It also offends my sense of proper design. <g>


-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/17/2011 11:21:01 PM
By the way:

you might be forced to do a :

#define PrtOpen PRT32OPEN
(etc.)

to actually use the 32-bit entry points. They are in PMSPL.DLL as:
PRT32OPEN 370
PRT32WRITE 371
PRT32CLOSE 373

Maybe this is not necessary (the OS2386.LIB will potentially do), a map file 
will help ...


Lars



"Lars Erdmann" <lars.erdmann@arcor.de> schrieb im Newsbeitrag 
news:4ec5812c$0$7629$9b4e6d93@newsspool1.arcor-online.net...
> Hm,
>
> shouldn't the USB port at least be connected to a printer driver?
> And what format is the data in ? Is it printer specific, could you 
> directly pass it to the printer ?
>
> If yes, I would experiment with:
> DevOpenDC with lType = OD_DIRECT (to circumvent the spooler)
> DevEscape with lCode = DEV_STARTDOC, DEV_RAWDATA, DEV_ENDDOC see also the 
> "Remarks" section for how to use the other parameters
> (DevCloseDC)
>
> Or you could use the API that the spooler would normally use (as far as I 
> understand, see Presentation Device Driver Reference):
> PrtOpen
> PrtWrite
> PrtClose
> (again see remarks, in particular for PrtOpen).
>
>
>
> Lars
>
>
>
> "Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
> news:mdq090pMZSKk-pn2-dZy0E0Stnrkf@localhost...
>> I'm trying to find a way to write a pre-generated print job file directly
>> to a USB printer port.
>>
>> Basically, this is the same type of operation as
>>   print whatever.prn /d:lpt1
>> except instead of LPT1 it's a USB port (e.g. EPSON_8900_1).
>>
>> The PRINT command evidently doesn't support USB ports with the /D
>> parameter, so I suspect I'm going to have to write my own program.
>>
>> Just to be clear: I don't want to go through the spooler.  I already
>> have a workaround which involves creating a dummy printer object using
>> IBMNULL with PM_Q_RAW and printing to that from REXX using the printing
>> API from VROBJ.DLL... but I find this to be an ugly solution.  (For
>> one thing, it requires the user to create a dummy printer object, which
>> is seriously inconvenient for a number of reasons).  So what I want to
>> do is just dump the file directly to the USB port.
>>
>> How can I do this?
>>
>> -- 
>> Alex Taylor
>> Fukushima, Japan
>> http://www.socis.ca/~ataylo00
>>
>> Please take off hat when replying.
> 

0
Lars
11/17/2011 11:21:37 PM
 > At this point, the spooler has already finished its work.  The
 > print job is complete and in printer-native format.  The only
 > step that remains is to pass it to the physical printer.

No need to answer: what if the physical printer isn't ready due to a 
e.g. a paper jam? Will the OS ever inform the use there's e.g. a paper
jam, in the same way as other printer errors pop up? Can the user 
still cancel the print job? Doesn't the spooler "pass it to the 
physical printer"? Does the spooler know the printer won't be ready 
for a while because the printer is printing?


--
0
A
11/18/2011 12:30:33 AM
Hallo Alex,


"Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
news:mdq090pMZSKk-pn2-MD88NfN0PqsI@localhost...
> On Thu, 17 Nov 2011 17:33:55 UTC, James Moe <jimoeDESPAM@sohnen-moe.com> 
> wrote:
>
>> > I'm trying to find a way to write a pre-generated print job file
>> > directly to a USB printer port.
>> >
>> > Basically, this is the same type of operation as
>> >    print whatever.prn /d:lpt1
>> > except instead of LPT1 it's a USB port (e.g. EPSON_8900_1).
>> >
>> > The PRINT command evidently doesn't support USB ports with the /D
>> > parameter, so I suspect I'm going to have to write my own program.
>>
>>   Why do you wish to bypass the spooler?
>
> Because I'm hoping to write a port driver, which needs to pass the data to 
> the
> printer (once it's done its other custom work).


I think you can hook in a filter that will be invoked by the spooler if you 
need special processing or something like that.
I haven't yet understood all the details.
Have a look at the presentation device driver reference.


Lars

0
Lars
11/18/2011 6:53:48 AM
On Thu, 17 Nov 2011 21:48:27 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> wrote:

> shouldn't the USB port at least be connected to a printer driver?
> And what format is the data in ? Is it printer specific, could you 
> directly pass it to the printer ?

The idea is that the file I'm sending has already been generated by
the appropriate printer driver.

Fundamentally, all I'm really talking about is exactly what the OS/2 "PRINT" 
command does, except that it works with USB printer ports...

Here's what I'm actually after.

Right now I'm using Ghostscript as a printer driver according to the
procudure which I've documented here:
http://svn.netlabs.org/ecups/wiki/GhostScriptRasterPrinting

The section "Printing to a Local USB Attached Printer" describes the
current, awkward, procedure which I'm concerned with at the moment.  

I want to either:
 1. Find (or write) a replacement for the PRINT command that I can use
    to send the job file to the printer instead of shunting it to a 
    secondary print object.
 2. Find out how to modify the OS/2 port of Ghostscript so that the
    '-sOUTPUTFILE' switch is capable of writing straight to the USB
    printer port. 
 3. Modify or replace UNI.PDR such that the contents of these various
    REXX script(s) are included in the port driver (which would require
    that the port driver itself is capable of writing to any of these
    ports/connections).

I haven't decided which is the best approach yet.


> If yes, I would experiment with:
> DevOpenDC with lType = OD_DIRECT (to circumvent the spooler)
> DevEscape with lCode = DEV_STARTDOC, DEV_RAWDATA, DEV_ENDDOC see also the 
> "Remarks" section for how to use the other parameters
> (DevCloseDC)
> 
> Or you could use the API that the spooler would normally use (as far as I 
> understand, see Presentation Device Driver Reference):
> PrtOpen
> PrtWrite
> PrtClose
> (again see remarks, in particular for PrtOpen).

Ah, that looks promising.  Thanks!


-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/18/2011 11:24:05 AM
Hallo Alex,

>> If yes, I would experiment with:
>> DevOpenDC with lType = OD_DIRECT (to circumvent the spooler)
>> DevEscape with lCode = DEV_STARTDOC, DEV_RAWDATA, DEV_ENDDOC see also the
>> "Remarks" section for how to use the other parameters
>> (DevCloseDC)
>>
>> Or you could use the API that the spooler would normally use (as far as I
>> understand, see Presentation Device Driver Reference):
>> PrtOpen
>> PrtWrite
>> PrtClose
>> (again see remarks, in particular for PrtOpen).
>
> Ah, that looks promising.  Thanks!

I would be interested in feedback of what worked and what did not. Maybe 
even a very stripped down code sample.


Lars 

0
Lars
11/18/2011 9:19:21 PM
Hi Alex,

On 17/11/11 21:34, Alex Taylor wrote:
> I'm trying to find a way to write a pre-generated print job file directly
> to a USB printer port.
>
> Basically, this is the same type of operation as
>     print whatever.prn /d:lpt1
> except instead of LPT1 it's a USB port (e.g. EPSON_8900_1).
>
> The PRINT command evidently doesn't support USB ports with the /D
> parameter, so I suspect I'm going to have to write my own program.
>
> Just to be clear: I don't want to go through the spooler.  I already
> have a workaround which involves creating a dummy printer object using
> IBMNULL with PM_Q_RAW and printing to that from REXX using the printing
> API from VROBJ.DLL... but I find this to be an ugly solution.  (For
> one thing, it requires the user to create a dummy printer object, which
> is seriously inconvenient for a number of reasons).  So what I want to
> do is just dump the file directly to the USB port.
>
> How can I do this?
It might be possible to use usb.exe from cups to use this.

The way cups works, the printer specific format gets piped to usb.exe - 
I think there's an environment variable that tells usb.exe which usb 
attached device to print to...


0
Paul
11/18/2011 10:16:43 PM
On Fri, 18 Nov 2011 21:19:21 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> wrote:

> >> PrtOpen
> >> PrtWrite
> >> PrtClose
> >> (again see remarks, in particular for PrtOpen).

On further investigation, it looks as though these functions are
simply wrappers for DosOpen/DosWrite/DosClose, so I might be able
to just use those in the same way...


> > Ah, that looks promising.  Thanks!
> 
> I would be interested in feedback of what worked and what did not. Maybe 
> even a very stripped down code sample.

It may be a while before I can get to this... my scope for testing is
somewhat limited at the moment.

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/19/2011 10:38:01 AM
"Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
news:mdq090pMZSKk-pn2-cdPOql53O2W6@localhost...
> On Fri, 18 Nov 2011 21:19:21 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> 
> wrote:
>
>> >> PrtOpen
>> >> PrtWrite
>> >> PrtClose
>> >> (again see remarks, in particular for PrtOpen).
>
> On further investigation, it looks as though these functions are
> simply wrappers for DosOpen/DosWrite/DosClose, so I might be able
> to just use those in the same way...

I don't think that PrtOpen/PrtWrte/PrtClose go through the filesystem API.
What they do is find the correct .PDR file and call the associated routines 
in there.
"Prt..." is preferred though, because they offer some layer of abstraction.
You can toss them a port name and they will find out what .PDR file 
implements that port.

>
>
>> > Ah, that looks promising.  Thanks!
>>
>> I would be interested in feedback of what worked and what did not. Maybe
>> even a very stripped down code sample.
>
> It may be a while before I can get to this... my scope for testing is
> somewhat limited at the moment.

Just curiosity. If you don't find the time, don't bother.

Lars 

0
Lars
11/20/2011 8:11:12 PM
On Fri, 18 Nov 2011 22:16:43 UTC, Paul Smedley 
<paulDESPAM@DESPAMMsmedley.id.au> wrote:

> > I'm trying to find a way to write a pre-generated print job file 
> > directly to a USB printer port.
> >
> It might be possible to use usb.exe from cups to use this.
> 
> The way cups works, the printer specific format gets piped to usb.exe - 
> I think there's an environment variable that tells usb.exe which usb 
> attached device to print to...

Interesting.  I may look into that.

....OTOH, if I'm going to go through CUPS, I should probably go all the
way and find a way to get foomatic-rip to work with OS/2 Postscript
files... which is after all the 'proper' way to do this. <g>  That's
my longer-term objective, I suppose.  


-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/23/2011 8:24:01 AM
On 2011-11-23, Alex Taylor <mail.me@reply.to.address> wrote:
> ...OTOH, if I'm going to go through CUPS, I should probably go all the
> way and find a way to get foomatic-rip to work with OS/2 Postscript
> files... which is after all the 'proper' way to do this. <g>  That's
> my longer-term objective, I suppose.  

IIRC these files become well-formed after running through ps2ps (with
latest GSes, I would also try ps2ps2).

Ilya
0
Ilya
11/24/2011 1:55:23 AM
On Thu, 24 Nov 2011 01:55:23 UTC, Ilya Zakharevich <nospam-abuse@ilyaz.org> 
wrote:

> > ...OTOH, if I'm going to go through CUPS, I should probably go all the
> > way and find a way to get foomatic-rip to work with OS/2 Postscript
> > files... which is after all the 'proper' way to do this. <g>  That's
> > my longer-term objective, I suppose.  
> 
> IIRC these files become well-formed after running through ps2ps (with
> latest GSes, I would also try ps2ps2).

Apparently not, since the file is already being received from ps2ps
before it goes through foomatic-rip, and that's what Ghostscript
chokes on.  

Here's the thing:
   OS/2 Postscript file --> Ghostscript --> printer
works fine (as long as GS 8.71 is used; v9.x has other problems).

But as soon as we go through CUPS+foomatic:
   OS/2 Postscript file --> pstops --> foomatic --> Ghostscript --> printer
Ghostscript aborts because the file is malformed somehow.

Same original Postscript file, same version of Ghostscript, same printer.
Both pstops and foomatic modify the file somehow, so clearly one of them
must be interacting badly with the OS/2-generated Postscript data.  I
assume it's probably foomatic, since pstops is used in regular CUPS 
setups and this problem doesn't seem to occur there.

The whole purpose of the original exercise is to provide a workaround by 
bypassing foomatic.  It works already, I just want to simplify it
because the setup required by the user is very awkward.


Longer term, the best solution is to fix the foomatic-rip printing
process.  SOMEhow.

I see two approaches.  

The "proper" way would be to figure out what's wrong with the original 
Postscript file that causes foomatic to mangle it, and fix the Postscript 
drivers (ECUPS.DRV etc.).  Unfortunately, I suspect this may require 
some fairly in-depth knowledge of the Postscript language, which I don't
have.

The simpler way would be simply to figure out which of foomatic's 
Postscript modifications is triggering the problem, and bypass it.

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/24/2011 10:48:01 AM
On Sun, 20 Nov 2011 20:11:12 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> wrote:

> >> >> PrtOpen
> >> >> PrtWrite
> >> >> PrtClose
> >> >> (again see remarks, in particular for PrtOpen).
> 
> I don't think that PrtOpen/PrtWrte/PrtClose go through the filesystem 
> API.  What they do is find the correct .PDR file and call the associated 
> routines in there.
> "Prt..." is preferred though, because they offer some layer of 
> abstraction. You can toss them a port name and they will find out what 
> .PDR file implements that port.

In retrospect, I think you're right.

However...


> > It may be a while before I can get to this... my scope for testing is
> > somewhat limited at the moment.
> 
> Just curiosity. If you don't find the time, don't bother.

Managed to try it out today.  First of all, looking at the map file
confirms that the VAC linker automatically maps PrtXX to the Prt32XX
entrypoints, so no worries there.

Unfortunately, PrtOpen doesn't seem to be able to match the port name
("EPSON_PX_101_1" in this case) to the actual port.  As a result, the
output simply gets dumped to a file on disk called EPSON_PX_101_1.

I may need to load USBPRT.PDR and call SplPdOpen/Write/Close directly.
That's probably the next thing I'll try.

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/24/2011 10:50:01 AM
Hallo,

"Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
news:mdq090pMZSKk-pn2-gLqTb9KNq6u6@localhost...
> On Sun, 20 Nov 2011 20:11:12 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> 
> wrote:
>
> Managed to try it out today.  First of all, looking at the map file
> confirms that the VAC linker automatically maps PrtXX to the Prt32XX
> entrypoints, so no worries there.
>
> Unfortunately, PrtOpen doesn't seem to be able to match the port name
> ("EPSON_PX_101_1" in this case) to the actual port.  As a result, the
> output simply gets dumped to a file on disk called EPSON_PX_101_1.

You might need to do some research in OS2SYS.INI /OS2.INI to find out what 
the port name actually is.
It might not be what you see in the GUI.
Unfortunately currently I don't have any printer installed otherwise I could 
tell you.
I am sure it will need some experimentation as it is all so badly 
documented.
If you search for USBPRT.PDR in OS2.INI /OS2SYS.INI you will get to the 
places
where you will most likely find the portname that Prt... needs.
Maybe it's even a combination of printer driver/port name I don't know.

> I may need to load USBPRT.PDR and call SplPdOpen/Write/Close directly.
> That's probably the next thing I'll try.

Hm. I don't feel comfortable with this solution for the reason already 
mentioned.
Prt... is nice because you have the universal solution making it easy to 
change from
one port to the other (parallel port to USB port etc.)

But of course it is your decision.

>
> -- 
> Alex Taylor
> Fukushima, Japan
> http://www.socis.ca/~ataylo00
>
> Please take off hat when replying. 

0
Lars
11/24/2011 12:04:14 PM
Hallo Alex,

if you get EPSON_PX_101_1 displayed as a port name,
try and pass "PM_EPSON_PX_101_1" as the port name to PrtOpen.

Reason: there will be an "application" key in your OS2SYS.INI (or was it 
OS2.INI ?) with this name.
And this in turn contains a key that specifies the port driver, USBPRT.PDR 
in this case.

I am sure PrtOpen will need to follow some search key to find the necessary 
information in the INI file(s).

Lars


"Lars Erdmann" <lars.erdmann@arcor.de> schrieb im Newsbeitrag 
news:4ece32bf$0$6565$9b4e6d93@newsspool4.arcor-online.net...
> Hallo,
>
> "Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
> news:mdq090pMZSKk-pn2-gLqTb9KNq6u6@localhost...
>> On Sun, 20 Nov 2011 20:11:12 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> 
>> wrote:
>>
>> Managed to try it out today.  First of all, looking at the map file
>> confirms that the VAC linker automatically maps PrtXX to the Prt32XX
>> entrypoints, so no worries there.
>>
>> Unfortunately, PrtOpen doesn't seem to be able to match the port name
>> ("EPSON_PX_101_1" in this case) to the actual port.  As a result, the
>> output simply gets dumped to a file on disk called EPSON_PX_101_1.
>
> You might need to do some research in OS2SYS.INI /OS2.INI to find out what 
> the port name actually is.
> It might not be what you see in the GUI.
> Unfortunately currently I don't have any printer installed otherwise I 
> could tell you.
> I am sure it will need some experimentation as it is all so badly 
> documented.
> If you search for USBPRT.PDR in OS2.INI /OS2SYS.INI you will get to the 
> places
> where you will most likely find the portname that Prt... needs.
> Maybe it's even a combination of printer driver/port name I don't know.
>
>> I may need to load USBPRT.PDR and call SplPdOpen/Write/Close directly.
>> That's probably the next thing I'll try.
>
> Hm. I don't feel comfortable with this solution for the reason already 
> mentioned.
> Prt... is nice because you have the universal solution making it easy to 
> change from
> one port to the other (parallel port to USB port etc.)
>
> But of course it is your decision.
>
>>
>> -- 
>> Alex Taylor
>> Fukushima, Japan
>> http://www.socis.ca/~ataylo00
>>
>> Please take off hat when replying.
> 

0
Lars
11/24/2011 12:31:03 PM
On Thu, 24 Nov 2011 12:04:14 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> wrote:

> > Unfortunately, PrtOpen doesn't seem to be able to match the port name
> > ("EPSON_PX_101_1" in this case) to the actual port.  As a result, the
> > output simply gets dumped to a file on disk called EPSON_PX_101_1.
> 
> You might need to do some research in OS2SYS.INI /OS2.INI to find out 
> what the port name actually is.
> It might not be what you see in the GUI.

Running SplEnumPort() does show the port name EPSON_PX_101_1 
(associated with USBPRT.PDR, so that's probably how PrtOpen resolves
the port driver).


> if you get EPSON_PX_101_1 displayed as a port name,
> try and pass "PM_EPSON_PX_101_1" as the port name to PrtOpen.

Same thing.  Now the created output file is called PM_EPSON_PX_101_1.


It's kind of annoying that the source code for USBPRT.PDR seems to be
the ONLY USB system component that's missing from the DDK...


-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/24/2011 1:07:00 PM
On 2011-11-24, Alex Taylor <mail.me@reply.to.address> wrote:
>> IIRC these files become well-formed after running through ps2ps (with
>> latest GSes, I would also try ps2ps2).
>
> Apparently not, since the file is already being received from ps2ps
                                                                ^^^^^
> before it goes through foomatic-rip, and that's what Ghostscript
> chokes on.  

>    OS/2 Postscript file --> pstops --> foomatic --> Ghostscript --> printer
                              ^^^^^^
> Ghostscript aborts because the file is malformed somehow.

Looks like you got hit by ps2ps vs pstops confusion...

Ilya
0
Ilya
11/24/2011 1:08:29 PM
Unfortunately, SplPdOpen,SplPdWrite,SplPdClose are not mandatory functions 
(for whatever reason).
For example, PARALLEL.PDR and SERIAL.PDR do not have these functions.
On the other hand, INFRARED.PDR,SLPR.PDR and USBPRT.PDR do.

Maybe the difference is because LPTx/PRN and COMx are supported by the 
normal file system APIs
DosOpen,DosWrite,DosClose ...

If it helps: you will find the sources for PARALLEL.PDR, SERIAL.PDR and 
INFRARED.PDR in the DDK.
wpshell\src\wpsh\infrared
wpshell\src\wpsh\parallel
wpshell\src\wpsh\serial

Here you will find a printer driver that actually uses 
PrtOpen,PrtWrite,PrtClose:
print\src\osdd\42xx

Lars


"Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
news:mdq090pMZSKk-pn2-BMRJ3lbHVfhi@localhost...
> On Thu, 24 Nov 2011 12:04:14 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> 
> wrote:
>
>> > Unfortunately, PrtOpen doesn't seem to be able to match the port name
>> > ("EPSON_PX_101_1" in this case) to the actual port.  As a result, the
>> > output simply gets dumped to a file on disk called EPSON_PX_101_1.
>>
>> You might need to do some research in OS2SYS.INI /OS2.INI to find out
>> what the port name actually is.
>> It might not be what you see in the GUI.
>
> Running SplEnumPort() does show the port name EPSON_PX_101_1
> (associated with USBPRT.PDR, so that's probably how PrtOpen resolves
> the port driver).
>
>
>> if you get EPSON_PX_101_1 displayed as a port name,
>> try and pass "PM_EPSON_PX_101_1" as the port name to PrtOpen.
>
> Same thing.  Now the created output file is called PM_EPSON_PX_101_1.
>
>
> It's kind of annoying that the source code for USBPRT.PDR seems to be
> the ONLY USB system component that's missing from the DDK...
>
>
> -- 
> Alex Taylor
> Fukushima, Japan
> http://www.socis.ca/~ataylo00
>
> Please take off hat when replying. 

0
Lars
11/24/2011 2:06:07 PM
On Thu, 24 Nov 2011 14:06:07 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> wrote:

> Unfortunately, SplPdOpen,SplPdWrite,SplPdClose are not mandatory 
> functions (for whatever reason).
> For example, PARALLEL.PDR and SERIAL.PDR do not have these functions.
> On the other hand, INFRARED.PDR,SLPR.PDR and USBPRT.PDR do.

Looks like they were only added in the Warp driver model and aren't in
the 2.x model that parallel and serial use.  (Seems the latter uses
SplPdInitPort and SplPdTermPort instead.)

PrtOpen is supposed to call the correct function(s) as needed for
the port driver, but it doesn't seem to be working for the USB port
in this case.

> If it helps: you will find the sources for PARALLEL.PDR, SERIAL.PDR and 
> INFRARED.PDR in the DDK.
> wpshell\src\wpsh\infrared
> wpshell\src\wpsh\parallel
> wpshell\src\wpsh\serial

Yeah, they've already been considerable help (for this and other
projects).


> Here you will find a printer driver that actually uses 
> PrtOpen,PrtWrite,PrtClose:
> print\src\osdd\42xx

Ineresting.  I searched all the port drivers... didn't think to search
the more obscure printer drivers, though.  I'll take a look.  Thanks.


-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/24/2011 2:59:17 PM
How about DevOpenDC ?

DEVOPENDATA od;

memset(&od,0,sizeof(od));
od.pszLogAddress = "EPSON_PX_101_1";

rc = DevOpenDC(hab,OD_DIRECT,"*",1UL,&od,NULLHANDLE);

I don't know if you need additional params defined in od.


And then use DevEscape to actually write something to the port.


Lars


"Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
news:mdq090pMZSKk-pn2-33Wf5PqnXneb@localhost...
> On Thu, 24 Nov 2011 14:06:07 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> 
> wrote:
>
>> Unfortunately, SplPdOpen,SplPdWrite,SplPdClose are not mandatory
>> functions (for whatever reason).
>> For example, PARALLEL.PDR and SERIAL.PDR do not have these functions.
>> On the other hand, INFRARED.PDR,SLPR.PDR and USBPRT.PDR do.
>
> Looks like they were only added in the Warp driver model and aren't in
> the 2.x model that parallel and serial use.  (Seems the latter uses
> SplPdInitPort and SplPdTermPort instead.)
>
> PrtOpen is supposed to call the correct function(s) as needed for
> the port driver, but it doesn't seem to be working for the USB port
> in this case.
>
>> If it helps: you will find the sources for PARALLEL.PDR, SERIAL.PDR and
>> INFRARED.PDR in the DDK.
>> wpshell\src\wpsh\infrared
>> wpshell\src\wpsh\parallel
>> wpshell\src\wpsh\serial
>
> Yeah, they've already been considerable help (for this and other
> projects).
>
>
>> Here you will find a printer driver that actually uses
>> PrtOpen,PrtWrite,PrtClose:
>> print\src\osdd\42xx
>
> Ineresting.  I searched all the port drivers... didn't think to search
> the more obscure printer drivers, though.  I'll take a look.  Thanks.
>
>
> -- 
> Alex Taylor
> Fukushima, Japan
> http://www.socis.ca/~ataylo00
>
> Please take off hat when replying. 

0
Lars
11/24/2011 5:18:36 PM
On Thu, 24 Nov 2011 17:18:36 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> wrote:

> How about DevOpenDC ?
> 
> DEVOPENDATA od;
> 
> memset(&od,0,sizeof(od));
> od.pszLogAddress = "EPSON_PX_101_1";
> 
> rc = DevOpenDC(hab,OD_DIRECT,"*",1UL,&od,NULLHANDLE);
> 
> I don't know if you need additional params defined in od.
> 
> And then use DevEscape to actually write something to the port.

Isn't that for PM printing, though?  The GPI documentation describes
that method in the context of presentation spaces, so I figured it was
specific to that.  Aren't device contexts a PM-specific thing?  (Never
really programmed on that level.)

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/25/2011 12:39:01 PM
I guess be are back to trial and error. The PM ref says DevOpenDC can open a 
port.
That's about all I know.

Lars

"Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
news:mdq090pMZSKk-pn2-w0mlf6TKnuXw@localhost...
> On Thu, 24 Nov 2011 17:18:36 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> 
> wrote:
>
>> How about DevOpenDC ?
>>
>> DEVOPENDATA od;
>>
>> memset(&od,0,sizeof(od));
>> od.pszLogAddress = "EPSON_PX_101_1";
>>
>> rc = DevOpenDC(hab,OD_DIRECT,"*",1UL,&od,NULLHANDLE);
>>
>> I don't know if you need additional params defined in od.
>>
>> And then use DevEscape to actually write something to the port.
>
> Isn't that for PM printing, though?  The GPI documentation describes
> that method in the context of presentation spaces, so I figured it was
> specific to that.  Aren't device contexts a PM-specific thing?  (Never
> really programmed on that level.)
>
> -- 
> Alex Taylor
> Fukushima, Japan
> http://www.socis.ca/~ataylo00
>
> Please take off hat when replying. 

0
Lars
11/25/2011 8:09:35 PM
On Fri, 25 Nov 2011 20:09:35 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> wrote:

> I guess be are back to trial and error. 

True.


Here's what I've got at the moment:
http://users.socis.ca/~ataylo00/os2/printing/eprint_test.zip

The basic logic is:
 - Call SplEnumPort to verify that the port exists and get the path to
   the port driver.
 - Load the port driver with DosLoadModule and try to register the
   SplPdOpen function.
    - If SplPdOpen does not exist, treat as a pre-Warp driver:
        - Free the module handle (not needed in this case)
        - Open with PrtOpen
        - Write the requested file with PrtWrite
        - Close with PrtClose
    - If SplPdOpen exists, register SplPdQuery, SplPdWrite and SplPdClose.
        - Call SplPdQuery to find out if SplPdWrite or SplPdProtWrite
          is requred; if the latter, register that one too.
        - Open with SplPdOpen
        - Write the requested file with SplPdWrite or SplPdProtWrite, as
          indicated.
        - Close with SplPdClose
        - Free the module handle
 - Done

At least trying to print to a USB port no longer generates a file on disk.  
 - If there is no printer connected to the port, the program stalls for 
   several moments before returning RC=21 from SplPdWrite.
 - If there is a printer, the program returns immediately reporting 
   success.  The printer does absolutely nothing.

(I am testing with an ASCII file, which possibly this ultra-cheap inkjet
printer doesn't like, but I assume all printers can handle ASCII.)

I have no parallel (or other) printers so I can't really test any other
port type.  (I tried with an SLPR port but SplPdOpen fails with RC=87.)

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/26/2011 9:09:56 AM
Hm,

the remarks for "SplPdInitPort" say that PrtOpen first calls DosOpen on the 
"device" and then calls SplPdInitPort.
Understood that you use neither SplPdInitPort nor PrtOpen but it's 
interesting to know.
That somehow implies that there IS a device to open before a port can be 
sensibly opened at least for this exact scenario.

I wonder how USBPRT.SYS adds to our scenario. I think we are still missing 
something.

Can you try DevOpenDC instead ? I am sure it will also need experimentation 
but maybe we can sensibly fill the fields for "pszLogAddress" and 
"pszDriverName" of the DEVOPENSTRUC structure.

Lars


"Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
news:mdq090pMZSKk-pn2-Rqe7RFUiL3pL@localhost...
> On Fri, 25 Nov 2011 20:09:35 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> 
> wrote:
>
>> I guess be are back to trial and error.
>
> True.
>
>
> Here's what I've got at the moment:
> http://users.socis.ca/~ataylo00/os2/printing/eprint_test.zip
>
> The basic logic is:
> - Call SplEnumPort to verify that the port exists and get the path to
>   the port driver.
> - Load the port driver with DosLoadModule and try to register the
>   SplPdOpen function.
>    - If SplPdOpen does not exist, treat as a pre-Warp driver:
>        - Free the module handle (not needed in this case)
>        - Open with PrtOpen
>        - Write the requested file with PrtWrite
>        - Close with PrtClose
>    - If SplPdOpen exists, register SplPdQuery, SplPdWrite and SplPdClose.
>        - Call SplPdQuery to find out if SplPdWrite or SplPdProtWrite
>          is requred; if the latter, register that one too.
>        - Open with SplPdOpen
>        - Write the requested file with SplPdWrite or SplPdProtWrite, as
>          indicated.
>        - Close with SplPdClose
>        - Free the module handle
> - Done
>
> At least trying to print to a USB port no longer generates a file on disk.
> - If there is no printer connected to the port, the program stalls for
>   several moments before returning RC=21 from SplPdWrite.
> - If there is a printer, the program returns immediately reporting
>   success.  The printer does absolutely nothing.
>
> (I am testing with an ASCII file, which possibly this ultra-cheap inkjet
> printer doesn't like, but I assume all printers can handle ASCII.)
>
> I have no parallel (or other) printers so I can't really test any other
> port type.  (I tried with an SLPR port but SplPdOpen fails with RC=87.)
>
> -- 
> Alex Taylor
> Fukushima, Japan
> http://www.socis.ca/~ataylo00
>
> Please take off hat when replying. 

0
Lars
11/26/2011 10:18:25 AM
On Sat, 26 Nov 2011 10:18:25 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> wrote:

> the remarks for "SplPdInitPort" say that PrtOpen first calls DosOpen on 
> the "device" and then calls SplPdInitPort.
> Understood that you use neither SplPdInitPort nor PrtOpen but it's 
> interesting to know.
> That somehow implies that there IS a device to open before a port can be 
> sensibly opened at least for this exact scenario.

SplPdInitPort is what 2.x drivers use.  It's been deprecated by 
SplPdOpen, according to the docs.  Elsewhere it says that SplPdOpen 
"emulates" DosOpen, which I assume means that it takes care of opening 
the device iteslf.

In the case of 2.x drivers (like PARALLAL.PDR) I use do use PrtOpen. 
Of course, I have no way of testing that, not having any parallel
printers available.

I'd really like to know if this technique does work with other port
types and it's just USB that's a problem... I don't suppose anyone
has a parallel printer they're willing to try this program on?


> I wonder how USBPRT.SYS adds to our scenario. I think we are still 
> missing something.

I wonder if USBMON might contain some clues... I really wish USBPRT.PDR
had source that I could look at.


> Can you try DevOpenDC instead ? I am sure it will also need 
> experimentation but maybe we can sensibly fill the fields for 
> "pszLogAddress" and "pszDriverName" of the DEVOPENSTRUC structure.

Ugh.  I'd rather not, but if I run out of other ideas I may have to.
I've never done anything with device contexts, so I'll need to study 
up on the subject first.  

I suppose I'd need to create a message queue and thus run the 
program in PM mode... looking at a whole new type of program here.

I probably won't be able to try it any time soon.

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/26/2011 1:21:01 PM
On 26 Nov 2011 07:21:01 -0600, Alex Taylor <mail.me@reply.to.address> wrote:

> I'd really like to know if this technique does work with other port
> types and it's just USB that's a problem... I don't suppose anyone
> has a parallel printer they're willing to try this program on?

I don't mind testing something...
0
Paul
11/26/2011 2:42:00 PM
On Sat, 26 Nov 2011 09:09:56 UTC, "Alex Taylor" 
<mail.me@reply.to.address> wrote:

> (I am testing with an ASCII file, which possibly this ultra-cheap inkjet
> printer doesn't like, but I assume all printers can handle ASCII.)

Not for the last 15 years, or so... 


-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

0
Doug
11/26/2011 5:14:30 PM
On Sat, 26 Nov 2011 14:42:00 UTC, Paul Ratcliffe 
<abuse@orac12.clara34.co56.uk78> wrote:

> On 26 Nov 2011 07:21:01 -0600, Alex Taylor <mail.me@reply.to.address> wrote:
> 
> > I'd really like to know if this technique does work with other port
> > types and it's just USB that's a problem... I don't suppose anyone
> > has a parallel printer they're willing to try this program on?
> 
> I don't mind testing something...

http://users.socis.ca/~ataylo00/os2/printing/eprint_test.zip
Executable and source included.

I tried to make the syntax similar to the standard "print"...
 - To try sending a file to a printer port:
     eprint <filename> /d:<portname>
 - To get a list of known ports:
     eprint /l


Thanks!

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/27/2011 2:04:01 AM
On 26 Nov 2011 20:04:01 -0600, Alex Taylor <mail.me@reply.to.address> wrote:

>> > I'd really like to know if this technique does work with other port
>> > types and it's just USB that's a problem... I don't suppose anyone
>> > has a parallel printer they're willing to try this program on?
>> 
>> I don't mind testing something...
> 
> http://users.socis.ca/~ataylo00/os2/printing/eprint_test.zip
> Executable and source included.
> 
> I tried to make the syntax similar to the standard "print"...
>  - To try sending a file to a printer port:
>      eprint <filename> /d:<portname>
>  - To get a list of known ports:
>      eprint /l

I tried "eprint eprint.c /d:LPT1" and got a nice text-format listing of
the program on my printer (Lexmark Optra E+). It bypasses the spooler,
but I guess this is what you were trying to achieve?
I tried it with the printer powered off and got
  Error writing to port: RC=28

eprint /L gives:

------------------------------------------------------------------------------
Port Name                        Port Driver
------------------------------------------------------------------------------
LPT1                             E:\OS2\DLL\PARALLEL.PDR
LPT2                             E:\OS2\DLL\PARALLEL.PDR
LPT3                             E:\OS2\DLL\PARALLEL.PDR
LPT4
LPT5
LPT6
LPT7
LPT8
LPT9
\PIPE\LPD7                       E:\TCPIP\DLL\LPRPDRVR.PDR
\PIPE\LPD6                       E:\TCPIP\DLL\LPRPDRVR.PDR
\PIPE\LPD5                       E:\TCPIP\DLL\LPRPDRVR.PDR
\PIPE\LPD4                       E:\TCPIP\DLL\LPRPDRVR.PDR
\PIPE\LPD3                       E:\TCPIP\DLL\LPRPDRVR.PDR
\PIPE\LPD2                       E:\TCPIP\DLL\LPRPDRVR.PDR
\PIPE\LPD1                       E:\TCPIP\DLL\LPRPDRVR.PDR
\PIPE\LPD0                       E:\TCPIP\DLL\LPRPDRVR.PDR
FILE
COM4                             E:\OS2\DLL\SERIAL.PDR
COM3                             E:\OS2\DLL\SERIAL.PDR
COM2                             E:\OS2\DLL\SERIAL.PDR
COM1                             E:\OS2\DLL\SERIAL.PDR
------------------------------------------------------------------------------

Attempting to print to LPT2 which is not connected to anything gave no
error, but obviously produced no output, at least not anywhere that I
could fine.
Attempting to print to LPT3, which is my Faxworks FxPrint queue gave
no error and no output either.
Attempting to print to LPT4 gave:
  The port LPT4 was not found

Using COM1 and COM2 gave "Failed to open output port COM1: RC=32" as
they are in use by other programs.
Using COM3 it just hung for about a minute and then produced:
  Error writing to port: RC=234

Anything else you want doing?
0
Paul
11/27/2011 10:30:33 AM
On Sun, 27 Nov 2011 10:30:33 UTC, Paul Ratcliffe 
<abuse@orac12.clara34.co56.uk78> wrote:

> >> > I'd really like to know if this technique does work with other port
> >> > types and it's just USB that's a problem... I don't suppose anyone
> >> > has a parallel printer they're willing to try this program on?
> 
> I tried "eprint eprint.c /d:LPT1" and got a nice text-format listing of
> the program on my printer (Lexmark Optra E+). It bypasses the spooler,
> but I guess this is what you were trying to achieve?

That's right.  Great to know that this much works, at least.

> I tried it with the printer powered off and got
>   Error writing to port: RC=28

Interesting, that seems to be an out-of-paper error.


> LPT1                             E:\OS2\DLL\PARALLEL.PDR
> LPT2                             E:\OS2\DLL\PARALLEL.PDR
> LPT3                             E:\OS2\DLL\PARALLEL.PDR
> LPT4
> LPT5
> LPT6
> LPT7
> LPT8
> LPT9

Very interesting.  I wonder why all those extra LPT ports show up.
Maybe I should filter out ports with no port driver associated
(other than FILE, maybe)...


> Attempting to print to LPT2 which is not connected to anything gave no
> error, but obviously produced no output, at least not anywhere that I
> could fine.
> Attempting to print to LPT3, which is my Faxworks FxPrint queue gave
> no error and no output either.

Just out of curiousity, what does the standard OS/2 "print" command do
with these ports?


> Using COM1 and COM2 gave "Failed to open output port COM1: RC=32" as
> they are in use by other programs.
> Using COM3 it just hung for about a minute and then produced:
>   Error writing to port: RC=234
> 
> Anything else you want doing?

Since you don't appear to have any USB printers, I think that's about
it.  But the above was very helpful.  I now know that, at a minimum,
my WritePort_Orthodox() function seems to work.  

Thank you!

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/27/2011 12:11:00 PM
On Sun, 27 Nov 2011 10:30:33 UTC, Paul Ratcliffe 
<abuse@orac12.clara34.co56.uk78> wrote:

> On 26 Nov 2011 20:04:01 -0600, Alex Taylor <mail.me@reply.to.address> wrote:
> 
> >> > I'd really like to know if this technique does work with other port
> >> > types and it's just USB that's a problem... I don't suppose anyone
> >> > has a parallel printer they're willing to try this program on?
> >> 
> >> I don't mind testing something...
> > 
> > http://users.socis.ca/~ataylo00/os2/printing/eprint_test.zip
> > Executable and source included.
> > 
> > I tried to make the syntax similar to the standard "print"...
> >  - To try sending a file to a printer port:
> >      eprint <filename> /d:<portname>
> >  - To get a list of known ports:
> >      eprint /l
> 
> I tried "eprint eprint.c /d:LPT1" and got a nice text-format listing of
> the program on my printer (Lexmark Optra E+). It bypasses the spooler,
> but I guess this is what you were trying to achieve?
> I tried it with the printer powered off and got
>   Error writing to port: RC=28

I tried "eprint eprint.c /d:LPT1" and got two pages of eight correct 
text, first page immediately and second after a while.

Usb "eprint eprint.c /d:HP_CLJ_2550_1" gave same result. Printer is HP 
Color Laserjet 2550 Ln.


eprint /L
----------------------------------------------------------
Port Name                        Port Driver
----------------------------------------------------------
\PIPE\LPD0                       E:\TCPIP\DLL\LPRPDRVR.PDR
\PIPE\ePDF
HP_CLJ_2550_1                    E:\OS2\DLL\USBPRT.PDR
FILE
COM4                             E:\OS2\DLL\SERIAL.PDR
COM3                             E:\OS2\DLL\SERIAL.PDR
COM2                             E:\OS2\DLL\SERIAL.PDR
COM1                             E:\OS2\DLL\SERIAL.PDR
LPT3                             E:\OS2\DLL\PARALLEL.PDR
LPT2                             E:\OS2\DLL\PARALLEL.PDR
LPT1                             E:\OS2\DLL\PARALLEL.PDR


-- 
Hessu
0
Heikki
11/27/2011 1:25:47 PM
"Alex Taylor" <mail.me@reply.to.address> writes:
>On Sat, 26 Nov 2011 14:42:00 UTC, Paul Ratcliffe 
><abuse@orac12.clara34.co56.uk78> wrote:
>
>> On 26 Nov 2011 07:21:01 -0600, Alex Taylor <mail.me@reply.to.address> wrote:
>> 
>> > I'd really like to know if this technique does work with other port
>> > types and it's just USB that's a problem... I don't suppose anyone
>> > has a parallel printer they're willing to try this program on?
>> 
>> I don't mind testing something...
>
>http://users.socis.ca/~ataylo00/os2/printing/eprint_test.zip
>Executable and source included.
>
>I tried to make the syntax similar to the standard "print"...
> - To try sending a file to a printer port:
>     eprint <filename> /d:<portname>
> - To get a list of known ports:
>     eprint /l

hI,

   Results as follows:

[F:\WORK]eprint /l
------------------------------------------------------------------------------
Port Name                        Port Driver
------------------------------------------------------------------------------
FILE
COM4                             C:\OS2\DLL\SERIAL.PDR
COM3                             C:\OS2\DLL\SERIAL.PDR
COM2                             C:\OS2\DLL\SERIAL.PDR
COM1                             C:\OS2\DLL\SERIAL.PDR
LPT3                             C:\OS2\DLL\PARALLEL.PDR
LPT2                             C:\OS2\DLL\PARALLEL.PDR
LPT1                             C:\OS2\DLL\PARALLEL.PDR
------------------------------------------------------------------------------

[F:\WORK]eprint buildrel.cmd /d:lpt1

[F:\WORK]

   Blinking LED on HP 2550n, normally used in PostScript mode.
After a bit of time (~minute), printed as expected.

Regards,

Steve N.
0
Bogus
11/27/2011 2:52:23 PM
On 27 Nov 2011 06:11:00 -0600, Alex Taylor <mail.me@reply.to.address> wrote:

>> I tried it with the printer powered off and got
>>   Error writing to port: RC=28
> 
> Interesting, that seems to be an out-of-paper error.

Printing normally gives that error as well, so much be a parallel port
interface thing. What other error might one expect?

>> LPT4
>> LPT5
>> LPT6
>> LPT7
>> LPT8
>> LPT9
> 
> Very interesting.  I wonder why all those extra LPT ports show up.
> Maybe I should filter out ports with no port driver associated
> (other than FILE, maybe)...

Ah, I've got (or at least had, as it's now REMmed out) some other driver
installed specifically to create those - LPT49.SYS.
I forget the detail of why now. Possibly Faxworks related, or possibly not.

>> Attempting to print to LPT2 which is not connected to anything gave no
>> error, but obviously produced no output, at least not anywhere that I
>> could fine.
>> Attempting to print to LPT3, which is my Faxworks FxPrint queue gave
>> no error and no output either.
> 
> Just out of curiousity, what does the standard OS/2 "print" command do
> with these ports?

PRINT puts stuff via the spooler, so LPT2 does nothing; LPT3 fires up
Faxworks and tries to queue a fax to be sent.
LPT4 gives a hard error SYS0038 (can't find LPT4 - true as the driver is
no longer installed), followed by SYS1529 returned by the PRINT command.

>> Using COM1 and COM2 gave "Failed to open output port COM1: RC=32" as
>> they are in use by other programs.
>> Using COM3 it just hung for about a minute and then produced:
>>   Error writing to port: RC=234

COM1-4 all return SYS1529 with PRINT.

> Since you don't appear to have any USB printers, I think that's about
> it.

Nope.

> But the above was very helpful.  I now know that, at a minimum,
> my WritePort_Orthodox() function seems to work.  
> 
> Thank you!

You're welcome.
0
Paul
11/27/2011 3:49:52 PM
 >>> I tried it with the printer powered off and got
 >>> Error writing to port: RC=28

 >> Interesting, that seems to be an out-of-paper error.
 
 > Printing normally gives that error as well, so much be a parallel
 > port interface thing. What other error might one expect?

Printer offline.


--
0
A
11/27/2011 10:32:55 PM
On 26 Nov 2011 20:04:01 -0600, Alex Taylor wrote:

:>On Sat, 26 Nov 2011 14:42:00 UTC, Paul Ratcliffe 
:><abuse@orac12.clara34.co56.uk78> wrote:
:>
:>> On 26 Nov 2011 07:21:01 -0600, Alex Taylor <mail.me@reply.to.address> wrote:
:>> 
:>> > I'd really like to know if this technique does work with other port
:>> > types and it's just USB that's a problem... I don't suppose anyone
:>> > has a parallel printer they're willing to try this program on?
:>> 
:>> I don't mind testing something...
:>
:>http://users.socis.ca/~ataylo00/os2/printing/eprint_test.zip
:>Executable and source included.
:>
:>I tried to make the syntax similar to the standard "print"...
:> - To try sending a file to a printer port:
:>     eprint <filename> /d:<portname>
:> - To get a list of known ports:
:>     eprint /l

My results as follows:
[D:\]eprint
/l
------------------------------------------------------------------------------

Port Name                        Port
Driver
------------------------------------------------------------------------------

SLPR1                            D:\OS2\DLL\SLPR.PDR
CUPS4                            D:\OS2\DLL\CUPS.PDR
CUPS3                            D:\OS2\DLL\CUPS.PDR
CUPS2                            D:\OS2\DLL\CUPS.PDR
CUPS1                            D:\OS2\DLL\CUPS.PDR
\PIPE\LPD0                       D:\TCPIP\DLL\LPRPDRVR.PDR
FILE
COM2                             D:\OS2\DLL\SERIAL.PDR
COM1                             D:\OS2\DLL\SERIAL.PDR
LPT3                             D:\OS2\DLL\PARALLEL.PDR
LPT2                             D:\OS2\DLL\PARALLEL.PDR
LPT1                            
D:\OS2\DLL\PARALLEL.PDR
------------------------------------------------------------------------------


Interestingly, physically I have only LPT1, and COM1-3. COM3 is not shown
here but is shown in the hardware manager. Com2/3 use high addresses and
interrupts (DC00/11 and D880/10), but if Com2 shows up I'd expect Com3 too.
LPT1 sits on D800, no interrupts

eprint d:\config.sys /d:LPT1 doesn't do anything, the light on my Canon
IP4000 doesn't blink. Normally it is connected to a router with LPT port. It
is possible my LPT1 port doesn't work, it's a fairly new machine and I
haven't used that port yet for OS/2.

Mat Nieuwenhoven


0
Mat
11/28/2011 6:48:59 PM
On Sun, 27 Nov 2011 13:25:47 UTC, "Heikki Kekki" <kekkihei@sgic.fi.invalid> 
wrote:

> I tried "eprint eprint.c /d:LPT1" and got two pages of eight correct 
> text, first page immediately and second after a while.
> 
> Usb "eprint eprint.c /d:HP_CLJ_2550_1" gave same result. Printer is HP 
> Color Laserjet 2550 Ln.

Sorry but I just want to be clear: are you saying that printing to
a USB port actually produced output?

Thanks.
-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/29/2011 12:32:02 PM
On Sun, 27 Nov 2011 15:49:52 UTC, Paul Ratcliffe 
<abuse@orac12.clara34.co56.uk78> wrote:

> Printing normally gives that error as well, so much be a parallel port
> interface thing. What other error might one expect?

You're right, now that I think about it.  The spooler message for that
error code is, IIRC, "Printer offline, jammed, or out of paper."


> > But the above was very helpful.  I now know that, at a minimum,
> > my WritePort_Orthodox() function seems to work.  



Some more findings... instead of trying with an ASCII text file, I
used Windows to create a printer-specific job file for my cheap-ass 
USB inkjet, and tried using EPRINT to print that to my USB port.

In this case, the printer actually reacts.  The print head makes its
"waking up" noise, and the job light starts flashing.  Unfortunately,
that's all it does.  It just keeps sitting there, job light flashing,
indefinitely.

So it looks like SplPdOpen/SplPdWrite is writing _something_ to the
printer.  I seem to be missing some critical step, however.


I also tried disabling the SplPd* stuff and using PrtOpen/PrtWrite for
all driver types.  This time, I changed the PrtOpen flags from
OPEN_ACTION_CREATE_IF_NEW (which is what the sample code shows) to
OPEN_ACTION_FAIL_IF_NEW.  This prevents it from creating a new file 
with the same name as the USB port.  It doesn't make it print to the USB
port... but, interestingly, trying to print like that with the printer
turned off causes the program to stall for several moments, as if it is
genuinely trying to open the USB connection to the printer.

I also tried this method to print to a LPR32 port, which works.  So
it looks like the Prt* functions do work with "new style" port drivers,
it's just the USBPRT driver in particular that seems to fail.

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/29/2011 12:42:01 PM
On Tue, 29 Nov 2011 12:32:02 UTC, "Alex Taylor" 
<mail.me@reply.to.address> wrote:

> On Sun, 27 Nov 2011 13:25:47 UTC, "Heikki Kekki" <kekkihei@sgic.fi.invalid> 
> wrote:
> 
> > I tried "eprint eprint.c /d:LPT1" and got two pages of eight correct 
> > text, first page immediately and second after a while.
> > 
> > Usb "eprint eprint.c /d:HP_CLJ_2550_1" gave same result. Printer is HP 
> > Color Laserjet 2550 Ln.
> 
> Sorry but I just want to be clear: are you saying that printing to
> a USB port actually produced output?

Yes, printing to USB port produced output, similar to Lpt1, two pages of
eight. 

-- 
Hessu
0
Heikki
11/29/2011 8:59:43 PM
On Tue, 29 Nov 2011 20:59:43 UTC, "Heikki Kekki" <kekkihei@sgic.fi.invalid> 
wrote:

> > Sorry but I just want to be clear: are you saying that printing to
> > a USB port actually produced output?
> 
> Yes, printing to USB port produced output, similar to Lpt1, two pages of
> eight. 


OK, could everyone please try this build:
http://users.socis.ca/~ataylo00/os2/printing/eprint_test.zip

I think I may have figured it out now.

First of all, I had a silly bug in my read/write loop.  I misread the 
DosRead API documentation and erroneously thought that ERROR_MORE_DATA 
was returned if end-of-file had not been reached.  Turns out that's only
when reading from a PIPE, not a file.  So basically, the loop was only
ever writing the first 4096 bytes to the port.  Small wonder we were 
getting odd results.

Also, I had a chance (for the first time in a few weeks) to test with
another USB laser printer at one of my workplaces.  This one behaves
somewhat differently from my cheap home inkjet.  

With the laser printer, using the Prt** functions seems to work just 
fine for printing through USB (besides the truncated data I was getting
as per above).  OTOH, with my home inkjet, PrtOpen returns DosError 110,
but changing to the SplPd** functions directly does work (now that I've
fixed the read/write loop).  What the difference could be, I don't know.

The current build uses the same logic as before: use Prt** for old-style
port drivers (basically COM* and LPT*, probably \PIPE\LPD* as well), and
the SplPd** functions for new-style port drivers (most others, including
SLPR, USB and IrDA).

For the next version I will probably change this to always TRY using the 
Prt** functions first, falling back to the SplPd** method if I get an 
error 110 on PrtOpen.  Sound reasonable?


BTW, the newest version no longer uses static 4KB buffers for reading
and writing.  It uses an allocated buffer (64KB by default) that can be
specified on the command line with /B:xx.  

I also added a verbose option /X which prints out some trace info.


Thanks again, all!

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
12/14/2011 12:14:01 PM
Hallo Alex,

> The current build uses the same logic as before: use Prt** for old-style
> port drivers (basically COM* and LPT*, probably \PIPE\LPD* as well), and
> the SplPd** functions for new-style port drivers (most others, including
> SLPR, USB and IrDA).
>
> For the next version I will probably change this to always TRY using the
> Prt** functions first, falling back to the SplPd** method if I get an
> error 110 on PrtOpen.  Sound reasonable?

I guess you already know my opinion: yes, I like your suggestion for the 
next version.
Let's be as "standard" as we can with OS/2 ...

Lars 

0
Lars
12/14/2011 10:20:53 PM
On Wed, 14 Dec 2011 12:14:01 UTC, "Alex Taylor" 
<mail.me@reply.to.address> wrote:

> OK, could everyone please try this build:
> http://users.socis.ca/~ataylo00/os2/printing/eprint_test.zip

Results as follows:

eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:LPT1
4198 bytes plain text, first page immediately and last page (9 lines) 
more than minute after.

eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:HP_CLJ_2550_1
Error writing to port: RC=21

Change HP Color Laserjet printer object output port to usb 
(HP_CLJ_2550_1)

eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:HP_CLJ_2550_1
4198 bytes plain text, first page immediately and last page (9 lines) 
more than minute after.

On paper prints look exactly same.

eprint eprint.c /D:HP_CLJ_2550_1
Eight pages immediately and last page after a minute.


-- 
Hessu
0
Heikki
12/15/2011 6:56:11 PM
On Thu, 15 Dec 2011 18:56:11 UTC, "Heikki Kekki" <kekkihei@sgic.fi.invalid> 
wrote:

> eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:LPT1
> 4198 bytes plain text, first page immediately and last page (9 lines) 
> more than minute after.

That delay before the last page is odd.  You seem to get it quite 
consistently.  (I haven't really tested with multipage documents here.)

I wonder if I need to perform some extra step when ending the document?


> eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:HP_CLJ_2550_1
> Error writing to port: RC=21

That's a "drive not ready" error.

Dumb question maybe, but was the printer connected (via USB) and
turned on at the time?


> Change HP Color Laserjet printer object output port to usb 
> (HP_CLJ_2550_1)
> 
> eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:HP_CLJ_2550_1
> 4198 bytes plain text, first page immediately and last page (9 lines) 
> more than minute after.

I'm not quite clear on what changed here.  Why did it work the
second time?  What exactly was different?


Thanks for the feedback.
-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
12/17/2011 12:21:01 AM
On Sat, 17 Dec 2011 00:21:01 UTC, "Alex Taylor" 
<mail.me@reply.to.address> wrote:

> On Thu, 15 Dec 2011 18:56:11 UTC, "Heikki Kekki" <kekkihei@sgic.fi.invalid> 
> wrote:
> 
> > eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:LPT1
> > 4198 bytes plain text, first page immediately and last page (9 lines) 
> > more than minute after.
> 
> That delay before the last page is odd.  You seem to get it quite 
> consistently.  (I haven't really tested with multipage documents here.)
> 
> I wonder if I need to perform some extra step when ending the document?

If I print one page document, it takes about two minutes get it out.
 
> > eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:HP_CLJ_2550_1
> > Error writing to port: RC=21
> 
> That's a "drive not ready" error.
> 
> Dumb question maybe, but was the printer connected (via USB) and
> turned on at the time?

Yes.
 
> > Change HP Color Laserjet printer object output port to usb 
> > (HP_CLJ_2550_1)
> > 
> > eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:HP_CLJ_2550_1
> > 4198 bytes plain text, first page immediately and last page (9 lines) 
> > more than minute after.
> 
> I'm not quite clear on what changed here.  Why did it work the
> second time?  What exactly was different?

Only the printer object outputport.

Yesterday that trick didn't work, even when I had printed from (a)e.exe 
via USB, eprint gave error RC=21. Switching usb-cable off and on helped.

Today I had printed two pictures from PMView via Lpt1. Printer was 
switched on and a couple of hours later:

eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:HP_CLJ_2550_1 /X
Read 2218/65536 bytes from file [0] : Wrote 2218/2218 bytes to port [0]

One, not full page after two minutes.
 
So far last page has always been delayed.

-- 
Hessu
0
Heikki
12/18/2011 3:31:59 PM
On Sun, 18 Dec 2011 15:31:59 UTC, "Heikki Kekki" <kekkihei@sgic.fi.invalid> 
wrote:

> > That delay before the last page is odd.  You seem to get it quite 
> > consistently.  (I haven't really tested with multipage documents here.)
> 
> If I print one page document, it takes about two minutes get it out.
>  
> > > eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:HP_CLJ_2550_1
> > > Error writing to port: RC=21
> > > Change HP Color Laserjet printer object output port to usb 
> > > (HP_CLJ_2550_1)
> > > 
> > > eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:HP_CLJ_2550_1
> > > 4198 bytes plain text, first page immediately and last page (9 lines) 
> > > more than minute after.
> > 
> > I'm not quite clear on what changed here.  Why did it work the
> > second time?  What exactly was different?
> 
> Only the printer object outputport.

That should be irrelevant.  EPRINT doesn't touch or even look at the
printer object or spooler queue configuration.  It bypasses all of that.

I double-checked today by printing to a USB port which wasn't associated
with any object/queue, and it came out of the printer just fine.

I think the fact that it worked after you made the change must've been
a coincidence; your next observation supports that:

> Yesterday that trick didn't work, even when I had printed from (a)e.exe 
> via USB, eprint gave error RC=21. Switching usb-cable off and on helped.
> 
> Today I had printed two pictures from PMView via Lpt1. Printer was 
> switched on and a couple of hours later:
> 
> eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:HP_CLJ_2550_1 /X
> Read 2218/65536 bytes from file [0] : Wrote 2218/2218 bytes to port [0]

That message is... odd.  I assume the file size is 2218 bytes.  But in
that case, the buffer should be reported as 2218 bytes, not 65536.


> One, not full page after two minutes.
>  
> So far last page has always been delayed.

Printing multi-page documents with EPRINT here, they all come out of
the printer right away.

Another dumb question: these files you're printing (all with the
extension .SLT, looks like)... I assume they are already in the 
printer's own native rendering format?  


I really can't duplicate the problems you're having.  I'd appreciate
some reports from other users so I can get a sense of whether this is
peculiar to your environment...

I've updated the file again today (I'll post in another message); you
might want to try with that.  I don't think it contains any changes 
that might fix this weird issues of yours, but it might have slightly
more informative message output.

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
12/19/2011 3:32:09 PM
 >> If I print one page document, it takes about two minutes get it 
out.

 > I really can't duplicate the problems you're having.  I'd 
appreciate
 > some reports from other users so I can get a sense of whether this
 > is peculiar to your environment...

You don't have a benchmark, so for all you know about two minutes may 
be twice as fast as usually using a HP driver. FWIW, it's possible the
problem is solved in a driver version you aren't using. For starters, 
a question could be if this is an expected delay. It may be normal, so
you may not need "reports from other users" nor the classic 
reproducability at all.
 

--
0
A
12/19/2011 7:37:51 PM
On Mon, 19 Dec 2011 15:32:09 UTC, "Alex Taylor" 
<mail.me@reply.to.address> wrote:

> On Sun, 18 Dec 2011 15:31:59 UTC, "Heikki Kekki" <kekkihei@sgic.fi.invalid> 
> wrote:
  
> That should be irrelevant.  EPRINT doesn't touch or even look at the
> printer object or spooler queue configuration.  It bypasses all of that.
> 
> I double-checked today by printing to a USB port which wasn't associated
> with any object/queue, and it came out of the printer just fine.
> 
> I think the fact that it worked after you made the change must've been
> a coincidence; your next observation supports that:
> 
> > Yesterday that trick didn't work, even when I had printed from (a)e.exe 
> > via USB, eprint gave error RC=21. Switching usb-cable off and on helped.
> > 
> > Today I had printed two pictures from PMView via Lpt1. Printer was 
> > switched on and a couple of hours later:
> > 
> > eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:HP_CLJ_2550_1 /X
> > Read 2218/65536 bytes from file [0] : Wrote 2218/2218 bytes to port [0]
> 
> That message is... odd.  I assume the file size is 2218 bytes.  But in
> that case, the buffer should be reported as 2218 bytes, not 65536.

eprint G:\1FOR_YOU\1KIRJANP\MKS2010.SLT /D:HP_CLJ_2550_1 /X
Found port HP_CLJ_2550_1 --> E:\OS2\DLL\USBPRT.PDR
Read 2218/2218 bytes from file [0] : Wrote 2218 bytes to port [0]
Read 0/2218 bytes from file [0] : Wrote 0 bytes to port [0]

Same delay as previous version.

eprint G:\1FOR_YOU\1KIRJANP\MKS2009.SLT /D:HP_CLJ_2550_1 /X
Found port HP_CLJ_2550_1 --> E:\OS2\DLL\USBPRT.PDR
Read 4197/4197 bytes from file [0] : Wrote 4197 bytes to port [0]
Read 0/4197 bytes from file [0] : Wrote 0 bytes to port [0]

Last page delays as previous version.

> Another dumb question: these files you're printing (all with the
> extension .SLT, looks like)... I assume they are already in the 
> printer's own native rendering format?  

Plain text files from dos program called "Ykk�nen", One in enlish, main 
program 1.exe. I use it book-keeping and billing. .SLT is 
"saldoluettelo", list of balances in english. It is print preview and 
ready for HP Laserjet printer. Prints from Ykk�nen and via eprint are 
identical.
 


-- 
Hessu
0
Heikki
12/19/2011 7:57:07 PM
On Mon, 19 Dec 2011 19:37:51 UTC, "A.D. Fundum" <what.ever@neverm.ind> 
wrote:

>  >> If I print one page document, it takes about two minutes get it 
> out.
> 
>  > I really can't duplicate the problems you're having.  I'd 
> appreciate
>  > some reports from other users so I can get a sense of whether this
>  > is peculiar to your environment...
> 
> You don't have a benchmark, so for all you know about two minutes may 
> be twice as fast as usually using a HP driver. FWIW, it's possible the
> problem is solved in a driver version you aren't using. For starters, 
> a question could be if this is an expected delay. It may be normal, so
> you may not need "reports from other users" nor the classic 
> reproducability at all.

From dos program text file prints immediately, via spooler also. 
Printing invoice with bar code makes no diffrence.


-- 
Hessu
0
Heikki
12/22/2011 8:29:58 AM
 > From dos program text file prints immediately, via spooler
 > also. Printing invoice with bar code makes no diffrence.

So the delay is avoidable, and it should be solved. Just wondering: is
the last character of the text file an EOF (26)?

/* LASTCHAR.CMD (not tested) */
CALL CharOut '','What file? '
PARSE PULL filename
IF Pos('"',filename',1)>0 THEN DO
   PARSE VAR filename '"' filename '"' .
END
   size=Stream(filename'C','QUERY SIZE')
IF size<>'' THEN SAY 'Last:' C2D(CharIn(filename,size,1))

If not,(what's the last character,) and assuming the last page is 
always printed with a delay: what happens if you print a space 
character, and add an EOF to this near-empty text file (or print a dot
instead of a space, if your printer ignores blank pages)? To create 
such a file:

REXXTRY CALL CharOut 'Print.Me!',' '||D2C(26)

Or try printing this file twice, quickly (i.e. clearly within the 
delay of a few minutes):

REXXTRY CALL CharOut 'PrintMe!.too',' '

Considerations: maybe the printer is waiting for an (explicit 
end-of-job XOR time-out) when this OS/2 method is in use.  If so, the 
created file "Print.Me!" should eject faster because it adds an EOF. 
The file "PrintMe!.too" can produce 2 pages (one page per job), or one
page (with a job implicitly continued within the delay). Again, 
replace the spaces between the '' characters with e.g. a dot if your 
printer ignores blank pages.

BTW, chances are the local helpdesk of the manufacturer of your 
printer (HP, isn't it?) is more than willing to help the author of a 
(generic) printer "driver", without you (the developer) having to RTFM
of a product you don't own). Just tell what you (the developer) are 
doing, and try to not mention OS/2 (too easy to say it isn't 
supported). Try explaining it in a generic way instead.


--
0
A
12/22/2011 4:29:51 PM
On 12/22/2011 11:29 AM, A.D. Fundum wrote:
>   >   From dos program text file prints immediately, via spooler
>   >  also. Printing invoice with bar code makes no diffrence.
>
> So the delay is avoidable, and it should be solved. Just wondering: is
> the last character of the text file an EOF (26)?

Good thought; the printer may well buffer the last page for a certain 
time interval if it doesn't receive a FF or EOF.  I forget how OP is 
generating the print data, you'd think the application would take care 
of this automatically.

0
Peter
12/22/2011 8:42:21 PM
On Sat, 17 Dec 2011 00:21:01 UTC in comp.os.os2.programmer.misc, "Alex Taylor" 
<mail.me@reply.to.address> wrote:

> That delay before the last page is odd.  You seem to get it quite 
> consistently.  (I haven't really tested with multipage documents here.)

I remember that on Windows 9x a long time ago, there used to be an option in 
various printer drivers, probably postscript ones, that said something like 
"Send Ctrl-D at end of job" and that option fixed problems exactly like this.

-- 
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
0
Trevor
12/22/2011 10:44:46 PM
On Thu, 22 Dec 2011 22:44:46 UTC, "Trevor Hemsley" 
<Trevor.Hemsley@mytrousers.ntlworld.com> wrote:

> > That delay before the last page is odd.  You seem to get it quite 
> > consistently.  (I haven't really tested with multipage documents here.)
> 
> I remember that on Windows 9x a long time ago, there used to be an option 
> in various printer drivers, probably postscript ones, that said something 
> like "Send Ctrl-D at end of job" and that option fixed problems exactly 
> like this.

Maybe I should consider adding a switch for that, but really, I think
that should be the responsibility of whatever generates the job file
(the printer driver or application).

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
12/23/2011 4:38:01 AM
On 12/22/2011 11:38 PM, Alex Taylor wrote:
> On Thu, 22 Dec 2011 22:44:46 UTC, "Trevor Hemsley"
> <Trevor.Hemsley@mytrousers.ntlworld.com>  wrote:
>
>>> That delay before the last page is odd.  You seem to get it quite
>>> consistently.  (I haven't really tested with multipage documents here.)
>>
>> I remember that on Windows 9x a long time ago, there used to be an option
>> in various printer drivers, probably postscript ones, that said something
>> like "Send Ctrl-D at end of job" and that option fixed problems exactly
>> like this.
>
> Maybe I should consider adding a switch for that, but really, I think
> that should be the responsibility of whatever generates the job file
> (the printer driver or application).
>

IMHO, the driver.  If it's the application and you redirect the output 
to a file you get a ^D stuck on the end.
0
Peter
12/23/2011 12:27:41 PM
On Thu, 22 Dec 2011 20:42:21 UTC, Peter Flass <Peter_Flass@Yahoo.com> 
wrote:

> On 12/22/2011 11:29 AM, A.D. Fundum wrote:
> >   >   From dos program text file prints immediately, via spooler
> >   >  also. Printing invoice with bar code makes no diffrence.
> >
> > So the delay is avoidable, and it should be solved. Just wondering: is
> > the last character of the text file an EOF (26)?
> 
> Good thought; the printer may well buffer the last page for a certain 
> time interval if it doesn't receive a FF or EOF.  I forget how OP is 
> generating the print data, you'd think the application would take care 
> of this automatically.

I put FF (ascii 12) at end of last line and file printed immediatly.
  

-- 
Hessu
0
Heikki
12/23/2011 12:37:15 PM
 > IMHO, the driver.  If it's the application and you redirect the
 > output to a file you get a ^D stuck on the end.

Right, an OS (and its components) should take care of this, assuming 
the underlying design isn't broken. 

If apps suddenly have to have embedded printer-specific code to solve 
this, we'll be back in the 80s with apps supporting just a few 
outdated printers.


--
0
A
12/23/2011 5:08:42 PM
 > I put FF (ascii 12) at end of last line and file printed 
immediatly.

So in this case the OS should make sure the last character is an 
end-of-job character, even if your printer has a hardware formfeed 
button.

I don't have such a printer, but maybe another trick is to PrtOpen() 
and PrtClose() right after the first, real PrtClose()? IMhO this will 
only work if the previous job isn't continued then, and the printer 
interpretes the start-of-job (second PrtOpen()) as an implied 
end-of-previous-job signal. Possible advantage: no characters added to
the output, no matter what the printer's mode is.

There are printers with a hexdump facility. If your printer has such a
facility, you could actually check what other apps are adding in a few
situations.


--
0
A
12/23/2011 5:22:44 PM
On Fri, 23 Dec 2011 12:27:41 UTC, Peter Flass <Peter_Flass@Yahoo.com> wrote:

> >> I remember that on Windows 9x a long time ago, there used to be an 
> >> option in various printer drivers, probably postscript ones, that said 
> >> something like "Send Ctrl-D at end of job" and that option fixed 
> >> problems exactly like this.
> >
> > Maybe I should consider adding a switch for that, but really, I think
> > that should be the responsibility of whatever generates the job file
> > (the printer driver or application).
> 
> IMHO, the driver.  If it's the application and you redirect the output 
> to a file you get a ^D stuck on the end.

Well, what I really meant was "or the application in the case where the
app uses its own built-in driver".  So in fact it was probably redundant. 
<g>

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
12/24/2011 3:51:02 AM
On Fri, 23 Dec 2011 17:08:42 UTC, "A.D. Fundum" <what.ever@neverm.ind> wrote:

>  > IMHO, the driver.  If it's the application and you redirect the
>  > output to a file you get a ^D stuck on the end.
> 
> Right, an OS (and its components) should take care of this, assuming 
> the underlying design isn't broken. 
> 
> If apps suddenly have to have embedded printer-specific code to solve 
> this, we'll be back in the 80s with apps supporting just a few 
> outdated printers.

I think it is fair for me to at least provide a switch that allows adding 
a FF or EOT byte on the end.  In retrospect, plain (ASCII) text files 
obviously haven't been processed by a driver at all, so something is
probably going to have to be done to tell the printer the job is complete.

OTOH, it'll have to be the user's responsibility to know when that
switch is necessary.  (They should presumably know when they're printing
ASCII text files rather than formatted jobs.)

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
12/24/2011 3:51:04 AM
On Mon, 19 Dec 2011 19:57:07 UTC, "Heikki Kekki" <kekkihei@sgic.fi.invalid> 
wrote:

> > Another dumb question: these files you're printing (all with the
> > extension .SLT, looks like)... I assume they are already in the 
> > printer's own native rendering format?  
> 
> Plain text files from dos program called "Ykknen", One in enlish, main 
> program 1.exe. I use it book-keeping and billing. .SLT is 
> "saldoluettelo", list of balances in english. It is print preview and 
> ready for HP Laserjet printer. Prints from Ykknen and via eprint are 
> identical.

Ah, OK.  So in that case, I think it probably is likely that manual
addition of a termination code -- presumably either ^D (end of 
transmission) or ^L (form feed) -- would be needed, since the printer
would by necessity have to treat this as an uncoded data stream rather
than a formatted job.

I guess I'll add a parameter for that.  It'll have to be incumbent on
the user to know when they're printing plain text and add that parameter
where appropriate -- there's no practical way that I can see for my 
program to know whether a file is printer-encoded or plain text.

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
12/24/2011 3:51:04 AM
 >> Right, an OS (and its components) should take care of this,
 >> assuming the underlying design isn't broken. 
 
 > I think it is fair for me to at least provide a switch that allows
 > adding a FF or EOT byte on the end.

If it's an EXE, yes. I'ld recommend using EOJ, or a flexible byte 
(e.g. /04), because a FF may eject an empty page.

 > In retrospect, plain (ASCII) text files obviously haven't been
 > processed by a driver at all, so something is probably
 > going to have to be done to tell the printer the job is
 > complete.

I don't own a modern printer and I don't have a need to print DBCS 
characters, but chances are non-printable characters indicate some 
graphic mode. If the file contains <Esc>E, it may reset the printer, 
but it's also save to assume other required characters were appended 
too.

if (non-printable_characters) /* Esc characters e.a.? */
   assume(as-is);
else
   if (first_2_bytes=="%!") /* PostScript? */
      assume(as-is);
else
   if (last_character!=EOJ)
      append(EOJ);

I'm not sure if this covers all modern situations.

 > it'll have to be the user's responsibility to know when
 > that switch is necessary.  (They should presumably
 > know when they're printing ASCII text files rather than
 > formatted jobs.)

Using an EXE and CMD.EXE.

You may want to look at x:\OS2\PRINT.COM's /B switch. It's like what 
you are suggesting now, it avoids not being compatible with a new 
graphic file format, and it shows what's acceptable. I should be able 
to print a file using your PRINT.COM, and you may assume I (should) 
know how PRINT.COM works. Not doing anything is safe (object dropped 
on your PRINT.COM). The user apparently  just has to wait a few 
minutes for the printed invoice, or a hardware EOJ-button has to be 
pressed.

Please note my remark regarding the OS was aimed at apps having to 
support printers again, while it may be possible to detect all modern 
modes. I don't expect to see an image of a lovely tree if I send 
"AAAA" to my printer. No special characters, no known special file 
headers, and doing nothing is a safe strategy. Albeit not the best 
strategy, it isn't that hard to at least check if e.g. all characters 
are printable (isprint() may not be your only friend in that area) 
with predictable output. That's important, I'ld say. Me printing AAAAs
produces predictable output, so it's possible to add a EOJ character. 
If needed, of course.


--
0
A
12/30/2011 1:14:07 AM
On Fri, 30 Dec 2011 01:14:07 UTC, "A.D. Fundum" <what.ever@neverm.ind> wrote:

>  > I think it is fair for me to at least provide a switch that allows
>  > adding a FF or EOT byte on the end.
> 
> If it's an EXE, yes. I'ld recommend using EOJ, or a flexible byte 
> (e.g. /04), because a FF may eject an empty page.

By EOJ I assume you mean 0x04 (a.k.a. EOT or ^L).  I've now added switches
for both that and FF.

> I don't own a modern printer and I don't have a need to print DBCS 
> characters, but chances are non-printable characters indicate some 
> graphic mode. If the file contains <Esc>E, it may reset the printer, 
> but it's also save to assume other required characters were appended 
> too.
> 
> if (non-printable_characters) /* Esc characters e.a.? */
>    assume(as-is);
> else
>    if (first_2_bytes=="%!") /* PostScript? */
>       assume(as-is);
> else
>    if (last_character!=EOJ)
>       append(EOJ);

I have no desire to implement any kind of data parsing.  My program
disclaims all responsibility for the file format, and I don't want to
go down that slippery slope at all.


> You may want to look at x:\OS2\PRINT.COM's /B switch. It's like what 
> you are suggesting now, 

I don't think that's the same.  Reading the command help, it looks as
though PRINT.COM normally stops reading the INPUT file when it hits a
^Z character, and /B tells it to read the whole file.  

My program always reads the whole file -- stopping on ^Z is ugly 
DOS-legacy stuff which IMHO should really never be necessary these days.

But has nothing to do with telling the PRINTER how to terminate the job.

Anyway, the next version of EPRINT will support the following options:

EPRINT - Enhanced PRINT version 0.4.0

Usage:  EPRINT <filename> /D:<port> [ /B:<size> ] [ /F ] [ /Z ] [ /X ]
        EPRINT /L

  /B:<size>  Set maximum read/write buffer size (default: 64 KB).
  /D:<port>  Attempt to print <filename> to port <port>.
  /F         Append a form feed (^L) to the print job.
  /L         Show a list of valid ports known to the system.
  /X         Show extra debugging information.
  /Z         Append an end-of-transmission byte (^D) to the print job (may 
             be required for plain text files).

I tested an ASCII file on my cheap inkjet but as before it refuses to 
print it at all... I guess it simply doesn't support ASCII printing.
(Not entirely surprising for a $70 printer.)

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
12/31/2011 1:53:01 AM
 > By EOJ I assume you mean 0x04 (a.k.a. EOT or ^L).

Or ^Z. Did the file you wanted testers to used end with a ^Z?

 >  I've now added switches for both that and FF.

An added FF may cause a blank page if the previous page was already 
full. If anything, you don't know the number of lines the printer 
supports at that moment, and the user may not know if a FF causes a 
blank page.

 > I have no desire to implement any kind of data parsing.

If PRINT.COM's mode is not a binary file, as its /B switch indicates, 
I cannot see a single problem regarding checking for at least an EOJ 
character (whithout wanting to define it that's ^Z or not, I don't own
such a printer). Other apps/drivers seem to have the required desire, 
since your app seemed to be the unexpected exception regarding the 
delay.

 >> You may want to look at x:\OS2\PRINT.COM's /B switch. 

 > I don't think that's the same.

Yes and no, /B also indicates if characters should be interpreted (by 
both the data reader and the output device?).    
 
 > But has nothing to do with telling the PRINTER how to terminate
 > the job.

Possibly wrong: if a ^Z means EOF (no /B used), you could add a ^Z if 
it's missing. After all the lack of a /B switch indicates ^Z should be
interpreted as an EOF. That was what I was thinking about, not the 
fopen(xxx,"b") mode.

If you're trying to write a PRINT.COM-like app, I'ld also suggest to 
not use /B (and PRINT.COM's other switches) for another purpose. What 
about /S (for Size of buffer)?

The EOJ-byte.I cannot confirm if that's indeed an EOJ character for 
his printer: what about  adding the byte to a switch, so the user can 
specify whatever a specific printer requires and you don't need a 
switch for every possible EOJ character combination? E.g.:

/X[xxx]: end-of-job ASCII character xxx, default: <whatever, e.g. a 12
or FormFeed>

I mentioned the EOF first, but apparently that wasn't tested. A FF may
occur in the middle of the job and ejects the page, a EOF should of 
course imply an EOJ/EOP(age).  


--
0
A
1/4/2012 3:09:48 AM
On Wed, 4 Jan 2012 03:09:48 UTC, "A.D. Fundum" <what.ever@neverm.ind> wrote:

>  > By EOJ I assume you mean 0x04 (a.k.a. EOT or ^L).
> 
> Or ^Z. Did the file you wanted testers to used end with a ^Z?

^Z (0x1a) is the substitute byte, which should be meaningless in this 
context.  I know DOS (and some OS/2 applications) uses it as an EOF
marker but that should have no relevance to how a printer interprets
it.


>>  I've now added switches for both that and FF.
> 
> An added FF may cause a blank page if the previous page was already 
> full. If anything, you don't know the number of lines the printer 
> supports at that moment, and the user may not know if a FF causes a 
> blank page.

That's the user's business, not mine.


>  > I have no desire to implement any kind of data parsing.
> 
> If PRINT.COM's mode is not a binary file, as its /B switch indicates, 
> I cannot see a single problem regarding checking for at least an EOJ 
> character (whithout wanting to define it that's ^Z or not, I don't own
> such a printer). Other apps/drivers seem to have the required desire, 
> since your app seemed to be the unexpected exception regarding the 
> delay.

What other apps/drivers?  There's PRINT.COM and then there's my 
program.  What other apps are there to dump a raw data stream to a 
printer port?


>  >> You may want to look at x:\OS2\PRINT.COM's /B switch. 
> 
>  > I don't think that's the same.
> 
> Yes and no, /B also indicates if characters should be interpreted (by 
> both the data reader and the output device?).    

What's your source for that?  The PRINT command documentation says 
nothing to that effect...


>  > But has nothing to do with telling the PRINTER how to terminate
>  > the job.
> 
> Possibly wrong: if a ^Z means EOF (no /B used), you could add a ^Z if 
> it's missing. After all the lack of a /B switch indicates ^Z should be
> interpreted as an EOF. That was what I was thinking about, not the 
> fopen(xxx,"b") mode.

Again, I'd be quite surprised if ^Z had any meaning to a typical printer.
Its ASCII control value is as a character substitute, which is to say
it's a effectively a data byte rather than a command byte.

That's not to say that SOME printers might not use it for something
like that.  The trouble is, I'm not sure what standard(s) there are,
if any, for printers when it comes to supporting a plain ASCII job 
stream.

It seems that some, including my cheap-ass home inkjet, don't accept
anything at all that's not in its native PJL.  I suppose there's a
certain logic in that, as coding the intelligence into the hardware
to recognize ASCII is going to add work and thus cost.


> If you're trying to write a PRINT.COM-like app, I'ld also suggest to 
> not use /B (and PRINT.COM's other switches) for another purpose. What 
> about /S (for Size of buffer)?

I'm not trying to perfectly duplicate PRINT.COM because I default to
assuming the file is binary.  


> The EOJ-byte.I cannot confirm if that's indeed an EOJ character for 
> his printer: what about  adding the byte to a switch, so the user can 
> specify whatever a specific printer requires and you don't need a 
> switch for every possible EOJ character combination? E.g.:
> 
> /X[xxx]: end-of-job ASCII character xxx, default: <whatever, e.g. a 12
> or FormFeed>

Yeah, that's not a bad idea in principle.  I've already been 
considering it... I do think having an explicit one for ^D is 
appropriate though.


-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
1/4/2012 7:05:01 AM
 >> I have no desire to implement any kind of data parsing.

 > Other apps/drivers seem to have the required desire

Just to answer the only question really worth answering, mainly 
because Alex' reply is missing here: which apps/driver? Your tester's 
"From dos program text file prints immediately, via spooler also. 
Printing invoice with bar code makes no diffrence.". Your solution is 
the broken solution (or the user's problem, whatever that means), 
because it's the only exception and the result wasn't expected. 
Apparently no problem with text files, no problem with graphic files, 
and no clear need to add any special character...


--
0
A
1/12/2012 3:26:59 AM
On Thu, 12 Jan 2012 03:26:59 UTC, "A.D. Fundum" <what.ever@neverm.ind> wrote:

>  >> I have no desire to implement any kind of data parsing.
> 
>  > Other apps/drivers seem to have the required desire
> 
> Just to answer the only question really worth answering, mainly 
> because Alex' reply is missing here: which apps/driver? Your tester's 
> "From dos program text file prints immediately, via spooler also. 
> Printing invoice with bar code makes no diffrence.". Your solution is 
> the broken solution (or the user's problem, whatever that means), 
> because it's the only exception and the result wasn't expected. 
> Apparently no problem with text files, no problem with graphic files, 
> and no clear need to add any special character...

The quote give no indication whether this DOS program includes
printer drivers (most DOS programs that deal with printing do,
in fact, because DOS itself doesn't)... if it does, that rather
changes the context because we don't know what format the printer
actually receives the data in.

I'll let the user who posted that try with the latest version (which
has the switches) and see if that helps.

I'll release it soon, I just wanted to see if I could add a "print
to spooler" feature first.  

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
1/12/2012 12:05:01 PM
On 4 Jan 2012 01:05:01 -0600, Alex Taylor wrote:

,snip>
:>>>  I've now added switches for both that and FF.
:>> 
:>> An added FF may cause a blank page if the previous page was already 
:>> full. If anything, you don't know the number of lines the printer 
:>> supports at that moment, and the user may not know if a FF causes a 
:>> blank page.
:>
:>That's the user's business, not mine.

I suggest to add the FF only if the last character of the print job is NOT a
FF. Or at least allow this possibility. E.g. /L == autoFF, /LL = always FF

Mat Nieuwenhoven


0
Mat
1/30/2012 6:27:34 PM
 > I suggest to add the FF only if the last character of the print job
is
 > NOT a FF. Or at least allow this possibility. E.g. /L == autoFF,
 > /LL = always FF

ISTR he didn't want to "parse" the data. That implies a "different" 
behaviour, like possible extra blank pages, compared to most - if not 
all - other apps.

Again: if it's not a binary file (PRINT.COM's switch) and it's not a 
PostScript file, it's likely a last FF has to be interpreted as a FF. 
Or add a SCAN4FF.EXE in order to reduce the "user's business" (as if 
an user can control all print files).

Your /LL is not needed anyway, if he always adds the intended FF. IIRC
/FF is the choosen behaviour, and then there's no "no FF"-setting.

BTW, "auto" suggests if avoids all unneeded FFs. What if the page is 
full (a driver may notice that), and the next character is the last 
FF?


--
0
A
2/1/2012 4:50:20 PM
Reply:

Similar Artilces:

Writing to a USB port to simulate a USB keystroke?
Is this possible? If it is possible is it also possible to simulate mouse actions this same way? ...

USB port adapter -> Multi USB ports existing ? Extending number of USB ports possible ?
Unfortunately my notebook has only ONE USB port. Is there something like an USB port adapter which I can plug in into the one available USB port and which offers at the other side multiple USB ports ? Something like a simple, portable USB hub ? Tom [ excessive crossposting trimmed ] ["Followup-To:" header set to comp.os.linux.hardware.] On Sun, 14 Dec 2003 11:17:11 +0100, Thomas Jerkins staggered into the Black Sun and said: > Unfortunately my notebook has only ONE USB port. Is there something > like an USB port adapter which I can plug in into the one available > USB ...

Problems Reading/Writing Parallel Port Data, Status & control Registers Using In Port.vi and Out port.vi
Hi, Can anyone there help me Please with the problem. I am trying to communicate with the parallel port using my program which i have attached to the message. I am running LabVIEW 7.0 Professional with application builder. All the program does is reads and writes to the three parallel port registers. It runs FINE!!! in my computer. But when i built an executable (see attached) and tried running on a different computer (with LabVIEW Runtime engine 7.0 installed) the program does not read/write to the registers. The target PC had the parallel port in SPP mode just like mine. I can't seem to...

Libretto 110ct Enhanced Port Replicator & USB port
I have a Toshiba Libretto 110ct with the Enhanced Port Replicator. I have a clean install of W2k. I can't get it to recognise the USB port. When I plug in my Sandisk Cruzer(1.0 gb), nothing happens. I do have it connectted to external power. any ideas? ...

USB/Virtual Serial Port
I have a problem reading data from the STEVAL-MKI005V1 development board for the LIS3LV02DL accelerometer.&nbsp; &nbsp; It's a USB/virtual serial port connection to the PC.&nbsp; I started out testing the connection with hyper terminal, which worked.&nbsp; I even changed the COM# settings (i.e. 2, 3, and 8) and still everything works.&nbsp; However, once I try this in Labview, I do not get any data read in.&nbsp; I also do not get an error.&nbsp; I do get a status code, 1073676294, which I've learned is ok.&nbsp; I've tried numerous things to get th...

Openeing Usb Port
Hi, Can any body please help me out by answering the following queries I trying to communicate with a Usb Device attached with my PC, using Palm Emulator. Following is the code used by me (open Usb Port) SrmOpenConfigType configP; UInt16 newPortIdP; Err error; UInt32 value; UInt32 romVersion; configP.function = serFncUndefined; // Open Usb Port FtrGet(sysFileCSerialMgr, sysFtrNewSerialVersion, &value); FtrGet(sysFtrCreator, sysFtrNumROMVersion, &romVersion); error = ...

Openeing Usb Port
Hi, Can any body please help me out by answering the following queries I trying to communicate with a Usb Device attached with my PC, using Palm Emulator. Following is the code used by me (open Usb Port) SrmOpenConfigType configP; UInt16 newPortIdP; Err error; UInt32 value; UInt32 romVersion; configP.function = serFncUndefined; // Open Usb Port FtrGet(sysFileCSerialMgr, sysFtrNewSerialVersion, &value); FtrGet(sysFtrCreator, sysFtrNumROMVersion, &romVers...

ACE_Asynch_Read_Dgram::Result.remote_address(ACE_Addr& addr) writes zeros for Port & IP
Hi everybody, this is the first time I send a problem-report, so I hope everythings correct. The Problem is the following: When a asynchronous Read-Dgram completes, the corresponding ACE_Handler.handle_read_dgram() - method is called. If I understand it correctly, something like this code can be used in order to get the remote address: <snip> ACE_INET_Addr remoteAddr; result.remote_address(remoteAddr); [issue asynch write using this remote address] <snip> The Problem I get is this: The IP-Address and the Port is zero, resulting in errorno: 89 (EDESTADDRREQ)...

More Problems with Serial Port on Mac OS X Intel and USB Serial port Keyspan
I just received a keyspan USB serial convertor and I can now communicate with numerous devices use the terminal. However the TCL/TK applications still can not communicate with the devices. Is there some special command for communicating with a serial device properly or is just broke in TCL/TK Aqua on the mac? I used the test script from the tcl.tk web site with these results: Error in startup script: bad option "-mode": should be one of -blocking, -buffering, -buffersize, -encoding, -eofchar, or -translation while executing "fconfigure $serial -mode "57600,n,8...

labview 8.0 tdm &quot;flush&quot; to force OS to write to disk
Hello, &nbsp; I'm using&nbsp;a producer loop for data acquisition and a consumer loop to write it out to a TDM file.&nbsp;&nbsp;The&nbsp;WindowsXp page file increases from @480MB to @2GB which is no good. &nbsp; I am using LabVIEW 8.0 and do not have the TDMS functions available to me.&nbsp;&nbsp;As I understand it, there is a flush function for the TDMS that forces the OS to write to the disk immediately, thereby freeing&nbsp;the buffer that was holding the data.&nbsp; Is there a way to do this in&nbsp;Labview 8.0? &nbsp; Thanks, Chris&n...

All USB & only USB
We were kicking around some ideas today for low-performance embedded systems for quick and dirty solutions to simple tasks. We often throw a BasicX controller (http://www.basicx.com/) at such problems, which is fine until we need to communicate with the user; adding keypads, LCD displays, etc. is a bit of a PITA. So we started talking USB microcontrollers. Once you have a USB port, using USB keyboards, mice, 10-key keypads, etc. for input is a no brainer, but what of the display? A quick web search didn't turn up any obvious candidates. Then someone came up with the idea of using a U...

Drivers: MultiMac Intel PCIe Gigabit Ethernet Adapter &quot;OS/2 Community&quot; Driver for OS/2 &amp; eCS V0.1.6
++ From the VOICE OS/2-eCS News Service http://www.os2voice.org ++ From: madodelDESPAM@DESPAMptdprolog.net On hobbes there is a new OS/2 NDIS2 network driver for the Intel PCIe Gigabit Ethernet Adapter. A debug version of the driver is included. This is part of the Multimac network driver project. The Standard MAC Driver Project for eComStation "This is an NDIS driver for Intel Gigabit PCI-Express LAN adapters. This driver is based on the source code of e1000e Linux kernel module and of nveth NVIDIA NIC driver for OS/2 developed by nickk." According to the project we...

&quot;Error 7 occurred at Open File +.vi:Open File&quot; when opening a newly built application
Hello, &nbsp; After successfully building a standalone application in LabView 7.1, I get this error when I try to run my .exe file.&nbsp; I don't think any files are supposed to open upon execution except for my top level VI, which appears to open just fine, so I'm unsure why this error pops up.&nbsp; Does anyone have any ideas that might help or has anyone run into this error&nbsp;before? &nbsp; Thanks in advance! &nbsp; Jason ...

is better to open, write, close file than open, write, append, close?
Hello, Let's say that I have a very big string to write into a file. If I concatenate strings and write the string into file at the end of processing than memory use will increase exponential. - BAD If I open a file and instead concatenating strings I write it into a file. At the end of processing I close the file. Ok, this works, memory usage increases but not exponential. Another method is to open a file, write string and close file. This actions repeats until the end of script processing. Which is best? I hope you understood because my english is not very good. Iulian Ilea wrote...

Web resources about - How to open & write to a USB port? - comp.os.os2.programmer.misc

Resources last updated: 1/30/2016 2:29:26 PM