Re: [Emc-users] XSY inverters (VFD)-way OT

[Karl Jacobs]

Am 26.09.2022 um 07:55 schrieb gene heskett:

We can measure everything to quite a few decimal places, but we still do
not know its propagation velocity.

We do for gravitational waves, the speed is c.
 T But that speed limit of C, messes with

our orbital math.

So one of them is wrong. We've been arguing about it for about a century
now.


Not really. Way OT, but do not confuse gravitational *waves* with a
gravitational *field*. For a pedestrian explanation see e.g.
https://en.wikipedia.org/wiki/Speed_of_gravity , chapter "Static fields".
Cheers,
Karl


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

Re: [Emc-users] LCNC vs bullseye on rpi4?

[Karl Jacobs]

To correct typos, that should rather read
"python3.7 -m venv "
and
"source /bin/activate"
to create and activate a python virtual environment, in this case with
the specific python version 3.7 that you want to use (which of course
must be installed and in your $PATH). If you just say python3, the venv
would still use the (default) 3.9 version.
Cheers,
Karl

Am 01.03.2022 um 23:17 schrieb Chris Albertson:

It is easy to install 3.7 First use "python3 -m vend "  then
"source /bin/activate" then install the version of
python you like and whatever version of the packages you want.  That's it.
Now you have a vertical environment.

In fact, almost every Python developer does this is it is generally a
really bad idea to run with the default Python that comes with the OS.



On Tue, Mar 1, 2022 at 5:46 AM gene heskett  wrote:


Greetings all;

Any progress on that? The python is too new. Buster is just fine with its
python-3.7, but bullseye has python-3.9.2 and breaks it.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Genes Web page 





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







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

[Emc-users] 7i92 hardware question

[Karl Jacobs]

Hi all,
sorry if this has been asked before: I am planning on using a Mesa 7i92M
board and connect it to an existing BOB that has 10kOhm pullup resistors
to 5V on its 74ACT14 inputs. I know about the 3.3V logic and the 5V
input option of the Mesa boards, but I could not find definite info
about the outputs. They seem to have an open drain mode, but can they
safely take the 5V pullups or do I have to get rid of them (or connect
them to 3.3V)?
Thanks,
Karl


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

Re: [Emc-users] Tool presetter

[Karl Jacobs]

That is actually a factor of 100 too thick, if I translate your 0.1"
right to 245nm. A fresh aluminum surface oxidizes to about 2nm within
hours and then continues to grow logarithmically with time. At 2nm,
there is even enough tunnelling current through the oxide without
needing dielectric breakdown. (I work on and with detectors using that).
Easy to punch with a tool without even a scratch.
Cheers,
Karl

Am 04.09.2020 um 16:40 schrieb Gene Heskett:
> This oxide coat may be less
> than .1" thick if fresh,


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

Re: [Emc-users] need advice, idea shoppingIOW.

[Karl Jacobs]

I meant to type "Hubble", of course.

Am 18.07.2020 um 22:47 schrieb Karl Jacobs:
> Hi Gene,
>
> 0.01 arcsec is way too high resolution. Unless you have a telescope
> with 12.6m diameter (sin(delta) = 1.22 * lambda/D, with delta the angle
> in radians, lambda the light wavelength (take green 500nm) and D the
> diameter.) Even then, in extremely good skies from ground level, our
> atmosphere might only allow an arcsec of seeing (scintillation or
> twinkling of the stars). This is why you guys over the pond launched
> Hubbly into orbit. And ground based astronomers use adaptive optics
> these days.
> And yes, I am an astrophysicist using LinuxCNC for fun.
> Cheers and clear skies,
> Karl
>
> Am 18.07.2020 um 19:01 schrieb Gene Heskett:
>> But for astrophotography, they are mentioning .01 arc-seconds or better,
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


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

Re: [Emc-users] need advice, idea shoppingIOW.

[Karl Jacobs]

Hi Gene,

0.01 arcsec is way too high resolution. Unless you have a telescope
with 12.6m diameter (sin(delta) = 1.22 * lambda/D, with delta the angle
in radians, lambda the light wavelength (take green 500nm) and D the
diameter.) Even then, in extremely good skies from ground level, our
atmosphere might only allow an arcsec of seeing (scintillation or
twinkling of the stars). This is why you guys over the pond launched
Hubbly into orbit. And ground based astronomers use adaptive optics
these days.
And yes, I am an astrophysicist using LinuxCNC for fun.
Cheers and clear skies,
Karl

Am 18.07.2020 um 19:01 schrieb Gene Heskett:
> But for astrophotography, they are mentioning .01 arc-seconds or better,


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

Re: [Emc-users] pix too big, rejected, so Chris is only other receiver.

[Karl Jacobs]

Hi Gene,

