HPGL to Analog Voltage (Driver)

[T3sl4co1l]

Curious, has anyone done a project like this before?

For motivation's sake: I have a HP 7035 plotter, which is purely analog X-Y.  Not... very useful, can't say I've taken it out many times since I acquired it... and I don't really intend to make anything here, it's not like it's going to be much more useful with this.  But, y'know, if I did, it'd be neat to run HPGL on it, right?  So, just hypothetically, or as an exercise, or maybe an idle project some day.

Similar projects include using PC audio to plot figures on oscilloscope (this would work too, i.e. rendering HPGL to audio -- if one has a DC-coupled sound card!), or most any vectorscope sort of thing really, but slowed down to suit the very low bandwidth of the plotter (which is merely a couple Hz, so no AC-coupled sound is gonna cut it here!).

Probably what I'd do is something like, small micro (probably an XMEGA because I have some, but anything on that order), uhh whatever buffer space is needed to render shapes (HPGL supports subroutines and fonts, something like that right?) so adding external memory in case onboard SRAM isn't enough, and, heck, PWMDAC will be more than enough ENOB in this kind of bandwidth, but maybe for plotting more complex shapes on vectorscopes, a proper pair of DACs would be nice.  (And maybe that would render to a frame buffer, then loop that for live display.)  I don't know how much memory and complexity is needed by an HPGL interpreter, but I know solutions exist, so, I'm not too interested in the practical details of that (but, if this inspires one of you, hey, go nuts ).


Also to say, holy shit did I ever stump Google, I get thousands of hits for "Analog XY-Plotter Output to HP-GL Translator", and there is just, absolutely no chance in hell of convincing it I want those words in the opposite order?  This is probably an easy enough thing that it exists, it's just utterly unsearchable with Google as it is today...

Tim

[moffy]

So just to see if I am understanding the issue, you want to convert HP-GL into an XY plot, using a micro? Like GRBL takes GCODE commands and converts them into XYZ steps to control the XYZ axes of a CNC machine?

[T3sl4co1l]

Yeah.  Or even doing it with a PC would be fine, but there aren't many DC-coupled solutions for that I think?  Aside from a whole-ass DAQ sort of thing.  As an inbetween, an MCU would be a fine way to go; it doesn't even need to do the thinking, it could be nothing more than a serial DAC.  (Oh, a regular SPI DAC paired with a USB-SPI would be easy.  Might not be an existing product with that, but very easy to breadboard at least.)

I suppose rate-limiting the vector data is still an open problem; an HPGL library might produce vectors, but they still need to be plotted as such, in this case into wave data, rather than say, stepper motor pulses.  Should be fine to use the same thing, actually, just output the X,Y at each waypoint instead of stepper X/Y rates, pulses.  Or make sample points for each pulse, say, maybe time-stamped corresponding to the stepper pulse rate.  And then resampling that as needed, whether a timestamp or fixed-time series is best used.  So, would need to start with a free library that does that sort of thing, or else sorting and plotting the vectors yourself isn't painful, just more work.

Or... is this obvious enough, do most CNC tools (e.g. Fusion) export an X,Y sequence already?  I'm rather out of touch with CNC stuff, maybe it's under my nose already...

Oh, there is one thing I guess: those video adapters that are just USB/1394/whatever streaming DACs; those ought to be DC-coupled?  Oodles of bandwidth, so, no problem getting ENOB up past the 8 bits provided...   Even has 3 channels, so X, Y, pen are all handy!

Tim

[free_electron]

