Re: [Emc-users] Gecko 203v

2020-08-28 Thread Jon Elson

On 08/28/2020 12:59 PM, Dave Pape wrote:

I had a noise problem with the 203v. I solved the problem by re tapping the
4-40 ground screw in the center of the Gecko's black heat sink. The heat
sink is anodized making it non electrically conductive. My 4 Gecko's are
all mounted on one common heat sink, and after making everything grounded
the same, the noise was gone.
Ah HA!  So, the OPPOSITE of my suggestion.  But, makes a lot 
of sense, if a big chunk of aluminum is floating, but 
capacitively coupled to the transistors inside, that could 
cause problems.


Jon


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


Re: [Emc-users] Noise Problems with Pico Systems USC and Gecko 203V Stepper Drives

2020-08-27 Thread Jon Elson

On 08/27/2020 11:57 AM, Matthew Herd wrote:

This leads me to the conclusion that either the supply somehow struggles under 
load or the Geckos are introducing inordinate noise.
Geckos are known to be quite noisy.  They are sending 72 V 
square wave pulses at 20 KHz into the motor coils.  Possibly 
putting a bit of a filter on the motor wires (maybe a small 
choke of 100 uH or less on each wire) might help.  Also, 
they send strong pulses into their metal cabinet, you might 
try isolating the Gecko mounting plate from the machine 
housing.  Make VERY sure to route motor wires and power 
wires for the Gecko drives well away from all other wiring, 
and if possible have these wires cross at right angles to 
any other wiring.


Jon



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


Re: [Emc-users] Mist Coolant

2020-08-21 Thread Jon Elson

On 08/20/2020 09:59 PM, John Dammeyer wrote:



-Original Message-
From: Jon Elson [mailto:el...@pico-systems.com]
Sent: August-20-20 7:36 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Mist Coolant

On Thu, 20 Aug 2020 at 21:36, John Dammeyer
 wrote:

The mill I have has flood coolant but I've never used it.  Read about bacterial 
growth and smell.  No way to easily add an expensive

disk oil separator.  Possibly a belt oil separator into the fill hole might 
work.

Thing is the machine shop may go unused for months at a time.

I used Tri-Cool for a while, and had issues with growth and
smell. Then, I got a bottle of Encool 9 by Engineered
Lubricants, a local outfit.  I could leave the sump for
months and have no problem with growth or smell.  Really
good stuff.  So, there are good coolants out there.  This
was a flood coolant system.

Jon


http://216.119.94.70/Products/Metalworking/MetalworkingProductLine.aspx

A search turned this up.  Doesn't look like they sell retail.  I doubt to 
Canada.

Yes, that's the outfit!  I am just a happy user.  Someday, I 
will use up the bottle they GAVE me as a sample, and will 
try to buy more.  I hope they don't only sell it in 55 
gallon drums.


Jon


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


Re: [Emc-users] Mist Coolant

2020-08-20 Thread Jon Elson
On Thu, 20 Aug 2020 at 21:36, John Dammeyer 
 wrote:

The mill I have has flood coolant but I've never used it.  Read about bacterial 
growth and smell.  No way to easily add an expensive disk oil separator.  
Possibly a belt oil separator into the fill hole might work.
Thing is the machine shop may go unused for months at a time.
I used Tri-Cool for a while, and had issues with growth and 
smell. Then, I got a bottle of Encool 9 by Engineered 
Lubricants, a local outfit.  I could leave the sump for 
months and have no problem with growth or smell.  Really 
good stuff.  So, there are good coolants out there.  This 
was a flood coolant system.


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-08-18 Thread Jon Elson

On 08/18/2020 12:13 PM, jrmitchellj wrote:

Hi Scott.
I have a Yaskawa V1000 on my spindle, and have installed a encoder on the
spindle.
Would you share what settings in the V1000 to get rigid tapping working
well?  I have braking resistors installed, but don't know what variable to
change to bring them into play.


Usually, the braking resistors are handled automatically by 
the drive, when it senses the DC bus voltage rising.  You 
usually have to tell it that a braking resistor is 
available, and to use dynamic braking when needed (as 
opposed to DC injection braking).  Most of the other 
settings are for conditions like speed ramp down when the 
forward or reverse command go away.  In the case of rigid 
tapping, the analog speed command should be ramped down 
smoothly by LinuxCNC and then the forward/reverse command 
switched when the analog speed command is near zero.


Jon


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


Re: [Emc-users] p-port problems?

2020-08-10 Thread Jon Elson

On 08/10/2020 01:34 PM, mar...@r-bechtold.de wrote:

I switched to an ethernet based mesa karte

it is nearly impossible to finde a PCI or PCIe parport card that support Real 
EPP


The 8875 is REALLY old.  But, there are good PCI and PCIe 
cards that do EPP just fine.
For PCI, I prefer the SIIG cards, but a number of other ones 
also work.
For PCIe, I use the Syba PEX10005 cards with the MOSCHIP 
MCS9900 or MCS9901 chips.


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-08-05 Thread Jon Elson

On 08/04/2020 02:05 PM, Thaddeus Waldner wrote:

Do any servos or VFD systems actually run their base frequency higher than 
20khz?

If not, where do those harmonics come from?


Many servo systems run above 20 KHz to increase bandwidth.  
And, the sharp switching transitions cause there to be many 
harmonics.  Most VFDs do not run above 20 KHz to keep 
switching losses low, and the drive frequencies to the motor 
are usually lower than with a servo.


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-08-04 Thread Jon Elson

On 08/04/2020 08:00 AM, Matthew Herd wrote:


I am guessing that the source of the trouble is probably the VFD, as 80kHz 
seems like a plausible base frequency for driving an AC motor.  Only the USC 
should be operating at a frequency higher than 60Hz other than the VFD.  The 
machine uses three gecko drives and large steppers, so it’s not very 
sophisticated.
I think 80 KHz is a multiple of the frequency of the Gecko 
drives. You might try turning off the power to them and see 
if the issue changes.



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-08-02 Thread Jon Elson

On 08/01/2020 01:37 PM, Matthew Herd wrote:

Thanks Gene, I hope you’re well also.  I disconnected that grounding wire, no difference observed 
in the ppmc.0.encoder.03.index behavior.  The noise seems the same both when spindle is running and 
stopped, with a tendency strongly toward "true" than "false."  Pulses seem to 
be both long and short, but I’d guess they’re about 80-90% true.  Not at all what I’d expect, even 
with noise.


This does not make any sense at all.  The encoder.xx.index 
reports detecting a falling edge on the index (Z) input.  it 
is reset every time it is read.  Long true pulses mean it 
was triggered at least once every millisecond, ie. faster 
than the servo thread samples it.


So, the encoder.xx.index is NOT looking at the STATE of the 
Z input, but whether a high-to-low transition occurred since 
the last time it was read.


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-08-02 Thread Jon Elson

On 08/01/2020 11:10 AM, Matthew Herd wrote:

I'm still having issues with the rigid tapping.  It works sometimes and
fails other times.  After scoping the motion.spindle-revs, it appears to be
consistent with what we would expect aside from one possible issue.  The
spindle revs reset to zero upon G33.1 being called, then count up until
they stop, reverse, go negative past zero, then return to clockwise
motion.  However, on the second zero crossing (going positive) the revs go
positive, only to be reset to zero momentarily thereafter.  I'm not sure if
this is normal behavior or not.
I'm not exactly sure what you are describing here.  Most of 
it sounds normal, but I am not aware of a second cycle of 
the index sync function at the end of the G33.1   If you 
have a Halscope picture, that could be interesting to look at.

However, what isn't normal behavior is that the ppmc.0.encoder.03.index
value is loaded with noise.  Not occasional noise, but constantly
triggering in irregular intervals regardless of whether the spindle is
turning.  I'm baffled as to how this could be so noisy and was wondering
where you might look next.  Grounds look fine aside from the fact that the
control cabinet and the power cabinet have a ground wire connecting them in
addition to being grounded through the machine.  When removed from the USC
board, the index can be measured with a multimeter as the spindle is
rotated.  I forgot to bring my scope to the shop today (I didn't think I'd
need it) so I can't scope anything until tomorrow.  Is it possible there's
a pull-up resistor missing?

Well, the index is not actually used except once for each 
G33.1 operation, to start the spindle synch motion.  So, it 
is only important for multiple-pass threading.


But, note that while the A and B transitions are filtered by 
requiring a valid quadrature state transition, the index 
pulse is not.  Even a 10 ns wide dip from +5 to near ground 
will trigger the index logic.
What is the resting voltage of the index signal?  Does it 
need a pull-up resistor to +5 V?  The logic threshold is 2.5 
V.  The USC does NOT provide any pull-up resistor.  If your 
encoders need such, consult the encoder data sheet to 
determine what resistor value is best.


Jon


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


