Re: [Emc-users] Stepper Motors/Drives

2016-01-15 Thread andy pugh
On 15 January 2016 at 01:04, Gregg Eshelman  wrote:
>
> The catch is that those small screws tend to cost more than larger ones.

They are not so bad now:
http://www.zappautomation.co.uk/r08-025b1-rsw.html

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] VFD Tweaking

2016-01-15 Thread andy pugh
To add to this thread. It became more and more likely that the
Variator was the source of the trouble, and then abundantly clear when
the Variator locked up.

It's an interesting device, and I think I have repaired it. Pictures here:

http://bodgesoc.blogspot.co.uk/2016/01/holbrook6.html

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] VFD Tweaking

2016-01-15 Thread Jim Craig
On 1/15/2016 8:59 AM, andy pugh wrote:
> To add to this thread. It became more and more likely that the
> Variator was the source of the trouble, and then abundantly clear when
> the Variator locked up.
>
> It's an interesting device, and I think I have repaired it. Pictures here:
>
> http://bodgesoc.blogspot.co.uk/2016/01/holbrook6.html
>
That is an interesting device. I have not seen anything like that 
before. It was also an entertaining read.

Thanks for the link.

Jim

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] calling Todd Z

2016-01-15 Thread Robert Ellenberg
I'd be happy to merge it into either if there's demand. My recent batch of
changes restored the original behavior of the velocity field in EMC status,
so I don't think there are any other obstacles. One minor concern is that
the extra math slightly increases the CPU time for the servo loop, but I
doubt it will matter on reasonably modern hardware.

On Mon, Jan 11, 2016, 2:25 PM Todd Zuercher  wrote:

> Rob,
>
> We've been running this for a little while now and it seems to be working
> well for us.  Is there any plans to move it to the mainstream (Master or
> 2.7)?
>
> - Original Message -
> From: "Robert Ellenberg" 
> To: "Enhanced Machine Controller (EMC)" 
> Sent: Tuesday, December 1, 2015 12:31:50 PM
> Subject: Re: [Emc-users] calling Todd Z
>
> That's consistent with the changes I made, that "velocity"  from the TP's
> perspective is now along the 6D path (instead of just XYZ).
>
> Maybe we could add fields / Hal pins for different interpretations? It
> wouldn't be too hard to calculate XYZ-only velocity, and report it on a
> separate pin. Or, for backwards compatibility, I could tweak the status
> update code so that motion only reports xyz velocity, even though
> internally it uses xyzuvw.
>
> On Tue, Dec 1, 2015, 12:14 PM Todd Zuercher 
> wrote:
>
> > Ok I got to test it again today some, and here is what I've found so far.
> > It looks like the g-code with Z and W are running the same as the only Z
> > g-code.  The same file runs for the same amount of time both ways.
> >
> > However I have noticed that it looks like the velocity display on the
> DRO,
> > is adding the velocity of the W axis to the Z, so that when milling at
> F80,
> > the DRO will show that the velocity was more than 80.  I'm not quite sure
> > how this could be corrected or if it should be.  There are configurations
> > where you may want the W and Z velocities to be additive (such as a knee
> > mill) but that situation might be better served by configuring it more
> like
> > 2 joints serving the Z axis.  I don't think it would be right to just
> > completely ignore the W velocity either, because there are situations
> where
> > the machine may be using only XYW for carving instead of XYZ or XYZW.
> > Maybe some way of only using the most significant velocity of the 2 (Z
> and
> > W) in the velocity calculation, sounds like a recipe for making something
> > simple (at least on the surface) into something very complicated.
> >
> > Again, it is only what is being shown for the velocity on the DRO that I
> > think is wrong, the actual movement of the the machine looks right, and
> the
> > run times for the files seem to confirm that.
> >
> > - Original Message -
> > From: "Robert Ellenberg" 
> > To: "Enhanced Machine Controller (EMC)"  >
> > Sent: Friday, November 27, 2015 10:56:44 AM
> > Subject: Re: [Emc-users] calling Todd Z
> >
> > I just tweaked naive cam detection to handle uvw axes too. Can you guys
> > give it a spin and see if it makes up the difference?
> >
> > -Rob
> >
> > On Wed, Nov 25, 2015, 4:09 PM sam sokolik 
> wrote:
> >
> > > the thing that is missing with uvy blends it the nieve cam detector
> > > (combining of short line segments..)  so it will run just a bit slower.
> > >
> > > sam
> > >
> > > On 11/25/2015 12:17 PM, Todd Zuercher wrote:
> > > > Just for perspective the current version of 2.7 using XYZW runs the
> > file
> > > below in 10min. 44sec.
> > > >
> > > > - Original Message -
> > > > From: "Todd Zuercher" 
> > > > To: "Enhanced Machine Controller (EMC)" <
> > emc-users@lists.sourceforge.net
> > > >
> > > > Sent: Wednesday, November 25, 2015 10:17:03 AM
> > > > Subject: Re: [Emc-users] calling Todd Z
> > > >
> > > > Seems to be working great.  I haven't found a problem XYZ and XYZW
> code
> > > seem to run mostly the same now, but not exactly.  The first file I
> > tested
> > > ran in 7min. 10 sec. using only XYZ code (with the W slaved to Z) and
> the
> > > same file using XYZW code, ran in 7min. 28sec.
> > > >
> > > > - Original Message -
> > > > From: "Robert Ellenberg" 
> > > > To: "Enhanced Machine Controller (EMC)" <
> > emc-users@lists.sourceforge.net
> > > >
> > > > Sent: Tuesday, November 24, 2015 11:39:38 PM
> > > > Subject: Re: [Emc-users] calling Todd Z
> > > >
> > > > Ok, i just pushed a fix for that build error, and now it seems to
> > compile
> > > > and run on my RTAI VM.  Also, I pushed the branch to the main
> linuxcnc
> > > > repository for the buildbot to chew on.
> > > >
> > > > -Rob
> > > >
> > > > On Tue, Nov 24, 2015 at 4:16 PM, Robert Ellenberg 
> > > wrote:
> > > >
> > > >> Todd,
> > > >>
> > > >> I'll troubleshoot the build tonight, it looks like a symbol is
> missing
> > > in
> > > >> the RT build that's