date:20200720


On 07/20/2020 09:00 PM, Tom Smart wrote:

I forgot to ask how would I calculate the loss of abilities of the mill if i 
don't drive the servos with their maximum rated power and amps? If I were to 
get drives that weren't rated to 180vdc what losses will i have and how do i 
calculate the loss?


First, find the rated speed of the motor.  If the motor is 
rated at 1800 RPM and directly drives a
5 TPI leadscrew, then it will give 360 IPM linear speed at 
rated voltage.  If you then run the servo
amps at half the motor's rated voltage, you would get half 
that speed, or 180 IPM.


Then, if the motor has a peak torque rating at some 
amperage, but your servo amp can only deliver
half the rating, you would only get half that torque.  if 
the motor only shows a continuous torque at

some current, you can guess the peak rating is 2-4 times higher.

I'll use those horrid imperial units, as that's what my 
cheat sheet was done in.
If the motor is rated in oz-in, then you can convert that to 
lb-ft by dividing by

12*16.  So, a 100 Oz-In motor provides 0.52 lb-ft or torque.

A 5 TPI leadscrew advances the axis 0.2 inch per turn.  This 
is equivalent to a spool with a radius of
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).


You can plug in your own numbers to calculate it for your 
own motors and servo amps.
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.

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


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.


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


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-20 Thread Tom Smart

I forgot to ask how would I calculate the loss of abilities of the mill if i 
don't drive the servos with their maximum rated power and amps? If I were to 
get drives that weren't rated to 180vdc what losses will i have and how do i 
calculate the loss?

Thanks for the assistance,
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-20 Thread Tom Smart

I looked at the machine today and pulled the y-axis servo. Apparently NASA's 
definition of machine working when taken out of service doesn't consider the 
fact parts were removed. The y-axis encoder is MIA. I did speak with Glentek 
today, they let me know the "special" designation was that they didn't include 
encoders in the servos. I'm going to check the other axis servo tomorrow. I'm 
uncertain if I have the power supply for the drives or not. I'm leaning towards 
they were part of the drives that were removed. There is a large capacitor that 
is labeled Glentek and all 3 drives were wired into it. I have 4 wires on top 
where the drives were. 1 white, 1 black, 1 red and another black. The white and 
black go to the servos. The wiring is done incredibly if only i had the road 
map aka wiring diagrams.

Oh I don't see any glass scales and there are wires in the servo where the 
encoder was likely connected.

I will continue pecking away at it trying to figure out what i need to bring it 
back to life.

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] Problem with Rigid Tapping on USC Equipped Bridgeport

On Monday 20 July 2020 20:39:38 andy pugh wrote:

> On Tue, 21 Jul 2020 at 01:33, Matthew Herd  wrote:
> > Good thoughts Jon and Gene, I was thinking the same thing.  The
> > count when running the encoder diagnostics keeps resetting to 0.  So
> > I will drag out my scope and see what I find.
>
> I think you will have a lot more luck with halscope than real-scope
> here.
>
> 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. 3 to 10 nanosecond stuff. That is right at the 
bandwidth limit of my digital, and approaching the limits of my elderly 
Hitachi V-1065 which is still showing me a usable signal at 180 MHZ. 
Mesa cards see it well.  No clue how fast Matthews stuff is though. 

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

On Monday 20 July 2020 20:30:59 Matthew Herd wrote:

> Good thoughts Jon and Gene, I was thinking the same thing.  The count
> when running the encoder diagnostics keeps resetting to 0.  So I will
> drag out my scope and see what I find.  Hopefully a little checking of
> the grounds plus a braking resistor and I’ll be able to rigid tap. 
> I’ve got a project coming up that involves tapping about a thousand
> 6-32 holes, hence this experiment.  It’d be a real hassle to do it by
> hand.  At any rate, I probably won’t get to it until Wednesday.
>
Be sure and let us know what you find Matthew.