Re: [Emc-users] smoother limit3 befor PID not after

2020-07-29 Thread Jon Elson

On 07/29/2020 01:33 AM, andrew beck wrote:

Hey Jon.  I think it's all and any usbs that are write protected.  I have
tried several different usb sticks.  Like it's a system option.


Ah, in the file /etc/group, you can add users to various 
groups, to have access to certain things.
I'm not sure what group is responsible for USB access, but 
maybe plugdev?


I did find this discussion that seems to mention this exact 
issue :


https://unix.stackexchange.com/questions/403798/set-removable-media-usb-drive-permissions-to-a-specific-group

Jon


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


Re: [Emc-users] smoother limit3 befor PID not after

2020-07-28 Thread Jon Elson

On 07/28/2020 04:42 PM, andrew beck wrote:

Just a quick question fellows.  I need to send the config files to Andy.
Now my USB is Copy protected in Linux.  Don't know how it happened but how
to I disable it so I can copy to USB?


Write protect?  Some USB memory sticks have a tiny write 
protect switch on the side.
IF the USB stick has a different group/user ID on a Linux 
file system, then you could use the sudo command to change 
the owner.


if your user name on the Linux system was  "andy", and the 
usual setup has the group name same as user,

then you would do :

sudo chown andy:andy /media/x

where x is the mount point of the USB stick.
You can verify your user name and group with :

ls -al ~

The 3rd column is your group name, 4th column is the user name.

And, of course, you can see what is on a mounted USB stick 
with :


ls -al /media/x

Jon


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


Re: [Emc-users] Little gear I'm cutting. Thought it may interest people.

2020-07-24 Thread Jon Elson

On 07/24/2020 02:09 AM, andrew beck wrote:

Greg can you educate me on what what gear cutters are enough for most gear
cutting needs?  Fusion 360 has a nice gear profile generator I can use.
But I'll have to model all the cutters after that I think...  Thinking keep
them pretty simple with no helix angle or anything.  And maybe plan to cut
most of it out with a endmill straight down the middle before putting the
gear cutter through the cut


Well, the traditional horizontal mill gear cutters usually 
come in a set of 6 for each gear tooth pitch.
You use each cutter for a range of tooth counts for that 
tooth pitch.  And, there are 14.5 degree and 20 degree 
pressure angles. So, there end up being a LOT of gear 
cutters that one could possibly need.


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-23 Thread Jon Elson

On 07/23/2020 05:21 AM, Matthew Herd wrote:

I should also note I made an error in my revolutions calculation.  It should be 
RPM / 2 / 60 sec * deceleration time = revolutions to stop, assuming linear 
deceleration.  That’s probably the default for most drives.  For 560 RPM, that 
comes out to 2.8 revolutions.  So my observations at 2.9 revolutions are 
consistent with that.

Who is in charge of the integrator’s manual?  I’d like to investigate writing 
some additional sections.

You can submit suggested changes to John Thornton, or get 
commit access yourself.


Jon


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


Re: [Emc-users] Calculating table acceleration. Was: Need help with Bostomatic BD18-2 to linuxcnc

2020-07-23 Thread Jon Elson

On 07/23/2020 05:09 AM, andy pugh wrote:

On Thu, 23 Jul 2020 at 09:22, John Dammeyer  wrote:


Not ignoring you at all.  Just waiting for an idea for the math that leads to 
calculating MAX_ACCELERATION in the ini file given the parameters I've 
mentioned before.

I think that the problem is treating the motor as an ideal torque
source. It has inertia, it has inductance, it has a non-linear
current-torque graph and it has back-emf.
While the inductance is visible at PWM frequencies, for the 
size motors we are dealing with, it really has little effect 
at the frequencies and bandwidth involved in CNC motion control.


Rotational inertia, however, is a BIG issue.  The leadscrew 
can be thought of as a torsion spring, the length of the 
active spring changes as the ball nut progresses down the 
screw, and the motor angular momentum turns it all into a 
spring and mass system.  I have this issue on my Bridgeport, 
the leadscrews are too small diameter for such a massive 
system, and I get a resonance that varies between 20 - 40 Hz.


Applying a voltage to a motor leads to reduced current as 
the motor speed increases, due to the back EMF generated.  
That's why it would be good to put a resistance in the 
circuit to get more constant current if trying to test 
practical acceleration limits.  Motor torque will be quite 
linear with respect to current over a wide range of currents 
within the motor's rating envelope.


Your extensive calculations are appreciated, but without 
knowing a few key parameters it can be hard to get started.  
I have the gear here to measure inductance, but not 
everybody does.  I guess with an encoder connected to a 
motor, and a constant-current source, rotor inertia could be 
obtained.


Jon



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


Re: [Emc-users] Calculating table acceleration. Was: Need help with Bostomatic BD18-2 to linuxcnc

2020-07-23 Thread Jon Elson

On 07/23/2020 02:00 AM, John Dammeyer wrote:

Hi Tomp,

I understand the process and the step response.   One thing in the mix that we 
haven't discussed, and I really was hoping Jon Elson would chime in again, is 
exactly how much impact the servo drive has on all this.
Well, both the motor and the drive have current limits.  
Often the drive has a lower limit than the motor, so it is 
the dominant one. Current in the motor equals torque, and 
torque is proportional to linear force on the axis.  So, the 
drive (or motor) current limit absolutely sets the 
acceleration that can be achieved.
You can crank up the MAX_ACCELERATION parameter in the .ini 
file and watch the error with Halscope (on machines equipped 
with encoders) and see when the servo drive "runs out of 
juice".  Then, back off on the accel parameter by 10 - 15 % 
to account for cutting forces, and you should be at the optimum.

The application of DC voltage to a motor and then measuring up to speed brings 
up the question as to how you know the motor is up to speed.  But anyway.  
Could do it with the scope monitoring step pulses and using evenly spaced 
pulses as the up to speed indication.


Well, actually, it isn't voltage, but current, that should 
be applied to the motor.  Using a small resistance in series 
would approximate a constant current source, and give 
constant acceleration.


Jon


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


Re: [Emc-users] wondering what the status is on S curve jerk control getting added into linuxcnc

2020-07-23 Thread Jon Elson

On 07/23/2020 12:00 AM, andrew beck wrote:

Yes I'm not worried about servo following error spikes.  But I'm shaking my
whole machine to death.  As the acceleration is instantly on.  In contrast
a friend's okuma can go at 40m/min without shaking.  Which is amazing to
watch.  They are both similar size


Well, do you have encoders on this machine that read back to 
LinuxCNC?  if so, you can graph the velocity of the axes and 
see if the servo is operating with stable response, or if 
you have oscillations.  You may have the MAX_ACCELERATION 
parameter in the .ini file set too high.


Jon


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


Re: [Emc-users] Calculating table acceleration. Was: Need help with Bostomatic BD18-2 to linuxcnc

2020-07-23 Thread Jon Elson

On 07/22/2020 11:52 PM, John Dammeyer wrote:
  
But does the accel value in F=ma have to be gravity?  And if not, what then?
  

No!  G and weight in Lbs are convenient units because we 
live on earth.  They are useless anywhere else.

But, they are familiar to anyone who lives here.

mass is a constant property of matter, anywhere in the 
universe, at least as long as you stay away from 
relativistic velocities.  And, the same for acceleration.  G 
is just a unit conversion to other units.
m/s^2 is a universal unit.  So, the acceleration on a 
machine part can be measured and expressed completely 
without reference to the earth.


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-22 Thread Jon Elson

On 07/22/2020 08:51 PM, Matthew Herd wrote:


Upon testing, I found that rigid tapping worked as intended,

Excellent.  Glad Robert Ellenberg is watching here, as most 
of us had no idea the trajectory planner had this behavior.


I love rigid tapping, and have made two fixture plates with 
a 1" grid of 10-32 holes.  Also, my PWM servo amps have 12 
or 14 4-40 tapped holes in each mounting plate.  I also did 
some brackets for circuit boards that have a bunch of 2-56 
holes.  Those make me bit my lip just a little.


The neatest thing is combo drill-taps, they have a twist 
drill front end and a tap further back.
You drill through sheet material at a low feedrate, then 
back up a bit and do G33.1 to tap

the hole, all with one tool.

Jon


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


Re: [Emc-users] need a logic bit mux.

2020-07-22 Thread Jon Elson

On 07/22/2020 01:17 AM, Gene Heskett wrote:

Greetings all;

The launch of linuxcnc on the pi is without any motor power until the F2
button is pushed.  So at launch time I get messages about the z drive
being tripped.

So I need a 1 or 2 second delay before that bit is sent on thru, but
instant transmission once timed out, giving the driver a chance to get
all its stuff in one sock from the powerup enabled by the F2 key. I want
to block any noise during the powerup surge.


