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.

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.

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.

Ken

Alan Battersby wrote:
> Hi,
> I am writing  a gcode generator to create paths for ornamental turning
> by simulating a rose engine. I have nearly completed the initial part
> and am now looking at one of my further aims which is to allow me to
> import a surface profile and then cut patterns following this profile. I
> have the facility to import a probe file produced by emc which is all
> working fine as is generating simple gcode, this is because I can access
> the surface depth data directly in my program.
> 
> My problem is that I thought I would use a bit more of emcs gcode
> capability. So an alternative gcode generator (I can select which to
> use) wraps every path as a gcode subroutine which is called from within
> a gcode loop, looping for depth of cut etc, see attachment which was
> generated without the surface following functionality. (I ultimately
> intend to save each path in its own code file and call them externally
> as required but not there yet).
> 
> Now the subroutine case the decision about what depth to cut is taken as
> the gcode is running rather than when the code is created.
> By way of example
> 
> In my program I use three bool flags; use_surface - true if using a
> surface profile, follow_surface which is set true if the cut is to
> follow the surface profile and finally a flag called
> surface_pre_machined which is true if the surface profile has already
> been cut before the path is cut.
> 
> By way of explanation assume at a given point on the path the surface
> depth is 10mm, the path depth is 6mm and the roughing cut depth is 2mm.
> If both follow_surface and pre-machined flags are true then the first
> cut depth should be 12mm and that I am cutting air for 10mm before I
> reach the surface. So after a rapid move to the position at a safe
> height I want a rapid move to depth 10mm then a linear feed move of 2mm.
> So a total depth can be cut in three passes. (I have incorporated a
> final finish cut pass but am ignoring that here).
> If pre-machined is false then I will be cutting the whole of the 16mm in
> 8 passes on the assumption that the surface profile will be cut later.
> 
> However at each pass I dont want to move the cutter depth to cut into a
> rising bit of surface profile deeper than necessary. So if at some point
> the current cutter depth is say 10mm and the surface rises to 2mm I need
> to raise the cutter to 8mm (2 + 6 path depth). Thus my need for depth
> data at run time.
> 
> I had thought that a clumsy way of overcoming this problem would be to
> set up a current_surface_depth variable and assign it as I loop through
> the points on the path in my program but I would rather access the data
> in array form if possible any suggestions?
> 
> Finally why am I doing it this way? Well I want to be able to take a
> flat block of wood etc and cut my pattern as if it was on a domed
> surface. Then fill the cuts with some coloured resin etc (easy to do on
> a flat topped surface) and then cut the dome afterwards as a lid.
> 
> Why am I bothering with subroutines and not just sticking to simple
> gcode? Well 1) the files are much smaller and 2) I like programming it
> was my job before I retired so this is also part of my hobby as much as
> the actual machining.
> 
> Last time I asked a question someone asked if I was releasing my code,
> the answer is yes and I have started a blog describing the program at
> http://wood at dyadica dot net/site/  obviously replace at with @ and
> dot with .  But I must emphasize that everything including the blog is
> at weak alpha release.
> 
> So can someone suggest the best way of achieving my aim?
> Thanks and sorry this is so long
> 
> Alan
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> 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

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

Reply via email to