take the attached file for 5mm calibration steps and put it into Cura
for slicing. This is about as simple as it gets for initial tests.
Download
https://www.thingiverse.com/thing:763622 for the benchy-boat torture
test. After you optimized that, you are a master.
Let me tell you that I admire your ambitious mind and perseverance,
knowing your age. Respect!
Karl

Am 05.06.2020 um 19:30 schrieb Gene Heskett:
> On Friday 05 June 2020 08:51:56 andy pugh wrote:
>
>> On Fri, 5 Jun 2020 at 13:34, Gene Heskett 
>> wrote:
>>
>> But before I try another 10 hour print, I'd like to see an improved
>> much
>>
>>> better filled tooth profile, my guess is that its 10% or less, no
>>> high strength fill behind what might be called teeth.  I'd like to
>>> see a 100% fill for at least 4mm behind the teeth, but cura isn't
>>> doing any of that.  Those teeth are 100% crushable all the way to
>>> the bore reinforcement.
>>
>> I have a feeling that you are under-extruding.
>
> That was my impression also, so I sped up the extruder about 3% so far.
>
>> Have you configured and calibrated the printer at all?
>
> The usual piece of paper to set nozzle gap, but adhesion is very poor if
> its not dragging gently.  Nothing for scale fine tuning which seems to
> be dead on.  The instructions I've found and printed have largely
> skipped over most of the stuff I see in the menu's.
>
> Help appreciated, but ATM the place is running on Nat gas power and has
> been since 09:42 am, an hour and a half ago. Power return is auto with
> this standby setup, so I could restart another test print. Anybody have
> a ready made file that will test & gage everything?  Seems like a huge
> thermal effect between hot and running vs cold when doing the auto-home,
> and added an "offsets apply", whatever that is after homeing.
>
> I've sped up the extruder feed, both in cura and in a menu I can't find
> again on the printer, so it should be getting around 115% of its starter
> value this time.
>
> Raised the start temps to 210 and 65, it lays one layer and drops both 10
> degrees for the rest of the run  Made two bird nests laying the raft,
> gave it a spot of hair spray. Stuck. Raised the extruder speed and read
> thru the rest of the help in cura, so we'll see it they know anything in
> about 6 hours.  Or more, I also slowed it down where it claimed better
> rendering.
>
> Thanks all.  Stay well now.
>
> Cheers, Gene Heskett
>


5mm_Calibration_Steps.stl
Description: Binary data
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] missing feature of openscad

[Karl Jacobs]

Gene, just make it executable and run the appImage. I use Cura to slice
for a Delta-printer and use LinuxCNC (actually, Machinekit on a
Beaglebone) to drive the hardware. Marlin on Arduino hardware works
nicely too, of course. Good luck with 3D-printing, just needs the usual
learning curve.
Karl

Am 02.06.2020 um 18:37 schrieb Gene Heskett:
>> When I go to the Cura downloads page it lists - Ultimaker Cura 4.6.1
>> Linux, 64 bit
>>
>> https://ultimaker.com/software/ultimaker-cura
>>
> Ok, I'll bite, what the heck is an apimage?  Better yet, what do I do
> with it on linux?  Debian 9.8 TBE, all up to date.


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

Re: [Emc-users] Beagle hal_arm335xQEP code

[Karl Jacobs]

https://github.com/machinekit/machinekit/tree/master/src/hal/drivers
Regards,
Karl

Am 24.02.2018 um 01:29 schrieb John Dammeyer:

Hi,
How do I get to the source code for the QEP module?
https://github.com/machinekoder/machinekit/wiki/hal_arm335xQEP

Thanks
John Dammeyer


--
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] glade (HAL)spinbutton issue or accident?

[Karl Jacobs]

Great, you got the physics almost right, Gene, except you should have 
said hydrogen *nucleus* aka proton. A hydrogen *atom* is way larger than 
this, about 32E-12 meters, although quantum physics means you can't 
really tell. And was it in G21 or G20?
Cheers,
Karl
Am 24.04.2016 um 14:14 schrieb Gene Heskett:
> On Sunday 24 April 2016 08:05:22 John Thornton wrote:
>
>> >what a crazy step increment, where is that at?
>> >
>> >JT
> One could go from ridiculous to sublime and ask which side of a up quark
> from a hydrogen atom is to be adjusted or cut away? Busted math
> someplace for sure.  Probably in python...
>

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] BeagleBone and LinuxCNC for a lathe.

[Karl Jacobs]

