Ray Henry <[EMAIL PROTECTED]> wrote: > And I'd interpose a third way -- task. Both of the above approaches > using the HAL and the Interpreter have a good deal of merit within the > context of each system. What is missing from each is a system wide way > of describing the state of the machine so that effective coordination > between IO, motion, and command can be handled
You may well be correct, that task is the "right" place to do such things. I think one of the main reasons we find ourselves looking to either g-code or HAL is that task (as currently implemented) is not flexible/configurable, while g-code and HAL are. Task is written in C++, and if you want to change it, you fire up your editor and modify the source, then recompile. And you hope you didn't break something when you made your changes. On the other hand, both g-code and hal are easier to change. Neither one is a general purpose programming language, although g-code is probably closer than HAL. Both lack such basic features as named variables, variable scope, etc. HAL lacks even rudimantary flow control, while g-code's abilities in that area are limited. What they do give you is the ability to make high level things happen with one or two lines of "code", and well defined side effects. In g-code, you can simply write G1 to generates a coordinated move, with little concern about anything happening beyond the move. However, someone who starts modifying task to make it do custom things needs an enormous amount of knowledge about the existing system. Other- wise, there is no way he can anticipage and deal with the various side effects of his actions. Excuse my rambling, but let me put it another way. G-code splits the task of making a part into two chunks. The g-code itself is contains the part specific knowledge, and the interpreter contains the general knowledge (the definition of the language). Likewise, a HAL config file contains system specific knowledge, while the HAL itself contains the general knowledge (definition of the language and the behavior of the individual components). Task doesn't have this split between application specific knowledge and general knowledge. The application specific stuff is buried in the code, right next to more generic stuff. Perhaps we need to look closely at task, with the idea of separating out the application specific stuff. We need a "language" that can tell task what machine specific things it needs to do, in the same way that g-code tells the interp what to do, and .hal files tell the HAL what to do. > Let me suggest that you read the following abstract and if you find > things that disturb your current thinking about the EMC software, > download and read the document. While it deals in more complex > IO/Motion systems that we do, the principles are the same. > > Barbera, et-al say, > > "The Real-time Control System (RCS) Methodology has evolved over a > number of years as a technique to capture task knowledge and organize it > in a framework conducive to implementation in computer control systems. > The fundamental premise of this methodology is that the present state of > the task activities sets the context that identifies the requirements > for all of the support processing. In particular, the task context at > any time determines what is to be sensed in the world, what world model > states are to be evaluated, which situations are to be analyzed, what > plans should be invoked, and which behavior generation knowledge is to > be accessed. This results in a methodology that concentrates first and > foremost on the task definition. > > http://www.isd.mel.nist.gov/documents/barbera/How_task_analysis.pdf Interesting document. I've only skimmed it so far, but good stuff. It basically outlines a process that is used to break up complex tasks like driving a vehicle (or running a machine tool) into smaller and smaller tasks which can eventually be implemented in software. The main problem that I see is that it assume a team of developers is going to go through the process from scratch for every new top-level task. That's fine when you are NIST and your individual projects are very challenging, such that you expect to spend months or years working on each one. You can go through the process, and embed what you from it directly in the code. But when you are a machine builder, you can't afford to go through the entire process from scratch. You want to be able to use as much of the existing knowledge as you can. Thzt means the knowledge can't be buried in the code. It needs to be out in the open, where you can read it, and modify the parts that you need to change for your specific machine. EMC's ini file has always been intimidating to new users, because it is an attempt to do exactly that. It puts a _lot_ of information out there where you can change it, even if 95% of users are only gonna change 5% of the items. HAL is the same way. But even that isn't enough = there is still a lot of hard-coded behavior in task and elsewhere. In general, you can take one of two paths - you can keep the configs simple by hard-coding the vast majority of behaviors, or you can stay flexible by using configuration data to define almost everything. You can't do both. If we want to support a wide variety of machines, we need to get the behavior definitions out of task and into some sort of configuration. (The behaviors might still be implemented by task, but they would be based on the config data, not hard-coded.) An example of this is the tool-change stuff. EMC1 (and I believe EMC2) has a "tool change position" in the ini file. That is the place where the machine goes when its time to change tools. Works great for tradtiional toolchangers, because that is what the developers had in mind when they hard-coded that behavior. But there are tool changers that store the tools in slots on the table, such that the machine needs to move to a certain slot to get the tool. The current task simply can't deal with that, because it doesn't fit the hard- coded expectations. The problem with getting all the hard-coded stuff out into the config files is that the 95% of people who only need to change 5% of the configuration are gonna be intimidaged by it. I really don't know the answer to that problem. I think this is a usefull discussion. I'm glad Jeff started it, and I look foward to seeing where it goes. Regards, John Kasunich ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