> > On Jul 20, 2020, at 8:04 PM, Gene Heskett 
> > wrote:
> >
> > On Monday 20 July 2020 18:57:03 Jon Elson wrote:
> >> On 07/20/2020 05:27 PM, Matthew Herd wrote:
> >>> Working through Jon’s suggestions, the answers to his questions
> >>> are as follows.  Also, I’m running version 2.7.11 if that helps. 
> >>> No internet in my shop means it gets infrequent updates.
> >>>
> >>> Running the universal stepper diagnostics program with the command
> >>> sudo .univstepdiags 378 bus indicates board 0 is firmware version
> >>> 3. No board 1 is shown, boards 2 and 4-f are "No Board" and board
> >>> 3 is "Unknown."
> >>>
> >>> Running the command sudo .univstepdiags 378 indexres 3 (from a
> >>> forum post) gives me +517.00, +517.00, +517.00, and a jittery
> >>> +0.000/+/-1.000 that seems to increase/decrease (depending on
> >>> CW/CCW rotation) then go back to zero as fast as I turn the
> >>> spindle.  I can see numbers greater than 1, but they flash back to
> >>> zero within a fraction of a second and keep jittering.
> >>
> >> Yes, that is normal.  The position count is being reset to
> >> zero each time the encoder passes the index position.
> >> Turning it by hand, you might want to see it count up to
> >> whatever your quadrature counts/rev is, before it resets.
> >> If it keeps resetting to zero with just a little rotation,
> >> then you are getting pulses on the Z channel that is
> >> resetting the counter in between the index positions.  That
> >> would be a hardware issue with the encoder or encoder wiring.
> >>
> >>> The encoder scale on axis 03 is "setp ppmc.0.encoder.03.scale
> >>> 2048" which is consistent with a 512 CPR encoder in quadrature. 
> >>> That’s what I’ve got installed.
> >>>
> >>> the connection to LinuxCNC looks like this:
> >>> newsig spindle-index-en bit
> >>> linkps motion.spindle-index-enable => spindle-index-en
> >>> linksp spindle-index-en => ppmc.0.encoder.03.index-enable
> >>>
> >>> AND
> >>>
> >>> newsig spindle-pos float
> >>> linkps ppmc.0.encoder.03.position => spindle-pos
> >>> linksp spindle-pos => motion.spindle-revs
> >>>
> >>> At 3600 RPM (as reported from the encoder) the velocity is 60.  At
> >>> 3600 RPM CCW, the velocity is -60.  I don’t readily have a means
> >>> of verifying actual RPM, but the dial on the vari-speed head seems
> >>> to read lower than actual RPMs, though I understand this is
> >>> consistent with a worn varispeed drive.  I also confirmed that one
> >>> revolution appears to correspond to one increase/decrease of the
> >>> ppmc.0.encoder.03.position as displayed by Hal Meter.  I took care
> >>> to rotate it one revolution as closely as I could manage and the
> >>> results checked out.
> >>>
> >>> Regarding the index, I probed it with a meter and found the
> >>> position at which it triggers.  I can confirm that it should work
> >>> as it showed 4.64V when at the index position.
> >>>
> >>> See below for my HAL files:
> >>>
> >>> univstep_motion.hal:  https://paste.ubuntu.com/p/h66KJZx3hC/
> >>>  univstep_io.hal:
> >>> https://paste.ubuntu.com/p/gMNkMwKDVw/
> >>>  univstep_load.hal:
> >>> https://paste.ubuntu.com/p/d36HgfwZ5Z/
> >>>  univstep_servo.hal:
> >>> https://paste.ubuntu.com/p/wyb6JPX7ts/
> >>>  xhc-hb04.hal:
> >>> https://paste.ubuntu.com/p/w9mNn8hSdT/
> >>>  pycp_panel.hal:
> >>> https://paste.ubuntu.com/p/dVNwxHWJD2/
> >>> 
> >>>
> >>> I realize most of these are not likely to be relevant, but I’ve
> >>> included them anyway.  The encoder is connected in the
> >>> univstep_motion.hal file.
> >>>
> >>> Also, re-testing the behavior, I seem to get two different
> >>> outcomes when I run G33.1.  First error behavior is shown here:
> >>> https://youtu.be/GMspKB5ZkoQ  and
> >>> the second error behavior is shown here: 
> >>> https://youtu.be/HJBOtFtXF5o .  In
> >>> the first behavior (which appears to be random, but I didn’t
> >>> restart axis repeatedly to test), the spindle is running before
> >>> the G33.1 command.  It feeds downward past the commanded 0.5" to
> >>> 0.8125 or so, then stops Z motion while it decelerates.  Then it
> >>> reverses, spins up to

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

On Monday 20 July 2020 20:30:30 Jon Elson wrote:

> On 07/20/2020 07:04 PM, Gene Heskett wrote:
> > I think I'd drag out one of my 100+ MHZ scopes and look for noise of
> > the type one might get from lack of a single point ground.
>
> Right.  if the indexres test of the diagnostics shows the
> position resetting multiple times/rev
> (may only happen when spindle drive is on) then there is
> noise on the Z.  The A and B have digital filtering that
> only accepts valid state transitions of the quadrature wave,
> that hides a lot of really nasty garbage that some systems
> have.  There is no way to digital filter the index pulse, it
> is edge-triggered, and a 10 ns pulse could trigger it.
>
> But, noise on the index will only affect the place where the
> spindle sync motion starts.  Once the spindle encoder senses
> an index pulse, then everything is counted from there.  So,
> a noisy index pulse should NOT cause the Z axis to behave as
> the videos show.  OHH, wait a minute!  One thing that COULD
> cause this behavior is if the move exceeded the Z soft
> limits.  Z would freeze at the most extended part, and then
> pull back when the spindle count brought the position back
> within the soft limits.  That's exactly what it did in the
> first video.
>
> So, Matt should check what his Z soft limits are set to in
> the .ini file, and then home the axis so
> it won't be exceeding the soft limits.

I've not encountered that particular symptom, so didn'tthink of it, but 
you obviously have.

> Having just spent about 3 weeks solving a ground loop issue
> on a PWM servo system remotely, they
> can cause an amazing array of crazy symptoms.  Having the
> user shorten up all the wiring fixed it.

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.

> 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

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

On Tue, 21 Jul 2020 at 01:33, Matthew Herd  wrote:
>
> Good thoughts Jon and Gene, I was thinking the same thing.  The count when 
> running the encoder diagnostics keeps resetting to 0.  So I will drag out my 
> scope and see what I find.

I think you will have a lot more luck with halscope than real-scope here.

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

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

I had a suspicion that the very long deceleration times might have exposed a 
bug in the software.  I doubt I’m exceeding soft limits, but I’ll run some more 
tests when I play with it next.

> On Jul 20, 2020, at 8:30 PM, Jon Elson  wrote:
> 
> On 07/20/2020 07:04 PM, Gene Heskett wrote:
>> 
>> I think I'd drag out one of my 100+ MHZ scopes and look for noise of the
>> type one might get from lack of a single point ground.
> Right.  if the indexres test of the diagnostics shows the position resetting 
> multiple times/rev
> (may only happen when spindle drive is on) then there is noise on the Z.  The 
> A and B have digital filtering that only accepts valid state transitions of 
> the quadrature wave, that hides a lot of really nasty garbage that some 
> systems have.  There is no way to digital filter the index pulse, it is 
> edge-triggered, and a 10 ns pulse could trigger it.
> 
> But, noise on the index will only affect the place where the spindle sync 
> motion starts.  Once the spindle encoder senses an index pulse, then 
> everything is counted from there.  So, a noisy index pulse should NOT cause 
> the Z axis to behave as the videos show.  OHH, wait a minute!  One thing that 
> COULD cause this behavior is if the move exceeded the Z soft limits.  Z would 
> freeze at the most extended part, and then pull back when the spindle count 
> brought the position back within the soft limits.  That's exactly what it did 
> in the first video.
> 
> So, Matt should check what his Z soft limits are set to in the .ini file, and 
> then home the axis so
> it won't be exceeding the soft limits.
> 
> Having just spent about 3 weeks solving a ground loop issue on a PWM servo 
> system remotely, they
> can cause an amazing array of crazy symptoms.  Having the user shorten up all 
> the wiring fixed it.
> 
> 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