I did exactly that with a BBB and Xylotex cape, using one of the unused 
limit inputs for a single pulse per rev sensor. You might want to follow 
the discussion on
https://groups.google.com/forum/#!topic/machinekit/RW_bnXdXzyE
(you'll have to read up to the end).
You need a little familiarity with redirecting the input pins of the BBB 
to the hardware encoder (eqep) on the BBB processor, and in case of the 
Xylotex cape, I had to remove the large capacitor of the input 
RC-circuit because it smears out the pulses too much. The eqep encoders 
are fully supported in the present machinekit images for BBB.
I did successfully manage to do threading on a small lathe with that 
contraption.
Cheers,
Karl


Am 13.08.2015 um 10:07 schrieb John Dammeyer:
> Forgetting for the moment a controllable speed spindle and just going for a
> single pulse per rev spindle sensor where would I begin to set up this
> system to run a lathe?  I have to use X and Z for the cross slide and lead
> screw respectively.  That leaves the pins for Y and A.  There are limit
> inputs for ESTOP, XYZ & A for limits.

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

Re: [Emc-users] Even smaller things are running G code now

[Karl Jacobs]

You guys must then also know tinyg  (https://www.synthetos.com
working on Atmel XMega, open source code). I was contemplating to use it 
for my small lathe before I learned about Machinekit/LCNC on a 
BeagleBone which now drives it.
Cheers,
Karl

Am 15.06.2015 um 12:48 schrieb Marius Liebenberg:
>I have been following that project from the word go and it is very
> impressive. I wrote a front end for it in C# but it was liberated from
> me along with my computers and laptop during an armed robbery. I
> unfortunately did not have it on github at the time.
>
> I am waiting for the arm version with bated breath :).
>
>
> -- Original Message --
> From: "sam sokolik" 
> To: "Enhanced Machine Controller (EMC)"
> 
> Sent: 2015-06-15 12:21:23
> Subject: Re: [Emc-users] Even smaller things are running G code now
>
>> it is a pretty cool project..  Might want to read some of the work I
>> had
>> done logging it..
>>
>> http://www.cnczone.com/forums/opensource-software/271966-grbl-logging-linuxcnc.html
>>
>> sam
>>
>> On 06/15/2015 02:14 AM, Sven Wesley wrote:
>>>   I replied on a forum about G Code and I had to check up what the heck
>>> he
>>>   was using for his machine.
>>>
>>>   An arduino. And a Java program...
>>>
>>>   https://github.com/winder/Universal-G-Code-Sender
>>>   There's even a Youtube video with a demo and all you need listed in
>>> the
>>>   description.
>>>   https://www.youtube.com/watch?v=1ioctbN9JV8
>>>
>>>   /S
>>>
>>> --
>>>   ___
>>>   Emc-users mailing list
>>>   Emc-users@lists.sourceforge.net
>>>   https://lists.sourceforge.net/lists/listinfo/emc-users
>>>
>>
>>
>> --
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

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

Re: [Emc-users] Backlash - what are ok numbers?

[Karl Jacobs]

Then you must be the guy who can translate Gene Heskett's "three fingers 
in a jelly glass of Jack, Black & neat" into acre-foot, which is one of 
the weirdest measure for volume I ever came across :-)
Karl

Am 07.04.2015 um 17:40 schrieb dave:
> I try to keep the  world right-side-up by a quick reality check: to a
> decent
> approximation 40 thou and 1 mm are equivalent.
>
> I worked in metric all my life ... weight, volume, etc but not distance.
> Since most of what I do now is related to pre-1920 guns I reverse engineer
> in imperial. I can think in mm but it takes a bit of effort.
>
> Dave
>
> On 04/07/2015 04:22 AM, John Alexander Stewart wrote:
>> Karl - Aaargh!
>>
>> And to think I used to work in imperial measurements only. Living around
>> the world, now back in "imperial land" you'd think that I'd still be able
>> to work in "thous" but looks like I can't!
>>
>> Thanks for the correction - John.
>> ​
>> --
>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>> Develop your own process in accordance with the BPMN 2 standard
>> Learn Process modeling best practices with Bonita BPM through live exercises
>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Backlash - what are ok numbers?

[Karl Jacobs]

just for correctness: 0.1mm is about 4 thou, not 2.5 ...
Cheers,
Karl
(a traveller between the metric and imperial parts of this planet)


