Re: [CAD_CAM_EDM_DRO] Re: hpgl code and plotters

ballendo wrote: (lotsa snipping..)

> But, for
> >machining anything past diamond drag engraving or vinyl cutting...
> >It leaves much to be desired.
>
> Your original question was why the engraving and vinyl cutters ahs
> stuck with HPGL! You've answered your own question above...

I don't think I answered it myself, because, if it is only good for diamond
drag and vinyl, why are there so many CNC router and engraver companies that
still use it , and even apply it for 3d work ?

>
> Different customers; different tools. And toolpath order is generally
> taken care of by the engraver or vinyl cutter internal s/w.

Whoooaa thar ! "Toolpath order - taken care of by the engraver/vinyl
INTERNAL s/w" ??

This I never saw. I never had any machine that anylized the code and changed
it for a particular "order" based on some controller setting. I think that
would be near impossible unless the Controller itself was a PC with a drawing
interface.

The Originating program *dictates* the entire cutting order ! The machine one
runs the code on only runs the items as it comes.

When you draw something in Corel, that IS the order it will Export the hpgl
code. You can make minor changes in Corel by "changing" the "home and End"
nodes for direction of cut, but you can not "reorder" anything unless you
re-draw it in the order you want it to cut. The machine itself lets you do
nothing. This is different than some DXF imports (FlashCut for one) which
does have some routines for setting cutting Order upon code Import. This is
done often for plasma and torch use.

Unless your point above is not about "Internal" but rather in regards a full
Sign Software package like Signlab (External).... There you can go and change
any direction, stop/start point Etc. Then the changes are reflected on
Export.

> >So, why is it that companies seem to not "see" what the products
> >capabilities are or where a market is that could use enhancements ?
>
> Human nature, IMO. Most of us are busy enough doing what we "know"
> that we don't spend too much time "looking" for things or areas that
> we do not know... Also, it is much harder to see what you do not
> already know, than it is to re-interpret what you know in different
> ways. (the reason I use analogies so frequently)

Well, this must be the case and it is too bad !

I think Mr. Marriss has a pretty good grip on things as I see a bit ahead in
the messages that he is looking and requesting input in regards his new
project.
Best wishes to him accomplishing this task !

> We've come again to my favorite subject. The g code standard isn't.
> And most programmers don't write "output drivers" anymore. They just
> pick from what's already available, adding them to their product
> (often without even understanding the code). If there was a universal
> G-code driver that these companies could easily "add", I believe they
> could be induced to do so...

I think we will not agree here. For one, G-Code has GOT to be far MORE
standard than the DXF format that so, so many people rely on from day to day.
I am not talking of a G-Code export filter that sticks in all of your
favorite auxiliary functions from toolchangers to spindle speeds. I'm talking
about simple X-Y locations prefaced with a G01 when "in the material" and a
G00 when not. It would have to be better than any DXF techniques.

SignLab allows you to export such a generic G-code or an enhanced one via
.ini settings. This should not be a problem to install even if they made the
filter themselves.

I also do not feel that most developers just can "grab" an off the shelf
filter...... My understanding is that Corel 10 FINALLY has DXF filters that
work. Somebody had to make them work, I don't necessarily think they found
them on a shelf. But, gee,,,, I am far from a programmer. If it turns out to
be THAT easy..... Some software companies are really in their own little
world !

> But windows changed the way the game is played (compared to
> dos). "You don't hafta write low-level stuff anymore; we did that for
> ya" . I've used designcad since dos. When they changed to windows,
> the hpgl "windows" driver no longer did arcs in a sensible "one
> stroke" way. Instead what used to be a coupla hunerd (at most)
> segments sequentially defining the circle, it worked quad by quad,
> like a pecking chicken (if watching a pen plotter- or a cnc<G>)

Here you are describing an issue where from one machine to another, I've seen
it handled in a variety of ways, across different OS platforms. Most of the
differences were in what the machine was expecting, or what it was designed
to receive and understand. Thus, the programs that generally communicate with
a particualr machine would need a "particular" post or configuration to
communicate effectively. Even then some machines were very difficult.
NewHermes engravers come back to haunt me in this regard though I did find
ways to run them that had the Sales/Engineers wondering.... I wouldn't tell
after their abilty to skirt the issues. Their newest of machines look very
nice and hopefully have a newer more open control. Some of the best hpgl
controls were the ones who prefered to NOT get any AA (arc) commands and just
took short line segments.

Momentarily, "Re-living" some of the many, many hours I spent with hpgl
machines, and the fact that I can produce output of like a hundred Different
hpgl machines (go to Cadlinks site and view information on "supported"
machines), This whole topic "Convinces" me that Hpgl is not as standard as I
would like anyhow ! Then when they try hpgl in a 3d environment with mishmash
extensions????.... no thanks.

> Isn't this borne out by the growth of EMC?

Growth of EMC would be hundred fold if it was packaged in a pretty box and
SOLD ! Because this will likely never happen, EMC *could* be the ultimate and
still never obtain the market share it could. Strange but IMO true........

> I would much rather dive into 20 or 30 thousand lines of G-Code
> than Hpgl to "see" where I am and what is going on.
>
> Gcode machinists spend thousands of hours each year doing the same
> thing. Your point is?

I CAN see with the many wonderful code editors out there. If G-Code was all
that non conforming, I don't think there would be so many of these excellent
programs out there. ( of course if software developers would put a decent
code editor in their programs, there probably wouldn't be).

I am however interested in ..... well, heres a good homework assignment.....
Name me ONE hpgl code editor with visual toolpath verification that has no
problem reading any of the hpgl code I could produce right out of a common
sign software package.....

If I was a betting man, I could put somethin on this.... Ya Know ??

Let me know where to look. There may be something on the otherside of the big
fishpond if hpgl is popular over there.


This is good stuff ! Eh ?

Chris L

Disclaimer: NONE of the above is meant argumentive. Detailed discussion,
helps all to look into the "corners" of our CNC world and find answers.
Answers that can make our CNC hobby more fun ! The knowledge shared by all in
this group is worth millions !