Excellent post, John. John Prentice wrote:
>Greetings > ><head_above_parapet> > >From: "Andre' Blanchard" <[EMAIL PROTECTED]> > > >>At 10:39 AM 8/20/2007, you wrote: >> >> >>>I beg to differ. >>> >>> ><snip> > > >>The work offset numbers are available in EMC but, how to access the tool >>table values in EMC? >> These move around a lot on different machines but are usually around >>#2000 or #10000 depends on if you have type I or type II offsets. >> >> ><snip> > > >>Machine position information. >> Preceding block endpoint, #5001,#5002, etc.. >> Current machine coordinate, #5021,#5022, etc.. >> Work coordinate, #5021,#5022, etc.. >> >> ><snip> > > >>And while EMC can do some of this the syntax is often very different >>making >>running a program written for a Fanuc on an EMC machine a challenge. Also >>gives part programmers one more reason not to like EMC based machines, >>which makes them less likely to get purchased in the first place. >> >> > >If one could make a control that would run code unaltered from "a Fanuc" >then it might be useful. I suspect the truth is the best that is possible is >to run code for a "Fanuc xxE Rev d.q Option 3" and that is hard and has >little general applicability. > > Additionally, it's impossible to make something that's compatible with *both* Fanuc *and* Haas, for example. So although users of a specific machine we might emulate will be happy, the users of the other 200 models/brands won't. >As soon as one conteplates modifying legacy programs full of # parameters >one is doomed. Is anyone left of this list who literaly programmed a "real" >program in binary/octal/hex machine code without the benefit of a symbolic >assembler? The nearest I came was keying the standard PDP8 boot loader. > >I submit one should not contemplate extension of the # parameter mechanism. > > I agree wholeheartedly. Unfortunately, it's often easier to make small changes to what's there than it is to design something new. >So what is needed? Probably many things are useful but I suggest two that >are different in kind. > >(a) Interactive CAM. The distinguishing feature is that the result of using >such a system is a "G-code" program or program fragment. There are plenty of >exemplars both in commercial machines and PC controllers. In essence one >defines the desired cut(s) by choosing from standard operations like >pockets, facing, PCD circles, standard panel apertures etc. and/or teaching >by recording jogs. Such a system have very little interaction with the >control beyond being easy to initiate, have a neat way of loading the >generated code and perhaps picking up DROs for teaching. >The author of this type of program needs access to tools to implement a GUI >for his/her users and the ability to write to a part program "file". > >(b) Interactive machining. Here the distinguishing feature is that the >thread of code run by the user actually controls the machine. This allows >two things. Firstly the control flow of the user program depends not only on >user input but on the machine state (e.g. the tripping of a probe, the input >power to the spindle). Secondly it can take place whilst a "G-code" program >is loaded - so is useful for tasks like semi-automatic stock preparation. >The author of an Interactive program needs access to tools to present the >GUI at the user side, the ability to issue commands to the machine (say in >the form of G-code strings) and to read the current state of hardware and >software (offset systems, modes, speeds etc). This is a tougher call. > > There's a (c) as well: non-machining applications. EMC2 has at its core a very nice motion controller, and an excellent I/O interface layer. There are a number of ways of using motion and I/O that aren't related to machining: robotics, packaging, cell-to-cell part moving, etc. There are a number of generic motion controllers out there, some even have pluggable kinematics like EMC (so you can use a serial robot but specify waypoints in cartesian coordinates instead of joint positions). Most start at the $2000 range, and don't have a lot of I/O. They're programmed in various ways, but there's usually some scripting language (see Yaskawa's SMC4040 for an example of a script language I don't much like :) ) I can see EMC2 with a similar scripting language as a front end instead of the G-code interpreter. Ideally, I'd like to be able to have the motion controller capable of servicing multiple clients simultaneously, but that's a very radical design change. Note: I mean multiple clients, like a G-code interpreter that outputs commands for 4 axes, plus a robot controller that outputs commands for a separate two or 3 axes, each being able to do its thing without the other necessarily knowing about it. This is distinct from several user interfaces all controlling the same "motion client": the G-code interpreter and its associated stack of protocols and processes. ><head_even_higher> > >These interfaces feel to me to be much like interactive web page designs. >Flash (and its support tools) seems to be a strong contender (very powerful >graphics - static and dynamic, a form of object orientated programming, >surprisingly efficient) although the Linux world seems currently rather >deprived on implementation. > ></head_even_higher></head_above...> > > <head out of a$$> I'd say that flash, although it's more or less fine for media, has no place in the requirements list for EMC2 :) There are any number of fine programming languages and environments to use for the UI. I'm not sure what you'd use to make a flash presentation on Linux anyway, and I wouldn't want to be beholden to Adobe to make updated versions for my OS (which they don't - I use a 64-bit version of Linux, and they don't seem to like supporting 64-bit OSes on anything but PowerPC macs AFAICS). On a technical level, I'm not sure what facilities Flash has for actually doing things that aren't "media" or web-related anyway. </head back in a ... oh, wait a minute> >John Prentice > > - Steve ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