Am 07.04.2015 um 07:01 schrieb dave:
>
>
> On 04/06/2015 12:29 PM, Gene Heskett wrote:
>> On Monday 06 April 2015 14:12:31 John Alexander Stewart wrote:
>>> Hi all;
>>>
>>> Finally fixed the Oldham couplers for my X/Y axes on my latest build,
>>> and was measuring backlash for inserting in the LinuxCNC ini file.
>>>
>>> This is for a "G0704" style of mill conversion, using one of those
>>> kits from the old KeilingCNC place.
>>>
>>> X/Y/Z is 0.1mm, 0.24mm 0.1mm  or, 2.5 thou, 9 thou, 2.5 thou.
>> The 2.5 thou is a bit loose, bigger balls in the nut perhaps?
>>
>> The 9 thou Y indicates either the thrust bearing at the solidly anchored
>> end of the screw is duff, or perhaps not properly assembled.  I was able
>> to fix one of those in a cheap 16mmx5 Chinese screw on my toy lathes z
>> by padding the outer ring separation with some half thou alu foil shims.
>> Several of them stacked. Tricky to cut too.  Seems to be holding up so
>> far.
>>
>>> Is this considered "ok" or "out of range"?
>>>
>>> I've put these figures in my mill ini file, and it's currently running
>>> the X and Y axes back and forth; will measure it again after a bit of
>>> wearing in.
>>>
>>> Any thoughts/comments?
>>>
>>> (as an aside, Andy Pugh's feedback for spindle soft-gearing works a
>>> treat - thank you again Andy)
>>>
>>> John.
>> Let us know what you found John, it helps the next person with a similar
>> problem.
>>
>> Cheers, Gene Heskett
> I've been dealing with a loose Y axis on my cinci contourmaster; this
> machine
> is set up so one can turn either the ballscrew or the servo motor to adjust
> position. The so-called lock on the servo end was loose and so the backlash
> was self-adjusting;out to unusable amounts.   Ugh. I'm in the process of
> a dual fix ... complete rebuild the mount for the ballscrew so I can
> lock it down tight and add a 10" 5 um glass scale for reference.
> For now I will connect just the glass scale with it's attendant tuning
> problems (just not quite enough counts) but the future holds a config
> where P and D are fed from a 40K count/in encoderon the ballscrew and I
> is driven by the glass scale in like manner to Stu's big machine.
>
> Some years ago I was asked to fab a bunch of blocks for a US First
> robotics team. Set them up and ran as a batch.
> When finished I miked them to see how I'd done. SD was 0.001 but the
> dimensions were all large by about 2 thou. This on a machine (mazak)
> with 0.0025 backlash on both X and Y. Appropriate cutter comp might have
> landed these in the right range if it made a difference. ;-) Just
> personal experience.
>
> Dave
>
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Super-simple linear motor

[Karl Jacobs]

Very cool indeed. A nice one (not quite as spectacular, but yes, I am a 
physicist) that I did often is here (in german, but the video tells it all):
http://www.experimentis.de/experimente-versuche/elektrizitaet-magnetismus/kleinster-elektromotor-der-welt/
This one is closer to making a lathe out of it :-)
Cheers,
Karl

Am 12.02.2015 um 11:15 schrieb andy pugh:
> http://youtu.be/J9b0J29OzAU
>
> I have to try this.
>

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G95 machinekit/linuxcnc not working SOLVED

[Karl Jacobs]

Installing the latest Machinekit package (incidentally now supporting 
the ARM "on-chip" quadrature encoders on a BeagleBone) solved the G95 
problem. Thanks for your helpful suggestions and sorry for pestering you.
Cheers,
Karl


Am 09.12.2014 um 22:33 schrieb Karl Jacobs:
> @sam: I ran sim->axis->lathe on my BeagleBone and it does the same thing
> as the "real" version: no influence of spindle speed to feed rate. Looks
> like a machinekit/BeagleBone or version 2.7.0 issue. I'll find out
> eventually.
>
> @Gene: Yes, I did in fact read the G95 part of the manual, and Sam's
> short code section does just that: give S and F after switching to G95.
> And I agree with you that the folks on this list are very responsive and
> hepful. Thanks for that.
> Karl
>
> Am 09.12.2014 um 20:08 schrieb sam sokolik:
>> well - can you run sim -> axis -> lathe and test G95.  That would tell
>> you if it is a configuration problem vs machinekit.
>>
>> sam
>> On 12/9/2014 11:18 AM, Karl Jacobs wrote:
>>> yes, that is understood and it works as expected ( I checked with hal
>>> meter).
>>> Karl
>>>
>>>
>>> Am 09.12.2014 um 16:08 schrieb sam sokolik:
>>>> threading and feed/rev use 2 different things...
>>>>
>>>> Threading uses:  (encoder position)
>>>> motion.spindle-revs IN FLOAT
>>>> For correct operation of spindle synchronized moves, this signal must be
>>>> hooked to the position pin of the spindle encoder.
>>>>
>>>> FPR uses:  (revolutions/second - encoder velocity)
>>>> motion.spindle-speed-in IN FLOAT
>>>> Actual spindle speed feedback in revolutions per second; used for G96
>>>> (constant surface speed) and G95 (feed per revolution) modes.
>>>>
>>>> So it is 2 different things - one could work without the other..
>>>>
>>>> Sam
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 12/9/2014 8:59 AM, Karl Jacobs wrote:
>>>>> Yes, I know that limitation on the Beaglebone, so I do not expect to
>>>>> operate it with a higher resolution encoder (in fact, just one index
>>>>> mark fedding phase A and phase Z and using encoder.position-interpolated
>>>>> for spindle-revs). I would have the same doubts as you if the G76 and
>>>>> G33 did not work as expected. I am not really discussing the quality of
>>>>> threading (which might be better using a higher resolution encoder). My
>>>>> question was rather why G76 and G33 work fine and G95 not at all.
>>>>> Karl
>>>>>
>>>>>
>>>>> Am 09.12.2014 um 15:43 schrieb sam sokolik:
>>>>>> You are using the hal encoder counter?  On the beagle bone - are you not
>>>>>> limited to just a servo thread?  1khz?  So you are running all the
>>>>>> encoder functions in 1 thread.  I don't know how that would work very
>>>>>> well with the hal encoder counter to calculate velocity.
>>>>>>
>>>>>> You might want to look at the signal going to motion.spindle-speed-in.
>>>>>> It might not be what you are expecting.
>>>>>>
>>>>>> sam
>>>>>>
>>>>>>
>>>>>> On 12/9/2014 8:23 AM, Karl Jacobs wrote:
>>>>>>> Thanks for checking, Sam, and good to know. I'll try sim on my version
>>>>>>> but I doubt it will be different to my "real world" version. I use the
>>>>>>> same low-passed spindle encoder velocity  on spindle-speed-in. I'll try
>>>>>>> to find the difference between the 2.7 and 2.8 code then (or the
>>>>>>> difference to the machinekit branch).
>>>>>>> Karl
>>>>>>>
>>>>>>> Am 09.12.2014 um 14:36 schrieb sam sokolik:
>>>>>>>> I don't have 2.7 here..  But in 2.8(master) lathe sim works as 
>>>>>>>> expected.
>>>>>>>>
>>>>>>>> This short program
>>>>>>>>
>>>>>>>> G95
>>>>>>>> s100m3
>>>>>>>> g1z4f.001
>>>>>>>> g0z0
>>>>>>>> m30
>>>>>>>>
>>>>>>>> Z moves to 4" at .1ipm (which seems right 100*.001=.1)
>>>>>>>> Changing the spindle speed change