Good thoughts Jon and Gene, I was thinking the same thing.  The count when 
running the encoder diagnostics keeps resetting to 0.  So I will drag out my 
scope and see what I find.  Hopefully a little checking of the grounds plus a 
braking resistor and I’ll be able to rigid tap.  I’ve got a project coming up 
that involves tapping about a thousand 6-32 holes, hence this experiment.  It’d 
be a real hassle to do it by hand.  At any rate, I probably won’t get to it 
until Wednesday.

> On Jul 20, 2020, at 8:04 PM, Gene Heskett  wrote:
> 
> On Monday 20 July 2020 18:57:03 Jon Elson wrote:
> 
>> On 07/20/2020 05:27 PM, Matthew Herd wrote:
>>> Working through Jon’s suggestions, the answers to his questions are
>>> as follows.  Also, I’m running version 2.7.11 if that helps.  No
>>> internet in my shop means it gets infrequent updates.
>>> 
>>> Running the universal stepper diagnostics program with the command
>>> sudo .univstepdiags 378 bus indicates board 0 is firmware version 3.
>>> No board 1 is shown, boards 2 and 4-f are "No Board" and board 3 is
>>> "Unknown."
>>> 
>>> Running the command sudo .univstepdiags 378 indexres 3 (from a forum
>>> post) gives me +517.00, +517.00, +517.00, and a jittery
>>> +0.000/+/-1.000 that seems to increase/decrease (depending on CW/CCW
>>> rotation) then go back to zero as fast as I turn the spindle.  I can
>>> see numbers greater than 1, but they flash back to zero within a
>>> fraction of a second and keep jittering.
>> 
>> Yes, that is normal.  The position count is being reset to
>> zero each time the encoder passes the index position.
>> Turning it by hand, you might want to see it count up to
>> whatever your quadrature counts/rev is, before it resets.
>> If it keeps resetting to zero with just a little rotation,
>> then you are getting pulses on the Z channel that is
>> resetting the counter in between the index positions.  That
>> would be a hardware issue with the encoder or encoder wiring.
>> 
>>> The encoder scale on axis 03 is "setp ppmc.0.encoder.03.scale 2048"
>>> which is consistent with a 512 CPR encoder in quadrature.  That’s
>>> what I’ve got installed.
>>> 
>>> the connection to LinuxCNC looks like this:
>>> newsig spindle-index-en bit
>>> linkps motion.spindle-index-enable => spindle-index-en
>>> linksp spindle-index-en => ppmc.0.encoder.03.index-enable
>>> 
>>> AND
>>> 
>>> newsig spindle-pos float
>>> linkps ppmc.0.encoder.03.position => spindle-pos
>>> linksp spindle-pos => motion.spindle-revs
>>> 
>>> At 3600 RPM (as reported from the encoder) the velocity is 60.  At
>>> 3600 RPM CCW, the velocity is -60.  I don’t readily have a means of
>>> verifying actual RPM, but the dial on the vari-speed head seems to
>>> read lower than actual RPMs, though I understand this is consistent
>>> with a worn varispeed drive.  I also confirmed that one revolution
>>> appears to correspond to one increase/decrease of the
>>> ppmc.0.encoder.03.position as displayed by Hal Meter.  I took care
>>> to rotate it one revolution as closely as I could manage and the
>>> results checked out.
>>> 
>>> Regarding the index, I probed it with a meter and found the position
>>> at which it triggers.  I can confirm that it should work as it
>>> showed 4.64V when at the index position.
>>> 
>>> See below for my HAL files:
>>> 
>>> univstep_motion.hal:  https://paste.ubuntu.com/p/h66KJZx3hC/
>>>  univstep_io.hal: 
>>> https://paste.ubuntu.com/p/gMNkMwKDVw/
>>>  univstep_load.hal: 
>>> https://paste.ubuntu.com/p/d36HgfwZ5Z/
>>>  univstep_servo.hal: 
>>> https://paste.ubuntu.com/p/wyb6JPX7ts/
>>>  xhc-hb04.hal: 
>>> https://paste.ubuntu.com/p/w9mNn8hSdT/
>>>  pycp_panel.hal: 
>>> https://paste.ubuntu.com/p/dVNwxHWJD2/
>>> 
>>> 
>>> I realize most of these are not likely to be relevant, but I’ve
>>> included them anyway.  The encoder is connected in the
>>> univstep_motion.hal file.
>>> 
>>> Also, re-testing the behavior, I seem to get two different outcomes
>>> when I run G33.1.  First error behavior is shown here: 
>>> https://youtu.be/GMspKB5ZkoQ  and the
>>> second error behavior is shown here:  https://youtu.be/HJBOtFtXF5o
>>> .  In the first behavior (which
>>> appears to be random, but I didn’t restart axis repeatedly to test),
>>> the spindle is running before the G33.1 command.  It feeds downward
>>> past the commanded 0.5" to 0.8125 or so, then stops Z motion while
>>> it decelerates.  Then it reverses, spins up to speed, and retracts
>>> in what appears to be synchronized motion.  The second error appears
>>> to do the same until it hangs somewhere after reversing.  It also
>>> won’t respond to MDI commands.  I had to go to manual mode and click
>>> the spindle stop button to get

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


