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. 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. 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. <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...> John Prentice ------------------------------------------------------------------------- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