Re: [Emc-users] G95 machinekit/linuxcnc not working

[Karl Jacobs]

@sam: I ran sim->axis->lathe on my BeagleBone and it does the same thing 
as the "real" version: no influence of spindle speed to feed rate. Looks 
like a machinekit/BeagleBone or version 2.7.0 issue. I'll find out 
eventually.

@Gene: Yes, I did in fact read the G95 part of the manual, and Sam's 
short code section does just that: give S and F after switching to G95. 
And I agree with you that the folks on this list are very responsive and 
hepful. Thanks for that.
Karl

Am 09.12.2014 um 20:08 schrieb sam sokolik:
> well - can you run sim -> axis -> lathe and test G95.  That would tell
> you if it is a configuration problem vs machinekit.
>
> sam
> On 12/9/2014 11:18 AM, Karl Jacobs wrote:
>> yes, that is understood and it works as expected ( I checked with hal
>> meter).
>> Karl
>>
>>
>> Am 09.12.2014 um 16:08 schrieb sam sokolik:
>>> threading and feed/rev use 2 different things...
>>>
>>> Threading uses:  (encoder position)
>>> motion.spindle-revs IN FLOAT
>>> For correct operation of spindle synchronized moves, this signal must be
>>> hooked to the position pin of the spindle encoder.
>>>
>>> FPR uses:  (revolutions/second - encoder velocity)
>>> motion.spindle-speed-in IN FLOAT
>>> Actual spindle speed feedback in revolutions per second; used for G96
>>> (constant surface speed) and G95 (feed per revolution) modes.
>>>
>>> So it is 2 different things - one could work without the other..
>>>
>>> Sam
>>>
>>>
>>>
>>>
>>>
>>> On 12/9/2014 8:59 AM, Karl Jacobs wrote:
>>>> Yes, I know that limitation on the Beaglebone, so I do not expect to
>>>> operate it with a higher resolution encoder (in fact, just one index
>>>> mark fedding phase A and phase Z and using encoder.position-interpolated
>>>> for spindle-revs). I would have the same doubts as you if the G76 and
>>>> G33 did not work as expected. I am not really discussing the quality of
>>>> threading (which might be better using a higher resolution encoder). My
>>>> question was rather why G76 and G33 work fine and G95 not at all.
>>>> Karl
>>>>
>>>>
>>>> Am 09.12.2014 um 15:43 schrieb sam sokolik:
>>>>> You are using the hal encoder counter?  On the beagle bone - are you not
>>>>> limited to just a servo thread?  1khz?  So you are running all the
>>>>> encoder functions in 1 thread.  I don't know how that would work very
>>>>> well with the hal encoder counter to calculate velocity.
>>>>>
>>>>> You might want to look at the signal going to motion.spindle-speed-in.
>>>>> It might not be what you are expecting.
>>>>>
>>>>> sam
>>>>>
>>>>>
>>>>> On 12/9/2014 8:23 AM, Karl Jacobs wrote:
>>>>>> Thanks for checking, Sam, and good to know. I'll try sim on my version
>>>>>> but I doubt it will be different to my "real world" version. I use the
>>>>>> same low-passed spindle encoder velocity  on spindle-speed-in. I'll try
>>>>>> to find the difference between the 2.7 and 2.8 code then (or the
>>>>>> difference to the machinekit branch).
>>>>>> Karl
>>>>>>
>>>>>> Am 09.12.2014 um 14:36 schrieb sam sokolik:
>>>>>>> I don't have 2.7 here..  But in 2.8(master) lathe sim works as expected.
>>>>>>>
>>>>>>> This short program
>>>>>>>
>>>>>>> G95
>>>>>>> s100m3
>>>>>>> g1z4f.001
>>>>>>> g0z0
>>>>>>> m30
>>>>>>>
>>>>>>> Z moves to 4" at .1ipm (which seems right 100*.001=.1)
>>>>>>> Changing the spindle speed changes the feed.
>>>>>>>
>>>>>>> Looking at hal in the lathe sim - the motion.spindle-speed-in is hooked
>>>>>>> to a low-passed spindle encoder velocity.
>>>>>>>
>>>>>>> sam
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 12/9/2014 6:38 AM, Karl Jacobs wrote:
>>>>>>>> Thanks for the info. If I disconnect spindle-speed-in, G76 and G33 stop
>>>>>>>> working too, so they seem to need both signals somehow, but from what
>>>>>>>&

