Re: [Emc-users] Got LCNC into a corner, painted in you might say

[Gene Heskett]

On Monday 28 May 2018 21:56:00 Jon Elson wrote:

> On 05/28/2018 08:12 PM, Gene Heskett wrote:
> > On Monday 28 May 2018 15:12:46 Jon Elson wrote:
> >> more /proc/meminfo
> >
> > gene@GO704:~$ sudo cat /proc/meminfo
> > [sudo] password for gene:
> > MemTotal:2059220 kB
> > MemFree: 1424600 kB
> > Buffers:   44556 kB
> > Cached:   372816 kB
> > SwapCached:0 kB
> > yadda yadda . . . . .
> >
> > No probs there Jon.
>
> Yup, 1.4 gig free OUGHT to be enough elbow room!
>
> > Now I have another problem, despite all the Z values in the code
> > being quite middle of the range, it won't run claiming Z max is
> > beyond the max limit. But if I (debug,first var in program) its not
> > been inited, so I gave up, put a thumb on thr esc button and and
> > clicked on run, run anyway. But apparently I need to convert the
> > result of the first g38.2 differently, a 1mm up move went about .2mm
> > into the contact target because the equ in metric of the #5223
> > capture is over 5mm below the target contact, so that calculation
> > puts it about 4.5 mm below the contact, obviously wrecking it. And
> > I'm burned out till I've had time to think on it.
>
> Well, I'd check the G54 offsets to the machine coord
> system.  I have a few times had them get
> crazy values in them, which would cause this message
> whenever you loaded a program or hit run.
> I forget the #5xxx parameter they are stored in, but I think
> you can look it up.  You can either try
> zeroing them out or maybe just do another touchoff to set
> the offsets.  And, of course, you need to
> have the machine homed before you load a G-code program, or
> you are likely to get these errors
> all the time.
>
> Jon
>
Thats an interesting comment, Jon. When starting a new invocation of 
lcnc, I don't have a normal load order, but I can make sure its homed 
first thing before loading code if there are some hidden gotchas. I have 
been known to nuke the stored vars files, both of them, but haven't done 
that recently. I do note that the dro seems to have a 0.003mm offset in 
the display when a touch-off 0.0 has been done. Been there for about 
a month now.

Got the grass under control for a day or two, but hit the fence and 
snapped off one of the "horns" that mount the hood over the engine. So I 
now have 2 reasons to go to flatwoods tomorrow. Now if Dee feels good 
enough I can be gone for 4 hours. This hot, humid weather is about to 
put her down for the count.

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



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

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

Re: [Emc-users] Got LCNC into a corner, painted in you might say

[Jon Elson]

On 05/28/2018 08:12 PM, Gene Heskett wrote:

On Monday 28 May 2018 15:12:46 Jon Elson wrote:


more /proc/meminfo


gene@GO704:~$ sudo cat /proc/meminfo
[sudo] password for gene:
MemTotal:2059220 kB
MemFree: 1424600 kB
Buffers:   44556 kB
Cached:   372816 kB
SwapCached:0 kB
yadda yadda . . . . .

No probs there Jon.

Yup, 1.4 gig free OUGHT to be enough elbow room!


Now I have another problem, despite all the Z values in the code being
quite middle of the range, it won't run claiming Z max is beyond the max
limit. But if I (debug,first var in program) its not been inited, so I
gave up, put a thumb on thr esc button and and clicked on run, run
anyway. But apparently I need to convert the result of the first g38.2
differently, a 1mm up move went about .2mm into the contact target
because the equ in metric of the #5223 capture is over 5mm below the
target contact, so that calculation puts it about 4.5 mm below the
contact, obviously wrecking it. And I'm burned out till I've had time to
think on it.
Well, I'd check the G54 offsets to the machine coord 
system.  I have a few times had them get
crazy values in them, which would cause this message 
whenever you loaded a program or hit run.
I forget the #5xxx parameter they are stored in, but I think 
you can look it up.  You can either try
zeroing them out or maybe just do another touchoff to set 
the offsets.  And, of course, you need to
have the machine homed before you load a G-code program, or 
you are likely to get these errors

all the time.

Jon

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

Re: [Emc-users] Got LCNC into a corner, painted in you might say

[Gene Heskett]

On Monday 28 May 2018 15:12:46 Jon Elson wrote:

> On 05/28/2018 03:47 AM, Gene Heskett wrote:
> > On Sunday 27 May 2018 23:54:57 Gene Heskett wrote:
> >
> > I forgot to mention that while all that was being worked out, I had
> > to re-boot again as it had become completely unresponsive.  And
> > still not a clue in the syslog.
>
> After starting LinuxCNC up, but before it croaks, in a
> terminal window, do :
> more /proc/meminfo
>
> Check the line that says MemFree:
>
> If it is a small percentage of total memory, that could be
> the problem.  You really always want to have at least a
> couple hundred MB free.
>
> Jon
>
gene@GO704:~$ sudo cat /proc/meminfo
[sudo] password for gene:
MemTotal:2059220 kB
MemFree: 1424600 kB
Buffers:   44556 kB
Cached:   372816 kB
SwapCached:0 kB
yadda yadda . . . . .

