Printer is crippled

[wedgetail]

Almost-retired

Hmmm, I think you are saying:

Portrait, fine

lp -d Epson_Stylus_NX515 my-lathe.hal

Landscape, I suggest using my way of specifying, less confusing, easy to remember. You are only doing +90 deg anyway. Works fine

lp -d Epson_Stylus_NX515 -o landscape  my-lathe.hal

This works fine here, nice ascii text still arrives at the backend, d00xxx-001

I get a bit lost in the rest of your post.  It seems to me that with your my-lathe.hal in hand you now load this into Firefox or open it in Firefox, and it probably looks like an ascii file?

At this stage you know that your system will not print properly to .ps (.pdf) there is this long line problem with a html format.  I thought it was only when doing html now it seems you must have the problem with text feed too.  

I can open my-lathe.hal in Opera, nice ascii content, same in kwrite too of course.  If I try to print from either I will end up with .pdf at the backend.  This is the weird part printing an ascii file it has to detour and visit postscript land in one form or another, this is great for fancy high quality proof, print ready stuff for an advertising company. Just a bit overboard for us tinkerers, I think. I don't understand this but generally we don't notice and the pc power is now so great, who cares the file is now some 20-100 times bigger.

So I can print your text file from either Opera or Kwrite using your printer 'simple' driver, it will be a pdf file that arrives at the backend and the file appears fine.

If I use command line printing lp -d .... my-lathe.hal I believe we both have the same, 'proper' ascii files arriving at the backend. (Both portrait and landscape)

If you use FF to handle your file, because of 'something is not right' you will get this cropping, which may be solveable by tinkering with the font.

Must admit it is only now it is sinking in that you have been using FF to print a text file, I did see it early on but it did not sink in, as I have said before I don't trust html at all when it comes to printing. I probably should say in this case I don't trust a web browser when it comes to printing but that is a personal thing.

We are back to what is going on when you print from FireFox, something is going on that I can not reproduce on the ISO 2012.02 based KDE-mini systems I have.

By the way I can't open the .hal in FF, if I try the file opens in Kwrite. Guess FF is smart enough to recognise pure ascii in the file and passes the file straight to Kwrite, which I think I set as default to open txt files. I don't consider this important as my FF is not kitted out with extras.

I am now so confused that I have to ask you.  When you try printing the .hal from FF have you checked what format arrives at the backend (pdf or .ps)?  Or have you already found that printing the .hal from FF to a file, that this file is 'damaged'.

[Almost-retired]

I am now so confused that I have to ask you.  When you try printing the .hal from FF have you checked what format arrives at the backend (pdf or .ps)?  Or have you already found that printing the .hal from FF to a file, that this file is 'damaged'.

first, the only time I've used FF in this manner, was by your request.  I don't normally do it, and I think FF got in the middle of this only because you wanted a std page like the pclos home page as a test file.  Or something like that.

However, it appears that IF I want to print that text file, the only way to do it successfully is to load it into FF12, which then displays it as normal text, which it is.
Now, IF I used FF, and print to file, with the print to file set to 'landscape' and 'shrink to fit', and to a .ps file, then the file will be good.  Load that .ps into okular, displays fine.  Print from okular, I select the epson, change its options also to 'shrink to fit' but in 'portrait' mode since its already rotated.  Then I get the only good printout I've had.  I suspect I could, now that I know how to work around this, do essentially the same thing from kwrite, kate, gedit or any of the others, as long as every step along the way is set to "shrink to fit", and one and only 1 of the two stages is set for landscape, probably the print to file only, leaving all subsequent steps in the portrait mode since we only want to rotate 90 degrees once.  FWIW, shrink to fit, doesn't seem to actually shrink it much if any, but it does fix the problem.

Just for grins:
#> lp -d Epson_Stylus_NX515 -o request-orientation=4 -o fitplot /net/lathe/home/gene/linuxcnc/configs/my-lathe/my-lathe.hal

