Gene, Knowing you have more experience of tricky tasks than I have, and seeing not much response to your question, I offer the following observations:
I have forgotten the exact reason you are dealing, in places, with the locations of the co-ordinate systems (#5222 etc), but my inclination is always to avoid this, where possible, by using G92, or G10 L20 or similar. I try to use named variables for any parameters which will have to change when I next run or edit the program. I use a lot of subroutines and pre-prepared program fragments, so my work cycle often looks like: load a pre-prepared program or subroutine; edit it to change speeds, sizes or whatever; then save. Reload the program and run it. With that kind of cycle, I need everything that could possibly change to be in a block of parameters at the start. I do this even with programs generated by post-processors (like the Vectric programs). I edit the program to define speeds using parameters, for example, so that I can experiment quickly with different materials. I make the guts of whole pograms into subroutines, etc. It doesn't take long to do, but frequently repays the effort. I often use subroutines which begin with G92 X0 Y0; do something centred on the (temporary) X0 Y0; then end with G92.1 I also keep track of X and Y throughout, by using named parameters and use parameters as counters for currentDepth, currentX, etc. That way, I seldom know what the actual co-ordinate value is, but mostly don't need to. I can't imagine rewriting the P1 map. I have done it, but can't imagine why it would be necessary in reality. I'm being a bit provocative, here, but hope the above might help stimulate a line of thought which might help. Apologies if it seems like asking you to suck eggs. It's not meant that way. It is meant to push your thinking sideways. Marcus On 28 May 2018, at 10:36, Gene Heskett wrote: > On Sunday 27 May 2018 23:54:57 Gene Heskett wrote: > >> On Sunday 27 May 2018 19:37:04 Gene Heskett wrote: >>> On Sunday 27 May 2018 17:16:50 Gene Heskett wrote: >>>> Giveing up on the jig brace, I decided to make a wooden one as it >>>> doesn't have to last till the rapture. I laid out a circle, then >>>> contemplated how to draw this circle such that its position was >>>> offset half a mm for each time that it was drawn, until I got the >>>> proper depth of cut. >>>> >>>> Without doing the arcgenm18 routine in 50 pieces of code, I tried >>>> to make a sub routine out of it by manipulating the y offset, but >>>> whilew it moved, it didn't want to do it in a straight line up the >>>> y axis, but wandered off the the right and got smaller. I moved >>>> vars around, but that failed similarly. So I got this wild hair to >>>> move the co-ordinate, then I could re-use the same subroutine >>>> until I'd hit the offset I wanted. But I stopped it as it was >>>> starting the 2nd semi-circle, which means the y coordinate had >>>> been moved what I thought was half a mm. >>>> >>>> But on further study of the docs, neither G10 L2 or G10 L20 take >>>> anything but absolute values. >>>> >>>> So this means I have to get the current y coordinate from the >>>> memory for P1's map, add my small var, and rewrite y with a G10 L2 >>>> y new value. >>>> >>>> Except I moved it 40mm with the first command, and now it says the >>>> first mpve will exceed the y limits. Then I noticed the - sign was >>>> missing too for y. >>>> >>>> Is this a place where I have to g53 g0 x0 y0 z0 >>>> and then rewrite the p1 map to all balls at that location? A >>>> shutdown, restart and rehome has not fixed it. Then reset y for >>>> each pass with G10 L2 P1 y[#5222 + 0.50000000] mm mode! >>>> >>>> And end the program with either a saved initial #5222, or another >>>> g53 etc etc? >>> >>> And I just found out why the corrections applied are so gross as to >>> disable lcnc. The value stored is in #5222(G54Y) is in inches, >>> despite its being in G21 mode. So I need to divide my var for >>> increments by 25.4 to make it inches. Sigh... Sure as hell there >>> ought to be a way to walk a D pattern in a while loop without >>> unrolling it to a 50kb file. >>> >>> Funny part is it looks great in the back plot. >>> >>> Thanks >> >> To those who wondered, its working and the poplar block is carved, and >> while I haven't carved brass in it yet, its quite a bit more rigid. >> I'm out of clamps so the tailstock is on a ladder step nearby, I bent >> up a 6" piece of 1/8" alu panel that gently holds the slug into a r8 >> driven by the table, so I think its going to work better than anything >> else I've tried, lots better. I wound up sampling #5222 into a global >> var and referencing that, the didling it to offset the tool a wee bit >> for each pass thru the while loop, gradually digging the U channel >> deeper. And restoring the Y offset by putting the global var back into >> #5222 as it wraps up the job. > typu correction above. >> To Jon; I had to reset the pwm-servo several times, it was tripping >> off at the m5, which is completely off while the motor was cranking >> the spindle at 1500. So thinking about the motors emf, I put an s100, >> g4p.5 in front of the m5. Hasn't tripped again. Its probably down to >> 100 revs in .1 seconds, maybe less. As a 4 quadrant controller, when >> its active, the motor responds _now_. I once measured the turnaround >> time at about 400 milliseconds from 2800 to -2800, or back, >> accompanied of course by a short chirp of the iron from the 16 amp >> current limit I set in deference to the wire gage in the PSU >> transformers. And that signal from motion has a limit3 in series with >> it to slow that rail to rail signal down so the servo's current >> limiter doesn't have to do it all. >> >> You make good stuff Jon. For anyone else similarly abusing Jon's >> pwm-servo, by running a 1 HP spindle motor with it, from a 127 volt >> psu, if its tripping the reset and turning on the led at a stop, put >> an s100 in front of the m5, along with enough time delay for the motor >> to be slowed. Should be the end of the problem. > > > > -- > 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> > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
