[Emc-users] Just took the first flexgear off the printer

2020-07-21 Thread Gene Heskett
Greetings all;

And had a hell of a time removing the internal supports, which probably 
out-weigh the gear, digging it out about 1/4" at a time until I was able 
to actually get a grip on the edge, at which time the last half of it 
popped right out in one piece, clean as a whistle.  But it seems like 
there ought to be a way to pop it all out in one piece as opposed to a 
couple hours work with a miniature back hoe in the form of the e. tech's 
ever present 5" flush cutters. Looks good, meshes well and walks around 
the ring gear like it should. 2nd one building, be done around a late 
dinner time tonight as its an 18+ hour job. Don't know if theres enough 
PLA on that spool for 3 of them. With all the support structure it uses 
a lot of PLA. Cura estimates it but I've forgotten now.

But is there a support removal tool that isn't radioactive?

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread John Dammeyer
So my question still stands.  Now we have 1703 In/Sec^2.
 
MAX_VELOCITY = 2.5
MAX_ACCELERATION = 7.5
 
So could I use that value?  What I'm trying to do with this tool is to take out 
some of the guesswork or the accident.tal divide instead of multiply.
 

 
> -Original Message-
> From: Bruce Layne [mailto:linux...@thinkingdevices.com]
> Sent: July-21-20 7:57 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc
> 
> 
> 
> On 7/21/20 10:09 PM, John Dammeyer wrote:
> > If Gravity is 32 ft/sec^2 then it's also 2.7 in/sec^2.
> 
> Only if there are 12 feet in an inch, but there are 12 inches in a foot,
> so one g is 384 in/sec^2.
> 
> 
> 
> 
> ___
> Emc-users mailing list
>   Emc-users@lists.sourceforge.net
>   
> https://lists.sourceforge.net/lists/listinfo/emc-users
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread John Dammeyer
Crap. Went the wrong way... 

> -Original Message-
> From: Bruce Layne [mailto:linux...@thinkingdevices.com]
> Sent: July-21-20 7:57 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc
> 
> 
> 
> On 7/21/20 10:09 PM, John Dammeyer wrote:
> > If Gravity is 32 ft/sec^2 then it's also 2.7 in/sec^2.
> 
> Only if there are 12 feet in an inch, but there are 12 inches in a foot,
> so one g is 384 in/sec^2.
> 
> 
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread Bruce Layne



On 7/21/20 10:09 PM, John Dammeyer wrote:
> If Gravity is 32 ft/sec^2 then it's also 2.7 in/sec^2.

Only if there are 12 feet in an inch, but there are 12 inches in a foot,
so one g is 384 in/sec^2.




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread Tom Smart
I started pulling stuff apart on the bostomatic today found out some 
information on the encoders and spindles.

The encoder is a encoder products company 755a it is 5000 cycles per 
revolution. Quadrature A channel with index. Line driver output, max 
frequency 200 kHz <= 3000 cycles per revolution.

There are 2 spindles on the machine.
Main spindle is uaaska-04D looks like its 1500/8000 rpm rated
Secondary spindle is the precise corporation sc82.
Spindle is 1-4 rpm rated.

There are linear rails on all 3 axis. A 15 position tool changer for the main 
spindle.

I think the machine should be really nice if i can get it running.

Also if anyone has ever heard of or knows Barry Tognazzi or Gary Wells both 
from Massachusetts I'm trying to get in touch with them. They were part of a 
company that specifically retrofit Bostomatic machines that was dissolved in 
2018. I hope to get some better info if i can get in touch with either of them.

Any suggestions on best way forward is appreciated. Trying to retrofit the 
machine on a fairly tight budget.

Thomas


From: andy pugh 
Sent: Monday, July 20, 2020 2:49 AM
To: Enhanced Machine Controller (EMC) 
Subject: Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

On Mon, 20 Jul 2020 at 02:44, Tom Smart  wrote:

> The motor is this glentek GM4040-41 180vdc, 9.1A. I decoded the serial number 
> it has no brake, no tachometer, a special encoder, no resolver.

Just how special is the encoder? Everything else sounds like a simple
retrofit, DC servos are relatively easy.
Do you have the power supply? If so, what is the actual output voltage?

The Pico servo amps are close:
http://www.pico-systems.com/pwmservo.html but may come up a little
short if the actual power supply voltage is 180V.
The 7i29 from Mesa
http://store.mesanet.com/index.php?route=product/product=83_90_id=141
also comes in a little low on voltage. (Note that you can run two
motors from each 7i29)
If you don't have the DC power supply then perhaps you could look at
AC input drives, https://www.a-m-c.com/product/ab30a200ac/ might be an
option. But AMC make so many drives it's probably best to actually
talk to them.

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread John Dammeyer
Hi Jon,
You're right.  That's fixed now.  As is the Peak Torque value too.
 
My INI file for Y axis which uses a KL34-180-90 DC servo (226 oz-in,  3000 RPM) 
has to move the X table and Y plus rotary section in between which I'd guess at 
400 lbs so...
http://www.autoartisans.com/milton.htm   The same as the Grizzly G3616.  The X 
pivots for Horizontal Milling and helical gear cutting.  Except I don't have 
the horizontal mill feature.  That was the G3617.
 
MAX_VELOCITY = 2.5
MAX_ACCELERATION = 7.5
 
If Gravity is 32 ft/sec^2 then it's also 2.7 in/sec^2.  So if we multiply 
the G value by that now taking into account the Reduction ratio I get 11.83 
in/sec^2
 
Does that mean the MAX_ACCELERATION value can actually be set to 11.83? 
 
And since the Peak Force is 4x that assuming I can draw 40A then the backlash 
value (2x MAX_ACCELERATION)
STEPGEN_MAXACCEL = 15.0
could also be larger.
 
A reasonable assumption is that the power supply will be at least capable of 
suppling the continuous motor torque value.  Otherwise we'd have to add 
Continuous Current, Power Supply Current and Peak Current values and then scale 
the Cont. Torque by that value.
 
It's a bit harder to calculate peak current.  My linear toroid based supply is 
up in the 26A range well above the 7.8A continuous.
 
What else would you like on this form?  Have I missed anything else?
 

 
Cheers,
John Dammeyer
 
> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> Sent: July-21-20 6:19 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc
> 
> On 07/21/2020 06:53 PM, John Dammeyer wrote:
> > Jon,
> > Here's a screen shot (assuming it makes it through).  I used your 100 oz-in 
> > motor and 0.2" pitch screw.  I set the RPM to 3000 but
> with a 3:1 reduction.  Not sure If it would be better to just add two boxes 
> for the reduction so that 0.25 is really 4:1 in two boxes.
> >
> You had a 4:1 reduction, but that doesn't seem to show in
> the linear force number.
> 
> Jon
> 
> 
> ___
> Emc-users mailing list
>   Emc-users@lists.sourceforge.net
>   
> https://lists.sourceforge.net/lists/listinfo/emc-users
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread Jon Elson

On 07/21/2020 06:53 PM, John Dammeyer wrote:

Jon,
Here's a screen shot (assuming it makes it through).  I used your 100 oz-in motor 
and 0.2" pitch screw.  I set the RPM to 3000 but with a 3:1 reduction.  Not 
sure If it would be better to just add two boxes for the reduction so that 0.25 is 
really 4:1 in two boxes.
  
You had a 4:1 reduction, but that doesn't seem to show in 
the linear force number.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Gene Heskett
On Tuesday 21 July 2020 18:40:35 Scott Harwell via Emc-users wrote:

>  Just got my new Control Engineering in the mail and saw this."Top 5
> VFD parameter changes explained"
>
>
>
>
>
>
>
>
>
>
>
> Top 5 VFD parameter changes explained
>
> Chris Vavra
>
> Learning Objectives Setting five parameters can take care of most VFD
> programming. Consider VFD control met...
>
>
>
>
>
>
>
> "www.controleng.com/articles/top-5-vfd-parameter-changes-explained/"
> It may help.
> Scott
>
> On Tuesday, July 21, 2020, 12:17:05 PM CDT, Matthew Herd
>  wrote:
>
>  Hi Rob,
>
> Thanks for the insights.  I suspected something along these lines,
> even if I might have other problems with noise.  I can confirm, the
> spindle stops way too slowly and definitely more than 10 revolutions
> pass before stopping.  Long story short, I can’t readily run the
> machine in back gear and the slowest I can go at 60Hz is 560 RPM
> without backgear.

But if you get the right control signal setup, you can drive that vfd at 
5 hertz! I am doing it. And I can do it for an hour at a time without 
heating the motor so hot I can't touch it. All you need is to find the 
register that sets the motors FLA, and transfer the FLA from the motors 
nameplate to that register. That way you are assured that the motor 
won't be quickly overheated and burned up at even very low speeds.  You 
may also have to locate the register that sets the minimum run speed as 
its likely set to faster than that, possibly even turning itself off at 
30 hertz or more.  There are registers also to control how fast it 
accels or decels.  The biggest problem is in translating the Chinglish 
in the booklets into your local dialect that you understand.

