Re: [CAD_CAM_EDM_DRO] Re: 2000 members, 15 cnc related programs?????

At 19:16 29/01/2002 +0000, you wrote:

>--- In CAD_CAM_EDM_DRO@y..., Tony Jeffree <tony@j...> wrote:
> > At 16:42 29/01/2002 +0000, you wrote:
> > >The database is poorly thought out, should be separated into
>several
> > >data bases, by category (CNC controllers, Cad only, Cad and Cam but
> > >NO controller, CAM only but NO controller)
> >
> > Hmm...so instead of 1 database you would advocate 4 separate ones
>(and by
> > the way, there is at least a fifth category, which has all 3
>functions, for
> > packages such as Supercam).
>
>My categories were carefully thought out, keeping that particular
>program and its capabilities in mind. I did not say that a program
>could not be in more than one catagory, just that the functional
>categories should be clearly demarked.

That's simply not true, Fred - 3 of your 4 categories do indeed explicitly
exclude packages that have multiple capabilities outside the ones
specified. That was exactly my point. Re-read your own "carefully thought
out" categories - Supercam (for example) could only be included in the CNC
controllers category (the only one not worded in an exclusive manner); it
would not be included in any of the other 3 by virtue (respectively) of its
support for:

- CAM and controller functionality;
- Controller functionality; and
- CAD and controller functionality,

in addition to the functionality called for by your categories.

I don't think your segmentation of the database helps at all.

> > Apart from the added inconvenience and
> > confusion that this would generate
>
>I think in fact that it would better clarify the tools available in
>the software end of things. Right now Discrimintor is listed as tool
>path software, Deskam and Lcam as CAD, and up until I requested it be
>removed, VectorCam was on the list twice. Confused yet? I would
>probably add a 5th category, but for other software that did not fit
>into any of the Cad-Cam categories, like editors, calculators, gear
>programs, translators, R2V, utilities, spread sheets,etc, etc, etc.
>
>Also by making 4 seperate breaks between the controllers cads & cams,
>the appropriate capabilities between the different packages could be
>related. Such as which controllers have cutter comp, which ones have
>continuous contouring, Dos, Linux, Mac, support G-code, allow
>programmed changes in Feed rates, etc, same for CAD, CAM. This is
>the only sensible way to present the information and any other way
>becomes a meaningless hodgepodge of data without any knowledge or
>wisdom imparted.

This is just proof by assertion, viz: "The only sensible way to do X is by
method Y" - thus automatically defining all other possible approaches as
not sensible. Sorry Fred, I don't buy it.

> >, I can't see the difference in the
> > information content between that & 1 table with a column (or 3 if
>you
> > prefer) that allows the category to be indicated.
> >
>
>That's because you have already done your homework and know the
>differences. They DON'T make a difference to you. Your opinioins
>are already formed and you don't need the table to help you get
>started. For a new person to this hobby, it may make all the
>difference in the world, between success and failure.

Part of "doing my homework" when I was "a new person to this hobby" was
made considerably easier by coming across just such a table on a website
somewhere (I don't recall where now, or even whether it listed Vector <G>).
It was very helpful to me at the time to be able to find a list of what
kinds of packages were around & (very broadly) what their capabilities
were. Its terribly patronizing to assume that people (even newcomers to the
hobby) looking at such tables will not realize their limitations and
interpret them accordingly.

> > Its a point of view. I doubt very much if Ballendo intended the
>list to be
> > either definitive or a complete selling document - more a handy
>reference
> > point & source of URLs so that people could get to the full selling
>info.
>
>That was/is already contained in the group links. Why bother if the
>database doesn't provide anything more than a place to store garbage.

May be garbage to you. Others may consider it to be useful.

>I think he is trying to collect data for his book.

I'm surprised to see a professional like yourself making what sounds like
such an unprofessional comment.

> > Personally, I think it is useful - and for companies like yourself,
>another
> > means of advertising (for which we don't even charge you)
>
>My company is glad to participate in meaningful and useful sources of
>info. This database is not and apparently will not be in that
>category.
>
>It was previously suggested (not by me) that a finer pricing
>distinction be applied. This was summarily ignored and arbitrarily
>dismissed and that only contributed more to the worthlessness of the
>data.

You have no basis for such assertions about the motivations of the table
designer(s) unless you were a party to the decisions that were taken, which
I can only assume you were not.

Regards,
Tony