On 07/20/2020 07:04 PM, Gene Heskett wrote:


I think I'd drag out one of my 100+ MHZ scopes and look for noise of the
type one might get from lack of a single point ground.
Right.  if the indexres test of the diagnostics shows the 
position resetting multiple times/rev
(may only happen when spindle drive is on) then there is 
noise on the Z.  The A and B have digital filtering that 
only accepts valid state transitions of the quadrature wave, 
that hides a lot of really nasty garbage that some systems 
have.  There is no way to digital filter the index pulse, it 
is edge-triggered, and a 10 ns pulse could trigger it.


But, noise on the index will only affect the place where the 
spindle sync motion starts.  Once the spindle encoder senses 
an index pulse, then everything is counted from there.  So, 
a noisy index pulse should NOT cause the Z axis to behave as 
the videos show.  OHH, wait a minute!  One thing that COULD 
cause this behavior is if the move exceeded the Z soft 
limits.  Z would freeze at the most extended part, and then 
pull back when the spindle count brought the position back 
within the soft limits.  That's exactly what it did in the 
first video.


So, Matt should check what his Z soft limits are set to in 
the .ini file, and then home the axis so

it won't be exceeding the soft limits.

Having just spent about 3 weeks solving a ground loop issue 
on a PWM servo system remotely, they
can cause an amazing array of crazy symptoms.  Having the 
user shorten up all the wiring fixed it.


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

On Monday 20 July 2020 18:57:03 Jon Elson wrote:

> On 07/20/2020 05:27 PM, Matthew Herd wrote:
> > Working through Jon’s suggestions, the answers to his questions are
> > as follows.  Also, I’m running version 2.7.11 if that helps.  No
> > internet in my shop means it gets infrequent updates.
> >
> > Running the universal stepper diagnostics program with the command
> > sudo .univstepdiags 378 bus indicates board 0 is firmware version 3.
> >  No board 1 is shown, boards 2 and 4-f are "No Board" and board 3 is
> > "Unknown."
> >
> > Running the command sudo .univstepdiags 378 indexres 3 (from a forum
> > post) gives me +517.00, +517.00, +517.00, and a jittery
> > +0.000/+/-1.000 that seems to increase/decrease (depending on CW/CCW
> > rotation) then go back to zero as fast as I turn the spindle.  I can
> > see numbers greater than 1, but they flash back to zero within a
> > fraction of a second and keep jittering.
>
> Yes, that is normal.  The position count is being reset to
> zero each time the encoder passes the index position.
> Turning it by hand, you might want to see it count up to
> whatever your quadrature counts/rev is, before it resets.
> If it keeps resetting to zero with just a little rotation,
> then you are getting pulses on the Z channel that is
> resetting the counter in between the index positions.  That
> would be a hardware issue with the encoder or encoder wiring.
>
> > The encoder scale on axis 03 is "setp ppmc.0.encoder.03.scale 2048"
> > which is consistent with a 512 CPR encoder in quadrature.  That’s
> > what I’ve got installed.
> >
> > the connection to LinuxCNC looks like this:
> > newsig spindle-index-en bit
> > linkps motion.spindle-index-enable => spindle-index-en
> > linksp spindle-index-en => ppmc.0.encoder.03.index-enable
> >
> > AND
> >
> > newsig spindle-pos float
> > linkps ppmc.0.encoder.03.position => spindle-pos
> > linksp spindle-pos => motion.spindle-revs
> >
> > At 3600 RPM (as reported from the encoder) the velocity is 60.  At
> > 3600 RPM CCW, the velocity is -60.  I don’t readily have a means of
> > verifying actual RPM, but the dial on the vari-speed head seems to
> > read lower than actual RPMs, though I understand this is consistent
> > with a worn varispeed drive.  I also confirmed that one revolution
> > appears to correspond to one increase/decrease of the
> > ppmc.0.encoder.03.position as displayed by Hal Meter.  I took care
> > to rotate it one revolution as closely as I could manage and the
> > results checked out.
> >
> > Regarding the index, I probed it with a meter and found the position
> > at which it triggers.  I can confirm that it should work as it
> > showed 4.64V when at the index position.
> >
> > See below for my HAL files:
> >
> > univstep_motion.hal:  https://paste.ubuntu.com/p/h66KJZx3hC/
> >  univstep_io.hal: 
> > https://paste.ubuntu.com/p/gMNkMwKDVw/
> >  univstep_load.hal: 
> > https://paste.ubuntu.com/p/d36HgfwZ5Z/
> >  univstep_servo.hal: 
> > https://paste.ubuntu.com/p/wyb6JPX7ts/
> >  xhc-hb04.hal: 
> > https://paste.ubuntu.com/p/w9mNn8hSdT/
> >  pycp_panel.hal: 
> > https://paste.ubuntu.com/p/dVNwxHWJD2/
> > 
> >
> > I realize most of these are not likely to be relevant, but I’ve
> > included them anyway.  The encoder is connected in the
> > univstep_motion.hal file.
> >
> > Also, re-testing the behavior, I seem to get two different outcomes
> > when I run G33.1.  First error behavior is shown here: 
> > https://youtu.be/GMspKB5ZkoQ  and the
> > second error behavior is shown here:  https://youtu.be/HJBOtFtXF5o
> > .  In the first behavior (which
> > appears to be random, but I didn’t restart axis repeatedly to test),
> > the spindle is running before the G33.1 command.  It feeds downward
> > past the commanded 0.5" to 0.8125 or so, then stops Z motion while
> > it decelerates.  Then it reverses, spins up to speed, and retracts
> > in what appears to be synchronized motion.  The second error appears
> > to do the same until it hangs somewhere after reversing.  It also
> > won’t respond to MDI commands.  I had to go to manual mode and click
> > the spindle stop button to get it to respond.
>
> I have no idea what is causing this.  You might set up
> halscope to trigger on the spindle reverse command and show
> Z velocity and spindle encoder position.  The G33.1 is
> supposed to follow the encoder count until the command has
> completed.  Clearly, it follows it for a while, then stops
> following it, and then in the first video it eventually
> follows it in the reverse direction.
>
> I did not see anything wrong in your hal files.
>
> Jon