One thing I've found is that most vfd's are directly controllable by a
12 volt swing from a pwm generator, running the pwm at 10 kilohertz.  The 
vfd's response averages that into an analog signal equivalent, so a 10% 
duty cycle pwm will run the vfd at say 12 hertz.  And I've some extra 
stuff in my .hal to measure the overshoot so I'll demo, live, right now. 
From 200 rpms, entering an m4 to reverse it, gets me a display of 1.0333 
revs that it overshot, or just a small hair over 1 full turn from 200 
revs. This is an E400 drive, running in 1st gear, and it has an 8" 4 jaw 
chuck that weighs just short of 40 lbs mounted. This particular vfd is 
controlled by a Mesa SpinX1 which has its own analog 0-10 volt output.

Your B-Port doesn't have near that amount of flywheel, and it ought to 
beat that time while spinning at 400 rpms.
 
> I’ll play a bit more with how quickly I can stop 
> the spindle with a braking resistor or I’ll attempt to get the HAL
> file to engage the mechanical brake to help transition faster. 
> Nonetheless, 10 revolutions seems fairly ambitious based on my best
> guess of how long it might take to stop the spindle even with a
> braking resistor.    That’s about 1 second, but should be achievable. 
> Currently the VFD is configured based on the fastest stop time for max
> RPM, and there doesn’t seem to be a way to decrease stop time for
> different inertial loads (i.e. lower gear ratios/spindle speeds). 
> However, I understand that the braking resistor should decrease stop
> time by approximately an order of magnitude based on some reading I
> did yesterday.
>
> Thanks!
> Matt
>
> > On Jul 21, 2020, at 1:00 PM, Robert Ellenberg 
> > wrote:
> >
> > Based on the videos and your descriptions of the behavior, you may
> > be running into a TP issue I've seen (in simulation) with very
> > sluggish spindles or very high spindle speeds. Here's what I think
> > is going on:
> >
> >  1. The rigid tapping cycle allows a hard-coded 10 revolutions
> > 
> >  >56> of overtravel beyond the nominal bottom of the hole when
> > reversing direction.
> >  2. The spindle starts reversing direction only after the Z axis has
> >  reached the bottom, so the spindle has to be able to stop in 10
> > revolutions to stay within the budgeted overtravel.
> >  3. If the TP hits the end of the overtravel, it prematurely
> > declares the motion to be complete and stops following the spindle
> > motion.
> >
> > Do you still see this behavior if you run the spindle slower? Your
> > spindle seems to take a long time to reverse, so at high speeds you
> > may be hitting this limit.
> >
> > Best,
> > Rob
> >  >56>
> >
> > On Tue, Jul 21, 2020 at 11:18 AM Matthew Herd  
wrote:
> >> Ahh, so I do use limit switches and a homing routine.  So it’s
> >> homing to the same position (plus or minus a few thousandths or
> >> so).
> >>
> >>> On Jul 21, 2020, at 11:07 AM, Jon Elson 
> >>> wrote:
> >>>
> >>> On 07/21/2020 04:20 AM, andy pugh wrote:
>  On Tue, 21 Jul 2020 at 10:18, andy pugh  
wrote:
> > We are not looking for noise, we are looking for spurious
> > encoder
> >>
> >> count resets.
> >>
> 

Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread John Dammeyer
Jon,
Here's a screen shot (assuming it makes it through).  I used your 100 oz-in 
motor and 0.2" pitch screw.  I set the RPM to 3000 but with a 3:1 reduction.  
Not sure If it would be better to just add two boxes for the reduction so that 
0.25 is really 4:1 in two boxes.
 
Using your table weight of 200 lbs and the resulting Continuous Linear force of 
almost 200 I get approximately 1 G as expected.
 
Now the ideal would be that the last box there would tell us what acceleration 
value we want to enter into the INI file.
 
So would you multiply the 0.98G by 32 Ft/Sec/Sec to get 31.36 or turn it into 
inches 376 Inch/sec/sec but since our table speed is in inches per minute 
divide by 60 or by 3600?  For inch/min/min?
 

 
Oh and of course the checkmark will convert the numbers and units indication to 
N.m etc.  Doesn't yet but that's just a bit of math and text output.
 
John Dammeyer
 
 
> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> Sent: July-21-20 1:52 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc
> 
> On 07/21/2020 02:54 PM, John Dammeyer wrote:
> > Hi Jon,
> > How did you come up with the constant 0.0318?
> Long story.  There's complicated formula to compute it from
> the helix angle of the screw.
> Too much fiddling around.  So, if you had a drum with a
> string wrapped around it that advanced the
> axis as much as the leadscrew, it should be equivalent
> (ignoring friction and diameter of the string).  So, how big
> would such a drum be?  The circumference should be equal to
> the pitch of the screw, in this case 0.2".  So, what is the
> radius of a circle with a 0.2" circumference?  2 Pi R =
> Circumf. so
> R = circumf./2 Pi   so, 0.2 / (2 Pi) = 0.0318
> 
> Now, if you apply 10 in-Lb torque to a 5 TPI leadscrew, you
> get 10 / 0.0318 = 314 pounds force.
> 
> 
> > " So, that 100 oz-in motor (0.52 lb-ft) would
> > produce 0.52/0.0318 = 16.35 lbs of linear force (neglecting
> > friction)."
> And, this was wrong due to a inch/foot mixup!
> 
> 0.52 lb-ft is 6.24 in-Lb, and the linear force would be 196 Lbs.
> > And how did you work out the 5G?
> >
> > "So, if your machine has a 200 Lb table, and the leadscrew
> > were to produce 1000 Lbs linear force,
> > it would accelerate at 5 G?
> >
> If you dropped the table on your toe (don't do this at home,
> kids!) it would accelerate at 1 G.
> if you push on the table with a force equal to 5 times it's
> weight, that will accelerate at 5 G.
> 
> Jon
> 
> 
> ___
> Emc-users mailing list
>   Emc-users@lists.sourceforge.net
>   
> https://lists.sourceforge.net/lists/listinfo/emc-users
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Scott Harwell via Emc-users
 Just got my new Control Engineering in the mail and saw this."Top 5 VFD 
parameter changes explained"

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Top 5 VFD parameter changes explained

Chris Vavra

Learning Objectives Setting five parameters can take care of most VFD 
programming. Consider VFD control met...
 |

 |

 |


"www.controleng.com/articles/top-5-vfd-parameter-changes-explained/"
It may help.
Scott

On Tuesday, July 21, 2020, 12:17:05 PM CDT, Matthew Herd 
 wrote:  
 
 Hi Rob,

Thanks for the insights.  I suspected something along these lines, even if I 
might have other problems with noise.  I can confirm, the spindle stops way too 
slowly and definitely more than 10 revolutions pass before stopping.  Long 
story short, I can’t readily run the machine in back gear and the slowest I can 
go at 60Hz is 560 RPM without backgear.  I’ll play a bit more with how quickly 
I can stop the spindle with a braking resistor or I’ll attempt to get the HAL 
file to engage the mechanical brake to help transition faster.  Nonetheless, 10 
revolutions seems fairly ambitious based on my best guess of how long it might 
take to stop the spindle even with a braking resistor.    That’s about 1 
second, but should be achievable.  Currently the VFD is configured based on the 
fastest stop time for max RPM, and there doesn’t seem to be a way to decrease 
stop time for different inertial loads (i.e. lower gear ratios/spindle speeds). 
 However, I understand that the braking resistor should decrease stop time by 
approximately an order of magnitude based on some reading I did yesterday.

Thanks!
Matt

> On Jul 21, 2020, at 1:00 PM, Robert Ellenberg  wrote:
> 
> Based on the videos and your descriptions of the behavior, you may be
> running into a TP issue I've seen (in simulation) with very sluggish
> spindles or very high spindle speeds. Here's what I think is going on:
> 
>  1. The rigid tapping cycle allows a hard-coded 10 revolutions
>  
>  of overtravel beyond the nominal bottom of the hole when reversing
>  direction.
>  2. The spindle starts reversing direction only after the Z axis has
>  reached the bottom, so the spindle has to be able to stop in 10 revolutions
>  to stay within the budgeted overtravel.
>  3. If the TP hits the end of the overtravel, it prematurely declares the
>  motion to be complete and stops following the spindle motion.
> 
> Do you still see this behavior if you run the spindle slower? Your spindle
> seems to take a long time to reverse, so at high speeds you may be hitting
> this limit.
> 
> Best,
> Rob
> 
> 
> On Tue, Jul 21, 2020 at 11:18 AM Matthew Herd  wrote:
> 
>> Ahh, so I do use limit switches and a homing routine.  So it’s homing to
>> the same position (plus or minus a few thousandths or so).
>> 
>>> On Jul 21, 2020, at 11:07 AM, Jon Elson  wrote:
>>> 
>>> On 07/21/2020 04:20 AM, andy pugh wrote:
 On Tue, 21 Jul 2020 at 10:18, andy pugh  wrote:
 