OK, so your drives indicate fault status when disabled?  
Yes, a lot of older drives (Copley, Westamp,
Servo Dynamics) do this.  I made up a module with an 
optocoupler, a CMOS NAND gate and
some RC delays to do this.  The servo amps usually take a 5 
V ENABLE/.  When the ENABLE/
is high, the circuit closes the E-stop loop by turning the 
optocoupler on.  When ENABLE/ goes
low, it continues to do this for about a second, then allows 
the servo amp's FAULT output to control the opto.


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 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] 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] 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 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 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 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] 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-20 Thread Jon Elson

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

2020-07-20 Thread Jon Elson

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

2020-07-20 Thread Jon Elson

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

2020-07-20 Thread Jon Elson

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

2020-07-20 Thread Jon Elson

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

2020-07-20 Thread Jon Elson

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

2020-07-19 Thread Jon Elson

On 07/19/2020 03:59 PM, Matthew Herd wrote:

Hi all,

I made my first attempt at using spindle synchronized motion for a rigid 
tapping operation on my Bridgeport BOSS mill today and it didn’t go as planned. 
 It has a spindle encoder and a Pico USC board.  I can use the spindle to read 
encoder counts and spindle position (I already use PYVCP to show me spindle 
speed).  However, G33.1 produces unusual results and doesn’t seem to work 
properly.  It appears that the down feed works properly, but the spindle either 
never reverses or reverses very slowly and the synchronized motion on retract 
doesn’t appear to reliably track the spindle motion.  In several tests, it 
either retracts while still turning clockwise, appears to retract faster than 
the counter-clockwise speed would allow, or just doesn’t retract at all.  
According to the g code reference page, motion.spindle-at-speed and 
encoder.n.phase-Z must be connected in HAL.  I don’t have spindle-at-speed 
hooked up, but am using rigid tapping sample HAL from Pico Systems, with the 
encoder connected to motion.spindle-revs.
encoder.n.phase-Z does not exist on the Pico boards.  Z 
(index) cannot be seen directly, it can only be detected by 
index-enable going from true to false, and the encoder 
position count going to zero.


Wow.  First, make sure that the value fed to scale the 
spindle encoder is correct.  It should be equal to the 
number of quadrature counts/rev of the spindle (4X the 
number of "lines" on the encoder). It should look something 
like this:

setp ppmc.0.encoder.03.scale 6912


The connection to LinuxCNC looks like this on my system :
net spindle-pos   ppmc.0.encoder.03.position   spindle.0.revs


The names might have been changed in newer versions.

You should look at ppmc.0.encoder.03.velocity with Halscope 
(or even Halmeter) to make sure this signal is properly 
registering the spindle rotation.  With the correct scaling 
factor, velocity should equal 60 at 3600 RPM (60 
revs/second) and ppmc.0.encoder.03.position should count up 
at 60 counts/second.
If the velocity shows negative when the spindle is running 
"forward" then change the arithmetic sign of the encoder 
scale to a minus number.  The velocity should show an 
opposite sign when the spindle direction is reversed, and 
the position should count in the opposite direction.  If 
not, something is quite wrong with the encoder or how it is 
connected.




I attempted to troubleshoot using this references:
https://forum.linuxcnc.org/27-driver-boards/26275-spindle-encoder-on-pico-usc 


I ran a halcmd sets on the spindle index enable and it reset counts to zero 
immediately.  spindle index enable remained false and fiddling with halscope 
wasn’t ever successful in showing a change from false to true while playing 
with G33 commands, etc.  I’m not sure what to try next.


the correct connection is :
net spindle-index-enppmc.0.encoder.03.index-enable 
spindle.0.index-enable


All of the above examples assume USC channel # 3 is used for 
the spindle, if different change the .03. to

whatever is needed.

The spindle index is only enabled once at the beginning of 
the spindle synchronized move.
I think the trajectory planner sets it true, and when the 
PPMC hardware detects a rising edge on the index input, it 
clears index-enable, and zeroes the position count.  So, one 
part of the system sets this bit true, and the ppmc driver 
sets it false.


In general, if the index is not working, LinuxCNC should 
hang forever waiting for index-enable to go false.  But, 
maybe if it is not hooked up at all, the behavior is different.


Jon

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


Re: [Emc-users] Retrofit Candidate?

2020-07-18 Thread Jon Elson

On 07/18/2020 06:08 PM, Bari wrote:

On 7/18/20 5:56 PM, Jon Elson wrote:




It would be hard to do anything like this with a Delta 
scheme, as the errors stack up.




Why I asked.

Well, the Quad IV C has a gantry with 1 um glass scales on 
it, apparently.  The Quad QSA-30
has shaft encoders with high resolution, I don't know what 
the resolution is, but I'm guessing it works out to
better than 25 um, for sure.  And, there is no angle to 
linear conversion required.  These machines have very 
limited Z movement, but a LOT of X-Y movement, somewhere 
around a meter or more, to reach all the feeders.  Also, the 
machine moves a head that must weigh 20 kg, at least, at 
several m/s, back and forth, from feeders to the board being 
stuffed.  It has to provide placement accuracy of better 
than 0.1mm over this entire range of motion.


I just don't see how a delta machine could do this, without 
it being incredibly large.  I just can't imagine a delta 
machine that can cover a 1 x 1 meter area, and do it rapidly 
with a heavy head and great precision.


Jon


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


Re: [Emc-users] Retrofit Candidate?

2020-07-18 Thread Jon Elson

On 07/18/2020 04:06 PM, Bari wrote:

On 7/16/20 9:45 AM, Jon Elson wrote:





An auction of electronic assembly gear just closed in 
Austin, TX yesterday.  I got a VERY nice pick and place 
machine for $500, the starting bid.  Only one other 
machine sold.  I was amazed!



Have you come across any delta robots used for PCB 
assembly on your auction searches?
The commercial machines are all XY gantry systems, and of 
massively heavy construction.
This Quad QSA-30A weighs 2250 Lbs and the maker somewhat 
optimistically rates it at 17000
components/hour.  It is supposed to place components with a 
3 Sigma repeatability of 0.1 mm.
The vision system is mounted on the head and measures the 
alignment of the parts on the three nozzles while the head 
moves over the board.


It would be hard to do anything like this with a Delta 
scheme, as the errors stack up.


Jon


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


Re: [Emc-users] another vmc project

2020-07-16 Thread Jon Elson

On 07/16/2020 10:11 AM, lloyd wilson wrote:
I've recently acquired another controller transplant 
candidate, a mid/late 80s Bridgeport 520 vmc. The old 
girl  uses Fanuc DC (yellow cap) axis servos and drives, 
spindle is also Fanuc. I hope to keep the Fanuc servo 
drives, but so far, I haven't been able to locate any 
documents that spec the interface signals for the drives 
(A06B-6047-H*, specifically). Can anyone point me towards 
the relevant documentation?
The way Fanuc did things, they had a chip in the controller 
that created a synthetic DC tachometer signal that was then 
fed back to the servo amps for velocity reference.  This 
chip (the ST micro L290) has been unavailable for decades.  
It could be done today with an FPGA and a little analog 
circuitry.  Some yellow cap motors actually have a DC tach 
in them, you can look and see,


if it is late 80's, the servo amps are almost certainly 
analog velocity servos.  You need some kind of enable 
signal, tach feedback and an analog velocity command 
signal.  And, the amps will provide some kind of fault signal.


Jon


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


Re: [Emc-users] Retrofit Candidate?

2020-07-16 Thread Jon Elson

On 07/16/2020 07:19 AM, Todd Zuercher wrote:

No it doesn't' have a Fanuc control, it is a Yaznac with all Yaskawa drives and 
motors.


Excellent!  Yaskawa makes documentation on older products 
available.  There's a good chance it uses analog velocity 
commands (+/- 10 V).  If so, all the drives could be re-used.


Jon


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


Re: [Emc-users] Retrofit Candidate?

2020-07-16 Thread Jon Elson

On 07/16/2020 12:39 AM, Bari wrote:



The pandemic has killed lots of businesses. 1 out of 4 
businesses near me are closing for good. I expect to see 
deals for the next year at least on just about everything.


An auction of electronic assembly gear just closed in 
Austin, TX yesterday.  I got a VERY nice pick and place 
machine for $500, the starting bid.  Only one other machine 
sold.  I was amazed!


Jon


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


Re: [Emc-users] Retrofit Candidate?

2020-07-16 Thread Jon Elson

On 07/15/2020 11:32 PM, Thaddeus Waldner wrote:

Some of those large, high-end Japanese names have temperature sensors installed 
throughout the frame, which they use to compensate for thermal expansion.


I doubt this machine has that, but it does look like it has 
a spindle cooler hanging on the back.


Jon


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


Re: [Emc-users] Retrofit Candidate?

2020-07-15 Thread Jon Elson

On 07/15/2020 09:03 PM, Stuart Stevenson wrote:

Looks like a Yasnac control. I zoomed in on the MPG. It is labeled Yasnac.


Ahh, more complicated than I thought.  Some models had 
Fanuc, but I did not recognize that control panel.
I don't know Yasnac, but they may be less proprietary than 
Fanuc, which are pretty legendary in that regard.  It might 
be easier to re-use the servo amps and spindle drive, then.


Jon


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


Re: [Emc-users] Retrofit Candidate?

2020-07-15 Thread Jon Elson

On 07/15/2020 08:51 PM, John Dammeyer wrote:

For that price, rip out the guts and replace the works with COTS units.  You 
end up with single phase.  Possibly only a 3HP spindle but do you need a bigger 
one?  The Chinese AC Servos appear to be pretty good.  Even the squeal problem 
from my spindle 1.8kW motor was a parameter error.  Quickly solved.


That's a SERIOUSLY large machine!  Various units may have 
different spindle motors, but at least one was 10 Hp.  
Probably several HP axis motors.  Note the nameplate shows a 
29 KVA load!


Jon




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


Re: [Emc-users] New Spindle working.

2020-07-15 Thread Jon Elson

On 07/15/2020 07:40 PM, John Dammeyer wrote:

After 3 decades of working with Turbo Pascal and then Delphi, Tcl/Python to me 
is such a step backwards it's painful to use.
Yes, I'm with you.  I wrote some big programs in Pascal a 
LONG time ago.  The biggest one was a Gerber file to raster 
converter program.  Recently, I took that old source and 
recompiled it under FPC (Free Pascal Compiler) and got it 
running in very short order.


My experience with Pascal was that once I got the program to 
compile without errors (minor syntax and variable name 
errors) they generally worked first time, or at least came 
very close.


About 15 years ago I wrote several large GUIs to control 
data acquisition systems, using Tcl/Tk for the screen 
interface and C for the back end hardware control and 
database of settings.  The C part was very complex but 
pretty straightforward.  The Tcl part was close to a 
nightmare, due to all the quirks in Tcl.


I have recently created a few smaller GUIs with an initial 
structure set up with Glade, interfaced to a back end in C.  
Once the initial xml is set up with Glade, I then go in and 
hand-edit all the special interface options, as Glade 
doesn't seem able to go in and modify an xml file once it is 
built.  But, the xml is a much saner way to just build a GUI 
than with Tcl.


Jon


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


Re: [Emc-users] Retrofit Candidate?

2020-07-15 Thread Jon Elson

On 07/15/2020 03:08 PM, Todd Zuercher wrote:

Would this machine look like a good candidate for a Linuxcnc retrofit?
https://hgrinc.com/productDetail/CNC/Used-Mori-Seiki-Mori-Seiki-Mv4540-CNC-VMC/0120091/
Anyone familiar with these, are there a good reasons not to buy it? (Or good 
reasons to buy it?)
Is this a good price? I don't see a year, but guessing it's from the late 1980s.