Gets a line wrapped, portrait mode printout.  'fitplot' was as close as I could get to a shrink to fit to lp.
If it was life & death, I could tell lp to use a smaller font, but the Brother Just Works.  I have to run to the basement to retrieve the printout, something these ancient (77yo) legs aren't always happy about.  When I bought that printer, the plan was to use it for program listings on the coco, originally by sending the file out the bitbanger port, thru a serial2USB adaptor, up a USB cable to this box, where a bash script listens to the usb port, saving what comes in, and closing out the file when no new data arrives for more than 2 seconds.  At that point, my bash script hands the file off to lp, which renders it, and ships it back down the usb cable to the same 7 port hub the serial2usb is plugged into, but sending it to the Brother.

That gives me a printer on the coco that is about 40x faster than any printer it ever had before.  But now we have a .jar file that monitors that same bitbanger port,  but at 115k baud rather than 9600, allows up to 4 virtual floppy drives of any size, handles the printer duties, translates midi files from the coco & plays them into the speakers here.  Its called drivewire.jar.

So, unless you want to continue this, I have a workaround, and you can file any notes you've been making away in case someone else arrives at this same impass.  Murphy is a permanent resident here, guaranteeing I will find the oddest problem that no one else can duplicate.  That seems to be a partial case here.

I thank you very much for the time you have devoted to this, my patience would have worn thin before now.  I have been too long involved with the day to day maintenance of a tv station, where whatever is broke, MUST be fixed by the time we roll the opening video for the 5 oclock news.  Under pressure like that I have found some mistakes in factory built gear that were so dumb, I steamed all night and called the maker the next day to talk to the engineer that designed it, usually just long enough to advise him of which piece of their gear I was calling about, what I found wrong with it, and by the way, the best part of you must have run down your mothers leg.  TTL nand gates used as an inverter, with one input floating?  I chased my tail on that one for 7 or 8 years, it was that intermittent.  Chyron still owes me.  Retired for about 10 years now, I am slowly mellowing out, emphasis on slowly. ;-)

Thanks again, and Cheers, Gene

[wedgetail]

Almost-retired

I agree, skipping the PCLinuxOS home page print test would likely have saved time. I introduced this particular test as I needed to get some graphics into the file in a hurry to make sure pictures would be handled as well as text, and I had used the website before. The aim is to use something that is 'the same' independent on where your are, something that others can test too for themselves.

The problem shat showed up by printing to .ps was unexpected, and I believe may be part of your problem.  The exercise of using the web site as a test did remind me again that printing an ascii file from kwrite, FF and Opera is via a pdf or ps file. As I have shown the file that is eventually used to transfer to the printer can be intercepted at the backend and it should not matter if it is pdf/ps if you are printing ascii but I am not happy with this.  I like an ascii file to be printed as a string of characters not wrapped in a page layout format.

I made a bit of mistake when asking you to download an ISO 2012.02  I did not specify the desktop.  I should have said KDE 2012.02 that is easier to use. It is only when you use KDE-mini you need to install anything.  In case you downloaded KDE 2012.02 I would be happy as I think this works better. FF and Okular are 'built' in to the KDE ISO.

I got my KDE 2012.02 CD out and started up.  Turns out that FF works like a charm when I dump your .hal file on the address line. This means that I can open ascii files without problems in my web browsers. I just seem to have a problem when using it in KDE-mini when not fully updated first, that is ok.

Having received your .hal file I opened that in FF and printed a landscape.ps file of this. Viewing it in Okular there are no cropping, did checks with Serif 17 and Bitstream Charter 14 font there are no margin limits on your file here.  As you pointed out your longest line was 121 characters and right at the top of the file.

Now I had a bit of luck, I stumbled over a very small ascii file, 120520-Bro.glk which I had made. It was your lpoptions -p Brother..., this happens to be a single line of 660 characters, I had saved the text in above file to run a commandline statement to put it into 'proper lines' as it was partly space separated statements.