> We are not looking for noise, we are looking for spurious encoder
>> count resets.
 But, thinking further, even if there _is_ noise on the index line, the
 encoder counter should ignore it. It ignores all the _real_ indexes
 unless index-enable is set true in HAL.
 
>>> Yes, the only thing I can think of is he's hitting his soft limits. Over
>> time, starting and stopping LinuxCNC,
>>> without homing, the machine limits will drift.  If you have rational
>> limits in the .ini file, you will eventually reach the end of them and have
>> really strange behavior.  it can be fixed by homing in a safe position,
>>> but best to put in home switches and actually home the machine to a
>> repeatable position every time.
>>> 
>>> Jon
>>> 
>>> 
>>> ___
>>> Emc-users mailing list
>>> Emc-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> 
>> 
>> 
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
  
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread andy pugh
On Tue, 21 Jul 2020 at 21:54, Jon Elson  wrote:

> > How did you come up with the constant 0.0318?
> Long story.  There's complicated formula to compute it from
> the helix angle of the screw.

Or a very simple formula based on a unit circle and the lead, simply
comparing two distances.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread John Dammeyer
Thanks.
I'll whip up a quick app for this.  Nothing special.  Could be done in as 
spreadsheet but where's the fun in that?
John


> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> Sent: July-21-20 1:52 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc
> 
> On 07/21/2020 02:54 PM, John Dammeyer wrote:
> > Hi Jon,
> > How did you come up with the constant 0.0318?
> Long story.  There's complicated formula to compute it from
> the helix angle of the screw.
> Too much fiddling around.  So, if you had a drum with a
> string wrapped around it that advanced the
> axis as much as the leadscrew, it should be equivalent
> (ignoring friction and diameter of the string).  So, how big
> would such a drum be?  The circumference should be equal to
> the pitch of the screw, in this case 0.2".  So, what is the
> radius of a circle with a 0.2" circumference?  2 Pi R =
> Circumf. so
> R = circumf./2 Pi   so, 0.2 / (2 Pi) = 0.0318
> 
> Now, if you apply 10 in-Lb torque to a 5 TPI leadscrew, you
> get 10 / 0.0318 = 314 pounds force.
> 
> 
> > " So, that 100 oz-in motor (0.52 lb-ft) would
> > produce 0.52/0.0318 = 16.35 lbs of linear force (neglecting
> > friction)."
> And, this was wrong due to a inch/foot mixup!
> 
> 0.52 lb-ft is 6.24 in-Lb, and the linear force would be 196 Lbs.
> > And how did you work out the 5G?
> >
> > "So, if your machine has a 200 Lb table, and the leadscrew
> > were to produce 1000 Lbs linear force,
> > it would accelerate at 5 G?
> >
> If you dropped the table on your toe (don't do this at home,
> kids!) it would accelerate at 1 G.
> if you push on the table with a force equal to 5 times it's
> weight, that will accelerate at 5 G.
> 
> Jon
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread Jon Elson

On 07/21/2020 02:54 PM, John Dammeyer wrote:

Hi Jon,
How did you come up with the constant 0.0318?
Long story.  There's complicated formula to compute it from 
the helix angle of the screw.
Too much fiddling around.  So, if you had a drum with a 
string wrapped around it that advanced the
axis as much as the leadscrew, it should be equivalent 
(ignoring friction and diameter of the string).  So, how big 
would such a drum be?  The circumference should be equal to 
the pitch of the screw, in this case 0.2".  So, what is the 
radius of a circle with a 0.2" circumference?  2 Pi R = 
Circumf. so

R = circumf./2 Pi   so, 0.2 / (2 Pi) = 0.0318

Now, if you apply 10 in-Lb torque to a 5 TPI leadscrew, you 
get 10 / 0.0318 = 314 pounds force.




" So, that 100 oz-in motor (0.52 lb-ft) would
produce 0.52/0.0318 = 16.35 lbs of linear force (neglecting
friction)."

And, this was wrong due to a inch/foot mixup!

0.52 lb-ft is 6.24 in-Lb, and the linear force would be 196 Lbs.

And how did you work out the 5G?

"So, if your machine has a 200 Lb table, and the leadscrew
were to produce 1000 Lbs linear force,
it would accelerate at 5 G?

If you dropped the table on your toe (don't do this at home, 
kids!) it would accelerate at 1 G.
if you push on the table with a force equal to 5 times it's 
weight, that will accelerate at 5 G.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread John Dammeyer
Hi Jon,
How did you come up with the constant 0.0318?

" So, that 100 oz-in motor (0.52 lb-ft) would 
produce 0.52/0.0318 = 16.35 lbs of linear force (neglecting 
friction)."

And how did you work out the 5G?

"So, if your machine has a 200 Lb table, and the leadscrew 
were to produce 1000 Lbs linear force,
it would accelerate at 5 G?

It would be handy to have a spreadsheet where once can key in motor in oz-in or 
Nm, max RPM, reduction ratio, and table weight.  Maybe even in addition to 
screw pitch and an acme or ball tweak factor.

Heck I'll whip up a Lazarus Free Pascal program with all the entry fields for 
this.  It would run on Linux, PCs, MACs,  Beagles and Pi computers.  I just 
need a bit more of the math/constants behind it.

John Dammeyer


> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> Sent: July-21-20 7:31 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc
> 
> On 07/20/2020 11:49 PM, Tom Smart wrote:
> > So my 3500 rpm rated motor at 180vdc would be 2916 rpm at 150 vdc and 2333 
> > rpm at 120vdc?
> Yes, exactly.
> > If my ballscrew is 5tpi then at rated voltage i would get 700 ipm at 150vdc 
> > 583 ipm and at 120vdc 466ipm feeds?
> Yes.
> > If i keep the amps at the rating of 9.1 I should keep my 31.3 IN-LBS or 2.6 
> > FT-LBS?
> >
> > So 2.6 / .0813 would be 81.76 lbs of linear force?
> That denominator s .0318 but your result is correct.
> > So if my table weighs 200lbs my acceleration would be .41 G?
> >
> > I'm wondering if I've done a calculation wrong or is this a good setup?
> >
> Well, 81 Lbs sounds pretty weak for a milling machine.  Is
> the motor directly driving the leadscrew or is there a belt
> reduction?  My Bridgeport setup is kind of anemic, but it
> has a 2.5:1 belt reduction on the motor.  That gets me to 23
> In-Lb at the leadscrew, for 700 Lbs of linear force.
> 
> Now, the 9.1 A rating of the motor, is that a continuous
> (stall) rating or a peak rating?  If that is stall, then the
> motor can handle more current during acceleration peaks, at
> least twice, possibly 4 X.
> That will help.
> 
> Jon
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] mailing list for ender 3 pro owners?

2020-07-21 Thread Gene Heskett
On Tuesday 21 July 2020 13:36:53 Bruce Layne wrote:

> On 7/17/20 6:03 PM, Gene Heskett wrote:
> > ...added 5.00 to the extruder feed, and gave it another go.  After
> > 4 restarts it laid down the first two layers of a raft, with no
> > missing lines and only one little bump, all while running at 20 lb
> > paper clearance, so the lines it was laying down were about 50%
> > coverage, but no missing gaps because it ran out of PLA.
>
> Rather than adjusting the extrusion rate to get a good first layer at
> the nozzle height you used to level the bed, I'd first calibrate the
> nozzle to extrude the correct amount of material.  Andy described how
> to do this earlier in this painful saga, where you mark the filament
> 120mm back, have it extrude 100mm of filament, measure how much
> filament it actually extruded, and then adjust the extrusion
> multiplier until it's extruding 100mm.

I have done that, and my currant setting is maybe 2% more. And ut 1o hour 
and 23mm up on a wave gear for a harmonic drive, and except for using 
more PLA in the central support for what will be the bottom of the 
coffee cup, its rendering beautifully. I was not aware that I could fine 
tune the flow. At std flow, 75-bed and 235 nozzle, adhesion is a bit 
strong. 2 layers up it switches to 60/220 and I may edit the second copy 
down to to 70/230, droppiing to 60/215.