I think I'd drag out one of my 100+ MHZ scopes and look for noise of the 
type one might get from

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

On 07/20/2020 05:27 PM, Matthew Herd wrote:

Working through Jon’s suggestions, the answers to his questions are as follows.
Also, I’m running version 2.7.11 if that helps. No internet in my shop means
it gets infrequent updates.

Running the universal stepper diagnostics program with the command sudo .univstepdiags 378 bus
indicates board 0 is firmware version 3. No board 1 is shown, boards 2 and 4-f are "No
Board" and board 3 is "Unknown."

Running the command sudo .univstepdiags 378 indexres 3 (from a forum post)
gives me +517.00, +517.00, +517.00, and a jittery +0.000/+/-1.000 that seems to
increase/decrease (depending on CW/CCW rotation) then go back to zero as fast
as I turn the spindle. I can see numbers greater than 1, but they flash back
to zero within a fraction of a second and keep jittering.
Yes, that is normal. The position count is being reset to
zero each time the encoder passes the index position.
Turning it by hand, you might want to see it count up to
whatever your quadrature counts/rev is, before it resets.
If it keeps resetting to zero with just a little rotation,
then you are getting pulses on the Z channel that is
resetting the counter in between the index positions. That
would be a hardware issue with the encoder or encoder wiring.

The encoder scale on axis 03 is "setp ppmc.0.encoder.03.scale 2048" which is
consistent with a 512 CPR encoder in quadrature. That’s what I’ve got installed.

the connection to LinuxCNC looks like this:
newsig spindle-index-en bit
linkps motion.spindle-index-enable => spindle-index-en
linksp spindle-index-en => ppmc.0.encoder.03.index-enable

AND

newsig spindle-pos float
linkps ppmc.0.encoder.03.position => spindle-pos
linksp spindle-pos => motion.spindle-revs

At 3600 RPM (as reported from the encoder) the velocity is 60. At 3600 RPM
CCW, the velocity is -60. I don’t readily have a means of verifying actual
RPM, but the dial on the vari-speed head seems to read lower than actual RPMs,
though I understand this is consistent with a worn varispeed drive. I also
confirmed that one revolution appears to correspond to one increase/decrease of
the ppmc.0.encoder.03.position as displayed by Hal Meter. I took care to
rotate it one revolution as closely as I could manage and the results checked
out.

Regarding the index, I probed it with a meter and found the position at which
it triggers. I can confirm that it should work as it showed 4.64V when at the
index position.

See below for my HAL files:

univstep_motion.hal: https://paste.ubuntu.com/p/h66KJZx3hC/

univstep_io.hal: https://paste.ubuntu.com/p/gMNkMwKDVw/

univstep_load.hal: https://paste.ubuntu.com/p/d36HgfwZ5Z/

univstep_servo.hal: https://paste.ubuntu.com/p/wyb6JPX7ts/

xhc-hb04.hal: https://paste.ubuntu.com/p/w9mNn8hSdT/

pycp_panel.hal: https://paste.ubuntu.com/p/dVNwxHWJD2/

I realize most of these are not likely to be relevant, but I’ve included them
anyway. The encoder is connected in the univstep_motion.hal file.

Also, re-testing the behavior, I seem to get two different outcomes when I run G33.1. First
error behavior is shown here: https://youtu.be/GMspKB5ZkoQ
and the second error behavior is shown here: https://youtu.be/HJBOtFtXF5o
. In the first behavior (which appears to be random, but I
didn’t restart axis repeatedly to test), the spindle is running before the G33.1 command. It
feeds downward past the commanded 0.5" to 0.8125 or so, then stops Z motion while it
decelerates. Then it reverses, spins up to speed, and retracts in what appears to be
synchronized motion. The second error appears to do the same until it hangs somewhere after
reversing. It also won’t respond to MDI commands. I had to go to manual mode and click the
spindle stop button to get it to respond.

I have no idea what is causing this. You might set up
halscope to trigger on the spindle reverse command and show
Z velocity and spindle encoder position. The G33.1 is
supposed to follow the encoder count until the command has
completed. Clearly, it follows it for a while, then stops
following it, and then in the first video it eventually
follows it in the reverse direction.

I did not see anything wrong in your hal files.

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

Working through Jon’s suggestions, the answers to his questions are as follows. 
 Also, I’m running version 2.7.11 if that helps.  No internet in my shop means 
it gets infrequent updates.  

Running the universal stepper diagnostics program with the command sudo 
.univstepdiags 378 bus indicates board 0 is firmware version 3.  No board 1 is 
shown, boards 2 and 4-f are "No Board" and board 3 is "Unknown."

Running the command sudo .univstepdiags 378 indexres 3 (from a forum post) 
gives me +517.00, +517.00, +517.00, and a jittery +0.000/+/-1.000 that seems to 
increase/decrease (depending on CW/CCW rotation) then go back to zero as fast 
as I turn the spindle.  I can see numbers greater than 1, but they flash back 
to zero within a fraction of a second and keep jittering.

