Announcement

Collapse
No announcement yet.

Won't network print to home computer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Won't network print to home computer

    Hi, I've got 3 computers networked together using ME. I have a serial printer (a Brady PC-LINK) on Computer 1 and am able to print to it from computer 2 and 3 using this format:
    STX$=CHR$(2)
    Brady=FREEFILE
    OPEN "\\Tom\TLS" FOR OUTPUT AS #Brady
    PRINT #Brady, STX$;"Q"; 'clear image memory

    etc.
    "\\Tom" in this case is computer 1.
    The problem I'm having is that I can't print to the printer from computer 1. Nothing happens. I know I can make it work by directly accessing COM 2, but I often upgrade this program for all three computers and I want to be able to do that in one version, not two.
    Hope this makes sense.
    Thanks

    ------------------

  • #2
    Bill,
    I have never used a serial printer myself, but have ran into situations where I needed certain options for one computer that I didn't need or want on another..... for example an application running on the main computer or server, I might want an option to backup data, but I don't want that option on a workstation. so I disable that feature on the workstation end.

    What I have done to accomidate this is create a small text file that I call OPTIONS.DAT and I place it in the path, usually in \windows\system or \windows\system32. In my case, the OPTIONS.DAT file contains the name of the computer...ie SERVER

    Then within my code, I open OPTIONS.DAT and read its contents and store its value in a global variable, then close the file.

    Then I can do something like this....

    If UCASE$(Option$) = "SERVER" then
    blah blah blah
    elseif UCASE$(Option$) = "CLIENT" then
    do this instead
    end if

    This way I only have to maintain 1 program to be used on multiple computers. It took me a while to come up with this plan... I use to maintain 3 copies of the same program with slight changes to accomidate a certain computer configuration or printer configuration....what a PAIN in the a$$. This approach work out real well. This worked out especially good in cases where a local printer on a server was LPT1 but a workstation that already had a local printer needed to print to the servers printer and mapped as LPT2. With the above IF-THEN-ELSE, this was pretty easy to work around. It is really a simple solution to what I think you are describing as your problem.

    HTH,




    ------------------
    Gary Stout
    [email protected]
    Thanks,
    Gary Stout
    gary at sce4u dot com

    Comment


    • #3
      Thanks for replying Gary, If I understand you correctly, you are basically (no pun intended) making a printer driver for DOS. I think it will work, but I was hoping for something more simple. It doesn’t matter that it is a serial printer by the way, I can’t get the server printer to print to an LPT port either, but all the other net computers will print to the server’s printer just fine. It seems like there ought to be an easy way around this. If no one has any other suggestions, then I’ll try your plan.
      Thanks

      By the way, I should have said "server" rather than "computer 1." The server won't print to it's own port using network jargon: OPEN "\\Tom\TLS" FOR OUTPUT AS #Brady.

      Bill Franke

      ------------------

      Comment


      • #4
        Bill,
        My method is not really a driver of any kind. It basically just directs the program in one of two directions depending on which machine it is on (as read from OPTIONS.DAT) or in your case if you can make it print with one command to the network printers and another command to the local printer, then by reading the external OPTIONS.DAT file and using the IF-THEN-ELSE routine, you can direct the program the route that it needs to go to accomplish the correct commands for each printer.

        Maybe this will clarify a litle....



        ------------------
        Gary Stout
        [email protected]
        Thanks,
        Gary Stout
        gary at sce4u dot com

        Comment


        • #5
          If you can redirect LPT1 to COM2 on that PC (ie, via the DOS MODE LPT1=COM2 command), you should be able to use:
          Code:
          IF <running on another pc> THEN 
            pt$ = "\\server\share"
          ELSE
            pt$ = "LPT1"  ' Use BIOS I/O by using "LPT1" rather than "LPT1:"
          END IF
          OPEN pt$ FOR OUTPUT AS #1  
          PRINT #1, "...da da da"
          CLOSE #1
          ...and it "should" be redirected through COM2 if MODE is doing its thing. That way all you need to do is alter the port string from a configuration, such as described by Gary above.

          The alternative would be to provide two print routines - one that uses OPEN "\\server\share", and the other that uses serial comms code instead (see the SERPRINT.FAQ file installed with PB/DOS for more info). Again, your program would need to be able to select between the two routines.

          Depending on the OS you are running, you might be able to use the UNC name method by bouncing the print job to another PC, when then redirects the print data back to the first machine again. I've not done that for a _long_ time, but I did use that method to solve a very similar problem on an old Win3.11 network. IIRC, there was a description of how to do it in one of the .TXT files that was included in the Win3.1x installation in the C:\WINDOWS folder.

          Yet another approach would be to consider using a parallel-to-serial converter, and simply connecting the printer to the local LPT port (much as I described initially above).


          ------------------
          Lance
          PowerBASIC Support
          mailto:[email protected][email protected]</A>
          Lance
          mailto:[email protected]

          Comment


          • #6
            Thanks you guys, I'll try these things, but it still seems to me that a server ought to be able to "see" it's own port some way.

            Bill Franke

            ------------------

            Comment


            • #7
              AFAIK, that is only possible under Windows NT/2000/XP due to the more limited UNC support the various other versions of Windows offer.

              ------------------
              Lance
              PowerBASIC Support
              mailto:[email protected][email protected]</A>
              Lance
              mailto:[email protected]

              Comment


              • #8
                Going back to an old post:

                I got this thing to work using the following code:

                Brady=FREEFILE
                Computer_ID=FREEFILE
                OPEN "C:\EDS\EDS.ID" FOR INPUT AS #Computer_ID
                LINE INPUT #Computer_ID, ID$
                CLOSE #Computer_ID
                IF ID$="TOM" THEN 'make this work on the host computer
                OPEN "com2:9600,n,8,1,DS0,CS0,CD0,RS,ME" FOR OUTPUT AS #Brady
                ELSE
                OPEN "\\Tom\TLS" FOR OUTPUT AS #Brady
                END IF

                PRINT #Brady, STX$;"n"; 'put printer in inches mode
                PRINT #Brady, "190000800000003"+"EDS"+FS$(1) 'record structure
                PRINT #Brady, "E" 'print
                PRINT #Brady, STX$;"c"; 'form stop position

                CLOSE #Brady

                It works great! Just one problem though, if I print using the host computer, I can’t print from any network computer. Or if I print first from any network computer, I can’t print from the host computer. I get the following message on the host computer:

                “There was an error writing to COM2 for the printer (TLS PC LINK). Cannot access the port. It may be in use by another program. Quit other programs and try printing again.”

                We have to shut off the (host) application and start it up again to be able to print from the other computer. I don’t understand this since I CLOSE the file after each time I print.

                Any help would be appreciated.

                ------------------

                Comment


                • #9
                  This problem used to be solved in Win 3.x & Win9x by adding the following line to SYSTEM.INI in the [386enh] section, and rebooting the PC:
                  Code:
                  COMnAutoAssign=1
                  ..where the n is the serial port number.

                  This tells Windows that it can reassign the port to another application 1 second after it has been closed, rather than leaving it assigned until the program is closed.

                  This method should still work in later versions of Windows, since Windows will automatically import SYSTEM.INI settings into [various parts of] the registry. Don't be surprised if the SYSTEM.INI entry is removed after the reboot though... thats just Windows doing its job.

                  Please let us know if this helps!

                  ------------------
                  Lance
                  PowerBASIC Support
                  mailto:[email protected][email protected]</A>
                  Lance
                  mailto:[email protected]

                  Comment


                  • #10
                    Let's have a little Halloween word play fun, OK?

                    You've already stated this is a network operation! OK, if this is
                    a frequently and repetitively used data set you need printed you can
                    always write a custom print 'server' executable for it.

                    You write the data to a specific file or collage of library files or
                    a master file with a list of increasing but known pointer positions.
                    The file or files are on the box with the desired printer on it that
                    you know works.

                    Then you write a dedicated little executable for servicing this set
                    of data. You load it with the needed data and let it run in a separate
                    session on that box. In your routine(s) you provide semaphore action
                    so that this print routime will not go off printing when another job is
                    printing, or .. if the operating system has decent spooling; use it.

                    If a little file is present; do or do not do this or that. If it is not
                    present; do or do not do this or that. When finished remove or modify
                    the little file to offer whatever sign on the tree is needed in the
                    woods for the next little venturer to see.

                    Then your custom little 'executable' just camps by the fireside, where
                    it periodically takes a look at who all else is around the fire! Not
                    too often so as to make a pest of itself, you know, grin. When an
                    appropriately marked guest shows up at the gathering, there is this
                    quiet little agreement reached. The required little printing job is
                    done, by agreement, (But who knows who knows the agreement, gring?) off
                    in the woods, by your little print ghoul! Your little print ghoul goes
                    back to sitting by the fireside and nobody is the wiser, chuckle.

                    When this little background task is finished, you either delete the
                    visitor from the gathering, or you stack the corpus in the write(sic)
                    pile, either end to end, or pointed to helter-skelter in the write way,
                    huge smiley.

                    You don't have to limit this scenario to printed data. You can slice
                    and dice all kinds of communicative bits of thingees this way and direct
                    them to not only a printer, but box 'em with other bits of thingees ..
                    or .. communicate them with other channels to other headless horsemen
                    round the same or other similar campfires on this or even other gobbl'em
                    up node machines. Forward march! Even backwards if you need to.

                    In some cases I have half a dozen of these little disk file aware little
                    PowerBASIC rogues operating in background sessions, even as DOS-VDM
                    sessions with no screen activity at all on a box. They do everything
                    from being an alarm clock and playing music in the morning, (as I'm
                    writing this) to printing billing invoices for automated data forwarding
                    on the same box, dumped into to directories, even by old FIdoNet BBS
                    software utilities across TELNET and the internet from afar! Cheeze,
                    what's an old Fido dog still doing around at a Halloween party?

                    Why, you can even make 'im bark when a new guest arrives this way
                    at the campfire site ...

                    Modern networking, the file systems it offers, plus semaphore and flag
                    control file techniques can do WONDERS for your PowerBASIC PB 3.5 for
                    DOS happiness. And if your little server application is backwoods
                    smart, it won't even fire up if the trails through the woods aren't
                    there because you aren't connected to the network! Simple trace file
                    not found error trapping will keep you out of the woods when there is
                    no woods into which to venture or it is full of teddy-bears having
                    another picnic at which you don't want to be caught!



                    Of course, the operating system you are using does have a bit to do
                    with all this. It must be able to pre-emptively run all these wonderous
                    little headless horsemen at the same time while orchestrating their
                    little tasks around the campfire. Wouldn't want to bring the party to
                    a premature halt, now, would we? Works best, so I've found, on OS/2
                    since it's pre-emptively able to even thread-level manage even a dozen
                    or so deals like this at one time across even multiple CPU's just fine,
                    even in good old DOS!

                    But you can get away, sometimes, with one of these little servants in
                    WIN-95/98 or so, if you do a good job of time slice releasing with
                    certain parts of your code. Maybe more will work at the same time in
                    later versions of WIN-NT and so on, I don't know. Haven't attended such
                    a party yet, smile. Might try that some day in the future as you can
                    run any version of WIN as a guest under OS/2 ... GDRFC, but not yet.

                    For the few who are OS/2 oriented here, smile wider. Warpstock 2003
                    in San Francisco last week was highly informative as to the past and
                    future. Even your old 1970-80's style 8250 UART assembler library code
                    merged in with PB 3.5 apparently will still work just fine, fully
                    supported past, present and into the all this future with full driver
                    and defect support for an indefinite period of time past December 31,
                    2006. Per published data now from officialese slides and talks, a
                    major Total Content Option (TCO) client of the claimed $48,000,000,000
                    contributed total of the IBM owner's profitable position for that has
                    been guaranteed full contract support now out to the year 2019.

                    Heck, 22,000,000 fully support IBM DOS installations, world wide, can't
                    be all that wrong, no? The number was published! Yes, still supported,
                    access to hardware and all.

                    Wonderful news for PB 3.5 and perhaps future fans of it, like you, and
                    what the new version of PB 3.5 will become. Especially like those
                    who huddle round all those fires in the sand out at Ocean Beach. Watch
                    the fog roll in, spend Halloween night protected from it. Current
                    costs for a year of support for OS/2 are less than even the $76 ticket
                    you can get if yor car is still in the parking lot on All Hallow's 'Een
                    when they come writing tickets, if you haven't got it moved to a better
                    operating platform by the time they get to it out there at the beach!

                    Bill, all it takes is to know where to park the car and who to let go
                    riding in it while you're all cozy and warm around the fireside networking
                    with all your friends! You just get up at the right moment, light up
                    the poi, twirl them all around and watch the sparks fly in all directions,
                    then go back and put a little more juice in the pot and wait again!

                    "Awesome ... What a dude!"

                    Happy Halloween.




                    ------------------
                    Mike Luther
                    [email protected]



                    [This message has been edited by Mike Luther (edited October 29, 2003).]
                    Mike Luther
                    [email protected]

                    Comment


                    • #11
                      Lance your fix worked great! Thanks alot. Luther, I have a hard enough time with analogies when I find them in theology. I only remotely understood yours as applied to networking. But thanks for trying. Unlike most of you creative programmers out there, I’m very pragmatic when it comes to my computer and right now it works, so I’m leaving it alone.

                      BF

                      ------------------

                      Comment

                      Working...
                      X