> Once the extrusion rate is 
> properly set, leave it alone.  Fix the first layer adhesion by
> tweaking the nozzle height using the bed leveling nuts, or by
> adjusting the first layer height and/or first layer extrusion
> multiplier in Cura.
>
> Your 3D printing experience has been needlessly difficult.  Maybe the
> default settings were grossly incorrect when you received your 3D
> printer but that's very rare these days.  Most people don't mess with
> the basic settings.  Most of us get a new machine, level the bed and
> start printing.  There is generally a little bit of a learning curve
> getting good first layer adhesion on your first 3D printer, but none
> of the ongoing problems you've experienced.  That sounds like hobby 3D
> printing ten years ago when the burden was on the hobby builder. 
> These days, 3D printers are built in factories and are almost consumer
> appliances with no need to adjust basic settings.  It's as if you
> bought a new car and it idled rough so you are building your own
> engine computer to fix it.
>
> I'm cheap, but I've learned that there is value at every level and
> it's usually the case that saving that last 10% is a negative value
> proposition.  I buy low cost items but usually not the lowest priced
> item, particularly on something as complex as a 3D printer.  I don't
> want to spend $220 on a 3D printer that was built in small numbers by
> people with little experience with 3D printers, who may not have
> configured it properly, used the very lowest quality components with
> no warranty or customer support, when I have a much better experience
> by spending $30 more.  If I need to spend $150 and three weeks of my
> time fixing problems, saving $30 was a bad deal.
>
> I just finished 3D printing 4kg of ABS parts for a small production
> run for a friend.  I did have two clogged nozzles but those are now an
> easy three minute one dollar repair.  I put another 3D printer into
> service in my small 3D print farm and the set screws backed out in an
> X axis idler pulley so I had to fix that.  I'll Loctite and properly
> torque the set screws on all of my 3D printers to avoid that failure
> in the future.  Otherwise, that 430 hours of printing those 132 parts
> was pretty much a matter of picking a part off the glass plate (they
> self release when cool in 15 minutes), adding a tiny amount of glue
> juice, distributing it on the glass plate with a nylon bristle brush
> and selecting Print Another Copy.  Once your 3D printer is adjusted
> properly, hardware and software, it should be reliable.
>
> I'm getting better with FreeCAD and I always preview the job using
> Simplify3D after slicing it.  Cura allows previewing too, so you can
> ensure that it's printing what you want, the way you want it to print.
>
> I hope your 3D printing becomes a lot easier and a lot more fun soon,
> Gene.  It shouldn't be this difficult.  I wish you could start fresh
> with a known good configuration.

Its getting that way. I'm doing way more hours of printing than I am 
fiddling and I'm not adjusting anything until I have tried the bearings 
for fit in their pockets.

> The only time I use a raft is when I'm printing a large number of very
> small parts with little contact area on the build platform, where any
> part that failed would ruin the entire print job.  Glue on glass makes
> a reliable first layer adhesion with ABS, PLA or TPU.
>
>
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There 

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Scott Harwell via Emc-users
 Matt,
Are you seeing overvoltage faults on the VFD? If you are not decrease the decel 
time until you see a fault and then bump it back up until you are fault free. I 
don't know what the breaking resistors will do if you are not seeing a fault 
now, they are used to drop the B+ from the regen during the stop. Is the tap 
sequence M3, M5, M4 or M3, M4. The M3, M4 sequence is normally much better for 
response an far less drift. What model number drive do you have? I have done a 
lot of work over the years with Yaskawa drives the Hitachi drives should be 
close. Lower Hz on the motor will normally help you more, I'm afraid that 
backgear will compound your ramp time. 

Scott
On Tuesday, July 21, 2020, 1:03:06 PM CDT, Matthew Herd 
 wrote:  
 
 On a related note, I’ve noticed that the G-Code reference for G33 and G33.1 
refers you to the integrators manual, but there’s little documentation on 
spindle synchronized motion.  I’d be willing to add a section based on what I 
learn from this experience.  It might be helpful to make sure there’s more of a 
checklist and some of these cautions and observations in there.

> On Jul 21, 2020, at 1:56 PM, Jon Elson  wrote:
> 
> On 07/21/2020 12:09 PM, andy pugh wrote:
>> On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg  wrote:
>> 
>>>    1. The rigid tapping cycle allows a hard-coded 10 revolutions
>>>    
>>>    of overtravel beyond the nominal bottom of the hole when reversing
>>>    direction.
>> That feels like there should be an error message.
>> 
>> "Maximum rigid tapping limit exceeded. And furthermore I have just
>> broken your tap"
>> 
> That, and maybe some explanation of this behavior in the docs. Maybe a more 
> specific message would be "spindle took too long to reverse while rigid 
> tapping".
> 
> Jon
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
  
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Gene Heskett
On Tuesday 21 July 2020 14:44:12 Robert Ellenberg wrote:

> I totally agree that a silent failure mode (especially one that can
> break taps) is bad news. Perhaps thankfully, we've gotten away with it
> for a long time: based on the git history, the 10-rev overshoot limit
> and this silent failure mode has been around at least since the 2.6
> days, maybe earlier.
>
> I have a few ways in mind to fix this:
>
>1. Throw an error and abort motion if it reaches some threshold of
>overshoot (say 90% of the maximum), or maybe if the position
> tracking error exceeds some threshold.
>2. Check if the rigid tap motion + max overshoot exceeds the axis
> limits (currently we check before adding the overshoot allowance,
> which in theory could lead to motion past the soft limits)
>3. (optional) Tell motion what the expected spindle acceleration is
> (via HAL pin), so that it can start reversing before it hits the
> bottom of the hole (reducing the overshoot). Leaving this pin at zero
> (default) would give you the current behavior.

Option 3 sounds like a great idea Rob, and it would/could/should be made 
to work with the G33.1 peck wrapper I hasn't published yet. I could even 
imagine 5 or 6 strokes, cutting air and programming that to achieve zero 
overshoot by actively adjusting the Z stop. Making it smarter than the 
average bear.

>  -Rob
>
> On Tue, Jul 21, 2020 at 2:17 PM Gene Heskett  
wrote:
> > On Tuesday 21 July 2020 13:09:16 andy pugh wrote:
> > > On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg 
> >
> > wrote:
> > > >1. The rigid tapping cycle allows a hard-coded 10 revolutions
> > > >
> > > >  > > >c#L8 56> of overtravel beyond the nominal bottom of the hole when
> > > > reversing direction.
> > >
> > > That feels like there should be an error message.
> > >
> > > "Maximum rigid tapping limit exceeded. And furthermore I have just
> > > broken your tap"
> >
> > "Maximum rigid tapping limit exceeded. And furthermore I have just
> >  broken your $85 carbide tap"
> >
> > There, I fixed it for you. :(
> >
> > 10 turns is way too far. I cut air at least once to measure the
> > turnaround (I have that stuff in my .hal file) and in what I have
> > done, that has led me to set a personal limit of 2 turns. Taking a
> > broken tap out of a valuable blind hole via EDM is a genuine PITA
> > and I will do whatever it takes to avoid that. But, I would not
> > uncouple the spindle from the tap either, killing the spindle drive
> > ASAP instead, then one might be able to  back the tap out of the
> > hole with the spindle, salvaging the part so maybe the hole could be
> > finished by hand.
> >
> > 10 turns, breaking the tap is the wrong thing to do. Shutting down,
> > leaving it coupled before the tap breaks is the best thing to do.
> >
> > 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)
> > If we desire respect for the law, we must first make the law
> > respectable. - Louis D. Brandeis
> > Genes Web page 
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
> ___
> 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Robert Ellenberg
I totally agree that a silent failure mode (especially one that can break
taps) is bad news. Perhaps thankfully, we've gotten away with it for a long
time: based on the git history, the 10-rev overshoot limit and this silent
failure mode has been around at least since the 2.6 days, maybe earlier.

I have a few ways in mind to fix this:

   1. Throw an error and abort motion if it reaches some threshold of
   overshoot (say 90% of the maximum), or maybe if the position tracking error
   exceeds some threshold.
   2. Check if the rigid tap motion + max overshoot exceeds the axis limits
   (currently we check before adding the overshoot allowance, which in theory
   could lead to motion past the soft limits)
   3. (optional) Tell motion what the expected spindle acceleration is (via
   HAL pin), so that it can start reversing before it hits the bottom of the
   hole (reducing the overshoot). Leaving this pin at zero (default) would
   give you the current behavior.

 -Rob

On Tue, Jul 21, 2020 at 2:17 PM Gene Heskett  wrote:

> On Tuesday 21 July 2020 13:09:16 andy pugh wrote:
>
> > On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg 
> wrote:
> > >1. The rigid tapping cycle allows a hard-coded 10 revolutions
> > >
> > >  > >56> of overtravel beyond the nominal bottom of the hole when
> > > reversing direction.
> >
> > That feels like there should be an error message.
> >
> > "Maximum rigid tapping limit exceeded. And furthermore I have just
> > broken your tap"
>
> "Maximum rigid tapping limit exceeded. And furthermore I have just
>  broken your $85 carbide tap"
>
> There, I fixed it for you. :(
>
> 10 turns is way too far. I cut air at least once to measure the
> turnaround (I have that stuff in my .hal file) and in what I have done,
> that has led me to set a personal limit of 2 turns. Taking a broken tap
> out of a valuable blind hole via EDM is a genuine PITA and I will do
> whatever it takes to avoid that. But, I would not uncouple the spindle
> from the tap either, killing the spindle drive ASAP instead, then one
> might be able to  back the tap out of the hole with the spindle,
> salvaging the part so maybe the hole could be finished by hand.
>
> 10 turns, breaking the tap is the wrong thing to do. Shutting down,
> leaving it coupled before the tap breaks is the best thing to do.
>
> 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)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Jon Elson

On 07/21/2020 12:43 PM, Matthew Herd wrote:

