Absolutely. One small step at a time, though.

Or maybe have an environment variable: GCODE_PATH and search a set of places
in order. Add to the GCODE_PATH with something from the .ini file.

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: Thursday, June 21, 2007 7:56 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] O word extension


At 12:17 PM 6/20/2007, you wrote:
>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.

May want to have it look in the current working directory and if not found
there look in a dedicated directory, the location of which is defined in
the setup file.



>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.

Does that mean it has to go to the hard drive every time a sub is called?
That could be slow if a sub or many subs are called from inside a while
loop.  Would be much better to load all the subs into memory as the file is
scanned.  Memory on a PC is cheap compared to a normal machine control may
as well use it.




>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.

Someday maybe I will figure out how to get the full version for now all I
have is the Live version. :(




>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.

How about within the file O100.ngc if the sub O100 calls other subs defined
within O100.ngc?
I would imagine they would have to be in order within O100.ngc.





>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.

I usually put subs at O8000s and O9000s because on most machines those
numbers can be write protected independently of the rest of the programs in
the control.
So if I had a file named O9000.ngc with all my standard subs in it and the
last one was
   O9000 SUB
   (Do nothing)
   O9000 ENDSUB

My main program, in a different file, could start out with a call to O9000
and then any sub defined in O9000.ngc could be used when needed.  That is
effectively the same as an include command.


>[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



___________
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

Reply via email to