No probs there Jon.

Now I have another problem, despite all the Z values in the code being 
quite middle of the range, it won't run claiming Z max is beyond the max 
limit. But if I (debug,first var in program) its not been inited, so I 
gave up, put a thumb on thr esc button and and clicked on run, run 
anyway. But apparently I need to convert the result of the first g38.2 
differently, a 1mm up move went about .2mm into the contact target 
because the equ in metric of the #5223 capture is over 5mm below the 
target contact, so that calculation puts it about 4.5 mm below the 
contact, obviously wrecking it. And I'm burned out till I've had time to 
think on it.

Me is beginning to think the code scanner is busted, as in with none of 
the programs #<_vars> initialized, how the heck does it determine its 
out of range when its not? Or is that the stock answer when it accesses 
a named var and gets #. for an answer?

This is beginning to resemble fish in the fridge, or company, after 3 
days, it should be thrown out. :) I can drive the machine by hand to do 
all this, at 20x the time wasted.

I'm going to go see if Dee's toy will start, put it in the driveway if it 
will, and see about some of this 18" grass. Way overdue for a john deer 
haircut. Maybe this is a place to use a g92 z0?
 
> --
> 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



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

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

Re: [Emc-users] Got LCNC into a corner, painted in you might say

[Gene Heskett]

On Monday 28 May 2018 15:09:00 Jon Elson wrote:

> On 05/27/2018 10:54 PM, Gene Heskett wrote:
> > 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.
>
> Yes, you certainly don't want to do a harsh reversal.  Even
> with a VFD on my Bridgeport, I have a lowpass filter to make
> the spindle start/stop and reversal more gradual.  I put the
> filter in between
> motion.spindle-speed-out and the DAC that drives the VFD.
> In this particular case, the VFD takes digital direction
> commands and a unipolar speed command, so I use the abs
> component to convert +/- values to all +.
>
> net spindle-speed motion.spindle-speed-out => mult2.1.in0
> setp   mult2.1.in1 0.002457
> net spindle-DAC-cmd mult2.1.out => lowpass.0.in
> net spindle-DAC-filt lowpass.0.out => abs.0.in
> setp lowpass.0.gain 0.005
> net spindle-DAC-abs  abs.0.out => ppmc.0.DAC.03.value
>
> Doing it with the filter means you never have to think about
> doing this in every G code program.
> The first setp has a cal factor for one belt ratio setting
> to spindle speed.  The second setp sets the time of the
> lowpass smoothing.  You can also use limit3 to do this.
>
> Jon

I'm using a limit3 in front of the PID command in. Just enough lag to 
make a 2800+ to 2800- in about 400 milliseconds in high gear. The amp 
(or the motors iron) lets out a faint chirp from the overcurrent kicking 
in at about 16 amps. Go for 1400+ to 1400- in low gear is a bit slower, 
more overshoot at the bottom of a rigid tap, and still gives a very 
short chirp thats easy to miss. And I don't recall ever getting an error 
trip doing that. Both are well above the motor max rpms when it was 
running on the oem 90 volt controller. Its in a keep box someplace in 
the garage. :) I'm guessing that with your control and a supply big 
enough to manhandle that motor, that I am getting close to 2 hp out of 
it at peaks.
>
> --
> 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



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

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

Re: [Emc-users] Got LCNC into a corner, painted in you might say

[Jon Elson]

On 05/28/2018 03:47 AM, Gene Heskett wrote:

On Sunday 27 May 2018 23:54:57 Gene Heskett wrote:

I forgot to mention that while all that was being worked out, I had to
re-boot again as it had become completely unresponsive.  And still not a
clue in the syslog.


After starting LinuxCNC up, but before it croaks, in a 
terminal window, do :

more /proc/meminfo

Check the line that says MemFree:

If it is a small percentage of total memory, that could be 
the problem.  You really always want to have at least a 
couple hundred MB free.


Jon

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

Re: [Emc-users] Got LCNC into a corner, painted in you might say

[Jon Elson]

On 05/27/2018 10:54 PM, Gene Heskett wrote:
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.
Yes, you certainly don't want to do a harsh reversal.  Even 
with a VFD on my Bridgeport, I have a lowpass filter to make 
the spindle start/stop and reversal more gradual.  I put the 
filter in between
motion.spindle-speed-out and the DAC that drives the VFD.  
In this particular case, the VFD takes digital direction 
commands and a unipolar speed command, so I use the abs 
component to convert +/- values to all +.


