Sounds like a normal renashaw type of probe you have. When probing your first touch is at a higher speed then the second touch is slower to get exact position. The results can be stored in a file. Look at gridprobe.ngc in your nc_files folder for an example.
John On 3 Jul 2008 at 9:47, Kai Schaeffer wrote: > Hi every1, > > Thank you for all the response to my question. So this is a very > active community. As our ERP system we have chosen ADempiere > (http://www.adempiere.com). There we have a very active community, too > (and we are an active part of it ;-) ). I know how valuable such a > community is for an OpenSource project is, or how valuable the > community makes the project. > > I took a look to the link Andre' posted. Yes, I guess that's the way. > Actually 10 points per inch is more than enough. Now we are using a > point distance of about 30-40mm, with a good result. > > But I have one question regarding the collection of the data: To > measure the points I think it would be necessary to save the axis > positions on a trigger pulse. The Datron machines do the probing with > a tip. It moves down and if it touches the material it sends out a > puls. And to make it precise the latching should happen with a very > short delay (the z-axis is still moving at this moment). I guess it's > the same problem you have with the measurement of the tool length. So > is there a functionality for this? Could it be done in user space? > > BTW: The sensor tip Datron uses is sensitive in all three dimensions. > So you could also use it to determine the position of a breakout - a > nice feature. > > -Kai > > Kenneth Lerman schrieb: > > 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 > > > > > -- > Schaeffer AG > Dipl.-Phys. Kai Schaeffer Vorstand > Nahmitzer Damm 32 Tel. +49-30-8058695-25 > 12277 Berlin FAX: +49-30-8058695-33 > http://www.schaeffer-ag.de > > HRB 93611 B, Amtsgericht Berlin Charlottenburg > Vorstand: Jörg Schaeffer, Kai Schaeffer > Aufsichtsrat: Dieter Kersten (Vorsitzender) > > > > ---------------------------------------------------------------------- > --- 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 > ------------------------------------------------------------------------- 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