capture hpgl output using a software plotter emulator and save as vector format.
load vector format in something that can produce g-code
play gcode on a stepper motor controller.
use stepper control signals to drive a dac. ( you have a direction and clock bit. use a three or four 4bit up/down counters like 74193 to drive a 12 or 16 bit dac.

scaling is done in software

[SiliconWizard]

Could be a fun project. Yes, oddly enough, the converse operation has been done, like: https://github.com/jshorstman/Analog-XY-Plotter-Output-to-HPGL-Translator
I guess there's not much demand doing what you want here. It's pretty niche. (Don't ask why the above has been done though, not sure it's any less niche!)

Fun part is that you could of course also draw things on a scope in XY mode with it, so I'm sure quite a few people could find it cool. With that said, there *are* projects for drawing vector stuff on scopes in XY mode, like this: https://github.com/ffd8/xyscope (it's Java, so don't expect to be able to reuse any of that on a MCU, but just to mention one such project.)

One problem I see is that if you only have X/Y inputs (and no "Z"), then you won't be able to implement things like the "pen up" and "pen down" commands. All drawn parts will be connected. On a scope, this can be mitigated using "sharp" edges, but I don't know how your plotter handles that.

[T3sl4co1l]

capture hpgl output using a software plotter emulator and save as vector format.
load vector format in something that can produce g-code
play gcode on a stepper motor controller.
use stepper control signals to drive a dac. ( you have a direction and clock bit. use a three or four 4bit up/down counters like 74193 to drive a 12 or 16 bit dac.

scaling is done in software

Ah, the old fashioned solution! Uh, just mind to add a preset for "home" command (set to DAC mid-level or whatever), and chain enough counters for the dynamic range, yeah.  Which is all easily done with those.

Can probably save on logic (chips) by using quadrature counter on an MCU, too?  Hmm...

Nice is it leverages existing toolchains, and stepper drivers/projects are dime a dozen.

Tim

[peter-h]

HPGL is not trivial. You can't just feed it to a DAC.

Many years ago I designed a box which would take in a vector stream in HPGL, Calcomp, OCE, Roland, Postscript, and various other plotter formats which were around then (1980s). The HPGL interpreter was written by a subcontractor and was "comprehensive". I've just looked to see if I have the source but I can find just a .lib, for IAR C. The output of this thing was a generic vector format.

The language has many commands.

More to the point, what is generating your HPGL? Most programs generate only a small subset.

[moffy]

Here is a HPGL to GCODE converter and plotter: https://github.com/ChrisAnd1998/GravoStyle-Spooler-HPGL-to-GCode
Though written in Visual Basic, it looks to run on a PC and also provides a graphic plot of the HPGL code. HPGL is pretty dead but GCODE is very alive with many resources, it might be a simpler path. I have modified grblHAL(GCODE controller software based on GRBL), running on a SEEED ArchMix board to output the full XYZ position of the machine every time a step is taken along with a precision timestamp. It outputs the data in realtime via the USB. It would be fairly simple to output it via DACs etc.

[Ian.M]

There's an Arduino HPGL interpreter (intended to drive steppers for a vinyl cutter) here:  https://www.semesin.com/project/2018/02/21/mesin-cutting-sticker-berbasis-arduino-hpgl/
You'll probably need Google Translate as the writeup is in Indonesian.

It doesn't look like it would be too hard to rip out the actual stepper drive code and drop in incrementing/decrementing a variable for each axis and outputting them to 16 bit DACs.

If its a HP 7035B plotter, there's a remote pen lift pin on the rear panel input connector J602.   Its in parallel with the pen lift switch, so with the switch open (Pen Up), ground it (and keep it grounded) to lower the pen.

[T3sl4co1l]

HPGL is not trivial. You can't just feed it to a DAC.

Uh yeah, am aware.   Plain text does not a graphics plot, make.

Many years ago I designed a box which would take in a vector stream in HPGL, Calcomp, OCE, Roland, Postscript, and various other plotter formats which were around then (1980s). The HPGL interpreter was written by a subcontractor and was "comprehensive". I've just looked to see if I have the source but I can find just a .lib, for IAR C. The output of this thing was a generic vector format.

The language has many commands.

More to the point, what is generating your HPGL? Most programs generate only a small subset.

Anything vector, really; HPGL is just an example, historically correct I suppose.

Whatever the format is, ultimately it's rendered into a sequence of vectors (whether those are linear, arc or other, is another matter); that would be as good a starting point as any.

Something with a low memory footprint would be effective for MCU; I recall the story of introducing Apple's LaserWriter, which quietly and patiently rasterized a neatly hand-optimized PostScript file into the, whatever it was, some tax form they were going to show off.  And it took forever, some minutes for its poor little CPU to crank out.  They unwrapped the code a bit, giving a much larger file, but a far simpler rendering process and it was ready to show off on stage, taking, 30s or whatever.

But yeah, if a PC or SBC is handy, rendering or plotting is relatively trivial, get it down to vectors (preferably sorted vectors!), just add path stepping (rate control) and DACs.

Tim

[LaserSteve]

I was in a similar vector situation, I needed G-code/Stepper to analog vector for  Galvo scanners on zero budget.

If you can live with 4096 x 4096 this is where you start.
Plotter file to G with whatever converter.. Then off the shelf G code hardware like GRBL because it is optimal for a single layer.
Hook the the GRBL step / direction  x and y outputs to
the STM32 with the xy step to vector converter code from this link. Wire the  Pen lift to an "M" output on the GRBL board.  Program the GRBL to run slowly in the command menu, and your done. Use the offset controls on the plotter to set a zero.

Search for
DIY STEP/DIR LASER GALVO CONTROLLER

Its still up on Hackaday.

Crude. 12 bit by 12 bit, scaling, resetting, finding zero or changing pens for color is a bit of a problem.

But it gives you a place to start for next to nothing in cost.
Yeah, and I too stumped Google.

I have a commercial stepper based laser engraving system now, but at the time the above lashup worked with a CO2 laser on a galvo pair.

Costs you a Arduino, A Blue Pill board, the programmer for the STM [7$ on sale];and a 12 bit DAC to try it.

The creator of the step to vector converter added tangent correction for the galvo deflection to his code. Just ignore it for now. For the small deflection  angles his code was wrote for, the amount of distortion you'll see in your plot should be miniscule.

Steve
 

[m k]

Back in the day Grafityp had a slitting cutter CSR and it's controller had a video chip of some sort.
No idea how it worked deep down but it had a propriety file format that wasn't big and no size limitations.
I guess the video chip was RGB something for X, Y and blade angle motors.

Anyway, it didn't do calculation errors, usually, and when it did it went through the roof.
So start and end were the same.

For a vinyl cutter that through the roof hiccup wasn't a major fault either.
If it wasn't horizontally through the whole roll.

In big picture the small error is obviously irrelevant but overall it can still be a show stopper.
Like where you can't produce some shape or form adequately.
Back in the day that was a show window case but even then it was probably more with the bad original.

My guess is that Grafityp counted triangles from fixed point.
But all curves, big or small, it did smoothly.
It was also pretty slow.

BTW,
distance of regular observation.