The encoder scale on axis 03 is "setp ppmc.0.encoder.03.scale 2048" which is 
consistent with a 512 CPR encoder in quadrature.  That’s what I’ve got 
installed.

the connection to LinuxCNC looks like this:
newsig spindle-index-en bit
linkps motion.spindle-index-enable => spindle-index-en
linksp spindle-index-en => ppmc.0.encoder.03.index-enable

AND

newsig spindle-pos float
linkps ppmc.0.encoder.03.position => spindle-pos
linksp spindle-pos => motion.spindle-revs

At 3600 RPM (as reported from the encoder) the velocity is 60.  At 3600 RPM 
CCW, the velocity is -60.  I don’t readily have a means of verifying actual 
RPM, but the dial on the vari-speed head seems to read lower than actual RPMs, 
though I understand this is consistent with a worn varispeed drive.  I also 
confirmed that one revolution appears to correspond to one increase/decrease of 
the ppmc.0.encoder.03.position as displayed by Hal Meter.  I took care to 
rotate it one revolution as closely as I could manage and the results checked 
out.

Regarding the index, I probed it with a meter and found the position at which 
it triggers.  I can confirm that it should work as it showed 4.64V when at the 
index position.

See below for my HAL files:

univstep_motion.hal:  https://paste.ubuntu.com/p/h66KJZx3hC/ 

univstep_io.hal:  https://paste.ubuntu.com/p/gMNkMwKDVw/ 

univstep_load.hal:  https://paste.ubuntu.com/p/d36HgfwZ5Z/ 

univstep_servo.hal:  https://paste.ubuntu.com/p/wyb6JPX7ts/ 

xhc-hb04.hal:  https://paste.ubuntu.com/p/w9mNn8hSdT/ 

pycp_panel.hal:  https://paste.ubuntu.com/p/dVNwxHWJD2/ 

I realize most of these are not likely to be relevant, but I’ve included them 
anyway.  The encoder is connected in the univstep_motion.hal file.

Also, re-testing the behavior, I seem to get two different outcomes when I run 
G33.1.  First error behavior is shown here:  https://youtu.be/GMspKB5ZkoQ 
 and the second error behavior is shown here:  
https://youtu.be/HJBOtFtXF5o .  In the first 
behavior (which appears to be random, but I didn’t restart axis repeatedly to 
test), the spindle is running before the G33.1 command.  It feeds downward past 
the commanded 0.5" to 0.8125 or so, then stops Z motion while it decelerates.  
Then it reverses, spins up to speed, and retracts in what appears to be 
synchronized motion.  The second error appears to do the same until it hangs 
somewhere after reversing.  It also won’t respond to MDI commands.  I had to go 
to manual mode and click the spindle stop button to get it to respond.

Thanks!
Matt

> On Jul 20, 2020, at 12:47 PM, Jon Elson  wrote:
> 
> On 07/20/2020 10:51 AM, Matthew Herd wrote:
>> Hi Andy,
>> 
>> "But does it also count negative in reverse?"
>> Yes, counts go up and down, depending on the direction I turn the spindle, 
>> either manually or under power.
>> 
>> 
> Hmmm, the mystery deepens!  Well, it may be that the encoder index-enable 
> connection in hal is not set up correctly.  Although, it seems that in that 
> case it would never begin the Z move.
> 
> 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

On Monday 20 July 2020 15:28:22 Jon Elson wrote:

> On 07/20/2020 01:59 PM, Gene Heskett wrote:
> > Jon's (Pico Systems) pwm-servo is a full 4 quadrant controller,
> > without a brakiing R, it will charge the caps in the supply from 125
> > to about 160 but turns my 1 hp PMDC motor on my GO704 around in
> > about 400 milliseconds.  If your supply is higher than mine, and it
> > probably is, talk to Jon about the higher voltage.
>
> But, he's running an AC motor.

With a vfd? That might need some programming mods in the vfd to slow the 
speed slew, but on my lathe, the max rigid tap revs is under 300, and it 
took a limit3 to slow it so it didn't trip the vfd which is cheap and 
brakeless.  I get about 3 turns of a 40 lb chuck after motion has issued 
the reverse at the bottom of the hole. 200 revs is correspondingly less 
overshoot of coarse.  Put it in backgear and the motors armature inertia 
is even worse at the higher spin speed.  Its not a vfd rated motor.

> 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

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


On 07/20/2020 01:59 PM, Gene Heskett wrote:

Jon's (Pico Systems) pwm-servo is a full 4 quadrant controller, without a
brakiing R, it will charge the caps in the supply from 125 to about 160
but turns my 1 hp PMDC motor on my GO704 around in about 400
milliseconds.  If your supply is higher than mine, and it probably is,
talk to Jon about the higher voltage.


But, he's running an AC motor.

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

On Monday 20 July 2020 10:57:30 Matthew Herd wrote:

> Thanks for the input Jon, Andy, and Scott.  Unfortunately, it already
> counts positive in the clockwise direction, so that’s not it.  I’ll go
> through Jon’s list of suggestions step by step when I get back to the
> machine in a few days and let you know how it goes.  I also realized
> that a spindle braking resistor will be necessary because the G33.1
> motion doesn’t engage the mechanical brake on deceleration.  That was
> something I hadn’t accounted for, but I have one on order now.
>
> Matt
>
Jon's (Pico Systems) pwm-servo is a full 4 quadrant controller, without a 
brakiing R, it will charge the caps in the supply from 125 to about 160 
but turns my 1 hp PMDC motor on my GO704 around in about 400  
milliseconds.  If your supply is higher than mine, and it probably is, 
talk to Jon about the higher voltage.
> ___
> 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] found a harmonic drive set of .stl's on thingiverse

On Monday 20 July 2020 10:08:16 Martin Dobbins wrote:

> >The zip contains a .step file. What does linux use to render/view
> > that? That file does contain the bearing part numbers, so that
> > helps, if my print is rendering the correct size.
>
> Freecad will open .step files.
>
> Martin
>
Means I have to cmake it. git is cloning the current src.

Thanks Martin.

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

I am using the vari-speed head, so I’m already in the high range and running at 
minimum speed.  Unfortunately I can’t tune the VFD ramp down to be optimum for 
low speed because at high speed it overloads (due to the increased inertia).  
And so far as I know my Hitachi VFD can only ramp down in a fixed time period.  
Thanks though!

> On Jul 20, 2020, at 2:39 PM, Scott Harwell via Emc-users 
>  wrote:
> 
> Do you have a 2 speed gear box? If so try tapping in high range with lower 
> spindle (motor) speed. This will give you a much better ramp. 
> 
> Scott
> 
>On Monday, July 20, 2020, 10:00:14 AM CDT, Matthew Herd 
>  wrote:  
> 
> Thanks for the input Jon, Andy, and Scott.  Unfortunately, it already counts 
> positive in the clockwise direction, so that’s not it.  I’ll go through Jon’s 
> list of suggestions step by step when I get back to the machine in a few days 
> and let you know how it goes.  I also realized that a spindle braking 
> resistor will be necessary because the G33.1 motion doesn’t engage the 
> mechanical brake on deceleration.  That was something I hadn’t accounted for, 
> but I have one on order now.
> 
> Matt
> 
> ___
> 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-20 Thread Scott Harwell via Emc-users

 Do you have a 2 speed gear box? If so try tapping in high range with lower 
spindle (motor) speed. This will give you a much better ramp. 

Scott

On Monday, July 20, 2020, 10:00:14 AM CDT, Matthew Herd 
 wrote:  
 
 Thanks for the input Jon, Andy, and Scott.  Unfortunately, it already counts 
positive in the clockwise direction, so that’s not it.  I’ll go through Jon’s 
list of suggestions step by step when I get back to the machine in a few days 
and let you know how it goes.  I also realized that a spindle braking resistor 
will be necessary because the G33.1 motion doesn’t engage the mechanical brake 
on deceleration.  That was something I hadn’t accounted for, but I have one on 
order now.

Matt

___
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


On 07/20/2020 10:51 AM, Matthew Herd wrote:

Hi Andy,

"But does it also count negative in reverse?"
Yes, counts go up and down, depending on the direction I turn the spindle, 
either manually or under power.


Hmmm, the mystery deepens!  Well, it may be that the encoder 
index-enable connection in hal is not set up correctly.  
Although, it seems that in that case it would never begin 
the 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

On Mon, 20 Jul 2020 at 17:07, Matthew Herd  wrote:
>
> It appears to increment/decrement by exactly 1 for each revolution, but I 
> didn’t put a degree wheel on the spindle to be sure of my rotation 
> measurement.

If it is close to 1, then it probably is 1.

I think we need to see your HAL file. https://paste.ubuntu.com is a
handy place to put a plain text file.

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

It appears to increment/decrement by exactly 1 for each revolution, but I 
didn’t put a degree wheel on the spindle to be sure of my rotation measurement.

> On Jul 20, 2020, at 11:58 AM, andy pugh  wrote:
> 
> On Mon, 20 Jul 2020 at 16:53, Matthew Herd  wrote:
> 
>> "But does it also count negative in reverse?"
>> Yes, counts go up and down, depending on the direction I turn the spindle, 
>> either manually or under power.
> 
> And motion.spindle-revs goes up or down by exactly 1.0 for each revolution?
> 
> -- 
> 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] Problem with Rigid Tapping on USC Equipped Bridgeport

On Mon, 20 Jul 2020 at 16:53, Matthew Herd  wrote:

> "But does it also count negative in reverse?"
> Yes, counts go up and down, depending on the direction I turn the spindle, 
> either manually or under power.

And motion.spindle-revs goes up or down by exactly 1.0 for each revolution?

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

Hi Andy,

"But does it also count negative in reverse?"
Yes, counts go up and down, depending on the direction I turn the spindle, 
either manually or under power.

Matt

___
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

On Mon, 20 Jul 2020 at 16:00, Matthew Herd  wrote:
>
> Thanks for the input Jon, Andy, and Scott.  Unfortunately, it already counts 
> positive in the clockwise direction, so that’s not it.

But does it also count negative in reverse?

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

Thanks for the input Jon, Andy, and Scott.  Unfortunately, it already counts 
positive in the clockwise direction, so that’s not it.  I’ll go through Jon’s 
list of suggestions step by step when I get back to the machine in a few days 
and let you know how it goes.  I also realized that a spindle braking resistor 
will be necessary because the G33.1 motion doesn’t engage the mechanical brake 
on deceleration.  That was something I hadn’t accounted for, but I have one on 
order now.

Matt

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

Re: [Emc-users] found a harmonic drive set of .stl's on thingiverse

2020-07-20 Thread Martin Dobbins

>The zip contains a .step file. What does linux use to render/view that?
>That file does contain the bearing part numbers, so that helps, if my
>print is rendering the correct size.

Freecad will open .step files.

Martin




___
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] found a harmonic drive set of .stl's on thingiverse

On Mon, 20 Jul 2020 at 12:20, Gene Heskett  wrote:

> > Layer-by-layer lets you see that. Most Thingiverse files suggest a
> > print direction and support options.
>
> An option I haven't found yet because the instant you do anything to the
> preview, it erases it presumably because the gcode is invalidated.

Prepare in the Prepare tab, then slice, then switch to preview and you
should see what will be printed.
The sliders in the right of the screen control the top and bottom
layers that are rendered.

