CAD CAM EDM DRO - Yahoo Group Archive

Re: Teach-in was Re: CNC UI (V hj vs. conversational prgmmg)]]

on 2000-11-08 13:45:06 UTC
Ballendo,

After thinking about this "learn" mode for a while, I can see that if
you allow one to start/stop recording, and have the operator enter in
Gcode commands, it would be a simple matter to create a reusable file.
While "turning the knobs", if blocks to be generated can be separated by
a specified keystroke to "mark", then the move just taken (linear,
single axis) could be used to define the movement to the next "point".
Or a multiple axis (coordinated) move could also be saved if the axis
move relationships were specified as you have mentioned. Could this
work? Is it being done somewhere already? Gcode output was the first
thought, although a .DXF would be useful also, it could be input into
the CAD program (going in circles here).

>
> -------- Original Message --------
> Subject: [CAD_CAM_EDM_DRO] Re: Teach-in was Re: CNC UI (V hj vs.
> conversational prgmmg)]
> Date: Wed, 08 Nov 2000 06:43:06 -0000
> From: ballendo@...
> Reply-To: CAD_CAM_EDM_DRO@egroups.com
> To: CAD_CAM_EDM_DRO@egroups.com
>
> Alan wrote:
> >Well, maybe there's some hope for the joystick yet! About
> >the "teach" operations, you think that's valuable?
>
> Yes. VERY. It's like Fred was pointing out in his post. You make the
> first part CAREFULLY. Then you "optimise" for the production parts
> based on what you have learned.
>
> It would be REALLY easy for a MaxNC or CncPRO to add a basic form of
> teach-in. Just write the MDI commands to a file as they are
> processed! Not the best, by a long stretch, but a WHOLE lot better 'n
> what we're workin' with now! Adding the Dancam/plot functions could
> really help. All the "math" is already in the control. It's just not
> being used in this way.

Yes, you did say write the MDI commands directly to a file. Here I go
again. Until MaxNC or CNCpro put a "record" function into their code,
perhaps a TSR can capture keystrokes. The real-time checks for the
keyboard might be a problem (TSR might get in the way). But programs
like Carbon Copy do stuff like that. It isn't that hard.

>
> It's like the adage I throw out here from time to time, "If your only
> tool is a hammer, then everything looks like a nail". We have to
> conceptualise outside our "available" tools.
>
> Ted Hall(inventor/developer of the shopbot) has said,"Early on, We
> decided against G codes". They took a "new" look at the problem.
> (personally, I don't think there's anything wrong with gcodes; just
> in the way we perceive using them)

I'll have to see what Shopbot is doing. No gcodes you say. How are we
looking at them wrong? I think of them as just a coding for moves in
several axis. Not unlike HPGL plotter code (2.5D), with some additional
controls. Just grown-up turtle graphics with better math! How do you
think we should look at them? Is there another way?

>
> I believe that one of the reasons shopbot has sold so many machines
> is their attention to the user needs. Simple for beginners, but with
> shortcuts and power for advanced users. For example, their "CC"
> command "cut circle" has the option of "tabbing" the part(raising the
> cutter slightly for a short distance repeatedly through the move to
> leave the part attached to the material by "tabs").

Attention to detail. Code written for the task, without trying to force
one into the program.

> Now we would/could do this in CAM(vector), but there it is, on/at the
> control! I hope Ron G or Art fenerty or anyone else writing a control
> looks at their S/W. manuals available online at:

> http://www.shopbottools.com
>
> If you know the syntax, you just put in the code; if you don't, a
> conversational input is easily available (on an as needed, where
> needed basis) You "slip" from one mode of interaction to the other,
> effortlessly. Nice. Easy. Powerful.
>
> Lots of power user stuff combined with newbie usefullness, IMO.
>
> Yes, Alan, I do believe teach-in is a "missing link" in the home
> machinist shop environment "chain".
>
> Ballendo
>
> P.S. Given the choice, I program (computers,not CNC) in BASIC.
> Powerbasic.(compiled) Part of the reason is a stubborn resistance to
> the "dumb compiler, obtuse language" direction of C . Several years
> back, the computer world had the chance to make the compilers'
> smarter, so the programmers could be dumber. But the "white shirts"
> intervened, and protecting their jobs, created the "syntactical MESS
> we call C++.

OK, some of us programmers LIKE obtuse. BASIC was written originally at
a university to TEACH programming, whereas 'C' was written to write
operating systems in. It gets down to the hardware quite good, and is
close to the assembly language. C++, on the other hand, is an attempt
to ADA-ize a good language, and see how ridiculously complex it could be
made (IMO). Use whatever is comfortable! Pascal, Forth! Don't know
about LISP. always lost track of the )))))'s.

>
> My powerbasic compiler lets me work at a BASIC (pun intended) level
> which anyone can master and understand at a glance, BUT it also
> SUPPORTS me at a very high level (inline assy, pointers, dynamic
> memory allocation, etc.) when/ if I need it.

Yes, anymore BASIC can do all the major things the other languages do.
Good 'C' is clean, crisp, and concise. Works for me!

>
> This is what I think the IDEAL CNC control should do also. The high-
> end machines of industry are getting close to getting this right. We
> just need to bring it on down to our "pocketbook" level, IMO.

So we'd better get busy doing our own! Good discussion! Lottsa good
ideas! I'm enjoying it! Would like to here Art's, Ron's, Dennis' and
other's thoughts. I just might have to write something.

Alan

Discussion Thread

Alan Marconett KM6VV 2000-11-08 13:45:06 UTC Re: Teach-in was Re: CNC UI (V hj vs. conversational prgmmg)]]