net spindle-speed motion.spindle-speed-out => mult2.1.in0
setp   mult2.1.in1 0.002457
net spindle-DAC-cmd mult2.1.out => lowpass.0.in
net spindle-DAC-filt lowpass.0.out => abs.0.in
setp lowpass.0.gain 0.005
net spindle-DAC-abs  abs.0.out => ppmc.0.DAC.03.value

Doing it with the filter means you never have to think about 
doing this in every G code program.
The first setp has a cal factor for one belt ratio setting 
to spindle speed.  The second setp sets the time of the 
lowpass smoothing.  You can also use limit3 to do this.


Jon


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

Re: [Emc-users] Got LCNC into a corner, painted in you might say

[Gene Heskett]

On Monday 28 May 2018 06:34:13 Marcus Bowman wrote:

> 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 am saveing #5222 in a fixed named var, and referencing the map move of 
the y with an g10 l2 p y[<_tmpy> + #<_y_reset>] where tmpy is the 
variable but must be made inches before letting the D10 L2 p1 anywhere 
near it.  

Then at the end, restoring #5222 from #<_y_reset>
And if I have to interrupt it, an #5222=#<_y_reset> in the mdi window 
puts it all back to square one.

I'd post the code, but there is one mistake at the end I want to fix, and 
I want to incorporate an automatic tool length measurement, the lack of 
which has caused some oops marks on the hats, and crushed 3 or 4 tools. 
I'd like to get it down to measure the shank OD and find the exact or a 
couple thou bigger drill, install it in the chuck mounted on the table, 
drive it to x0y0 as its touched off to be centered on the drill, bore 
the thru hole with a very gentle start so the bolt hole coming it from 
the side for the keying cap screw doesn't pull it too far off, then once 
its past the center drill cut, crank up the feed and go down till no 
more brass comes out.

Raise it 150 mills, remove the r8, poke the brass slug out of it and 
transfer it to the rotating jig's r8, measure the stub to see how big a 
grub screw to use, find a tap drill for that sized screw, change code to 
switch in the drill routine.

I was cutting a small flat on the sides  so the drill didn't walk, but a 
sharp drill at slow feed for the first mm solves that. Then switch the 
feed rate up to 40mm until the drill is about to start a whole plumb 
thru, pull it back out, turn the table 90 degrees and repeat till its 
270.  Drilling done, change the vars that select drill or tap and tell 
it what the tpmm of this tap is, put the tap in the spindle, use a g38.2 
to measure its length so I can put the tap tip in the hole, then peck 
tap to around 11 or 12mm from that measured tap length. But the tap 
routine has a small retract while the table is turning, and of coarse I 
rezero the table for the first hole by running it back to -10, then fwd 
to zero so all table moves are against the same side of the worm, its 
factory equiped with about 3 degrees of backlash. It can be adjusted but 
the bull gear has 2 or 3 thou of eccentricity, so you leave it loose 
enough the motor can drive it. Never, ever, buy a table made in India. 
POS.

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

Which it needs from time to time.

Another item I'll mention, I've bought a couple more sets of metric er-20 
collets. And they are slit in an 8 slot pattern.  And they can, by 
putting the taps stub corners in the slots, absolutely drive a tap with 
no slippage. They are only grabbing it by the square, so there is room 
for some tip eccentricity, but its 90% gone after the first hole is 
tapped. Being able to do that is pure serendipity. These 2 kits came 
with a much simplified TTS holder without the depth stop ring, and a 
frosted finish on the longer shank, AND THEY DON"T SPIN IN THE R8!.

I'd assume its something to do with the frosted shank.

> Marcus

I appreciate the input Marcus, as there is often a 

Re: [Emc-users] Got LCNC into a corner, painted in you might say

[Marcus Bowman]

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.5000] 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 

Re: [Emc-users] Got LCNC into a corner, painted in you might say

[Gene Heskett]

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.5000] 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 

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

Re: [Emc-users] Got LCNC into a corner, painted in you might say

[Gene Heskett]

On Sunday 27 May 2018 23:54:57 Gene Heskett wrote:

I forgot to mention that while all that was being worked out, I had to 
re-boot again as it had become completely unresponsive.  And still not a 
clue in the syslog.

I'm going to glue a piece of pcb to the top of this, and start using a 
g38.2 to determine both drill bit length and tap length, to get rid of 
editing so many things when the drill and tap are changed due to the 
size and tpmm of the grub screw.

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

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

Re: [Emc-users] Got LCNC into a corner, painted in you might say

[Gene Heskett]

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.5000] 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 #5522 as it 
wraps up the job.

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 

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

Re: [Emc-users] Got LCNC into a corner, painted in you might say

[Gene Heskett]

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.5000] 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


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

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

[Emc-users] Got LCNC into a corner, painted in you might say

[Gene Heskett]

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.5000] mm mode!

And end the program with either a saved initial #5222, or another g53 etc 
etc?

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

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