Yes. I thought you would never ask. :-) The latest trunk does something like that.
What it actually does: If an o-word is not found in the current file, it looks for a file named oNNNN.ngc in the current working directory. If it finds that, it searches the file for the oword and executes the oword subroutine. Otherwise it is an error. The first time the oword is encountered, the file is scanned up to the point of the oword definition. Owords found along the way are added to the internal index. Subsequent calls of the oword do a direct seek into the file to avoid the linear scan of the file. The source file interp_o_word.cc contains a comment with the important contents: "// TESTME!!! !!!KL". This should be taken as an indication that the functionality should not be relied on until it undergoes more thorough testing. I DID test it though. I believe that it is a side effect of this code that it is no longer necessary to define an oword subroutine earlier in the file than its use. The program will just do a linear scan until it finds the definition or generate an error at the end of file. There are some 'funny' consequences of how things are done. Suppose the file o100.ngc has subroutines o100 and o101 defined in it in that order. If another file foo.ngc calls o100 and then o101, there will be an error because o101 will not be scanned since it occurs AFTER o100 in the file o100.ngc. If the order of subroutines in file o100.ngc is changed so that o101 occurs before o100 in that file, it will work fine. The best way to handle this is to define the subroutine o100 LAST in the file o100.ngc. Then, if any subroutines in that file are used, o100 should be called first. If you make o100 a dummy subroutine that does nothing, that will solve the problem. [NOTE: A possible clean fix to this is to have symbolic (or possibly hard) links where o100.ngc, o101.ngc, o102.ngc, etc all point to the same file. The code would then have to test to see if a new file resolved to the same file as previously loaded files and in that case, just use the original file. At this time, it seems like a lot of work that isn't worth doing.] Ken [EMAIL PROTECTED] Mark Kenny Products Company, LLC 55 Main Street Voice: (888)ISO-SEVO (888)476-7386 Newtown, CT 06470 Fax: (203)426-9138 http://www.MarkKenny.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andre' Blanchard Sent: Wednesday, June 20, 2007 11:46 AM To: Enhanced Machine Controller (EMC) Subject: [Emc-users] O word extension On most CNC machines you can have multiple programs loaded up (registered) in the control at the same time and a sub call is really just calling another program. So it is easy to keep any commonly used subs loaded in the control all the time and just call them when you need to. With the way the sub call and definition works on EMC the subs have to be in the file with the program that calls them. This makes it harder make changes to a sub that may be used by multiple programs. Has anyone considered adding an O word such as? O- include [path/file] So that common subs may be maintained in libraries and used buy any program that needs them. ____________ Andre' B. __________ Andre' B. Clear Lake, Wi. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
