Re: HP-GL for slice data

From: Stephen J Rock (rocks@cat.rpi.edu)
Date: Tue Nov 26 1996 - 16:48:43 EET


Ian,

I see your point on the increased file sizes required for ever-finer facet
approximations of 3-D objects (e.g. STL files). In principle, I think that the
most elegant solution is to use exact (or at least higher order) math forms
which require less "data" to more accurately represent the same surface
"information". In practice, this will require more sophisticated CAD software
to handle the increased complexity and variety of geometrical primitives.
This increases development costs and make compatibility more difficult to
ensure.

This seems to give one the ability to trade programming cost for computer
hardware cost. Given that RP process accuracy should always be limited by
the hardware (not the data), it seems the question is "can future compute
power and storage capabilities evolve at a faster rate than necessary to
keep pace with RP process hardware accuracy advances?" If I were forced to
bet, I'd gamble that they could. I'm sure by today's standards "file sizes
and [the] amount of number crunching [required to support RP] is going to
become ridiculously large," but I think the power of the computers on our
desktops will even outpace this.

I'll leave the rest of the 2-D (direct slicing) vs. 3-D (slice at the
process controller) debate for someone else.

Regards,
Steve
=====================================================================
Stephen J. Rock rocks@cat.rpi.edu
CII8015 (518)276-2280
NYS Center for Advanced Technology 276-8652
in Automation, Robotics & Manufacturing fax 276-4897
Rensselaer Polytechnic Institute
Troy, NY 12180 USA http://cat.rpi.edu/~rocks
=====================================================================

> From rp-adm@bart.lpt.fi Tue Nov 26 01:02 EST 1996
> X-Authentication-Warning: bart.lpt.fi: major set sender to owner-rp-ml using -f
> X-Sender: igibson@hkucc.hku.hk
> Mime-Version: 1.0
> To: rp-ml@bart.lpt.fi
> Subject: Re: HP-GL for slice data
>
> Sorry for this long posting, including that already sent, but I felt I
> needed to keep the picture.
>
> >
> >
> >On Mon, 25 Nov 1996, Delft Spline Systems wrote:
>
> >> How can this language ever represent true (3D) surface data ?
> >> The only assumption I can make is that you mean to use slice data
> >> to represent the 3D surface in a large number of 2D sections. In contrast
> >> to using 3D STL files, when using HPGL the slicing will have to be done
> >> in the CAD-software.
> >> Regards
> >> Lex Lennings.
> >
> > This is correct. When people speak of using HP-GL as a language for
> >communicating to fabricators (or "RP machines"), they are speaking of
> >transferring slice data. The CAD program or an intermediate slice program
> >would take the responsibility for creating a series of HP-GL contours
> >from the 3-D data.
> > The current configuration of the Genie fabricator runs on HP-GL. But
> >we have a slice program that reads StL and outputs HP-GL.
> > HP-GL does have the advantages of being able to represent standard
> >curves, such as circles and ellipses, efficiently and without faceting.
> >So for these curves, it is better to get the data direct from the CAD
> >representation instead of through StL, which will break these curves up
> >into little lines. However, I am not aware of a way for HP-GL to
> >represent complex curves, e.g. from NURBS surfaces, directly. (If there is
> >a way, someone please correct me.) Because of this, I believe we will
> >ultimately have to do better than HP-GL.
> > Comments?
> >
> >Best regards,
> >Marshall Burns
> >marshall@ennex.com
> >
> >
> >
> As you all know, I'm a layman, but I am a loud mouthed layman, so here I go:-
>
> Am I right in thinking that breaking things up into little lines does not
> cause a particular problem provided the lines are small enough? If the stl
> file has a minimum triangle size smaller than the resolution of the process
> then they are not going to be noticed in the part.
>
> However, as the resolution of the current and future rp processes improves,
> I feel that the file sizes and amount of number crunching is going to become
> ridiculously large.
>
> HPGL therefore looks quite attractive from the point of view of cutting out
> the middle man. By using this method, slices can be generated directly from
> the CAD model without the need for the intermediate stl file. To me this
> looks very efficient. A couple of years ago I saw the F&S guys (what
> happened to them BTW?) promoting HPGL in this way. They showed a macro that
> seemed to slice a very big file in the blink of an eye and it all struck me
> as being ingeniously simple.
>
> However, I think it means the CAD system should be tied to the rp system
> somewhat, which may be undesireable. Variable thickness slicing and dynamic
> control of the build height may be problems unless the CAD system is on hand
> to provide slice data in real time. Support structures will also have to be
> generated using the CAD system. Unless these points are adhered to then
> there would be no particular advantage in using HPGL.
>
> But doesnt that look interesting, particularly for the small rp systems? A
> CAD system directly connected to the rp system, sharing resources, avoiding
> the generation of large data files. A direct database of the operating
> parameters of the machine inbuilt into the CAD system. Hmmmm.......
>
> One other point though. Direct slicing of CAD seems to have gone out of
> vogue, largely as a result of the debate from people much more qualified
> than I. There are obviously many more issues than I raised here. Perhaps one
> of the software gurus can enlighten us?
>
> Regards
>
> IG
>
> Dr Ian Gibson
> Dept. Mechanical Engg.
> University of Hong Kong
> Hong Kong
>
> email: igibson@hkucc.hku.hk
> www: http://hkumea.hku.hk/acad_igibson.html
> tel: +852 2859 7901
> fax: +852 2858 5415
>
> Did you know that the wingspan of a jumbo jet is longer than the first
> flight of the Wright brothers?
>
>



This archive was generated by hypermail 2.1.2 : Tue Jun 05 2001 - 22:37:46 EEST