When I installed the spindle encoder, I used a shaft at the top of the head.  
Due to my failure to investigate more fully, it turns out that it’s geared 1:1 
with the spindle (but is not a part of the spindle).  So when I go into 
backgear, the encoder reads opposite direction and at a different ratio equal 
to the backgear ratio (whatever that is, I’ve never bothered to determine it).  
Fine for running a face mill or fly cutter, but not usable for rigid tapping 
without some HAL to reverse direction and compensate for the ratio change when 
in backgear).  Also, I’ve never gotten automatic spindle speed set up since I 
manually operate the vari-speed drive via push buttons on the head (HAL 
operates the air valves for me).  I also have a +/-10V DAC board to control VFD 
frequency, but have never set that up either.  I’m hoping to get rigid tapping 
working without solving some of these other issues, but if that’s the way it’s 
got to be, then so be it.


On Jul 21, 2020, at 1:27 PM, andy pugh  wrote:

On Tue, 21 Jul 2020 at 18:16, Matthew Herd  wrote:


Thanks for the insights.  I suspected something along these lines, even if I 
might have other problems with noise.  I can confirm, the spindle stops way too 
slowly and definitely more than 10 revolutions pass before stopping.  Long 
story short, I can’t readily run the machine in back gear

I think that's a story cut too short. Why can't you run the machine in
back-gear? I really wouldn't anticipate rigid tapping being done
without it.
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users





___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Gene Heskett
On Tuesday 21 July 2020 13:09:16 andy pugh wrote:

> On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg  
wrote:
> >1. The rigid tapping cycle allows a hard-coded 10 revolutions
> >   
> >  >56> of overtravel beyond the nominal bottom of the hole when
> > reversing direction.
>
> That feels like there should be an error message.
>
> "Maximum rigid tapping limit exceeded. And furthermore I have just
> broken your tap"

"Maximum rigid tapping limit exceeded. And furthermore I have just
 broken your $85 carbide tap"

There, I fixed it for you. :(

10 turns is way too far. I cut air at least once to measure the 
turnaround (I have that stuff in my .hal file) and in what I have done, 
that has led me to set a personal limit of 2 turns. Taking a broken tap 
out of a valuable blind hole via EDM is a genuine PITA and I will do 
whatever it takes to avoid that. But, I would not uncouple the spindle 
from the tap either, killing the spindle drive ASAP instead, then one 
might be able to  back the tap out of the hole with the spindle, 
salvaging the part so maybe the hole could be finished by hand.

10 turns, breaking the tap is the wrong thing to do. Shutting down, 
leaving it coupled before the tap breaks is the best thing to do.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Jon Elson

On 07/21/2020 12:27 PM, andy pugh wrote:

On Tue, 21 Jul 2020 at 18:16, Matthew Herd  wrote:


Thanks for the insights.  I suspected something along these lines, even if I 
might have other problems with noise.  I can confirm, the spindle stops way too 
slowly and definitely more than 10 revolutions pass before stopping.  Long 
story short, I can’t readily run the machine in back gear

I think that's a story cut too short. Why can't you run the machine in
back-gear? I really wouldn't anticipate rigid tapping being done
without it.
I do all my rigid tapping on smaller taps in direct drive 
with the belt on the highest speed setting.
This reduces the effective inertia of the motor, for faster 
reversing.  The motor is usually running
at 15-20 Hz in this mode.  I do 2-56 up to 6-32 taps at 1000 
RPM, and 10-32 and 1/4-20 at about

600 RPM.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Jon Elson

On 07/21/2020 12:14 PM, Matthew Herd wrote:

Hi Rob,

Thanks for the insights.  I suspected something along these lines, even if I 
might have other problems with noise.  I can confirm, the spindle stops way too 
slowly and definitely more than 10 revolutions pass before stopping.  Long 
story short, I can’t readily run the machine in back gear and the slowest I can 
go at 60Hz is 560 RPM without backgear.
I do not use backgear or belt reduction when doing small 
taps (2-56 up to 10-32).  I do the smaller taps at 1000 RPM, 
and maybe 600 for the 10-32.  So, the motor is running quite 
slowly at these speeds, maybe 15 - 20 Hz.  This makes it 
much easier to stop and reverse the motor.  I DO have a 
braking resistor on the VFD.  You can actually use stovetop 
heating elements for this (look in the back of any Haas 
machine.)

   I’ll play a bit more with how quickly I can stop the spindle with a braking 
resistor or I’ll attempt to get the HAL file to engage the mechanical brake to 
help transition faster.  Nonetheless, 10 revolutions seems fairly ambitious 
based on my best guess of how long it might take to stop the spindle even with 
a braking resistor.That’s about 1 second, but should be achievable.  
Currently the VFD is configured based on the fastest stop time for max RPM, and 
there doesn’t seem to be a way to decrease stop time for different inertial 
loads (i.e. lower gear ratios/spindle speeds).  However, I understand that the 
braking resistor should decrease stop time by approximately an order of 
magnitude based on some reading I did yesterday.
My machine (Bridgeport with 1J head) can reverse in a 
fraction of a second, probably 2 revolutions from 1000 RPM.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Matthew Herd
On a related note, I’ve noticed that the G-Code reference for G33 and G33.1 
refers you to the integrators manual, but there’s little documentation on 
spindle synchronized motion.  I’d be willing to add a section based on what I 
learn from this experience.  It might be helpful to make sure there’s more of a 
checklist and some of these cautions and observations in there.

> On Jul 21, 2020, at 1:56 PM, Jon Elson  wrote:
> 
> On 07/21/2020 12:09 PM, andy pugh wrote:
>> On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg  wrote:
>> 
>>>1. The rigid tapping cycle allows a hard-coded 10 revolutions
>>>
>>>of overtravel beyond the nominal bottom of the hole when reversing
>>>direction.
>> That feels like there should be an error message.
>> 
>> "Maximum rigid tapping limit exceeded. And furthermore I have just
>> broken your tap"
>> 
> That, and maybe some explanation of this behavior in the docs. Maybe a more 
> specific message would be "spindle took too long to reverse while rigid 
> tapping".
> 
> Jon
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Jon Elson

On 07/21/2020 12:09 PM, andy pugh wrote:

On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg  wrote:


1. The rigid tapping cycle allows a hard-coded 10 revolutions

of overtravel beyond the nominal bottom of the hole when reversing
direction.

That feels like there should be an error message.

"Maximum rigid tapping limit exceeded. And furthermore I have just
broken your tap"

That, and maybe some explanation of this behavior in the 
docs. Maybe a more specific message would be "spindle took 
too long to reverse while rigid tapping".


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Jon Elson

On 07/21/2020 12:00 PM, Robert Ellenberg wrote:

Based on the videos and your descriptions of the behavior, you may be
running into a TP issue I've seen (in simulation) with very sluggish
spindles or very high spindle speeds. Here's what I think is going on:

1. The rigid tapping cycle allows a hard-coded 10 revolutions

of overtravel beyond the nominal bottom of the hole when reversing
direction.
2. The spindle starts reversing direction only after the Z axis has
reached the bottom, so the spindle has to be able to stop in 10 revolutions
to stay within the budgeted overtravel.
3. If the TP hits the end of the overtravel, it prematurely declares the
motion to be complete and stops following the spindle motion.


AND, so the guy who actually WROTE THE CODE explains what is 
REALLY going on!

Yes, that explains at least the first video quite well.

Obviously, for rigid tapping, you need a spindle drive that 
is capable of a pretty strong stop and reversal.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread andy pugh
On Tue, 21 Jul 2020 at 18:46, Matthew Herd  wrote:

> When I installed the spindle encoder, I used a shaft at the top of the head.  
> Due to my failure to investigate more fully, it turns out that it’s geared 
> 1:1 with the spindle (but is not a part of the spindle).  So when I go into 
> backgear, the encoder reads opposite direction and at a different ratio equal 
> to the backgear ratio (whatever that is, I’ve never bothered to determine 
> it).  Fine for running a face mill or fly cutter, but not usable for rigid 
> tapping without some HAL to reverse direction and compensate for the ratio 
> change when in backgear).

You would also need to pick up an index (but only an index) from
something that does run 1:1.

If you accept that you only do spindle-synched motion in back-gear
then you don't need to do much in HAL.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Jon Elson

On 07/21/2020 10:15 AM, Matthew Herd wrote:

Ahh, so I do use limit switches and a homing routine.  So it’s homing to the 
same position (plus or minus a few thousandths or so).


So, use the # key to show machine coordinates, and then move 
the Z to the safe limits of travel, and note the Z values.  
Then, put these values into the .ini file for MAX_LIMIT and 
MIN_LIMIT.  Then, try to jog beyond those limits and observe 
if the machine makes a controlled stop at those points.  If 
so, you now have the soft limits set right.  Then, try the 
G33.1 again and see if the issue still happens.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Jon Elson

On 07/21/2020 10:14 AM, Matthew Herd wrote:

The ppmc.0.encoder.03.index pin is something I can halscope easily enough.  I 
was having a little trouble getting used to the halscope interface, and without 
a signal that I know will repeat every revolution, it’s hard to be sure you’re 
not just missing it with your scope parameters.
Well, the way the index pin works, it will stay true until 
read, so it will always be one sample wide.

I’m sure the machine is homed because I tried to run G33.1 and it wouldn’t run 
the command with the machine un-homed.  I can’t say with certainty I have 
enough travel but I do have far more travel than was being used.
OK, if true, then that kills the only idea I had.  But, the 
index function of the encoder would NOT have caused the 
crazy results you showed in the video.  Maybe some halscope 
traces of the G33.1

would make what happened more obvious.

Note that Z moving downward is a -Z move.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Matthew Herd
When I installed the spindle encoder, I used a shaft at the top of the head.  
Due to my failure to investigate more fully, it turns out that it’s geared 1:1 
with the spindle (but is not a part of the spindle).  So when I go into 
backgear, the encoder reads opposite direction and at a different ratio equal 
to the backgear ratio (whatever that is, I’ve never bothered to determine it).  
Fine for running a face mill or fly cutter, but not usable for rigid tapping 
without some HAL to reverse direction and compensate for the ratio change when 
in backgear).  Also, I’ve never gotten automatic spindle speed set up since I 
manually operate the vari-speed drive via push buttons on the head (HAL 
operates the air valves for me).  I also have a +/-10V DAC board to control VFD 
frequency, but have never set that up either.  I’m hoping to get rigid tapping 
working without solving some of these other issues, but if that’s the way it’s 
got to be, then so be it.

> On Jul 21, 2020, at 1:27 PM, andy pugh  wrote:
> 
> On Tue, 21 Jul 2020 at 18:16, Matthew Herd  wrote:
> 
>> Thanks for the insights.  I suspected something along these lines, even if I 
>> might have other problems with noise.  I can confirm, the spindle stops way 
>> too slowly and definitely more than 10 revolutions pass before stopping.  
>> Long story short, I can’t readily run the machine in back gear
> 
> I think that's a story cut too short. Why can't you run the machine in
> back-gear? I really wouldn't anticipate rigid tapping being done
> without it.
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] mailing list for ender 3 pro owners?

2020-07-21 Thread Bruce Layne


On 7/17/20 6:03 PM, Gene Heskett wrote:
> ...added 5.00 to the extruder feed, and gave it another go.  After 
> 4 restarts it laid down the first two layers of a raft, with no missing 
> lines and only one little bump, all while running at 20 lb paper 
> clearance, so the lines it was laying down were about 50% coverage, but 
> no missing gaps because it ran out of PLA.

Rather than adjusting the extrusion rate to get a good first layer at
the nozzle height you used to level the bed, I'd first calibrate the
nozzle to extrude the correct amount of material.  Andy described how to
do this earlier in this painful saga, where you mark the filament 120mm
back, have it extrude 100mm of filament, measure how much filament it
actually extruded, and then adjust the extrusion multiplier until it's
extruding 100mm.  Once the extrusion rate is properly set, leave it
alone.  Fix the first layer adhesion by tweaking the nozzle height using
the bed leveling nuts, or by adjusting the first layer height and/or
first layer extrusion multiplier in Cura.

Your 3D printing experience has been needlessly difficult.  Maybe the
default settings were grossly incorrect when you received your 3D
printer but that's very rare these days.  Most people don't mess with
the basic settings.  Most of us get a new machine, level the bed and
start printing.  There is generally a little bit of a learning curve
getting good first layer adhesion on your first 3D printer, but none of
the ongoing problems you've experienced.  That sounds like hobby 3D
printing ten years ago when the burden was on the hobby builder.  These
days, 3D printers are built in factories and are almost consumer
appliances with no need to adjust basic settings.  It's as if you bought
a new car and it idled rough so you are building your own engine
computer to fix it.

I'm cheap, but I've learned that there is value at every level and it's
usually the case that saving that last 10% is a negative value
proposition.  I buy low cost items but usually not the lowest priced
item, particularly on something as complex as a 3D printer.  I don't
want to spend $220 on a 3D printer that was built in small numbers by
people with little experience with 3D printers, who may not have
configured it properly, used the very lowest quality components with no
warranty or customer support, when I have a much better experience by
spending $30 more.  If I need to spend $150 and three weeks of my time
fixing problems, saving $30 was a bad deal.

I just finished 3D printing 4kg of ABS parts for a small production run
for a friend.  I did have two clogged nozzles but those are now an easy
three minute one dollar repair.  I put another 3D printer into service
in my small 3D print farm and the set screws backed out in an X axis
idler pulley so I had to fix that.  I'll Loctite and properly torque the
set screws on all of my 3D printers to avoid that failure in the
future.  Otherwise, that 430 hours of printing those 132 parts was
pretty much a matter of picking a part off the glass plate (they self
release when cool in 15 minutes), adding a tiny amount of glue juice,
distributing it on the glass plate with a nylon bristle brush and
selecting Print Another Copy.  Once your 3D printer is adjusted
properly, hardware and software, it should be reliable.

I'm getting better with FreeCAD and I always preview the job using
Simplify3D after slicing it.  Cura allows previewing too, so you can
ensure that it's printing what you want, the way you want it to print.

I hope your 3D printing becomes a lot easier and a lot more fun soon,
Gene.  It shouldn't be this difficult.  I wish you could start fresh
with a known good configuration.

The only time I use a raft is when I'm printing a large number of very
small parts with little contact area on the build platform, where any
part that failed would ruin the entire print job.  Glue on glass makes a
reliable first layer adhesion with ABS, PLA or TPU.






___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread andy pugh
On Tue, 21 Jul 2020 at 18:16, Matthew Herd  wrote:

> Thanks for the insights.  I suspected something along these lines, even if I 
> might have other problems with noise.  I can confirm, the spindle stops way 
> too slowly and definitely more than 10 revolutions pass before stopping.  
> Long story short, I can’t readily run the machine in back gear

I think that's a story cut too short. Why can't you run the machine in
back-gear? I really wouldn't anticipate rigid tapping being done
without it.
-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Matthew Herd
Hi Rob,

Thanks for the insights.  I suspected something along these lines, even if I 
might have other problems with noise.  I can confirm, the spindle stops way too 
slowly and definitely more than 10 revolutions pass before stopping.  Long 
story short, I can’t readily run the machine in back gear and the slowest I can 
go at 60Hz is 560 RPM without backgear.  I’ll play a bit more with how quickly 
I can stop the spindle with a braking resistor or I’ll attempt to get the HAL 
file to engage the mechanical brake to help transition faster.  Nonetheless, 10 
revolutions seems fairly ambitious based on my best guess of how long it might 
take to stop the spindle even with a braking resistor.That’s about 1 
second, but should be achievable.  Currently the VFD is configured based on the 
fastest stop time for max RPM, and there doesn’t seem to be a way to decrease 
stop time for different inertial loads (i.e. lower gear ratios/spindle speeds). 
 However, I understand that the braking resistor should decrease stop time by 
approximately an order of magnitude based on some reading I did yesterday.

Thanks!
Matt

> On Jul 21, 2020, at 1:00 PM, Robert Ellenberg  wrote:
> 
> Based on the videos and your descriptions of the behavior, you may be
> running into a TP issue I've seen (in simulation) with very sluggish
> spindles or very high spindle speeds. Here's what I think is going on:
> 
>   1. The rigid tapping cycle allows a hard-coded 10 revolutions
>   
>   of overtravel beyond the nominal bottom of the hole when reversing
>   direction.
>   2. The spindle starts reversing direction only after the Z axis has
>   reached the bottom, so the spindle has to be able to stop in 10 revolutions
>   to stay within the budgeted overtravel.
>   3. If the TP hits the end of the overtravel, it prematurely declares the
>   motion to be complete and stops following the spindle motion.
> 
> Do you still see this behavior if you run the spindle slower? Your spindle
> seems to take a long time to reverse, so at high speeds you may be hitting
> this limit.
> 
> Best,
> Rob
> 
> 
> On Tue, Jul 21, 2020 at 11:18 AM Matthew Herd  wrote:
> 
>> Ahh, so I do use limit switches and a homing routine.  So it’s homing to
>> the same position (plus or minus a few thousandths or so).
>> 
>>> On Jul 21, 2020, at 11:07 AM, Jon Elson  wrote:
>>> 
>>> On 07/21/2020 04:20 AM, andy pugh wrote:
 On Tue, 21 Jul 2020 at 10:18, andy pugh  wrote:
 
> We are not looking for noise, we are looking for spurious encoder
>> count resets.
 But, thinking further, even if there _is_ noise on the index line, the
 encoder counter should ignore it. It ignores all the _real_ indexes
 unless index-enable is set true in HAL.
 