Re: [Emc-users] G95 machinekit/linuxcnc not working

[Karl Jacobs]

Yes, that was done correctly.

Am 09.12.2014 um 16:07 schrieb andy pugh:
> On 9 December 2014 at 14:59, Karl Jacobs  wrote:
>
>> My
>> question was rather why G76 and G33 work fine and G95 not at all.
>>
>
> Make sure that the value is revs per second, not revs per minute. Not that
> that would explain the observed behaviour, though.
>

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G95 machinekit/linuxcnc not working

[Karl Jacobs]

yes, that is understood and it works as expected ( I checked with hal 
meter).
Karl


Am 09.12.2014 um 16:08 schrieb sam sokolik:
> threading and feed/rev use 2 different things...
>
> Threading uses:  (encoder position)
> motion.spindle-revs IN FLOAT
> For correct operation of spindle synchronized moves, this signal must be
> hooked to the position pin of the spindle encoder.
>
> FPR uses:  (revolutions/second - encoder velocity)
> motion.spindle-speed-in IN FLOAT
> Actual spindle speed feedback in revolutions per second; used for G96
> (constant surface speed) and G95 (feed per revolution) modes.
>
> So it is 2 different things - one could work without the other..
>
> Sam
>
>
>
>
>
> On 12/9/2014 8:59 AM, Karl Jacobs wrote:
>> Yes, I know that limitation on the Beaglebone, so I do not expect to
>> operate it with a higher resolution encoder (in fact, just one index
>> mark fedding phase A and phase Z and using encoder.position-interpolated
>> for spindle-revs). I would have the same doubts as you if the G76 and
>> G33 did not work as expected. I am not really discussing the quality of
>> threading (which might be better using a higher resolution encoder). My
>> question was rather why G76 and G33 work fine and G95 not at all.
>> Karl
>>
>>
>> Am 09.12.2014 um 15:43 schrieb sam sokolik:
>>> You are using the hal encoder counter?  On the beagle bone - are you not
>>> limited to just a servo thread?  1khz?  So you are running all the
>>> encoder functions in 1 thread.  I don't know how that would work very
>>> well with the hal encoder counter to calculate velocity.
>>>
>>> You might want to look at the signal going to motion.spindle-speed-in.
>>> It might not be what you are expecting.
>>>
>>> sam
>>>
>>>
>>> On 12/9/2014 8:23 AM, Karl Jacobs wrote:
>>>> Thanks for checking, Sam, and good to know. I'll try sim on my version
>>>> but I doubt it will be different to my "real world" version. I use the
>>>> same low-passed spindle encoder velocity  on spindle-speed-in. I'll try
>>>> to find the difference between the 2.7 and 2.8 code then (or the
>>>> difference to the machinekit branch).
>>>> Karl
>>>>
>>>> Am 09.12.2014 um 14:36 schrieb sam sokolik:
>>>>> I don't have 2.7 here..  But in 2.8(master) lathe sim works as expected.
>>>>>
>>>>> This short program
>>>>>
>>>>> G95
>>>>> s100m3
>>>>> g1z4f.001
>>>>> g0z0
>>>>> m30
>>>>>
>>>>> Z moves to 4" at .1ipm (which seems right 100*.001=.1)
>>>>> Changing the spindle speed changes the feed.
>>>>>
>>>>> Looking at hal in the lathe sim - the motion.spindle-speed-in is hooked
>>>>> to a low-passed spindle encoder velocity.
>>>>>
>>>>> sam
>>>>>
>>>>>
>>>>>
>>>>> On 12/9/2014 6:38 AM, Karl Jacobs wrote:
>>>>>> Thanks for the info. If I disconnect spindle-speed-in, G76 and G33 stop
>>>>>> working too, so they seem to need both signals somehow, but from what
>>>>>> you say that still does not necessarily mean that G95 must work as well.
>>>>>> I rather suspect the motion planner. Maybe someone can verify if G95
>>>>>> works in the non-machinekit linuxcnc version? I will post to the
>>>>>> machinekit list as well.
>>>>>> Am 09.12.2014 um 12:24 schrieb andy pugh:
>>>>>>> On 9 December 2014 at 08:53, Karl Jacobs  wrote:
>>>>>>>
>>>>>>>> I can rule out hardware problems of an encoder by using a hal siggen
>>>>>>>> component to drive the hal encoder inputs (Phase A and Z, counter mode)
>>>>>>>> to simulate the spindle speed signal. That must be working correctly
>>>>>>>> because G76 and G33 both give the right result (my X and Z axis
>>>>>>>> components drive a real lathe so I can watch and check the motions).
>>>>>>>>
>>>>>>> G76 and G33 use motion.spindle-revs, and G95 uses 
>>>>>>> motion.spindle-speed-in
>>>>>>> So, it is possible to have a fully functional G76 and G33 but not have a
>>>>>>> working G95.
>>>>>>>
>>>>>>> It is possible that this is due to the new mot