> And cura's ability to monitor seems limited to tracking the two temps,
> everything else is blanked.

If you set it up right it will display a web-cam image there.
(Probably only with Octoprint with the Ender3)

-- 
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] found a harmonic drive set of .stl's on thingiverse

On Mon, 20 Jul 2020 at 10:40, Gene Heskett  wrote:

> Am I supposed to be able to write the cura output gcode file to the
> printers u-sd card while its printing a differennt file?

I wouldn't expect so.



-- 
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] found a harmonic drive set of .stl's on thingiverse

On Monday 20 July 2020 07:04:21 andy pugh wrote:

> On Mon, 20 Jul 2020 at 11:50, Gene Heskett  
wrote:
> > > Those two inspection points are before the STL is created and
> > > after it has been used. (the Cura preview is a G-code preview)
> >
> > I've never seen video on the preview tab.
>
> I have no idea what you mean.
>
> What I mean is, in the preview tab, move the sliders so that you see a
> single layer, then zoom right in and see what the tooth shape looks
> like.
>
> > For some reason these stl files are all stood on edge.  But face
> > down puts the drive hub up in the air, so I've no clue what cura
> > will do for support structure.  Need an xray view of preview.
>
> Layer-by-layer lets you see that. Most Thingiverse viles suggest a
> print direction and support options.

An option I haven't found yet because the instant you do anything to the 
preview, it erases it presumably because the gcode is invalidated.

And cura's ability to monitor seems limited to tracking the two temps, 
everything else is blanked.

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] found a harmonic drive set of .stl's on thingiverse

On Mon, 20 Jul 2020 at 11:50, Gene Heskett  wrote:

> > Those two inspection points are before the STL is created and after it
> > has been used. (the Cura preview is a G-code preview)
>
> I've never seen video on the preview tab.

I have no idea what you mean.

What I mean is, in the preview tab, move the sliders so that you see a
single layer, then zoom right in and see what the tooth shape looks
like.

> For some reason these stl files are all stood on edge.  But face down
> puts the drive hub up in the air, so I've no clue what cura will do for
> support structure.  Need an xray view of preview.

Layer-by-layer lets you see that. Most Thingiverse viles suggest a
print direction and support options.

-- 
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] found a harmonic drive set of .stl's on thingiverse

On Monday 20 July 2020 05:49:19 andy pugh wrote:

> On Mon, 20 Jul 2020 at 10:40, Gene Heskett  
wrote:
> > Some, but at much higher resolutions than what is being laid down in
> > plastic. My point is that .stl's obtained from non-openscad src's,
> > are reproduced much more accurately. Openscad's tooth profile for an
> > XL pulley is good. Any smaller teeth dissolves into a 20% fill with
> > almost zero resemblance to the tooth you can see in cura.
>
> That doesn't make any sense. If the model looks good in OpenSCAD and
> the G-code looks good in Cura then there is no way that it can be
> OpenSCADs fault.
Doesn't make sense to me either, but thats what seems to happen.

> Those two inspection points are before the STL is created and after it
> has been used. (the Cura preview is a G-code preview)

I've never seen video on the preview tab. Until now.
I just plugged the cable in and when I started cura, it paused the 
printer and parked it, so I'm seeing if resume works from its own 
control now.  Looks like it worked. I've loaded the wave gear, and 
flipped it open face down then sliced it. 17 hrs 42 minutes render time.
For some reason these stl files are all stood on edge.  But face down 
puts the drive hub up in the air, so I've no clue what cura will do for 
support structure.  Need an xray view of preview. Maybe shoulda put bolt 
face down, supports would be on back side and more easily removable.

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] found a harmonic drive set of .stl's on thingiverse

On Mon, 20 Jul 2020 at 10:40, Gene Heskett  wrote:

> Some, but at much higher resolutions than what is being laid down in
> plastic. My point is that .stl's obtained from non-openscad src's, are
> reproduced much more accurately. Openscad's tooth profile for an XL
> pulley is good. Any smaller teeth dissolves into a 20% fill with almost
> zero resemblance to the tooth you can see in cura.

That doesn't make any sense. If the model looks good in OpenSCAD and
the G-code looks good in Cura then there is no way that it can be
OpenSCADs fault.
Those two inspection points are before the STL is created and after it
has been used. (the Cura preview is a G-code preview)

-- 
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] found a harmonic drive set of .stl's on thingiverse

On Monday 20 July 2020 04:15:59 andy pugh wrote:

> On Mon, 20 Jul 2020 at 01:01, Gene Heskett  
wrote:
> > And I can say without fear of contradiction the openscad IS the
> > problem,
>
> Or your application of OpenSCAD is at fault?
>
> Have you tried looking closely at the layer preview in Cura? Does that
> show facets?

Some, but at much higher resolutions than what is being laid down in 
plastic. My point is that .stl's obtained from non-openscad src's, are 
reproduced much more accurately. Openscad's tooth profile for an XL 
pulley is good. Any smaller teeth dissolves into a 20% fill with almost 
zero resemblance to the tooth you can see in cura. 

> You can experiment with STL resolution and slice preview in Cura while
> the printer is busy making parts.

Am I supposed to be able to write the cura output gcode file to the 
printers u-sd card while its printing a differennt file? That would be 
handy, replacing the sneakernet I'm doing now.

I have a usb cable ran, and I can see a hint of what its doing but 
nowhere near what I can see on its own screen. I've not been able to see 
a dir list from the card. I just took the first circular gear off, and 
started another copy, took around 13 hours for the first gear. Its 
stamped '015 on its top surface. As near as I can count, its a 42/1 
drive if tooth count / 2 is how you do it..

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

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

Re: [Emc-users] found a harmonic drive set of .stl's on thingiverse