>>> Yes, the only thing I can think of is he's hitting his soft limits. Over
>> time, starting and stopping LinuxCNC,
>>> without homing, the machine limits will drift.  If you have rational
>> limits in the .ini file, you will eventually reach the end of them and have
>> really strange behavior.  it can be fixed by homing in a safe position,
>>> but best to put in home switches and actually home the machine to a
>> repeatable position every time.
>>> 
>>> Jon
>>> 
>>> 
>>> ___
>>> Emc-users mailing list
>>> Emc-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> 
>> 
>> 
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread andy pugh
On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg  wrote:

>1. The rigid tapping cycle allows a hard-coded 10 revolutions
>
>of overtravel beyond the nominal bottom of the hole when reversing
>direction.

That feels like there should be an error message.

"Maximum rigid tapping limit exceeded. And furthermore I have just
broken your tap"

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Robert Ellenberg
Based on the videos and your descriptions of the behavior, you may be
running into a TP issue I've seen (in simulation) with very sluggish
spindles or very high spindle speeds. Here's what I think is going on:

   1. The rigid tapping cycle allows a hard-coded 10 revolutions
   
   of overtravel beyond the nominal bottom of the hole when reversing
   direction.
   2. The spindle starts reversing direction only after the Z axis has
   reached the bottom, so the spindle has to be able to stop in 10 revolutions
   to stay within the budgeted overtravel.
   3. If the TP hits the end of the overtravel, it prematurely declares the
   motion to be complete and stops following the spindle motion.

Do you still see this behavior if you run the spindle slower? Your spindle
seems to take a long time to reverse, so at high speeds you may be hitting
this limit.

Best,
Rob


On Tue, Jul 21, 2020 at 11:18 AM Matthew Herd  wrote:

> Ahh, so I do use limit switches and a homing routine.  So it’s homing to
> the same position (plus or minus a few thousandths or so).
>
> > On Jul 21, 2020, at 11:07 AM, Jon Elson  wrote:
> >
> > On 07/21/2020 04:20 AM, andy pugh wrote:
> >> On Tue, 21 Jul 2020 at 10:18, andy pugh  wrote:
> >>
> >>> We are not looking for noise, we are looking for spurious encoder
> count resets.
> >> But, thinking further, even if there _is_ noise on the index line, the
> >> encoder counter should ignore it. It ignores all the _real_ indexes
> >> unless index-enable is set true in HAL.
> >>
> > Yes, the only thing I can think of is he's hitting his soft limits. Over
> time, starting and stopping LinuxCNC,
> > without homing, the machine limits will drift.  If you have rational
> limits in the .ini file, you will eventually reach the end of them and have
> really strange behavior.  it can be fixed by homing in a safe position,
> > but best to put in home switches and actually home the machine to a
> repeatable position every time.
> >
> > Jon
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


[Emc-users] odd fault in a DM542

2020-07-21 Thread Gene Heskett
Greeting all;

As told, I switched out a 1600 oz/in nema 34 motor in favor of one of the 
new 3 phase 3NM motors on the z axis.

That meat I had to replace the DM860's psu with a lower voltage one 
because the 3 phase driver is only rated for 50 volts max and the toroid 
kludge I had in there was making a non-adjustable 63 volts.  But the 
shape of the 48volt, 7,5 amp switcher also displaced the 42 volt toroid 
kludge driving the X axis's DM542. So two of the48 volt, 7.5 amp 
supplies wre installed, after turning them down to 42.5 volts.

The additional current and stiff voltage upped the max speeds of both 
axis and I just tested both at 120 ipm, nominally double the former Z 
speed and 4x the former X stall speed.

The lathe pawn makes a good exercise code, and I've modified it to make 
50 copies in the air in front of the chuck. But the DM542 driving the X 
motor is now occasionally faulting. Seems to occur as I'm removing my 
finger from the jog key. The motor is not stalling but just coasts to a 
stop because the power is turned off at the fault point.

I am using an extra microsecond for pulse widths, is it possible to 
confuse a DM542 with wide pulses when the switch rate is about the limit 
of the DM542's opto's? Pulling the max jog back to 90 ipm seems to stop 
that failure.

Unforch, the DM542 has no external fault tally reporting connections.

Ideas? Or just limit it to what it can do, 100% of the time? This is a 
bunch faster than it was before.

Thanks everybody.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Matthew Herd
Ahh, so I do use limit switches and a homing routine.  So it’s homing to the 
same position (plus or minus a few thousandths or so).

> On Jul 21, 2020, at 11:07 AM, Jon Elson  wrote:
> 
> On 07/21/2020 04:20 AM, andy pugh wrote:
>> On Tue, 21 Jul 2020 at 10:18, andy pugh  wrote:
>> 
>>> We are not looking for noise, we are looking for spurious encoder count 
>>> resets.
>> But, thinking further, even if there _is_ noise on the index line, the
>> encoder counter should ignore it. It ignores all the _real_ indexes
>> unless index-enable is set true in HAL.
>> 
> Yes, the only thing I can think of is he's hitting his soft limits. Over 
> time, starting and stopping LinuxCNC,
> without homing, the machine limits will drift.  If you have rational limits 
> in the .ini file, you will eventually reach the end of them and have really 
> strange behavior.  it can be fixed by homing in a safe position,
> but best to put in home switches and actually home the machine to a 
> repeatable position every time.
> 
> Jon
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Matthew Herd
The ppmc.0.encoder.03.index pin is something I can halscope easily enough.  I 
was having a little trouble getting used to the halscope interface, and without 
a signal that I know will repeat every revolution, it’s hard to be sure you’re 
not just missing it with your scope parameters.

I’m sure the machine is homed because I tried to run G33.1 and it wouldn’t run 
the command with the machine un-homed.  I can’t say with certainty I have 
enough travel but I do have far more travel than was being used.

I’ll take a look at the machine grounding and may re-wire some of it this 
week/weekend, but I am aware of star grounding.  The only possibility I can 
think of off hand is that I may have created a ground loop through the machine 
by connecting the power cabinet ground bolt to the control cabinet ground bolt 
via a wired connection.  Both cabinets are bolted to the machine so they’re 
also grounded via the machine.  I did the conversion 8 years ago, so I’m a 
little fuzzy on the details of how I ran the grounds.

> On Jul 21, 2020, at 11:04 AM, Jon Elson  wrote:
> 
> On 07/21/2020 04:18 AM, andy pugh wrote:
>> On Tue, 21 Jul 2020 at 01:59, Gene Heskett  wrote:
>> 
 Try halscoping motion.spindle-revs through a G33,1 cycle in air.
>>> halscope hasn't, Andy, by decades, enough bandwidth to register the noise
>>> I'd be looking for.
>> We are not looking for noise, we are looking for spurious encoder count 
>> resets.
>> 
>> If you can't see it in halscope (by looking in the right place) then
>> it can't affect LinuxCNC.
>> 
> Halscope can view this signal through the ppmc.0.encoder.03.index pin.  On 
> the rising edge of the index pulse, a hardware register bit is set.  After 
> the register is read, the bit is cleared.  Viewing this register with 
> Halscope, you should see one pulse per revolution of the spindle.  If you see 
> more, and they appear to be random, then you have a noise issue.
> 
> 
> BUT -- I don't think that is the problem.  Noise on the index would make it 
> impossible to do multi-pass threading, as on a lathe.  But, it should not 
> affect single-pass G33.1 rigid tapping, just that the start angle would be 
> random.  I really think the issue is an un-homed machine that is hitting the 
> soft travel limits.
> 
> What would you rather have the trajectory planner do in this case? Your only 
> choices are to stay in spindle sync and drive the axis off the end of the 
> soft limits, or stop at the limit and break the tap.
> Neither is a good choice.
> 
> Matt should check the MAX_LIMIT and MIN_LIMIT in his .ini file, and then 
> check the machine coordinate position by clicking the "#" key to show the 
> machine coordinates.
> 
> Jon
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread Jon Elson

On 07/21/2020 08:33 AM, Andrew wrote:

вт, 21 лип. 2020 о 06:17 Jon Elson пише:



So, if your machine has a 200 Lb table, and the leadscrew
were to produce 1000 Lbs linear force,
it would accelerate at 5 G.


This is a simplified calculation, it doesn't account for rotary inertia of
ballscrew and other rotary parts.
You need to reduce that rotary inertia to a mass and add it to the table
mass. And that will be a pretty significant amount, particularly if the
ballscrew is long and massive.

Yes, quite true.  But, in fact, the ballscrew is 
insignificant compared to the MOTOR mass.

But, this was just a ballpark figure.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Jon Elson

On 07/21/2020 04:20 AM, andy pugh wrote:

On Tue, 21 Jul 2020 at 10:18, andy pugh  wrote:


We are not looking for noise, we are looking for spurious encoder count resets.

But, thinking further, even if there _is_ noise on the index line, the
encoder counter should ignore it. It ignores all the _real_ indexes
unless index-enable is set true in HAL.

Yes, the only thing I can think of is he's hitting his soft 
limits. Over time, starting and stopping LinuxCNC,
without homing, the machine limits will drift.  If you have 
rational limits in the .ini file, you will eventually reach 
the end of them and have really strange behavior.  it can be 
fixed by homing in a safe position,
but best to put in home switches and actually home the 
machine to a repeatable position every time.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Jon Elson