Re: [Emc-users] G95 machinekit/linuxcnc not working

[Karl Jacobs]

Yes, I know that limitation on the Beaglebone, so I do not expect to 
operate it with a higher resolution encoder (in fact, just one index 
mark fedding phase A and phase Z and using encoder.position-interpolated 
for spindle-revs). I would have the same doubts as you if the G76 and 
G33 did not work as expected. I am not really discussing the quality of 
threading (which might be better using a higher resolution encoder). My 
question was rather why G76 and G33 work fine and G95 not at all.
Karl


Am 09.12.2014 um 15:43 schrieb sam sokolik:
> You are using the hal encoder counter?  On the beagle bone - are you not
> limited to just a servo thread?  1khz?  So you are running all the
> encoder functions in 1 thread.  I don't know how that would work very
> well with the hal encoder counter to calculate velocity.
>
> You might want to look at the signal going to motion.spindle-speed-in.
> It might not be what you are expecting.
>
> sam
>
>
> On 12/9/2014 8:23 AM, Karl Jacobs wrote:
>> Thanks for checking, Sam, and good to know. I'll try sim on my version
>> but I doubt it will be different to my "real world" version. I use the
>> same low-passed spindle encoder velocity  on spindle-speed-in. I'll try
>> to find the difference between the 2.7 and 2.8 code then (or the
>> difference to the machinekit branch).
>> Karl
>>
>> Am 09.12.2014 um 14:36 schrieb sam sokolik:
>>> I don't have 2.7 here..  But in 2.8(master) lathe sim works as expected.
>>>
>>> This short program
>>>
>>> G95
>>> s100m3
>>> g1z4f.001
>>> g0z0
>>> m30
>>>
>>> Z moves to 4" at .1ipm (which seems right 100*.001=.1)
>>> Changing the spindle speed changes the feed.
>>>
>>> Looking at hal in the lathe sim - the motion.spindle-speed-in is hooked
>>> to a low-passed spindle encoder velocity.
>>>
>>> sam
>>>
>>>
>>>
>>> On 12/9/2014 6:38 AM, Karl Jacobs wrote:
>>>> Thanks for the info. If I disconnect spindle-speed-in, G76 and G33 stop
>>>> working too, so they seem to need both signals somehow, but from what
>>>> you say that still does not necessarily mean that G95 must work as well.
>>>> I rather suspect the motion planner. Maybe someone can verify if G95
>>>> works in the non-machinekit linuxcnc version? I will post to the
>>>> machinekit list as well.
>>>> Am 09.12.2014 um 12:24 schrieb andy pugh:
>>>>> On 9 December 2014 at 08:53, Karl Jacobs  wrote:
>>>>>
>>>>>> I can rule out hardware problems of an encoder by using a hal siggen
>>>>>> component to drive the hal encoder inputs (Phase A and Z, counter mode)
>>>>>> to simulate the spindle speed signal. That must be working correctly
>>>>>> because G76 and G33 both give the right result (my X and Z axis
>>>>>> components drive a real lathe so I can watch and check the motions).
>>>>>>
>>>>> G76 and G33 use motion.spindle-revs, and G95 uses motion.spindle-speed-in
>>>>> So, it is possible to have a fully functional G76 and G33 but not have a
>>>>> working G95.
>>>>>
>>>>> It is possible that this is due to the new motion planner.
>>>>>
>>>>> It is also possible that this is a Machinekit-only problem. Machinekit has
>>>>> now diverged considerably from LinuxCNC, and your query should probably be
>>>>> directed to the Machinekit mailing list.
>>>>>
>>>> --
>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>> ___
>>>> Emc-users mailing list
>>>> Emc-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>>
>>>>
>>>
>>> --
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>&

