One possible solution to the probing issue is to write a special kinematics that interfaces with probing. With the kinematics turned off, probe the sheet at the desired resolution. A special (new) command would write the X, Y, Z coordinates of each probed point to the kinematics.
When the kinematics is turned on, it would then provide a Z axis correction for each point based on interpolation of the table that was generated during probing. This should be pretty straight forward to do. My first approach would be to do most of the work in user space. The user space code would collect the probe data. It would then generate a table in a form most usable by the kinematics code. The table would then be read into a shared memory region where it could be accessed by the kinematics code. To make this fast, I would probably use a table with a uniform grid, say 10 points per inch. (Kai, would that be fine enough?) For a 20 inch x 30 inch panel (600 square inches), that would require 60,000 points. Storing a real number for each is only a quarter of a megabyte. That's reasonably small by today's standards. A 100 points per inch would require about 24 meg. That's still not unreasonable. The kinematics are a simple change to trivkins to add or subtract the Z-axis correction from the target value based on the X and Y locations. My guess is that it would take about a week for someone who had done a kins before and who knew what he was doing. Allow a month for someone who is new to the game. Ken Kai Schaeffer wrote: > Andre' Blanchard schrieb: >>> Why would it run out of lines? It should always have a buffer >>> of interpreted G-code to read ahead. I did some experiments >>> with the relatively new G64 Pxxxx command to set the allowable >>> tolerance during contouring. I was doing 588 blocks of G-code a >>> second, and that seemed to be limited by the feedrate I had set >>> and acceleration limits for the machine, not the CPU. This was >>> on a 600 MHz Pentium III, so much faster hardware is available. >>> >> It kind of sounds like the current system may be running multiple machines >> off one computer, some type of drip feed DNC. >> > > No, one computer per machine. But the software they have right now is > ... let's say not perfectly optimized.;-). So it could happen from time > to time on the older machines with older PCs. > > But we just had another case were it happened: We milled a gear which > was defined over DXF file with a lot of small lines (some thousand). So > the radius compensation took a while (some seconds). > > >>>>>> - Measurement of the surface for a Z-correction >>>>>> >>>>>> >>>>> probing? >>>>> >>>>> >>>> At the beginning of each program we measure the Z-profile of the surface >>>> of the sheet. This profile is used to correct the position of the Z-axis >>>> to get a precise cutting depth. >>>> >>>> >>> EMC currently doesn't have a feature like that. I suspect it >>> could be done, but it wouldn't be trivial. >>> >> May be easier to run an EMC program to probe the surface and store the data >> in a file. >> Run an offline program to appliy the probe data to the part program. >> Then run the modified part program in EMC. >> > > I am not sure. Let's say you have a movement over the whole sheet. How > could you correct it if you have a little buckle in the middle? > > I would say it should be a layer somewhere between the vector generation > and the hardware. What does "it wouldn't be trivial" mean in man-months? > > Regards, > Kai > > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
