Re: [Gerbv-devel] Changes to logic which determines file type

[Julian <the...@gm...>]

Yes, I agree with your thoughts, Stefan.  I've never come across a
bulletproof way of IDing a pick and place file, to be honest.  I think I
threw some logic in there to look at how many lines it found with consistent
numbers of columns and compared that to how many lines there were in the
file.  It also aborted if it found a few of the Gerber commands.  It would
really be nice to get some more PNP examples from different CAD programs and
look for a better metric, though.

BTW, I think I still need to update the pick and place code for my latest
unit changes...I believe it segfaults on some pick and place files during
rendering since I haven't initialized all the layer or state variables in
the pnp file...I'll work on cleaning that up in a few days.

Cheers--

On Dec 28, 2007 4:24 PM, Stefan Petersen <sp...@st...> wrote:

> Stuart Brorson wrote:
> > Guys,
> >
> > I've been looking at the logic which decides what type of file is to
> > be read in.  The logic is kind of funky, and is certainly not robust.
> > You can find it starting at gerbv.c:401.  The code (in pseduocode)
> > looks like this:
> >
> > if (is_drill)
> >    parse_drill
> > else if (is_pick_and_place)
> >    parse_pick_and_place
> > else
> >    parse_gerb
> >
> >
> > Now, if you look at the functions which check the file type, they work
> > like this:
> >
> > is_drill:  Default = False, but if certain drill codes are found, then
> > return True.
> >
> > is_pack_and_place:  Default = True, but if certain drill or Gerber
> > codes are found, then return False.
> >
> >
> > My thoughts on this:
> >
> > *  It would be nice to have a function "is_rs274X", which returned
> > True if the file has Gerber codes, *and* aperture definitions are
> > found, and False if not.  This would be much better than just trying
> > to open a Gerber by default.
> >
> > *  It would be nice to have a fcn "is_rs274D", which checks that the
> > file is a Gerber file (i.e. has Gerber codes), but has no aperture
> > definitions.
> >
> > *  The if/else stuff should have a default which just prints a message
> > like "Unrecognized file type" if no positive indications of file types
> > are found.  This would help with the segfault problem.
> >
> > *  The stuff which recognizes pick-n-place files should default to
> > False (not True), and only return True if *positive* indications of
> > pick-n-place are found.
> >
> > Any objections if I make these changes?  Any ideas what one should
> > look for as a *positive* indication that a file is a pick-n-place
> > file?  That is, what codes are unique to pick-n-place files?
>
> I did some changes in this yesterday and realized how stupid it was
> made. I just put band aid on it to be able to go on.
>
> I started to think a bit about it today and came to about the same
> conclusion as you have. So I just say, go ahead.
>
> The pick-n-place files are comma separated files, like the ones you can
> import to Excel. Comma separated varies between europe and the states;
> the states use comma as separator and europe semicolon.
>
> There are some examples in the example/pick-and-place directory.
>
> Best regards,
> /Stefan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gerbv-devel mailing list
> Ger...@li...
> https://lists.sourceforge.net/lists/listinfo/gerbv-devel
>