HP-UX 9.05 & HP Designjet 4000

[DON F]

Bit of along shot, In our office we have an old GIS system(Accugraph's MountainTop) which run's on HP-UX 9.05. Our IT department hasn't been able to connect our HP Designjet 4000 due to lack of drivers AFAIK. Would anyone have any suggestion on how we could connect the plotter?

Thanks

[Steven E. Protter · Accepted solution]

Shalom,

Try compiling a samba client on the system, and hang the plotter off another system that has drivers.

The plotter is probably far newer than the OS. No way anyone wrote drivers for 9.05 HP-UX.

If you get the samba/cifs client to work on 9.05 you have a chance of submitting print jobs to another print queue remotely.

SEP

[DON F]

I should also mention the desktop is running NT and using Reflection X to access the Mountaintop App.

Thanks for the suggestion

[TwoProc]

Also, if you're printing in native HPGL or PCL, you an usually copy your file (using dd) to the port that the plotter is hooked to - if you're using a parallel or a serial port.

I used to run my GIS systems on HPUX 9.x this way when drivers became a problem.

[Bill Hassell]

HP-UX has no printer (or plotter) drivers. It's not Windows. The good news is that unlike cheaper printers that are incompatible with old printer codes (PCL), the DesignJet still uses HPGL/2. The bad news is that your OS has been obsolete for more than 15 years, so connecting it using current technology is doubtful. If your system has the directory /opt/hpnp, you have the (also obsolete) JetAdmin software and you can connect to the plotter over the network. Just run the command: jetadmin.

If you don't have this directory, you must add the printer using sam as a remote printer. Since the plotter is very new (compared to your prehistoric 9.05 system), it has a network card that should support RFC1179 communication. When sam asks for the 3 names, the first is the plotter's name in HP-UX, the second is the IP address of the plotter and the 3rd will be the internal name -- use the name: raw and check the option for BSD handling.

Now all of this assumes that you have software that can generate HPGL/2 plotting commands. Unlike a printer, it cannot print plain ASCII text, but I'm sure you know that.

[DON F]

Thanks for all the replies. I passed the details to our IT department but unfortunately they have tried all the above before with no luck. Its a obsolete system that will die a death a some stage.

[TwoProc]

Since I've been in your exact situation before, I want to maybe just clarify and build on what myself and Bill Hassell have mentioned above.

The key to solving this problem would be to "print" to a file, in either HPGL or PCL format. If you can do that, then you're good from here on out.

At that point you can just dd that file to the serial/parallel port that you've got the printer connected to in a script.

And, I may add, that since your program runs on HPUX 9.05 machine, there's a fair chance that it is using starbase graphics, which is the library that was implemented as "starbase on x", called "sox" starting with HPUX 9.0.2.x and beyond.

The reason I bring this up, is that "starbase graphics" and "starbase on x" where just screen based graphical libraries based on hpgl. And these programs would use a device file in /dev/[cant remember the name] as their output device. This tells us that we've already got everything drawn in HPGL, and you really need to do, is just redraw the image into a file.

Now, we owned our source code, but the idea was that we'd open an ordinary file in C (our GIS was written in C) and grab the graphic buffer and issue a redraw() command from the graphic buffer, against a different output device, that is, the FILE* device I just created, and then just doing an fclose() on it.

After dropping the file, now full of hpgl content, we could just dd the file to the the /dev/xxxxx interface of the printer. Since my printer spoke hpgl, it worked like a charm, and at a same time gave us the ability to save our output plots.

Now, I know you're running someone else's GIS, but it probably has extendable hooks or apis in it that you can call from C, etc. if it can't print directly to a file itself with the "print command" in the program.

Hope some of this info helps.

John

[DON F]

Just to give you an update. I managed to get it working in the end. It was a lot more straight forward that I thought. Basically I added a network plotter using SAM. I then found an option to output to the plotter from the GIS software in HPLG2 and it worked first time.

One last question would anyone have a recommendation for an alternative to Reflection X that can be used in a commercial environment free?.

Thanks for all the help you all put me on the right track.

[Dennis Handly]

>would anyone have a recommendation for an alternative to Reflection X that can be used in a commercial environment free?

Have you looked at VNC?

[Steven E. Protter]

Shalom,

Generally I use a Linux work station.

I connect as follows:

ssh -X hostname

Then I can run any X window based command I want, and it goes back to the X server on the Linux box.

Linux is a free X windows client(server really).

This is really unrelated to the original thread and deserves its own thread.

SEP