Re: [Emc-users] G95 machinekit/linuxcnc not working

[Karl Jacobs]

Thanks for checking, Sam, and good to know. I'll try sim on my version 
but I doubt it will be different to my "real world" version. I use the 
same low-passed spindle encoder velocity  on spindle-speed-in. I'll try 
to find the difference between the 2.7 and 2.8 code then (or the 
difference to the machinekit branch).
Karl

Am 09.12.2014 um 14:36 schrieb sam sokolik:
> I don't have 2.7 here..  But in 2.8(master) lathe sim works as expected.
>
> This short program
>
> G95
> s100m3
> g1z4f.001
> g0z0
> m30
>
> Z moves to 4" at .1ipm (which seems right 100*.001=.1)
> Changing the spindle speed changes the feed.
>
> Looking at hal in the lathe sim - the motion.spindle-speed-in is hooked
> to a low-passed spindle encoder velocity.
>
> sam
>
>
>
> On 12/9/2014 6:38 AM, Karl Jacobs wrote:
>> Thanks for the info. If I disconnect spindle-speed-in, G76 and G33 stop
>> working too, so they seem to need both signals somehow, but from what
>> you say that still does not necessarily mean that G95 must work as well.
>> I rather suspect the motion planner. Maybe someone can verify if G95
>> works in the non-machinekit linuxcnc version? I will post to the
>> machinekit list as well.
>> Am 09.12.2014 um 12:24 schrieb andy pugh:
>>> On 9 December 2014 at 08:53, Karl Jacobs  wrote:
>>>
>>>> I can rule out hardware problems of an encoder by using a hal siggen
>>>> component to drive the hal encoder inputs (Phase A and Z, counter mode)
>>>> to simulate the spindle speed signal. That must be working correctly
>>>> because G76 and G33 both give the right result (my X and Z axis
>>>> components drive a real lathe so I can watch and check the motions).
>>>>
>>> G76 and G33 use motion.spindle-revs, and G95 uses motion.spindle-speed-in
>>> So, it is possible to have a fully functional G76 and G33 but not have a
>>> working G95.
>>>
>>> It is possible that this is due to the new motion planner.
>>>
>>> It is also possible that this is a Machinekit-only problem. Machinekit has
>>> now diverged considerably from LinuxCNC, and your query should probably be
>>> directed to the Machinekit mailing list.
>>>
>> --
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>>
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G95 machinekit/linuxcnc not working

[Karl Jacobs]

Thanks for the info. If I disconnect spindle-speed-in, G76 and G33 stop 
working too, so they seem to need both signals somehow, but from what 
you say that still does not necessarily mean that G95 must work as well. 
I rather suspect the motion planner. Maybe someone can verify if G95 
works in the non-machinekit linuxcnc version? I will post to the 
machinekit list as well.
Am 09.12.2014 um 12:24 schrieb andy pugh:
> On 9 December 2014 at 08:53, Karl Jacobs  wrote:
>
>> I can rule out hardware problems of an encoder by using a hal siggen
>> component to drive the hal encoder inputs (Phase A and Z, counter mode)
>> to simulate the spindle speed signal. That must be working correctly
>> because G76 and G33 both give the right result (my X and Z axis
>> components drive a real lathe so I can watch and check the motions).
>>
>
> G76 and G33 use motion.spindle-revs, and G95 uses motion.spindle-speed-in
> So, it is possible to have a fully functional G76 and G33 but not have a
> working G95.
>
> It is possible that this is due to the new motion planner.
>
> It is also possible that this is a Machinekit-only problem. Machinekit has
> now diverged considerably from LinuxCNC, and your query should probably be
> directed to the Machinekit mailing list.
>

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] G95 machinekit/linuxcnc not working

[Karl Jacobs]

Hi,
new to this list with a question about G95 (units per revolution) for 
lathe operation in machinekit/emc/linuxcnc 2.7.0~pre0, running on a 
BeagleBone Black. G76 (threading) and G33 (synchronized motion) works 
nicely and the feed speed in Z reacts to the motion.spindle-speed-in hal 
signal as expected. But G95 gives me feed speeds independent of 
spindle-speed-in, corresponding to a constant one revolution per second 
of the spindle/encoder speed. I see motion.spindle-speed-in changing 
when I command it to change, but no change in Z motion speed (well below 
the speed limits).
I can rule out hardware problems of an encoder by using a hal siggen 
component to drive the hal encoder inputs (Phase A and Z, counter mode) 
to simulate the spindle speed signal. That must be working correctly 
because G76 and G33 both give the right result (my X and Z axis 
components drive a real lathe so I can watch and check the motions). 
What am I doing wrong or not understanding?
Karl

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users