[gene@coyote ~]$ lpoptions -p BROTHEHL2140
auth-info-required=none copies=1 cpi=12 device-uri=usb://Brother/HL-2140%20series finishings=3 fitplot=true job-hold-until=no-hold job-priority=50 job-sheets=none,none lpi=7 marker-change-time=0 number-up=1 orientation-requested=4 printer-commands=AutoConfigure,Clean,PrintSelfTestPage printer-info='BROTHER HL-2140' printer-is-accepting-jobs=true printer-is-shared=true printer-location=coyote.den printer-make-and-model='Brother HL-2140 Foomatic/hpijs-pcl5e (recommended)' printer-state=3 printer-state-change-time=1336261962 printer-state-reasons=none printer-type=8433684 printer-uri-supported=ipp://localhost:631/printers/BROTHEHL2140 scaling=100 wrap=true
[gene@coyote ~]$

As I had opened it in FF, then just out of curiosity I printed this from FF to a a landscape.ps and when I looked at it with Okular I found it is cropped close to character position 224 (no shrinking attempt of course) so there is a margin limit in landscape, I should check if this matches with landscape dimensions and just indicates landscape print border is reached and rest of line is dropped.

So using your .hal this limit might not have been reached.  I will let this rest and return to lp test of same 660 character line:

lp d Almost-retired-simple -o landscape 120520-Bro.glk

Intercepting this at /var/spool/cups/d00xxx-001 I get the exact same ascii file, single line 660 chars long.

Do I understand correctly that so far that now it is only the .hal file that is causing you problems in that you can not print out a simple text file without going through this tortuos route you have discovered. 

I would like you to do following based on your .hal file. I have taken the longest line and added a bit. Make a text file of it yyy.txt using Kwrite then:

loadrt   [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES Wedgetails additions

lp -d Epson_Stylus_NX515 -o landscape yyy.txt

I can not get my head around why ascii text should fail to write to the printer or worth it seems to screw up the communications all together when doing simple lp printing. 

I am not quite ready to throw in the white towel yet but don't hesitate to say you have had enough. 

[Almost-retired]

I had grabbed the full monty desktop version when I pulled the cd iso. from an ls p*
pclinuxos-kde-2012.02.iso

The cd is burnt, still in the drive tray, but I've not rebooted.  With all the custom scripts that handle the mail here, and the monitoring stuff I start, I still have about 5 minutes worth of typing to get everything running after the kde desktop is up and running.
 
I've turned off the printer
lp -d Epson_Stylus_NX515 -o landscape-yy.txt

Which has hung that konsole session, and no new d00* file has arrived in the /var/spool/cups dir.
Ahh, no file, fix command line to
>lp -d Epson_Stylus_NX515 -o landscape landscape-yy.txt and the d00684-001 file is ascii and good.
Turn printer back on,  it prints, line-wrapped and all there, in landscape mode!
Now according to man lp, -o orientation-requested=4, and -o landscape, are supposedly interchangeable, so lets try.  And that worked, line-wrapped, all there, and landscape mode.
Adding -o cpi=15 is too much compression, the text is trashed , so scale that down to 14, with a -o lpi=8, now its readable, and all on one line but not enough room left to set the cpi to 13.  lp accepts floating point in its scaling, so 13.5 might still fit but between last night & way before sunup this morning I have quite a pile of paper to recycle.

The bottom line is that something has changed, several files have been updated by the updater since we started looking at this, and I cannot now duplicate the problem at will either!  I'd go get a beer, but at 5am I need the sleep worse.  ;-)

Thanks & Cheers, Gene.

[wedgetail]

Almost-retired
Blimey, you beat me solid   I have just lit the fire under my hp laserjet to check some lp printing. Now probably suffice to say that my thinking was that with a bit of luck and using letter size then by changing the option -o cpi=12 or higher would bring you longest line aboard.  I have used only 5 top lines in your .hal (muliple pages wore the novelty off). For example this example is readable fine here. However I can understand you want to maximise linelength.

lp -d hp_LaserJet_2300_series -o landscape -o cpi=16  my-lathe_short.hal

When you have added umpteen options to the command line, look for Creating Saved Options on this page  http://localhost:631/help/options.html You are on your own here as I have not tried it yet, have seen it a number of times and been tempted.  

I am sorry, first now I realise how dumb that filename I suggested was, I should have left the 'landscape' part out.  This could have shaken the average user.

Here I tried to send the 660 character long line to my laser printer in landscape mode.  The laser printer wrapped the line nicely.  I thought way back earlier in the post that my homespun 111 character line had been tested as ascii print:

I am going to make a simple text file that has more than 80 characters in length so that I can test landscape.

Looking closer I think it was printed from kwrite and then would have been a pdf in the d00xxx-001 bundle.  So I missed out staying firm at that stage and check the printer properly doing long ascii line.  Further it may even have been just a bit too short for wrapping in landscape, next time I will make sure anybody get to use a longer line.

Ouch, I did not realise you were updating automatically, never occurred to me.   I shall sleep well tonight feeling that progress has been made.  Now I feel that the Epson is likely to be able to handle a long ascii stream, the expectation it will just wrap when too long. (provided wrap has not been turned off of course via lp)

 

[Almost-retired]

The majority of the reason to 'contain' the line wrapping, is that in drivers which count linefeeds to determine page length, a wrapped page containing many such lines will print right off the bottom of the page.  In this case it isn't a big deal, but I hate it when that happens halfway through a 400 page document and throws away the last 2 lines on the page which are the heart of an explanation.  I actually printed the whole 410 pages of the pdf-1.3 specification once.  Duplex by hand to boot, 50 page bundles at a time.  It did make good middle of the house reading at the time. Outdated of course now and I am not about to baby sit this thing while it goes thru another $75 worth of ink & $10 in paper again.  Ink in particular was about 1/3rd its cost today.  About the only thing I'll go through that again are the manuals for what used to be EMC, but the real, and older company came calling about a year ago & we had to rename it to LinuxCNC.

The complexity of that totally free package virtually demands access either to hardcopy, around 700 pages worth or having the machines install of Ubuntu-10-04 LTS set up with enough workspaces that you can run FF against the auto-generated for every build, html docs from the buildbot.linuxcnc site.  Plus I always keep an IRC session going that is inhabited by the guys who write this code, and make a living from, the machines this software runs.  Toyota uses it to finish their racing engine blocks, all  alu, because it is capable of running the 6+ axis (I lost count after that watching the utube video) machining center that does that work of art they go racing with, in about half the time other commercial, $5000 a seat, software can do.  LinuxCNC can do 9 axis's, and that machining center has the ability for the usual XYZ motions, plus rotary table like moves that can present the engine block to the cutter head at all angles with one remount of the block to allow access to the other side, called ABC motions, and can tilt the cutter head in the last 3 axis's UVW.   Plus tool changing is automatic, using tools according to how gross a cut is being made.  I'd give a link, but it seems utube has expired that video. And all I can find now are in 5 axis machines, using a HAAS control.  And I see motions being made by the HASS as its executing a loop to bore the cylinder of a 427 ford V8 that aren't needed, nor used by experienced gcode carvers who know how LinuxCNC works.  That right there would speed the process by 20% because it can program a downward spiral cut, and production houses would kill for something that makes their $250,000 machining center 20% faster.  But because this software is free, the MBA's have no one to sue if it miss-behaves, plus they'll have to keep somebody on staff who can actually fix things.  They don't often understand that those are CODB items that will make them money at the end of the quarter.  One of the guys on the mailing list has a Cincinatti Milicron with a 26 foot x bed, and the 2 axis motion of the cutting head that alone weighs nearly 5000 lbs. Stuart Stevenson bought it, about to be cut up for scrap because the 35 year old control had died.  He converted it to be run by LinuxCNC, and the first job they gave it was a bearing seat for a 7" diameter ball bearing for a railroad locomotive.  It, worn ways and all, carved that seat to within 2/10000" of an inch of ideal perfect fit, way more than "good enough for the girls we go with".

During the setup of the servo's he had it oscillating the z (up/down) axis at about 100 hz hard enough it showed up on the siezmographs in Dayton, 50 miles away.  The 4 foot thick concrete slab under it cost him more than the mill itself.  The whole z axis lashup weighs quite a few tons...

The only difference between men & boys is the size of the toys.    I'm a very small boy in that center ring with my stuff all being table top toys.  Keeps me out of the bars don'cha  know.

Thanks & Cheers, Gene

[djohnston]

Gene,

I gotta say, that is one helluva story, regardless of the "size of your toys"! 

[wedgetail]

Almost-retired
Yeah, this printing did not give me peaceful sleep after all, now it is my turn to be grumpy.  Since I had the printer going, hp Laserjet 2300dn at the moment running network connected with the parallel cable hanging out ready for use too.

I decided to look at how to change the font size.  First I attempted via lp and looking on the net I am not the only one that was keen.  I did not find any solution. Then I thought easy fixed, we know that printing from Kwrite will go through a pdf detour.

I took the short version of of your .hal, just the 5 top lines as it included the long line. Opened it in Kwrite and set the font height to 8pt so there was no doubt it was small. Then printed this from Kwrite to the pinter, but as far as I could see it had no impact on the font size.  That spoilt my evening. 

At that stage I had already noticed that opening the text file in FF and Opera looked fine but changing the font in FF had apparently no influence on the font when printing to the .ps format.  I did not really take any notice at the time thinking more about the Epson problem then.

Apparently lpr can change the font itself but so far I am not sure if one can change the font size.  I am not sure what fonts are built into my printer either I have just assumed that any application default font would be in the printer.

Any pointer welcome? The problem fits in nicely here 

CNC is a world to itself, I notice it is catching the home workshops attention.  The most impressive piece as far as I am concerned was the Stepperhead by Alan Jackson you could say it was an improvement on the Urwic_Metalmaster design, that really caught my heart but since I am electronics man I am resigned to the fact I will not have time in this lifetime to build one.  If it goes into production I would be serious on-looker.  I have actually already started 'building' it in 3D Milling in that world is beautiful and extremely fast, cheap too if you make a mistake. (I have pemission to make the 3D model, but with PCLinuxOS tinkering I am unlikely to finish the model)

[Almost-retired]

I hadn't, so far, needed to change the font family from the 'lp' options.  I assume it can be done, but a good read of lp's man page might make me out to be a liar too.

As for font size, that is adjustable in floating point precision by use of the -o cpi=float and -o lpi=float options.  Down to where you'll need a serious magnifying glass to read it, and the nozzles will have to be clean clean.  The printer folks don't make it easy to get too, but a wet (water) Q-Tip swipped across the bottom of the head can work wonders on cleaning up blurry microfonts.  Don't be surprised if you go thru a whole box of them getting it clean either if you've some time on the printer.

As for the stepperhead, its cute, but severely lacking in the rigidity to to that spiral milling in metal.  My converted table top mill, some pix of which are in the 'emc' link off my home page at
<http://coyoteden.dyndns-free.com:85/gene>
can do that sort of thing in steel up to about 11" long because I'd have to fit a tailstock to the right end of the X bed to support the steel against the cutting forces.

That bright blue 7x12 lathe now has motors on it, and is capable of cutting arbitrarily sized and pitched threads at 50 times the speeds it can be done on an older gear driven version of that lathe.  For thread cutting, the spindle and the carriage are locked together electronically to at least the precision the former gears can do.  If the single tooth cutting tool is sharp and properly shaped, the threads are very smoothly cut works of art.

One such 1/4" x 28 tpi thread was tested by some extreme duty with pressures in the 15,000 psi range this evening at the local rifle range.  The newly built nipple for #209 shotgun primers was tested at first a 3 shot group using 50 Gr of BlackHorn 209 powder, gave a 2" group at 50 yards, then a 2.5" group using 75 gr of that same powder.  The rifle itself, a TC Black Diamond now resting in a thumb hole stock I carved from solid maple, is rated to go to 150 gr of powder in real black, or most of the substitutes, but BlackHorn-209 is in fact a smokeless powder with smoke so it looks like black when fired.  But 6 shots had it quite warm so I swapped to another BP 50 cal, and ran 6 through it, warming up a brand new barrel to the hey that's too hot! state, so I saddled up & brought everything home again as it was past dinnertime.  The 2nd BP rifle, a TC Omega in a laminated factory thumb hole stock, also gave far better groups than it had ever done before once I got it on the paper with a bore sighter, so out of 12 shots, 11 of them would have brought home the venison.

That is the point...  Now the bigger problem is getting me, with enough insulation on my diabetic feet, out into the deer fields in the cold weather of hunting season.  Getting old is not for wimps.

Thanks & Cheers, Gene

[wedgetail]

Almost-retired
I have carried out some experiments on short part of the .hal file you sent. My question about change font size/height using the -o cpi=float -o lpi=float well I will take your word for being able to real decimal numbers here. I have set the original font to monospace 10 pt and lp printed with a couple of combinations.

lp -d hp-2300dn-ps -o landscape -o cpi=13 -o lpi=16 my-lathe_short.hal

lp -d hp_LaserJet_2300_series -o landscape -o cpi=13 -o lpi=10 my-lathe_short.hal

Font height varies nicely with the changing the lpi settings value.  I don't think the character form factor is maintained but I can live with that

Did quick test in LibreOffice Writer, Portrait seemed ok with very big letters but landscape screwed up. 

I think I have had enough of this for while, I am going to bail out of here as it seems you are on the right track with your Epson.

[Almost-retired]

While I am the OP, I'm inclined to bail myself.  Whether the fault was in gutenprint, or whatever is being used in place of enscript ATM, the fact remains that for monotone work, the Brother HL2140, a $110 laser printer, just works.

I suppose to make it complete, I should send it once, in landscape mode via lp, to the Brother with it turned off or cupsdisabled, and see what the d00XXX-001 file contains with okteta.  But I have a dental appointment at 13:30 that I am about an hour from being able to get in the GMC & drive the 45 minutes to it.  So it won't be done today, and tomorrow is highly subject to this old farts poorer as the years go by short term memory.

I try to make fun of it, but the effect is real, and its maddening sometimes to have to re-invent the wheel 2 days in a row.

10+ years since I retired, and I'm half committed to turning a 40 kw Harris VSB transmitter into a linear amplifier for the tv station yet this summer in order to raise our power and get back some of the coverage we lost when we went digital.  But even from 10kw peak to 40kw peak is not going to get us anywhere near the 100 kw ERP we had before.  The FCC virtually put tv broadcasters in mountainous country out of business with the changeover to digital.  None of us are reaching past 50% of the area we did cover.  But the ability to adapt will take more thought than it used to, and probably some missfires as we discover what doesn't work vs what does.  However, since we stayed in the Low-V band, on channel 5 because their original channel assignments ignored the Nation Radio Astronomy Quiet Zone whose border is 2 miles from our old transmitter site, we had the legal power to force the commission to reconsider since our output power on channel 58 would have been limited to 4.7 watts.  I had fun going to the NAB show with that denial letter in hand, asking the transmitter makers for a 4.7 watt digital transmitter. )

We even had some beer to cry into over that, so it wasn't a total loss.  I got to share a few beers, and some war stories with some of the industries real old engineering hands.  How we lived through some of it still amazes us.

Thanks & Cheers, Gene