Re: [Emc-users] Any Interest or Ideas for a Linuxcnc Fest 2016 ?

2016-10-03 Thread Jon Elson
On 09/28/2016 06:07 PM, Sebastian Kuzminsky wrote:
>>>
>>> The plan is:
>>>
>>> Monday October 17 through Sunday October 23
>>> Helix Machine, 3434 West Harry, Wichita, Kansas
>>>
>>> It's going to be a rocking nerdy good time.
>>
Where is everyone staying?  I think last time I stayed at 
the Days Inn, which looks like it is a lot closer to 
Stuart's new place than it was to MPM.  First time out there 
I stayed at Western Holiday, which was a bit TOO cheap!
Days Inn was OK, and the airport actually was pretty quiet 
at night.

(I'm still trying to get a bunch of stuff squared away so I 
can take the time off, hope it all works out...)

Jon

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


[Emc-users] Speaking of batteries

2016-10-03 Thread Gene Heskett
Greetings all;

I don't believe I was the only one to buy one of those DS-201 pocket 
o-scopes about 2, maybe 3 years back.

I reached to get mine, which had been plugged into a usb port on TLM's 
computer, probably for close to a year.  And when I had pulled it off 
the shelf, it felt thick.  The battery had swelled up and pushed the 
back out about an eighth of an inch.  It still worked but the display 
was dimmer than I remember it.

Has anyone else's also gotten obese & dim?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Question on Renishaw MP3 IR probe

2016-10-03 Thread Florian Rist
Hi Hubert

> Renishaw replied that it used a 12 volt rechargeable

Oh, that sounds unusual and impossible to get in that form factor.

Thanks for the update
Flo




--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Question on Renishaw MP3 IR probe

2016-10-03 Thread hubert
Renishaw replied that it used a 12 volt rechargeable but the probe 
became obsolete in the 90s.  I have decided to assemble either a 10.8 or 
14.4 battery out of rechargeable Lithium Button cells and see how that 
works.


On 10/1/16 1:58 PM, Florian Rist wrote:
> Hi Hubert
>
>> Does anybody know what batteries a Renishaw MP3 IR probe with a round
>> battery compartment uses.  All the current literature shows a
>> compartment with 2 9-volt batteries.
> The OMP40 (and some other probes as well) uses two 1/2 AA 3.6V lithium
> batteries. These batteries are about 25mm long, so two are only slightly
> longer than a 9V block. The diameter of the 1/2 AAs is 14.5mm. Maybe the
> MP3 also uses 1/2 AAs.
>
> See you
> Florian
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Got nother math problem

2016-10-03 Thread Gene Heskett
On Sunday 02 October 2016 15:54:35 Gene Heskett wrote:

Ping...

> Greetings all;
>
> I am trying to put together a G76 wrapper that will let me do a clean
> cut, test the fit, and if it doesn't, decrement a value thats is added
> or subtracted from the desired thread OD and factored into the z_start
> point, to run it again until it fits.
>
> I am trying to use some math to allow the usual variations in thread
> face angles, normally around 30 degrees for most threads to adjust the
> z axis start point.  For a 30 degree example, sin[30]=0.5, but that
> with a #<_drive_zstart>=[2.0 +[#<_t_offset> * SIN[30]], according to
> the backplot, is too much of an advance.  Nominally twice too much.
>
> What I want to get is a backplot that shows the start point of the
> threading motion follows the same up to the left angle as a normal G76
> run shows so that the point of the tool continues to cut on its
> leading edge only while cutting the thread deeper and deeper until it
> actually fits. The threads I am getting with good 08ERA60 inserts sure
> have a lot of "hair", and I do have the tip of the insert level with
> the centerline.  This hair, while it cleans up nicely with a die or a
> pass with the correct nut, totally makes trying to measure it a waste
> of time.
>
> Here is the gcode, without adding the looping yet, this needs editing
> the t_offset at the top of the file.
> 
> %
> ( adding a couple new vars to aid in the cut, test for fit, adjust and
> ) ( wash rinse and repeat till the stop button is clicked because it
> now fits. )
> #<_t_offset>  =   -0.7500 ( use this to adjust size! )
> #<_p_offset>  =   0.000 ( place holder )
> #<_thread_od> =   9.525 ( starting value )
> #<_thread_end>=   -24 ( mm's obviously )
> #<_q_angle>   =   30.000 (degrees)
> G7 G21 (diameter mode,mm mode, g20=inch mode)
> S250
>
> ( diddle this stuff if inches as below)
> (#<_tp_mm>=   1.00)
> #<_tpi>   =   24
> #<_pitch> =   [1.000 / #<_tpi>]
> #<_pitch> =   [#<_pitch> * 25.4] (needs mm's)
> #<_thread_od> =   [#<_thread_od> + #<_t_offset>]
> ( from thread_OD set drive xline )
> ( set drive line OD 1st)
> #<_drive_xline>   =   [#<_thread_OD> + 1.5000] ( a bit large for mm's,
> works for ext )
> #<_p_offset>  =   [#<_t_offset> * SIN[#<_q_angle>]] (sine of 30? degree
> angle)

