On Saturday 28 March 2015 23:53:53 Scott Salrin wrote: > Thanks again for the words of encouragement the other day, guys. > I've been thinking, which has always been dangerous for me. I need to > bounce my thoughts off of some smart people, to set me straight. > > First let be beg forgiveness if this is inappropriate, or if I pull > this thread off topic... It seemed dead anyway. > > As I mentioned, I have not received the machine yet, so all of this is > theory at this point. The router is a Probotix Nebula, and will come > ready to make chips out of the crate, but I have a lot to learn in > preparation and trying to figure it out on my own is starting to hurt. > I am having a tool length switch installed and it will come configured > with a tool changing routine. The routine is called by a o100 command. > I am also having a 4th axis rotary installed. > > This is where I am confusing myself. I haven't purchased the cam yet, > but do believe it will be vectric aspire. This means the the rotary > work will have to be wrapped around I believe the x axis, in this > case, at the post processor. I also want to use the makers guide > featured in the attached video, foe most of my work, and will need to > pull off all the custom buttons and code to make that happen. > > Am I correct in thinking that all the coding I'll need to do will be > in absolute co-ordinates, and not affected by the gcode that is > wrapped around the x axis. Like if I set the rotary to be say a G55 > work co-ordinate, and run a wrapped gcode file that has tool changes > in it, when a tool change routine is called the machine will go to the > tool change position, wait for me, do the routine and go back to G55 > and start running the wrapped code again? > > Or, is it going to sit there after the new tool length offset and spin > the A axis instead of travelling back the the work offset origin? > > Here is a link to the code Probotix uses: > http://www.probotix.com/wiki/index.php/Automatic_Tool_Length_Sensor
That page, after I hit ctl+ enough times to make it readable, contains one statement right at the top that with linuxcnc, is not true, and represents that each tools operations have to be in a separate file. With the use of different co-ordinate systems, the splitting of files, such as an eagle drill file where many different drill sizes are used, the auto tool length subroutine is inserted as a wrapper around the M6 T# issued eac h time its found in the generated file, doing the tool length measurements and correcting the co-ordinate system used for the next drilling operations. To use eagle as the gcode source via pcb-gcode, I have written tedautoz.ngc for top of board operations, and bedautoz.ngc for bottom of the board operations. I am changing tool/drills manually on my toy mill but these routines handle the rest of it. Once the pallet co-ordinates are known, and tholefinder.ngc has located a small brass pipe inserted into one corner of the pallet and connected to the G38.2 probing pin of the parport, has located the center of that pipe, then the rest of the code consists of inserting the xy offsets into a g55 system for top operations, and a G56 system for bottom operations. Net result is that while the jig shown in a recent video link is purty, I didn't have to make one since its placement looks like an error source to me. So I measure a pipe glued into the pallet for x/y zeroing and measure the pcb itself for the z zeroing. I can drill to -0.033" thru the FR-4 with a .0315" drill, turn the board over and run the bottom drills to that same depth, getting one hole with virtually no offset errors where the two drill operations meet in the middle of the pcb's thickness. You can get those 3 routines from my web page in the sig, in: Genes-os9-stf/LCNC and use them as templates to write your own, or just edit them to suit your tools. My tholefinder.ngc expects a different tool in the form of a sewing needle threader wire soldered into the end of a 1/8" brass pipe from the hobby shop, and reformed a bit into a sharp pointed profile, bent to center it as well as you can, and is used by running the spindle slowly, about 300 rpms. Then it descends until first contact is detected, backs up to clear that initial contact, then begins the xy search, recording each contact, does the math to find the exact center of each direction, records it in the coordinate system to be used, then backs up to a good height allowing it to be extracted and the first tool mounted. Repeatable accuracy in my toy mill is generally less than a thousandth with this method. One thing I had to do because that contact is fleeting, was to add a ten uf tantalum capacitor to the G38.2 probe detector line, effectively prolonging the contact long enough for LCNC to reliably detect it. The probe in the form of that wire, becomes a perfect cone of wire because its rotating. And it can, if you forget to connect the probe cable to it, be bent and re-straightend again with no damage, not the case if using a rigid cone shape as a probing tool. There are other ways and means to do this of course. This is my form of a solution to the problem. I do make a new pallet for each size of pcb I have made, but so far have not needed to resort to a vacuum hold down as the pcb's have not been big enough for the normal FR-4 warpage to come into play enough to need fixing. The autoz stuff uses the copper of the pcb as contact, and does it so lightly that no mark is left on the copper at the x/y contact point chosen. > I apologize for all the background, but don't know enough to know how > much info you might need, or if you get these "newbie" questions all > the time. > > I do appreciate any time taken to help, There are, I believe, me included, some frustrated teachers here on this list. If what I have is usefull, use it. The warranty is: If you find an error and break it, you get to keep both pieces. ;-) > Scott Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
