Stephen Wille Padnos wrote: > Kenneth Lerman wrote: > > >> Here is my first guess at how I would do this: >> >> 1 -- First, I would "enhance" emc to support a new M code that took at >> least four arguments and returned at least one variable. Lets say M999 >> takes arguments N, X, Y, Z. N would be the name of an external program >> to run (say N=123, then ExtFn123 would be run). The other variables >> would be passed as arguments. Variable #999 (or whatever) would get the >> return value. >> >> >> > Why not enhance the existing "external M-code" feature so that it can > pass multiple arguments (not just P and Q) to the called program, and > which can get some sort of function return? The returned value could > even be a string that gets parsed, so the program could return something > like #999=[47.2] #998="-109" ... > I hesitate to change the existing feature because I wouldn't want to break existing programs. My understanding is that the values of P and Q are assigned to the first and second arguments of the script. It makes sense to just pass the named arguments to the script in (not necessarily in the order that they occur) including the letter, the '=' and the value (after evaluation of functions).
I think that parsing the returned string value is an excellent idea. That would even let you call a gcode subroutine with supplied values. > >> 2 -- I would implement a new scan function that called M999 N=1 X=... >> Y=... Z=... ExtFn1 would take the X, Y, Z values and store them in some >> file. >> >> >> > Probing can already do most of this, though it would be interesting to > have a "hook" that gets called whenever a probe move finishes. This > hook should receive several pieces of information, probably including > start position, target position, probe trip position, and a flag or two > saying what kind of probe was being done and whether it succeeded. (the > success flag is redundant, but it saves comparing the probed position > with the target endpoint and including fuzz, in every hooked program) > Incidentally, this could be something like the existing probe log > comment/commands: > (PROBE_HOOK, "M199 myfile.txt") > > >> 3 -- I would implement a conversion function that converted the scan >> file into an easily (efficiently) read format. That might be M999 N=2 >> (ExtFn2). >> >> 4 -- I would implement an external function (ExtFn3) that takes the >> arguments X and Y and returned the Z value (in variable #999). This >> function would use the file format described above. >> >> All of this seems pretty straight forward. >> >> >> > I think this all remains the same using the scheme I outlined. > Thanks for your comments, Steve. Since I don't have a probe, I don't think I'll be implementing this any time soon. > - Steve > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > Regards, Ken -- Kenneth Lerman Mark Kenny Products Company, LLC 55 Main Street Newtown, CT 06470 888-ISO-SEVO 203-426-7166 ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