Something that almost works
#<_p_offset> = [#<_t_offset> * SIN[#<_q_angle> *.587000]]
But it doesn't track #<_q_angle> very well, needing a different fudge if 
#<_q_angle> is changed.

So while it sort of works, that tells me my math is busted.  But where?

> ( constrain this #<_p_offset> to be lt #<_pitch> either direction )
> o150 WHILE [#<_p_offset> lt -#<_pitch>]
> #<_p_offset>  =   [#<_p_offset> + #<_pitch>]
> o150 ENDWHILE
>
> o151 WHILE [#<_p_offset> gt #<_pitch>]
> #<_p_offset>  =   [#<_p_offset> - #<_pitch>]
> o151 ENDWHILE
>
> ( set z far enough away sync is good for startup accel wibblies )
> #<_drive_zstart> = [2.0 + #<_p_offset>] ( assumes mm's, too far for
> inches )
> #<_z_end> =   [#<_thread_end> + #<_p_offset>]
> ( calculate this K from pitch )
> ( set k, peak to valley of std USS/USF thread format = pitch/0.866
> -10% clipped from peak and valley )
> #<_kpp>=[0.8 * [#<_pitch> / 0.866]]
>
> (debug, kpp=#<_kpp>)
> ( set threads OD, drive_line minus i )
> #<_i_cut>=[0.000 - [#<_drive_xline> - #<_thread_OD>] - 0.01]
>
> m3g4p1 (start spindle, wait for speed)
> g0x41.1 ( clear armstrong bolts spinning base )
> g1f450 z#<_drive_zstart>
> g1f250 x#<_drive_xline>
> g76 p#<_pitch> z#<_z_end> i#<_i_cut> j0.25 k#<_kpp> r1.6 q#<_q_angle>
> h5 e0.25 l2
> ( leave it where it started from )
> g1f450 x#<_drive_xline>
> (but out of the way for test fits)
> g1f650 z#<_drive_zstart>
> m5
> g1f650x41.1 (back it out of the way to check screw fit)
> g0z150
> m2
> %
> ===
>
When I finish with the pocketing for wrench access in the side of the 
toolpost base, I'll get back to making 3 more of the armstrong bolts, 
but will make the rest of them with the screw on the right as chucked. 
Cutoff will be messy with my cutoff knife, but will still waste less 
steel. That also means more time to think on this as its probably going 
to be not more than 2 pockets a day even after I figure out why I'm 
getting following errors at 1/3rd the Z axis's speed ability.
 
Thanks all.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] 6 DOF Serial Kinematics

2016-10-03 Thread Marius Alksnys
Hi, Allyssa,

interesting project! Would like to know more about it and its progress.

I went that way too - used genserkins in 6 axis industrial robot arm 
retrofit project.

1. Drifting or error from perfect line.
While possible, but I doubt there are errors in genserkins math. And 
perfect visualisers confirm that.

More likely reality differs from your theoretical parameters.
Are you sure scale of all axes is correct?
Are homing or zero positions in place?
Are your entered DH parameters accurate enough? Usually arm drawing 
specifies the dimensions, but in reality they might differ slightly. I 
saw people using precision 3D digitisers to get those parameters right.
Joint position might be not exact due to loose PID.
Mechanical gear unit, including toothed belts and shafts might be worn 
out, thus having backlash and looseness.

Robot programming with original robot controller is done by teaching 
method usually. This eliminates or decreases similar errors, which exist 
even with a new robot and a brand controller.


2. Impossible joint angles.
This happens at near-singularity postures. Have to dig deeper in math to 
understand this. For start, I would just recommend not to approach such 
postures and use joint mode to go-by or re-arrange the joints.



For more or better solutions, I would recommend searching for 
information or people.
There are more people who went similar ways too. Maybe they could add 
something more...

Good luck!
Marius

08/03/2016 09:37 PM, Alyssa Wells rašė:
> We are currently working on a project to retrofit a 6 DOF industrial robot 
> with LinuxCNC controls. We have communications working over EtherCAT and can 
> use Axis to jog all six axes of the robot. We have tried our hand at setting 
> the D-H parameters for genserkins, with mixed results. The kinematics appear 
> to be at least a little bit off, despite looking correct in numerous 
> kinematics visualizer softwares.
> For the most part, the robot tends to jog in a straight line, but drift in 
> sort of a curve in at least one direction. Sometimes the kinematics solve to 
> joint angles that are impossible, and the robot faults for "over speed" from 
> trying to go to positions > 1 degrees.
>
> Thank you for taking the time to read this! If you have any ideas or tips on 
> how we can fix our kinematic model, it would be greatly appreciated.
>
> Thanks,
> Alyssa
> --
>


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users