Well, it has a Fanuc control.  The servo amps are pretty 
proprietary, although Mesa may have a way to interface with 
them. Pico Systems (that's me) can convert the Fanuc serial 
encoders to look like
ordinary quadrature encoders with commutation.  Assuming it 
has Fanuc red cap motors, they are very good.  The tool 
changer is always the most difficult part.  Also, if the 
tool changer is hydraulic, that can be a nightmare, as well 
as power-hungry and noisy.


Jon


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


Re: [Emc-users] off topic: pwm with a stepper driver/motor

2020-07-14 Thread Jon Elson

On 07/14/2020 01:51 PM, andy pugh wrote:

On Fri, 10 Jul 2020 at 10:34, andy pugh  wrote:


I don't see why there is any limit to the possible reduction of a belt
drive, if idlers are added to increase the wrap.

And here is an example:

https://youtu.be/7zBrbdU_y0s

OH MY!  Some people REALLY have too much time on their 
hands!  Did anyone tell this guy that scissors are made to 
be held in a person's hands?  Two fingers do the snip snip 
just fine.


Jon


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


Re: [Emc-users] off topic: pwm with a stepper driver/motor

2020-07-14 Thread Jon Elson

On 07/14/2020 04:49 AM, Chris Albertson wrote:

But what I wanted to add is that when you read the speed vs. torque curve
it is for FULL steps.  The amount of holding torque is reduced with
microsteps.   It makes sense too, full steps use full current that is
switched between coils just 100% on or 100% off.   With microsteps one
coild gets perhaps 3/8 of full current and the other gets something like
5/8.  So the current is overall reduced.

Well, this is only partially true.  It is a rare case where 
the actual standstill holding torque is exceeded by the 
load.  Most often, the motor is stalled while moving.  The 
running torque of a stepper is less (sometimes MUCH less) 
than the holding torque, and resonances really hurt the 
running torque.  A microstepping drive reduces the 
resonances, and smart microstepping like Gecko uses adds 
active damping to absorb the resonant energy.  These systems 
will have much higher running torque than a full-step drive.


Jon


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


Re: [Emc-users] More cbn headaches

2020-07-08 Thread Jon Elson

On 07/08/2020 08:03 PM, Gene Heskett wrote:


Absolutely Jon. But to do it right requires a machine with little or no
backlash so it can't pull the work.

Or else, you always did a climb mill finish pass with a very 
shallow cut.  That's what I did on my ancient Bridgeport 
before I did the CNC conversion.  You could get away with it 
like that.


Jon


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


Re: [Emc-users] More cbn headaches

2020-07-08 Thread Jon Elson

On 07/08/2020 04:01 PM, Gene Heskett wrote:


Its the next edge coming round to do another cut, which has to cut thru
the oxide that forms on the raw alu after the previous edge clears the
scene.


And, that's why climb milling works so much better that 
conventional milling.  With conventional,
the cutting edge rides up on the shallow slope until enough 
pressure develops to break through.
With climb milling, the cutting edge punches immediately 
through the full depth of the cut, never sliding.

The difference in cutter life is quite amazing.

Jon


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


Re: [Emc-users] Jerky jog in new 2.8 and 2.9 but not old 2.8 (onscreen buttons + mouse OK but not keyboard)

2020-07-07 Thread Jon Elson

On 07/06/2020 07:05 PM, Leonardo Marsaglia wrote:

One thing I find my wireless keyboard does sometimes is that a key can get
"sticky wirelessly". Mostly when I'm typing I sometimes get a ""
until It suddenly stops. I'm mostly using the keyboard for signing in and
modify the tool table etc, but since I'm using axis I sometimes think it
would be a good idea to deactivate the keyboard from axis to avoid
uncontrolled motion.


PC keyboards have key-up and key-down messages.  if a key-up 
message is lost by the wireless link, that will do what you 
have seen.  in a high-electrical-noise environment like a 
CNC machine, wireless keyboards and mice could be a problem.


Jon


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


Re: [Emc-users] PCIe vs Ethernet Mesa card?

2020-07-06 Thread Jon Elson

On 07/06/2020 05:47 PM, John Dammeyer wrote:

It's not a big deal.  Whacks me across the head if I rush starting AXIS.  
There's always something to do as the system is brought to life.  Like sweep up 
shavings or add oil to the spindle lube cups on the lathe.  Put tools away.  
Clean rust film that started showing up this year after 10 years of no rust.


Connmanctl is a really neat thing for portable computers.  
It scans the net traffic and figures out that "Oh, looks 
like he's at Ohare airport, I'll hook him up to the WiFi 
thare".  But, in a static environment, it sometimes is too 
smart for your totally "set it once, and forever" settings.


Jon


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


Re: [Emc-users] PCIe vs Ethernet Mesa card?

2020-07-06 Thread Jon Elson

On 07/06/2020 03:51 PM, John Dammeyer wrote:

From: andy pugh [mailto:bodge...@gmail.com]
On Mon, 6 Jul 2020 at 21:22, Chris Albertson  wrote:

Is there any advantage to using a bus connected Mesa card like the 6i25 vs
using one of the Ethernet-connected cards such as 7i92M or 7i93

PCI might be more reliable. Not so much during runs, but at startup.
It is quite easy to imagine something changing the network setup of
your machine, and finding that you just can't get it to run.

No experience with the PCI cards but what I have noticed with my 7i92H is that 
after I boot and sign on into Linux it's important that I go and do something 
else for a few minutes.   Then come back and click on the icon that runs the 
actual LinuxCNC Axis program that uses the HAL file for the 7i92H.

Seems otherwise the Ethernet connection to the 7i92H can't be found for the 
first few minutes.

There may well be some parameter that can be set so the 7i92H Ethernet 
connection happens faster.


This may be due to connmanctl trying to figure out what 
network is running on the port that is connected to the Mesa 
board.  There may be a way to tell connmanctl to not touch 
that port.


Jon


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


Re: [Emc-users] More cbn headaches

2020-07-05 Thread Jon Elson

On 07/05/2020 08:55 PM, Gregg Eshelman via Emc-users wrote:
That was my clue that I was never going to light a smith 
wrench anywhere near mag.
If you've ever seen a magnesium engine or transmission case 
burn, it is quite a show.
And, when the fire department doesn't have foam in their 
truck, the only thing they have is water.
LOTS of water will put out burning magnesium, but will cause 
a white-hot explosion at first, the firemen have to have the 
high temperature suits to get away with it.


I've seen a VW microbus go up, and they only had one tiny 
foam can. The foam knocked it down for a few seconds quite 
nicely, but then when they hit it with water it looked like 
a 4th of July display gone wrong!


Jon


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


Re: [Emc-users] More cbn headaches

2020-07-04 Thread Jon Elson

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


IIRC no sparks, 200 or so revs, could just barely hear it touching,
peeled two strips down to the alu about 1/4" wide. Not at all impressed.
Up to that point, I was watching a very thin cloud of steel dust
drifting away in the work light and figured it would get to where it
should be in about half an hour.  I wound up doing it on the bench
grinder with a glass of water to keep from burning my fingers.


Unless you are whetting the edge on a scalpel, no need to 
use diamond to shape a lathe tool.


A coarse alumina wheel will do a fine job.

Jon


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


Re: [Emc-users] More cbn headaches

2020-07-04 Thread Jon Elson

On 07/04/2020 04:23 PM, andy pugh wrote:

On Sat, 4 Jul 2020 at 22:08, Eric Keller  wrote:


Steel bonds to diamond, and then you are cutting with steel.

My understanding of the problem was that it is due to carbon being
soluble in steel. And diamonds are just expensive carbon.

This is likely to be much more of a problem with single-point turning
than with grinding, however,
Yes, but you have to get the diamond hot for the iron to be 
able to dissolve into it.
Since the wheel has a bit of time to cool off as it turns 
around, the diamond is always
cooler than the thing you are grinding.  Either 
water-cooling the diamond or just keeping the surface speed 
down will allow the diamond to last a long time.  Of course, 
that also slows the cutting rate.


Jon


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


Re: [Emc-users] More cbn headaches

2020-07-04 Thread Jon Elson

On 07/04/2020 12:54 PM, andy pugh wrote:

On Sat, 4 Jul 2020 at 18:02, Gene Heskett  wrote:


Attacking HSS with diamond is a waste of time and burns up the expen$ive
diamond.

Whilst it is meant to be a terrible idea, in practice it works OK.
I think it depends on surface speed.  If the speed is high 
enough that the sparks are totally white-hot, it will alloy 
with the diamond.  At lower speeds, especially where the 
sparks are barely glowing, it doesn't seem to hurt the 
diamond at all.


Jon


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


Re: [Emc-users] More BS-1 clone headaches.-

2020-07-04 Thread Jon Elson

On 07/03/2020 08:50 PM, Gene Heskett wrote:


If you can get it truly lox clean. Or you can find one marked "permanent"
which has solvents that can penetrate the lube film.


Sharpies have, I believe MEK in them, and so will leave a 
good mark on surfaces with a trace of oil.
Won't work on cast iron due to the porosity making it almost 
impossible to get all the oil off, but should work quite 
well on machined steel parts.


Jon


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


Re: [Emc-users] More BS-1 clone headaches.-

2020-07-03 Thread Jon Elson

On 07/03/2020 07:23 PM, Gene Heskett wrote:
I thought of that, but I don't know where I could src some 
of that locally. Is "diechem blue" the right search term 
to feed google?? Thanks Andy Cheers, Gene Heskett 

If it is cleaned of oil, you can use a magic marker or Sharpie.
DyKem is a layout fluid that dries to put a very thin blue 
layer on a material to be marked with a scribe.
There is also hi-spot blue, which gives a non-drying film 
that is easily rubbed off.  But, it dyes skin and clothing 
pretty badly. Also known as Prussian Blue artist's oil 
pigment.  Either of these should work for the purpose.


Jon


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


Re: [Emc-users] SSD reliability

2020-07-03 Thread Jon Elson

On 07/03/2020 11:01 AM, Sam Sokolik wrote:

I can't remember ever having an issue with any ssd I have used.  My laptop
which currently has a Samsung SSD 860 EVO M.2 1TB

Power_On_Hours = 11845



My desktop SSD reports 57388 power-on hours.

Jon


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


Re: [Emc-users] SSD reliability

2020-07-03 Thread Jon Elson

On 07/03/2020 12:03 AM, linden wrote:

Hello All,

Any one here have real world experience with 
reliability of Solid State Drives.


I have been using SSDs in several systems.  I have a travel 
laptop that has a small one, Ubuntu 14.04, I think.  It gets 
relatively light use.


My main desktop has a 120 GB SSD that was initialized in 
Dec. 2016 and has gotten quite a bit of use,
web browsing, email, electronic design, tax programs, and on 
and on.  I have a spinning hard drive there for backup every 
couple days.


One thing to do, especially on older systems is to set the 
file system to noatime, and maybe a few other things.  This 
prevents a directory write EVERY TIME you open a file.  
Older systems didn't know to do this automatically when they 
detected an SSD, and it would chew up the disk lifetime with 
writes.
Newer systems, I think, do know to set this for SSDs.  The 
SSD in my desktop is a Micron brand unit.

I think you really DO want to stay with well-known brands.

Jon


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


Re: [Emc-users] First test run on 3D printed CNC conversion

2020-06-24 Thread Jon Elson

On 06/24/2020 02:55 AM, Chris Albertson wrote:
VERY similar design except I bought much larger X and Y 
motors than you did so there was no need to gear them down.
Oh, and that machine is all servos, but the way.  The X is a 
Pittman brushless motor, the Y and Z are brush motors.  (I 
make brush and brushless servo drives and controllers 
compatible with LinuxCNC, this was my demo machine.)


Jon


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


Re: [Emc-users] First test run on 3D printed CNC conversion

2020-06-24 Thread Jon Elson

On 06/24/2020 02:55 AM, Chris Albertson wrote:
I looked at the photos, can you tell me anything about how 
the machine performed. If you milled a circle how 
off-round has it?
Well, it has Acme (or square thread) screws with about .004" 
backlash, so, not perfectly round.

But, actually, not real bad, either.
Yes, the Mini Mill does not have a bearing in the Y axis. 
I installed a pair of thrust bearing that are held in 
place by the drive pulley and the nut on the hand wheel. 
It is really odd that Sieg did not put a bearing on the Y 
axis when they used on X.

Yup, never understood that decision.
I wanted to keep this build VERY simple so I made a 
plastic plate that screws to an existing hole on the mill 
and then there is a pocket where the two bearings are 
press-fit into the plastic. I did not want to cut any 
metal as that would go against my "simple as possible" 
goal. I wanted this to be do-able with only hand tools. 
The goals is to say "look what can be done with a 3D 
printer and a screw driver." I looked at your photos. VERY 
similar design except I bought much larger X and Y motors 
than you did so there was no need to gear them down. I 
have torque to spare. They run 1:1 for X and Y. You wrote 
that you found the smallest ball screw you could for the Z 
axis. I took the other approach and used the largest one I 
could physically fit in the space. Mine is a 16 mm 
diameter. The difference is that your design spins the 
screw, my design spins the nut. I had planned to use 
aluminum like you did, then thought A 4 Newton Meter 
motor can produce no more than 4 Newton meters of rection 
torque even if it stalls. Plastic can handle a load like 
that. All the cutting force is taken by cast iron dovetails 
OK, the rotating nut might actually be a brilliant idea in 
this case.  But, I found that ballscrew on eBay for cheap, 
and it was a perfect fit.  I bored the Y axis bearing block 
on my Bridgeport, which is my main CNC machine.  It has less 
backlash than the minimill, somewhere around .001 to 
.0015".  Part of that is flex in the mounting of the screws 
and nuts.


Jon


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


Re: [Emc-users] First test run on 3D printed CNC conversion

2020-06-23 Thread Jon Elson
On Tue, Jun 23, 2020, 2:38 PM Chris Albertson 
 wrote:

I shot an iPhone video of the first test with all three axes assembled.


https://youtu.be/wupYP2NNsXI


That looks a bit like my X-2 hack (although mine isn't a 
real X-2, it is the same machine.)

See http://pico-systems.com/minimill.html   for some photos.

I found one big problem was the Y axis handle assembly did 
not have a ball bearing, but just a bronze sleeve and the 
handle jam nuts would slowly tighten up until the axis bound 
up.  The X has a pair of ball bearings with the handle nuts 
preloading them.  So, I cut the Y axis handle bracket to 
work the same way.

You can just barely see it in one of the pictures.

I used to use this machine for demos at shows, but there 
haven't been too many shows lately.
I also put a spindle encoder on it first, as it was a lot 
easier to do than on a Bridgeport.


Jon


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


Re: [Emc-users] OT: getting an auction purchase shipped

2020-06-20 Thread Jon Elson

On 06/20/2020 04:52 PM, grumpy--- via Emc-users wrote:
i spotted an item on bitspotter.com that i would like to 
bit on
if i where to win the auction how do i go about getting it 
shipped


If this is with a commercial auction house, send them email 
or call.
They probably have a lot of items that are bought out of 
town and have to

be shipped.  They should know what would be required.

Bidspotter is just a clearing house, like eBay, that makes 
listings by commercial

auctioneers available online.

Jon


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


Re: [Emc-users] Universal spindle speed control for $7

2020-06-20 Thread Jon Elson

On 06/19/2020 11:04 PM, Gene Heskett wrote:

And they work great, on ferrous gears, but they are all nylon in that
machine.

Well, of course, they don't have to be ACTUAL gears.  You 
could make a thin steel disc with notches, and it would 
still trip the sensor.


Jon


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


Re: [Emc-users] Universal spindle speed control for $7

2020-06-19 Thread Jon Elson

On 06/19/2020 10:30 PM, andy pugh wrote:

On Sat, 20 Jun 2020 at 04:05, Ken Strauss  wrote:


Obviously I'm not contemplating threading at 10K RPM! However, I'd like to
leave the encoder installed at all times which is why I'm concerning about
it surviving at high RPM.

My guess would be that it won't explode, it will just stop counting.
And that probably isn't actually a problem.

Qou only really care about accurate counting at low speeds.

Well, I have a spindle RPM display on a PyVCP on my mill, it 
is nice to check that I'm getting the right speed.


Jon


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


Re: [Emc-users] Universal spindle speed control for $7

2020-06-19 Thread Jon Elson

On 06/19/2020 10:03 PM, Ken Strauss wrote:



Obviously I'm not contemplating threading at 10K RPM! However, I'd like to
leave the encoder installed at all times which is why I'm concerning about
it surviving at high RPM. Suggestion for a cheap gear tooth sensor?

I have a little article on my web site :
http://pico-systems.com/bridge_spindle.html

The sensor is the Allegro ATS667LSGTN-T  It senses the 
passage of the tooth in front of the sensor, so it gives a 
nice 50% duty cycle over a wide speed range and different 
tooth pitch.  I get these from Digi-Key for about $8 each.


Jon


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


Re: [Emc-users] Universal spindle speed control for $7

2020-06-19 Thread Jon Elson

On 06/19/2020 07:03 PM, andy pugh wrote:

On Sat, 20 Jun 2020 at 00:38, Ken Strauss  wrote:

Good point regarding the need for an index. Are there cheap encoders capable
of higher RPM?

It will cost you less than $10 to find what happens to those encoders
at 10k rpm.

(My guess would be that they just stop seeing the edges)

Oh, if you need 10 K RPM, then it is best to use a gear 
tooth sensor and a modest number of
teeth to sense.  Spindle encoders do not really need a high 
count/rev to give good threading

results.

Jon


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


Re: [Emc-users] Universal spindle speed control for $7

2020-06-19 Thread Jon Elson

On 06/19/2020 01:01 PM, Chris Albertson wrote:

There is all the space I need to build an encoder for the HF mill's
spindle.  The sensor will fit above the drawbar.

I'm thinking of using this sensor.  The shaft would point down and
thesensor is aligned with an directly over the spindle.
ebay.com/itm/360-600P-R-Photoelectric-Incremental-Rotary-Encoder...



Nope, 2 phase means A and B only, no index pulse.  Look for 
one with 3 channels, A B and Z (index).


Jon


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


Re: [Emc-users] running a press brake on linuxcnc

2020-06-12 Thread Jon Elson

On 06/12/2020 04:47 AM, andrew beck wrote:


has anyone every retrofitted a pressbrake with linuxcnc?


Tx/Rx Labs in Houston has a press brake, and I'm pretty sure 
it runs LinuxCNC (everything else there does).  It is one of 
the most amazing makerspaces in the world, but their web 
site doesn't have a lot of detail you can look up.


You might try sending them an email through the web site.

Jon


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


Re: [Emc-users] Working on Pendant and debouncer PCBs, comments welcome.

2020-06-08 Thread Jon Elson

On 06/07/2020 10:59 PM, Chris Albertson wrote:

*One question:Does a pendant need a "activate" button* on the side such
that the controls are disabled if you don't hold the button down.  You
don't want to jog a mill by accident if the wheel is bumped.
YES !!!  I have mine set up that way.  Make sure the button 
can be held by your index finger while your thumb can turn 
the skirt on the MPG dial, this allows one-hand jogging to 
touch-off.


On this picture, the button at the lower left is the jog 
enable, the one above it is a momentary E-stop.

http://pico-systems.com/images/mmpendant.jpg


Jon


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


Re: [Emc-users] MesaNet cards free to good home

2020-06-07 Thread Jon Elson

On 06/07/2020 08:10 PM, Scott Harwell via Emc-users wrote:

  How much for the cards? I'm wanting something to play with.



In the subject line :  FREE to good home.

Jon


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


Re: [Emc-users] max motor size that a 8i20 can control

2020-06-06 Thread Jon Elson

On 06/06/2020 06:47 AM, andrew beck wrote:

hey andy

my motor feedback type is a fanuc incremental encoder.  i think it is a sin
cos.
If this is the 10S motor you are talking about, it has 
traditional differential TTL quadrature plus index, plus 4 
commutation signals that repeat 4 times per revolution.  
Yes, it is an 8-pole motor.

  I did go throught it and checked that it was not a serial encoder a
couple of months ago but I wil try dig the info out later  I think it is
2048ppr
No, the 10S is not available with 2048 pulses.  Your choices 
are 1000, 2000, 2500, 3000 and 10,000.



Jon


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


Re: [Emc-users] Simple spindle speed control for mini mill

2020-06-01 Thread Jon Elson

On 06/01/2020 12:11 AM, Chris Albertson wrote:

My cheap Harbor Freight mini mill has a variable speed spindle that is
controlled by hand with a knob on the front of the mill.  This knob turns a
potentiometer.I think all mini mills work like this.

Has anyone interfaced the potentiometer to LinuxCNC?   I don't have the
schematic for the spindle motor controller but I assume the potentiometer imply
sends a control voltage to control the duty cycle of a PWM generator.  The
motor is a simple DC brushed motor
Most importantly, note that this speed control is NOT 
isolated from mains voltage.  So, any interface
with it needs (presumably) optical isolation.  Several 
outfits (PMDX, CNC4PC, I think) make interfaces to these 
speed controls.


Jon


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


Re: [Emc-users] FERROR MIN_FERROR value?

2020-05-27 Thread Jon Elson

On 05/27/2020 01:52 PM, Chris Albertson wrote:



On Wed, May 27, 2020 at 11:34 AM Gene Heskett  wrote:


Have any idea how much spring there is in the iron?



I know that just leaning on the head of my Bridgeport will 
deflect the spindle .001" easily.
I often do this when using a boring bar to prevent the tip 
from scribing a line in the bore
when I retract the quill.  They are a lot springier than one 
would suspect!


Jon


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


Re: [Emc-users] Lathe Spindle Rebuild Quistions

2020-05-27 Thread Jon Elson

On 05/27/2020 12:18 PM, Curtis Dutton wrote:

So after finishing the retrofit of the old Miyano gang lathe the spindle
bearings are shot. You can grab the spindle nose and push it side to side
about .0005" to .001". The cut quality is also fairly bad. Just cutting a
spring pass on an aluminum bar shows a lot of chatter like marks.

I can also measure a .0005" to .001"  axial play by pushing on the face or
the collet closer of the spindle. Not to mention there is roughness and
fairly loud bearing noise while running.

I expected this but I'm looking for someone that can refurbish it or any
advice from others that have done this before. I haven't ever sent anything
out to be rebuilt so I'm ignorant on the process.
One online quote I received was 4500 to 6500. Is that reasonable? Does
anyone know of someone or have pointers? I'm not opposed to trying to do it
myself but I know it would be very challenging to get it right. I'm sure
I'd need to order 2 sets of bearings... One for the first attempt and one
to get it right!

Well, it may not be that tricky.  It is probably just a pair 
of angular contact precision ball bearings,
and may have some type of spacer to get the preload right.  
Do you have any drawings of the
headstock?  That might give some idea of how the spindle is 
assembled.


Jon


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


Re: [Emc-users] FERROR MIN_FERROR value?

2020-05-26 Thread Jon Elson

On 05/25/2020 07:43 PM, Gene Heskett wrote:
Without PID's, where do we get a following error that we 
can see on the halscope?
OK, WITHOUT a PID, then the step generators have a maximum 
speed, set by (possibly)
BASE_PERIOD, step_width and step_space.  If you set maximum 
velocity in the ini file
above that limit, you will get following errors.  So, you 
have to know from the setup
of the step generators what the max speed is, and then be 
sure to not set max velocity above
that.  You should have no need to scope it, but you could 
probably get this on most systems
by looking at the commanded position and the actual 
position, if the step generator provides

this.

Jon


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


Re: [Emc-users] FERROR MIN_FERROR value?

2020-05-25 Thread Jon Elson

On 05/25/2020 02:50 PM, N wrote:

Do anyone here have any suggestion for FERROR and MIN_FERROR values?



It depends on your "user units", as well as the general 
accuracy and speed of the machine.
FERROR is a multiplier to velocity in user units/second that 
is added to MIN_FERROR.
MIN_FERROR is the allowable following error with the machine 
not moving.


On a servo system, you should have Halscope graph the 
following error and find out what
your actual errors are, and then set MIN_FERROR 
accordingly.  Then, set FERROR to

accommodate larger error at rapid traverse speed.

There's no one good value for everybody.

Jon


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


Re: [Emc-users] Encoder HAL programming.

2020-05-25 Thread Jon Elson

On 05/25/2020 11:01 AM, R C wrote:
In the video I posted earlier (it's a year old)... the guy 
using that chip says it cost  him $40,  he showed it on 
line for about $28.


(and that's just for the LS7366R by itself.)


This just doesn't make sense anymore.  You can take a bottom 
of the line FPGA and put 4, 8 or maybe even dozens of 
quadrature counters in it, with digital filtering, latch on 
index and other features. The Spartan 3A chips I use are 
just over $10 each.


Jon


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


Re: [Emc-users] Face Milling

2020-05-21 Thread Jon Elson

On 05/21/2020 11:39 AM, John Dammeyer wrote:

This was a year ago but based on the latest fly cutting results I'm getting 
slight ridges so either the fly cutter isn't exactly turning a perfect 
horizontal arc or I need to tram again.
http://www.autoartisans.com/mill/TrammedVertical.jpg


Tramming the head-spindle to the table surface is not what 
you want, especially on an older (worn) mill.
What I do is have a program that mills a circular path on a 
piece of scrap.  Step down a little at a time until it cuts 
all the way around.  Then, move to the center, and put in 
the dial indicator and sweep the circle.
This allows you to tram to the actual X-Y plane of motion of 
the machine, which may NOT be parallel to the surface of the 
table.  My 1938 Bridgeport cuts a kind of saddle shape that 
moves up and down a few thousandths of an inch over about a 
7" sweep.  This way, I can tram the head to be as close to 
perpendicular to that as possible.


Jon


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


Re: [Emc-users] Face Milling

2020-05-21 Thread Jon Elson

On 05/20/2020 11:56 PM, John Dammeyer wrote:


Anyone used one of these?
https://www.aliexpress.com/item/4000890081459.html


Years ago, we had CNC meetings at Roland Friestad's shop 
near Galesburg, IL.  He made CNC retrofits to sell to tech 
schools, and apparently made some of his own tooling.  I 
found a bunch of very similar
small face mills with R-8 taper, and I think we bought all 
he had. I'm still using them for this type
of face milling work.  The bigger the face mill, the more 
accurately you need to have your machine trammed.


Jon


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


Re: [Emc-users] timestamp ethernet hardware

2020-05-19 Thread Jon Elson

On 05/18/2020 10:40 PM, Thomas J Powderly wrote:

I think timestamping was a benefit, esp for PPMC.

Some PPMC devices can use time stamps to estimate encoder 
velocity. I don't think that has anything to

do with Ethernet packets.

Jon


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


Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-09 Thread Jon Elson

On 05/09/2020 01:12 AM, John Dammeyer wrote:

One of the greats in computer science has a series of interesting quotes.
https://www.azquotes.com/author/15849-Niklaus_Wirth

One I really like is:
"The belief that complex systems require armies of designers and programmers is 
wrong. A system that is not understood in its entirety, or at least to a significant 
degree of detail by a single individual, should probably not be built." ~ Niklaus 
Wirth

I often wonder if LinuxCNC has reached this point.

No, the general, overall understanding of LinuxCNC is held 
by at least several people.  I know I don't
know all areas of it well.  But, the area I work in, I do 
know fairly well.  People like Andy and Robert Ellenberg, as 
well as Jeff Epler and Chris Radek seem to know a LOT about 
the internals.  John Kasunich built hal and interfaced it to 
the internals of the old EMC to create EMC2.  So, at least 
these people really

know it WELL.

LinuxCNC has reached a point of complexity that is needed to 
do CNC tasks on a variety of CNC machine configurations.  I 
do NOT think it is too complex.


Jon


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


Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-09 Thread Jon Elson

On 05/08/2020 09:36 PM, Dan Henderson wrote:

Thanks for the examples. I'm not going to lie, I've got some homework to do
on this. You guy's make this sound easy but to the new guy looking in? No
so much, lol

There is a good HAL document in the documentation section, 
written by Hal's author, John Kasunich.
HAL can do a lot more, but it is used to connect the parts 
of LinuxCNC together.


Jon


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


Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-08 Thread Jon Elson

On 05/08/2020 06:45 PM, Gene Heskett wrote:

On Friday 08 May 2020 18:01:41 Jon Elson wrote:


On 05/08/2020 04:04 PM, Dan Henderson wrote:

Thanks Jon and Chris!

Jon do you have a code example of the Hal filter that is needed?

# set up 4th DAC generator as a spindle speed control
newsig spindle-speed float
newsig spindle-DAC-cmd float
newsig spindle-DAC-filt float
newsig spindle-DAC-abs float
linkps motion.spindle-speed-out => spindle-speed
linksp spindle-speed => mult2.1.in0
setp   mult2.1.in1 0.002457
linkps mult2.1.out => spindle-DAC-cmd
linksp spindle-DAC-cmd => lowpass.0.in
linkps lowpass.0.out => spindle-DAC-filt
setp lowpass.0.gain 0.005
linksp spindle-DAC-filt => abs.0.in
linksp spindle-DAC-abs => abs.0.out
linksp spindle-DAC-abs => ppmc.0.DAC.03.value


That hal code is all, I assume, from your 2.5.4 install Jon.  everything but
the setp has been deprecated, and I am not sure todays version of hal
understands those commands.
Yes, I'm pretty sure it still does.  But, yes, this is OLD 
STYLE hal code, for sure.
You can combine any newsig / linkps / linksp into one net 
command, with


net signal-name pin pin pin ...

And, you don't have to tell it the signal type, it gets it 
from the first pin.


Jon


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


Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-08 Thread Jon Elson

On 05/08/2020 04:04 PM, Dan Henderson wrote:

Thanks Jon and Chris!

Jon do you have a code example of the Hal filter that is needed?

# set up 4th DAC generator as a spindle speed control
newsig spindle-speed float
newsig spindle-DAC-cmd float
newsig spindle-DAC-filt float
newsig spindle-DAC-abs float
linkps motion.spindle-speed-out => spindle-speed
linksp spindle-speed => mult2.1.in0
setp   mult2.1.in1 0.002457
linkps mult2.1.out => spindle-DAC-cmd
linksp spindle-DAC-cmd => lowpass.0.in
linkps lowpass.0.out => spindle-DAC-filt
setp lowpass.0.gain 0.005
linksp spindle-DAC-filt => abs.0.in
linksp spindle-DAC-abs => abs.0.out
linksp spindle-DAC-abs => ppmc.0.DAC.03.value


This is for my PPMC analog boards, but ppmc.0.DAC.03.value 
is the speed value sent to the drive.
lowpass.0.gain is set to 0.005, the name of the pin is a bit 
odd, as gain is actually what sets the time constant of the 
filter.  You will have to loadrt lowpass and then addf 
lowpass to the servo_thread


mult2 sets up the speed factor so that the S word gives the 
right speed.


Jon






On Fri, May 8, 2020 at 3:58 PM Chris Albertson 
wrote:


You have to compare the signals on BOTH sides of the interface to see what
is happening.   The build-in halscope can only see what has crossed the
interface.  Compare this to what is on the parallel port pins and also what
is on the encoder side of the opto-isolators.

If a new digital oscilloscope is out of budget then look at one of these:
ebay.com/itm/USB-SALEAE-24M-8CH-Logic-Analyzer...
<
https://www.ebay.com/itm/USB-SALEAE-24M-8CH-Logic-Analyzer-24M-8-Channel-with-Buffer-Support-1-1-16/173828458153?hash=item2878fbc6a9:g:tDUAAOSwJiddkJ1E
It is an 8-channel logic analyzer that is fast enough fo anything you will
ever do with a machine tool of motion control.  It has no trouble sampling
Mhz class square waves.   (The above is a Chinese clone of the actual
Saleae unit.)

Get the software for it here.  You can try the software without buying the
hardware but obviously can't collect data.
https://www.saleae.com/downloads/

The oscilloscope is best because it shows the actual analog waveform but
the analyzer has more channels and has very complex triggers and can
de-code serial busses





On Thu, May 7, 2020 at 3:45 PM Gene Heskett  wrote:


On Thursday 07 May 2020 17:39:32 Dan Henderson wrote:


Why certainly Gene (see attached). I actually have it working a little
better now. My spindle-at-speed LED will start going bonkers around
1200 rpm. I'm guessing this is when the counter "throws up it's hands
and says - I quit!" lol. The spindle will operate all the way to
around 4700 rpm but anything above this and the MC-2100 shuts it down
-- must be some kind of voltage limiter kicking in then.


The one time I tried to use one of them was a failure, it seemed to have
a mind of its own.  I made a power supply and bought one of the pico
systems pwm-servo's. Bulletproof but be sure and tell Jon you are going
to drive a PMDC spindle motor with it so he'll add more toroids so it
runs cooler when working continuously.

That said, your config is as well laid out as any I've looked at, and I
don't see anything wrong at all. But I can also see how the parport and
its missing of the encoders signals could be all of the higher speed
problems.  The 4700 limit might be the pwmgen going to 100% duty, losing
the 0% recharge pulse. You can check that with halscope. I run more
voltage than the mc2100 can muster, so I can spin a treadmill motor up
to where I worry about the cast iron fan/pulley exploding but set limits
somewhat below that, probably around 7 grand max. Even though its geared
3/1 before it gets near the spindle drive, its still too fast to cut
steel.

If you can set the encoder even lower you might get to a couple thousand
revs before the tach gets funkity.

18:40 here, I'd better go see what my missus wants for dinner.



On Thu, May 7, 2020 at 2:29 PM Gene Heskett 

wrote:

On Thursday 07 May 2020 13:19:23 Dan Henderson wrote:

I believe this is open loop. Isn’t PID only used in closed loop
control?

Its (the PID is) a waste of processor time if open loop. I don't use
one of those in any spindle run by a vfd, the vfd is generally stiff
enough control by itself. If I thread on that machine, it will have
a spindle encoder, but its only job is to glue the axis motion being
driven to cut the thread, to the spindle rotation, in the case of a
g33.1, going both in and out of the hole. If you aren't useing a PID
for the spindle, that leaves motion I think.

I think its time we saw your .hal file. Can you insert it into a
mail?


On Thu, May 7, 2020 at 11:03 AM Gene Heskett


wrote:

On Thursday 07 May 2020 11:27:57 Jon Elson wrote:

On 05/06/2020 09:20 PM, Dan Henderson wrote:

I’ve confirmed the fluctuation occurs when spindle-at-speed
is configured. When I remove this feature, the spindle rpm
appears to stabilize. It’s almost like it gets caught in a
loop trying to

Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-08 Thread Jon Elson

On 05/08/2020 01:34 PM, Dan Henderson wrote:

There are times when letting the smoke escape becomes part of the learning
process :)

Thanks for your guidance Gene. Would think the DC motor energy would be
absorbed by the act of tapping once the M3 is turned off? Surely the G33.1
cycle doesn't flip from 500 CW to 500 CCW does it?
Without filtering, it does exactly that.  But, you can put a 
lowpass filter or a limit component in there

to slow down the reversal.

  I'm going to want to
initiate that cycle with a slow spindle to begin with and I'm not sure how
built-in speed ramp controlled by the MC-2100 will handle this. A hacked in
pause between M3 and M4 may be order, huh?

But, the G33.1 doesn't allow you that control.  It just goes 
from forward to reverse in one servo cycle
when it determines the programmed depth has been reached.  
So, that's why you need a filter

in the spindle command if you want a softer reversal.

(By the way, I do the 4-40 rigid tapping on my machine at 
1000 RPM. The reversal takes about

a half second.)

Jon


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


Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-08 Thread Jon Elson

On 05/08/2020 11:38 AM, John Dammeyer wrote:


Hi Jon,
I suppose you are using external hardware to create motion and count encoder 
pulses?
So BASE_PERIOD isn't even used?
Or is it still needed for tapping?
  My understanding is the SERVO_PERIOD time is used to calculate the spindle 
velocity from the time between encoder pulses at the BASE_PERIOD.
Yes, I have hardware encoder counters in my machine, and 
there is no BASE_PERIOD.  (Effectively, the
base_period is 1 us.)  The base_period is only used to help 
the software encoders not miss pulses (and the step 
generators go faster).


Depending on hardware, the various encoder drivers may have 
several ways to compute velocity.
It can just take difference between current and last encoder 
position, but this is very noisy due to the
double quantization (in both time and position).  Or, it can 
use a timestamp of the most recent quadrature
transition to compute time between pulses.  This can be less 
noisy, especially with a little arithmetic to filter toward 
zero velocity when there hasn't been a transition in a few 
servo cycles.


Jon


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


Re: [Emc-users] Sourced from: Re: Fluctuating RPM using CUI ATM 10 encoder

2020-05-08 Thread Jon Elson

On 05/07/2020 06:43 PM, Dan Henderson wrote:

I should have mentioned, I’m in the process of building a reverse polarity
circuit to trip polarity by issuing a CCW M4 via a 5v output. My motor
controller doesn’t natively support CCW.

I entered the code and it made it all the way down until the spindle
stopped.  No reverse so it stayed there.


So, that shows it synched up to the spindle and the index.  
So, it should work.


Jon


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


Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-08 Thread Jon Elson

On 05/07/2020 06:33 PM, Dan Henderson wrote:

Thanks Gene! I can go down to 48 PPR on the encoder. If I do so, what is
the trade off for reducing resolution on my mill project? Is that enough to
successfully use rigid tapping and synchronized feed/speeds?


48 pulses is 192 quadrature counts/rev, so not too bad.  
Roughly 2 degrees.  I do tons of rigid tapping with 4-40 
taps using an 81-tooth gear as the encoder wheel on my 
Bridgeport.  It does just fine.


You do need to have the index pulse hooked up for rigid 
tapping, lathe threading, etc.


Jon


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


Re: [Emc-users] Sourced from: Re: Fluctuating RPM using CUI ATM 10 encoder

2020-05-07 Thread Jon Elson

On 05/07/2020 12:23 PM, Dan Henderson wrote:

Is there a simple test code I can run to confirm ridged tapping is working
or even the feed rate is synchronized to the encoder feedback? Without,
spindle-at-speed enabled I’ve no way to visually confirm this.


Just try these lines and see what it does, with the Z clear 
to move down to Z-1 without hitting anything :

M03 S500
G01 F10 Z0.5
G33.1 Z-0.55 K0.025

If it stalls with the spindle running, it never saw the 
spindle encoder trip the index-enable to off.
If it moves down in Z, then reverses the spindle and pulls 
back in Z, then it is all working.

That will give a 40 TPI thread (assuming inch units).

Jon



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


Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-07 Thread Jon Elson

On 05/07/2020 12:19 PM, Dan Henderson wrote:

I believe this is open loop. Isn’t PID only used in closed loop control?


Oh, so the situation with and without spindle-at-speed were 
BOTH open loop?  That is
totally different, then, and now I have no idea what is 
going on. But, checking all signals

related to the spindle speed control with Halscope is indicated.

Jon


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


Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-07 Thread Jon Elson

On 05/06/2020 09:20 PM, Dan Henderson wrote:

I’ve confirmed the fluctuation occurs when spindle-at-speed is configured.
When I remove this feature, the spindle rpm appears to stabilize. It’s
almost like it gets caught in a loop trying to chase its tail.


This is VERY common in servo systems, and is due to delay in 
response of the object being controlled.
You need to slow down the response of the PID to ignore the 
delay. This may be possible by adding

D to it.

Jon


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


Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder

2020-05-06 Thread Jon Elson

On 05/06/2020 09:20 AM, Gene Heskett wrote:

On Wednesday 06 May 2020 09:14:20 Dan Henderson wrote:


Here are a couple screen shots of the encoder inputs using Halscope.
The first is captured at 300 rpm spindle speed. The second is at 2500
rpm. The signals are inconsistent at the higher speed. Not sure if
this is normal or an issue?

That _is_ the issue. Ir you have a real scope, take a look at the cable
from the encoder.. If you still see that, the encoder is the problem.
Conversely if that looks good, the port is mussing pulses

Or, the sample rate of Halscope is just too low.  But, 
clearly, the displayed results at 2500 RPM
show a major problem.  Since it clearly shows less pulses on 
B than on A, however, it may really

be an optoisolator problem or something of that nature.

Jon


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


<    1   2   3   4   5   6   7   8   9   10   >