On 07/21/2020 04:18 AM, andy pugh wrote:

On Tue, 21 Jul 2020 at 01:59, Gene Heskett  wrote:


Try halscoping motion.spindle-revs through a G33,1 cycle in air.

halscope hasn't, Andy, by decades, enough bandwidth to register the noise
I'd be looking for.

We are not looking for noise, we are looking for spurious encoder count resets.

If you can't see it in halscope (by looking in the right place) then
it can't affect LinuxCNC.

Halscope can view this signal through the 
ppmc.0.encoder.03.index pin.  On the rising edge of the 
index pulse, a hardware register bit is set.  After the 
register is read, the bit is cleared.  Viewing this register 
with Halscope, you should see one pulse per revolution of 
the spindle.  If you see more, and they appear to be random, 
then you have a noise issue.



BUT -- I don't think that is the problem.  Noise on the 
index would make it impossible to do multi-pass threading, 
as on a lathe.  But, it should not affect single-pass G33.1 
rigid tapping, just that the start angle would be random.  I 
really think the issue is an un-homed machine that is 
hitting the soft travel limits.


What would you rather have the trajectory planner do in this 
case? Your only choices are to stay in spindle sync and 
drive the axis off the end of the soft limits, or stop at 
the limit and break the tap.

Neither is a good choice.

Matt should check the MAX_LIMIT and MIN_LIMIT in his .ini 
file, and then check the machine coordinate position by 
clicking the "#" key to show the machine coordinates.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread Jon Elson

On 07/21/2020 04:07 AM, andy pugh wrote:

On Tue, 21 Jul 2020 at 05:52, Tom Smart  wrote:


If i keep the amps at the rating of 9.1 I should keep my 31.3 IN-LBS or 2.6 
FT-LBS?

So 2.6 / .0813 would be 81.76 lbs of linear force?

So if my table weighs 200lbs my acceleration would be .41 G?

I'm wondering if I've done a calculation wrong

The way I think about it.[1]

Imagine pushing with a force of 1 lb  on the end of a 1 foot  handle
fastened to the end of the screw through one complete turn. That is
circle of radius 1 foot and a distance of 2 x pi X 12  = 75 inches and
a torque of 1 lb/ft
The screw moves 0.2 in
The ratio is 75" / .2" = 377:1
So 2.6 lbft on a 5tpi screw is 750lbs.
I think there was a feet to inches error in the calculation above. And
a shuffling of 0.0138 to 0.0813.


OK, I screwed up.  I had to do a whole page of calculations 
to see it.  My cheat sheet was in INCH Pounds,

not FOOT pounds!

So, to start over :

31.3 Inch-Lb / 0.0318 = 985 Lbs linear force.  That should 
be fine.


Sorry for the error in my earlier posts.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread Jon Elson

On 07/20/2020 11:49 PM, Tom Smart wrote:

So my 3500 rpm rated motor at 180vdc would be 2916 rpm at 150 vdc and 2333 rpm 
at 120vdc?

Yes, exactly.

If my ballscrew is 5tpi then at rated voltage i would get 700 ipm at 150vdc 583 
ipm and at 120vdc 466ipm feeds?

Yes.

If i keep the amps at the rating of 9.1 I should keep my 31.3 IN-LBS or 2.6 
FT-LBS?

So 2.6 / .0813 would be 81.76 lbs of linear force?

That denominator s .0318 but your result is correct.

So if my table weighs 200lbs my acceleration would be .41 G?

I'm wondering if I've done a calculation wrong or is this a good setup?

Well, 81 Lbs sounds pretty weak for a milling machine.  Is 
the motor directly driving the leadscrew or is there a belt 
reduction?  My Bridgeport setup is kind of anemic, but it 
has a 2.5:1 belt reduction on the motor.  That gets me to 23 
In-Lb at the leadscrew, for 700 Lbs of linear force.


Now, the 9.1 A rating of the motor, is that a continuous 
(stall) rating or a peak rating?  If that is stall, then the 
motor can handle more current during acceleration peaks, at 
least twice, possibly 4 X.

That will help.

Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread Andrew
вт, 21 лип. 2020 о 06:17 Jon Elson пише:


> So, if your machine has a 200 Lb table, and the leadscrew
> were to produce 1000 Lbs linear force,
> it would accelerate at 5 G.
>

This is a simplified calculation, it doesn't account for rotary inertia of
ballscrew and other rotary parts.
You need to reduce that rotary inertia to a mass and add it to the table
mass. And that will be a pretty significant amount, particularly if the
ballscrew is long and massive.

WBR,
Andrew

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread andy pugh
On Tue, 21 Jul 2020 at 10:18, andy pugh  wrote:

> We are not looking for noise, we are looking for spurious encoder count 
> resets.

But, thinking further, even if there _is_ noise on the index line, the
encoder counter should ignore it. It ignores all the _real_ indexes
unless index-enable is set true in HAL.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread andy pugh
On Tue, 21 Jul 2020 at 01:59, Gene Heskett  wrote:

> > Try halscoping motion.spindle-revs through a G33,1 cycle in air.
>
> halscope hasn't, Andy, by decades, enough bandwidth to register the noise
> I'd be looking for.

We are not looking for noise, we are looking for spurious encoder count resets.

If you can't see it in halscope (by looking in the right place) then
it can't affect LinuxCNC.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Need help with Bostomatic BD18-2 to linuxcnc

2020-07-21 Thread andy pugh
On Tue, 21 Jul 2020 at 05:52, Tom Smart  wrote:

> If i keep the amps at the rating of 9.1 I should keep my 31.3 IN-LBS or 2.6 
> FT-LBS?
>
> So 2.6 / .0813 would be 81.76 lbs of linear force?
>
> So if my table weighs 200lbs my acceleration would be .41 G?
>
> I'm wondering if I've done a calculation wrong

The way I think about it.[1]

Imagine pushing with a force of 1 lb  on the end of a 1 foot  handle
fastened to the end of the screw through one complete turn. That is
circle of radius 1 foot and a distance of 2 x pi X 12  = 75 inches and
a torque of 1 lb/ft
The screw moves 0.2 in
The ratio is 75" / .2" = 377:1
So 2.6 lbft on a 5tpi screw is 750lbs.
I think there was a feet to inches error in the calculation above. And
a shuffling of 0.0138 to 0.0813.

[1] Except in metric, generally.
-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

2020-07-21 Thread Gene Heskett
On Monday 20 July 2020 22:14:10 Jon Elson wrote:

> On 07/20/2020 07:43 PM, Gene Heskett wrote:
> > Interesting. I wonder if he accidently fixed an unwanted ground, or
> > made a bad one good doing it?  Murphy is alive and well despite our
> > reward funds.
>
> Yes, he had unwanted grounds (loops) all over the place.
> Actually, he has NO ground, only a neutral, which is
> connected to some 120 V loads.  Clearly not NEC compliant.
>
Ohmy   gawd

> Also, he had the grounds for the servo amps looped all over
> the place, had the signals and  grounds to the servo amps
> following wildly different paths, all sorts of stuff.  I had
> him rewire so the signal and ground
> for the servo amp inputs were bundled together, and logic
> power and enable follow the shortest path.
> He had to rewire the thing at least a dozen times, but it
> eventually cleared up the issues.
>
> I just instinctively know how to wire signals in a
> high-noise environment, so I didn't know how touchy
> things actually were.
>
> One of the shortcuts I took in my servo amps was to not
> isolate the power stage from the logic, and to
> only have one ground, common for both the power stage and
> the logic.

I've had thoughts about that, but with an isolated analog supply for just 
that motor, its not turned out to be a problem at the end of the day.

I use switchers for everything else in both cases The opto on the enable 
line would have made the hoops I've had to jump thru a little easier by 
making it controllable with normal 5 volt pulldown logic. ISTR I've got 
something from sparkfun switching the 12 volts into that interface in 
both of them, works so well I've forgotten what it is. :)  With the 
extra toroids for spindle duty, its runs at room temps.


> I SHOULD have also opto-isolated the enable pin 
> on the servo amp.  So, if you have long wires on that common
> ground, a star connection from the distant motor power
> supply, large voltages will appear on the ground for the
> logic as well.
> That was the basic problem.  I had to have him put a
> terminal block as close to the servo amps as
> possible, so the path from one amp's ground to the other was
> as short as possible.  Then, bundling the PWM, direction and
> ground to the servo amps finished the fix.
>
> I've sold 124 of these PWM servo controllers, and NEVER run
> into a problem like this.  I've had a few people run into
> minor noise issues, but this one really had me going in circles.
>
Its a great controller Jon. With suitable toroids, and a suitable current 
limiting resistor, mine are both set at around 17 amps, its best 
described as bullet-proof, you simply cannot make it hurt itself. If I 
have a PMDC motor to control, no discussion, you get the order.
> Jon
>
>
> ___
> 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users