Re: [Emc-users] who has used thin client pcs

[Kenneth Lerman]

These aren't really thin, but they are pretty nice. They are fanless and
use the case as a heat sink.
Made in China.

Qotom Computers
<https://www.amazon.com/QOTOM-celeron-Processor-Fanless-pfSense/dp/B01CSCGD58?th=1>

Kenneth Lerman
55 Main Street
Newtown, CT 06470



On Wed, Feb 9, 2022 at 7:02 PM andrew beck  wrote:

> hey everyone
>
> just wondering who has used the thin client computers
> i am looking for a fanless pc that i can buy in oceania
>
> https://www.youtube.com/watch?v=tVXn_fEbDTs
>
> ___
> 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] Execute MDI command, from hal pin

[Kenneth Lerman]

I've implemented some safe probing routines here
<https://drive.google.com/file/d/1D7_BacRTk4LwG0izKLDASTxHSK0RL5nM/view?usp=sharing>.
They are examples of subroutines that might be called by external switches
-- or in my case from buttons on a pendant.

Ken
Kenneth Lerman
55 Main Street
Newtown, CT 06470



On Sat, Feb 5, 2022 at 6:54 PM Kenneth Lerman  wrote:

> The other half of the pins that Sebastian mentioned is that the commands
> must be defined in the .ini file.
>
> This
> <https://linuxcnc.org/docs/2.6/html/config/ini_config.html#sub:HALUI-section> 
> will
> tell you that you can put things like:
>
>-
>
>*MDI_COMMAND = G53 G0 X0 Y0 Z0* - An MDI command can be executed by
>using halui.mdi-command-00. Increment the number for each command listed in
>the [HALUI] section.
>
> The first such entry will be executed when halui.mdi-command-00 is
> asserted. The second corresponds to -01, etc.
>
> You might then write subroutines to do such things as jog in +X, -X, +Y,
> -Y, etc. Those subroutines might save the direction of the last jog. You
> could also have a subroutine to use your touch probe. It could be "smart
> enough" to probe in the direction of the last jog.
>
> Ken
>
>
> Kenneth Lerman
> 55 Main Street
> Newtown, CT 06470
>
>
>
> On Sat, Feb 5, 2022 at 5:56 PM Sebastian Kuzminsky 
> wrote:
>
>> On 2/5/22 1:13 PM, Nicklas SB Karlsson wrote:
>> > Anybody know about a method to execute a MDI command with g-code then
>> on
>> > a hal pin flank?
>>
>> I'm not entirely sure what you're asking for, but one of my machines has
>> a hardware button coming in to HAL through a gpio, connected to a halui
>> input which triggers an MDI command.  Check out halui.mdi-command-XX:
>>
>> http://linuxcnc.org/docs/devel/html/man/man1/halui.1.html#PINS
>>
>>
>> --
>> Sebastian Kuzminsky
>>
>>
>> ___
>> 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] Execute MDI command, from hal pin

[Kenneth Lerman]

The other half of the pins that Sebastian mentioned is that the commands
must be defined in the .ini file.

This
<https://linuxcnc.org/docs/2.6/html/config/ini_config.html#sub:HALUI-section>
will
tell you that you can put things like:

   -

   *MDI_COMMAND = G53 G0 X0 Y0 Z0* - An MDI command can be executed by
   using halui.mdi-command-00. Increment the number for each command listed in
   the [HALUI] section.

The first such entry will be executed when halui.mdi-command-00 is
asserted. The second corresponds to -01, etc.

You might then write subroutines to do such things as jog in +X, -X, +Y,
-Y, etc. Those subroutines might save the direction of the last jog. You
could also have a subroutine to use your touch probe. It could be "smart
enough" to probe in the direction of the last jog.

Ken


Kenneth Lerman
55 Main Street
Newtown, CT 06470



On Sat, Feb 5, 2022 at 5:56 PM Sebastian Kuzminsky  wrote:

> On 2/5/22 1:13 PM, Nicklas SB Karlsson wrote:
> > Anybody know about a method to execute a MDI command with g-code then on
> > a hal pin flank?
>
> I'm not entirely sure what you're asking for, but one of my machines has
> a hardware button coming in to HAL through a gpio, connected to a halui
> input which triggers an MDI command.  Check out halui.mdi-command-XX:
>
> http://linuxcnc.org/docs/devel/html/man/man1/halui.1.html#PINS
>
>
> --
> Sebastian Kuzminsky
>
>
> ___
> 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] What Would You Suggest?

[Kenneth Lerman]

Hi John,

I'm planning on controlling two axes. The third axis (vertical) would
require a lot more gearing and my general experience is machine a surface,
measure, drop down, machine some more, repeat.

The ELS type of thing is about what I have in mind. Jog to set the xmin,
xmax, ymin, ymax. Set a mode. Select a stepover. Hit go.

Martin pointed me at the teensy computers. They have a 3.2 inch touch
screen that might be just the thing to control this. The stepper library
should do the job very nicely.

Ken

Kenneth Lerman
55 Main Street
Newtown, CT 06470



On Fri, Feb 4, 2022 at 3:22 PM John Dammeyer  wrote:

> In wanting to automate this grinder exactly how many axis do you want to
> control.
> I can see the movement of the table back and forth at that 1 RPM.  I can
> see the cross slide at the end of each pass or pass and return?
> Finally I guess depth might also be desired to a total depth?
>
> If depth was adjusted manually then my ELS can be configured to do
> something like this:
> http://www.autoartisans.com/ELS/
> I'd set it up to turn the Z axis for BEGIN, END positions to move the
> table in the X axis directions.
> I'd set the X axis for the 'depth' of each pass so it would move the table
> across using some of the parameters to fool it into not retracting but
> either moving further in for the pass in the other direction or moving the
> stone out of the way for the return.
>
> But then that's just as easy with some simple G-Code and one of those far
> east CNC control boxes like this:
> https://www.aliexpress.com/item/1005003646128482.html
> For $140 Cdn with free shipping it's almost worth the risk to buy it and
> try it.  You need stepper motor drivers, power supply, motors and pulleys
> anyway.
>
> > -Original Message-
> > From: Martin Dobbins [mailto:tu...@hotmail.com]
> > Sent: February-04-22 10:47 AM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] What Would You Suggest?
> >
> > Hi Kenneth,
> >
> > I don't know if this will be any use to you at all, and it's not
> Linuxcnc at least not yet.
> >
> > I an effort to emulate this:
> >
> > https://www.youtube.com/watch?v=z4t8pmsnYow
> >
> > Which is all powered by a PIC
> >
> > I liked this but didn't want to use a PIC.  Tried first with an Arduino
> because I had one on hand, but that just wasn't going to work.
> > So, I moved to one of these and got the 3.2 version:
> >
> > https://www.pjrc.com/teensy/
> >
> > Partly because it has an excellent library for controlling steppers:
> >
> > https://luni64.github.io/TeensyStep/
> >
> > It's driving a NEMA 34 1805 oz/in through one of these
> >
> > http://www.leadshine.com/uploadfile/down/ma860hm.pdf
> >
> > which will work with AC or DC
> >
> > So, one of these:
> >
> > https://www.ebay.com/itm/194282558090
> >
> > On the back of which is a jumper to set input voltage 240, 220, 200,
> 110.  With outputs on the back for 110v and 220v.  It's intended
> > to be a travel item so your 110 volt stuff will work on 220v and vice
> versa. A step up step down transformer.  If you lie to it you can
> > feed it 118v to 120v (what comes out of my wall sockets) and get it to
> supply lesser AC volts to the stepper driver.
> >
> > If you're still awake?
> >
> > I can get 2000 rpm plus out of that big stepper, but I don't need speed
> like that, I need torque, so it's geared down 4:1 with the
> > spindle it's driving (when the stepper's rotating at a leisurely 25 rpm
> the spindle is turning at 100 rpm).  It's still an unfinished project.
> >
> > I'm envious of that grinder.
> >
> > Martin
> >
> > 
> > Kenneth Lerman wrote:
> >
> >
> > Chris -- At my house, computers are all over the place. I think I have a
> > spare atom floating around. Also a couple of other machines.
> > Gene -- The grinder is here.
> > <
> https://drive.google.com/file/d/1L8JiX0rtDZO99rVnQKNjUH7m-ZgFz2Un/view?usp=sharing
> >
> > The
> > ways look pretty clean. The only accessory I have is a magnetic chuck.
> >
> > I don't really need a surface grinder, but no shop is complete without
> one.
> > Once I started to use it, I realized that my right arm and shoulder
> really
> > aren't suited to this type of manual work.
> >
> > The longitudinal travel is just over a foot, and it takes about 3-1/2
> turns
> > of the crank to go that distance. I'm thinking around  a second per 

Re: [Emc-users] What Would You Suggest?

[Kenneth Lerman]

I don't think I'm ready for yet another hobby (3-D printing), so I think
I'll just put an oversized motor and pulley.

Gene -- What stepper family are you using for the lathe? (A link, please.)

Regards,

Ken


Kenneth Lerman
55 Main Street
Newtown, CT 06470



On Fri, Feb 4, 2022 at 12:25 PM gene heskett  wrote:

> On Friday, February 4, 2022 10:31:23 AM EST Kenneth Lerman wrote:
> > Chris -- At my house, computers are all over the place. I think I have
> > a spare atom floating around. Also a couple of other machines.
> > Gene -- The grinder is here.
> > <https://drive.google.com/file/d/1L8JiX0rtDZO99rVnQKNjUH7m-ZgFz2Un/view
> > ?usp=sharing> The
> > ways look pretty clean. The only accessory I have is a magnetic chuck.
> >
> Cute little thing Ken. And with a mag chuck, you stole it.
>
> > I don't really need a surface grinder, but no shop is complete without
> > one. Once I started to use it, I realized that my right arm and
> > shoulder really aren't suited to this type of manual work.
>
> As the senior member here, I get to complain first :) But you're excused
> ;o)
> As to you gear ratio problems, I agree, which is why I designed a small
> variation of a harmonic drive for use on the A axis of my 6040 mill. But
> its too small I think for what you want to do. But the 3d slicer "cura"
> can scale, and if you've a 3d printer that can handle PETG, one of the
> higher temp plastics, on an everyday basis, this thing scaled up 200%
> should do the job for you ok. Gear ratio, about as high as it can go at
> the native size is 50/1 but could be as low as 30/1.
>
> I'm driving it with a 1NM version of the new 3 phase stepper/servo's, but
> that family of servo's can be had at 3NM or about 425 oz/in, as all have
> an 8mm diameter d-flated shaft, which I put on my milling machine, power
> up to lock it and make the flat bigger, so the measurement from flat to
> back of the round is 6.5mm. With a printed armature hub that grips the
> whole shaft its strong enough in PETG that no hard to machine metal hub
> insert is needed. In my size, I can make 2 of them out of a $20 kilo of
> PETG, and a small bottle of crosman bb's, or about 15$ a drive. At a
> scaleup for what you need, about 200%, will x4 the amount of filament,
> and probably x4 the print time too but I don't see why it won't work if
> you wanted to try it. My whole idea is cheap, if it breaks, print
> another.
>
> > The longitudinal travel is just over a foot, and it takes about 3-1/2
> > turns of the crank to go that distance. I'm thinking around  a second
> > per turn would be about the maximum. So, that's 60 RPM. I'm thinking
> > of a 1:6 ratio on the timing belt pulleys, so that's 360 RPM at the
> > stepper which is pretty slow. A full stepping rate would be 200 *
> > 360/60 => 200 * 6 which is only 1200 steps per second.
> >
> > An alternative would be to provide more gearing, but I don't think it's
> > practical to get more than about a six to one ratio in a single belt
> > reduction and I'd like to avoid mechanical complexity if I can.
>
> OpenSCAD, which I used to design this, is quite capable of doing any part
> that fits on the bed of your 3d printer. And if at 87 I can learn it, I'm
> convinced you could too.
>
> Two OpenSCAD master files, are text files, and this drive and the driver
> sprocket to replace the alu crap that came on this A drive originally,
> total about 1400 LOC, several hundred of which is comments so I can
> figure out a month from now, what the heck I was doing. Lots of it is
> from thingiverse, and modified by me. But the final version hasn't made
> it to my web site, yet... Something about the only time a program is
> finished is when someone shoots the programmer.
>
> I am also driving my converted 11x54 Sheldon lathe with the 3NM and 2NM
> versions of this motor/driver stepper/servo. And driven by LinuxCNC
> running on a rpi4, its doing dance steps that it could not do 80 years
> ago when it was shipped to the navy. Including correcting for the 13 thou
> of bed wear right in front of the chuck. This lathe has been rode hard,
> thrown across the truck bed going around a corner too fast and put away
> wet long before it followed me home in a cargo van.
>
> If interested, give me you PM address and I'll email the .scad to you.
>
> > Thoughts?
>
> Take care and stay well.
>
> > Ken
> >
> > Kenneth Lerman
> > 55 Main Street
> > Newtown, CT 06470
> >
> Cheers, Gene Heskett.
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, 

Re: [Emc-users] What Would You Suggest?

[Kenneth Lerman]

Chris -- At my house, computers are all over the place. I think I have a
spare atom floating around. Also a couple of other machines.
Gene -- The grinder is here.
<https://drive.google.com/file/d/1L8JiX0rtDZO99rVnQKNjUH7m-ZgFz2Un/view?usp=sharing>
The
ways look pretty clean. The only accessory I have is a magnetic chuck.

I don't really need a surface grinder, but no shop is complete without one.
Once I started to use it, I realized that my right arm and shoulder really
aren't suited to this type of manual work.

The longitudinal travel is just over a foot, and it takes about 3-1/2 turns
of the crank to go that distance. I'm thinking around  a second per turn
would be about the maximum. So, that's 60 RPM. I'm thinking of a 1:6 ratio
on the timing belt pulleys, so that's 360 RPM at the stepper which is
pretty slow. A full stepping rate would be 200 * 360/60 => 200 * 6 which is
only 1200 steps per second.

An alternative would be to provide more gearing, but I don't think it's
practical to get more than about a six to one ratio in a single belt
reduction and I'd like to avoid mechanical complexity if I can.

Thoughts?

Ken

Kenneth Lerman
55 Main Street
Newtown, CT 06470



On Fri, Feb 4, 2022 at 7:13 AM Chris Albertson 
wrote:

> If looking for lowest cost solution you can us the old "Atom" computer to
> control the grinder as long as you do not  need to run the mill and
> grider at the same time.  Get an Eiternet interface Mesa card for the new
> machine,  You need two config files, just load the one for the mill or the
> one for the grinder.
>
> Then someday you buy a second computer you only have to move the Ethernet
> cable over.   The best option is a newer version of the Atom.  They seem to
> sell for just under $200.   Finally Newegg.com always has many used oe
> refurb PCs   Used PCs sourced locally can be a cheap as "free"
>
> But 9ld PCs tend to burn up a lot of power.  I am trying to get mone to do
> "wake on LAN" so it can not use power until I need to log onto it
>
> On Thu, Feb 3, 2022 at 6:52 PM Kenneth Lerman  wrote:
>
> > I'm considering converting a surface grinder to CNC. To start, I'll
> > probably just convert the longitudinal and transverse axes.
> >
> > I'll go with steppers for this -- I'm thinking NEMA-42 motors.
> >
> > My current Bridgeport clone uses servos and Jon Elson's hardware on a
> > little Intel Atom Box. I'm thinking of using a Rpi for this. It will
> need a
> > minimal display/control panel when completed, but initially will need a
> > display with touchscreen or mouse and possibly a keyboard. In the long
> run,
> > some buttons. and perhaps an mpg might be useful.
> >
> > I'd like to use a raw Rpi without adding special hardware directly. That
> > probably means using a USB or ethernet interface to control the steppers.
> > I'm thinking of using Mesa hardware.
> >
> > Can someone suggest the most cost effective way to do this? (Although I
> > have to admit, that after buying the timing belts and pulleys, the
> > steppers, power supply, stepper drivers, ..., it's too late to be really
> > cost effective.). And the surface grinder only cost me $300.
> >
> > Thanks,
> > Ken
> >
> >
> >
> > Kenneth Lerman
> > 55 Main Street
> > Newtown, CT 06470
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
>
> ___
> 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] What Would You Suggest?

[Kenneth Lerman]

I'm considering converting a surface grinder to CNC. To start, I'll
probably just convert the longitudinal and transverse axes.

I'll go with steppers for this -- I'm thinking NEMA-42 motors.

My current Bridgeport clone uses servos and Jon Elson's hardware on a
little Intel Atom Box. I'm thinking of using a Rpi for this. It will need a
minimal display/control panel when completed, but initially will need a
display with touchscreen or mouse and possibly a keyboard. In the long run,
some buttons. and perhaps an mpg might be useful.

I'd like to use a raw Rpi without adding special hardware directly. That
probably means using a USB or ethernet interface to control the steppers.
I'm thinking of using Mesa hardware.

Can someone suggest the most cost effective way to do this? (Although I
have to admit, that after buying the timing belts and pulleys, the
steppers, power supply, stepper drivers, ..., it's too late to be really
cost effective.). And the surface grinder only cost me $300.

Thanks,
Ken



Kenneth Lerman
55 Main Street
Newtown, CT 06470

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

Re: [Emc-users] Choice of CNC conversions

[Kenneth Lerman]

Hi Gene,

Don't give up your only ethernet port. Instead, add one with a $10 USB
dongle.

Regards, Ken

Kenneth Lerman
55 Main Street
Newtown, CT 06470



On Mon, Dec 27, 2021 at 4:37 PM gene heskett  wrote:

> On Sunday, December 26, 2021 1:30:42 PM EST John Dammeyer wrote:
> > Hi Mark,
> > I'll summarize your basic premise here that all machines are different.
> > That's true!
> >
> > And MACH2/3/4 has a huge user base without ever needing a command line
> > editor.  So if it can be done for Windows then certainly it can be done
> > for LCNC.
> >
> > Having said that I'm also not suggesting we do away with the underbelly
> of
> > what is LCNC.   Please recall my original post in this subject.   The
> > ACORN based system cannot run an old iron system with existing servo
> > drives.  It's likely it can't even run a system with a STMBL drive that
> > faults on low power supply voltage which mine does because I have a soft
> > start delay on mine so ENABLE shows up before the Voltage is there.
> > Doesn't look like it can even do step/dir for the spindle (which MACH3
> > can).  So there is a place for the 'raw' LinuxCNC install and HAL/INI
> > file model.
> >
> > But that user I mentioned wasn't interested in learning a new OS and the
> > ACORN was a one stop shop for the Ethernet controlled step/dir/VFD/IO
> > board and windows CNC software.  He went with Clearpath Servos so he
> > wasn't adverse to spending money.  He could just as easily have installed
> > LCNC 2.8.2 and the MESA board with terminal strips and used the config
> > screens in AXIS and I suspect for less money.  But the LinuxOS itself
> > appeared to also scare him away so he likely would never be a user.
> >
> > I think everyone who likes using an editor for configuration and issuing
> > multiple commands with a command line interface has already been brought
> > over to the dark side so to speak.   They aren't the market for expanding
> > the LCNC user base.
> >
> > I've attached a screen shot of something I've been playing with.  Took
> > about an hour to write using a modern GUI based software development
> > tool; in this case Lazarus Free Pascal.  The TCanvas Property has all
> > sorts of drawing tools so I thought I'd take a quick look at the Axis
> > source code.  To see how easy it would be to port over the Preview screen
> > to Pascal.
> >
> > I was immediately reminded of something I written many years ago by
> > Nicholas Wirth the author of Pascal.  "Those who learn Fortran as their
> > first language are brain damaged for life". Rather harsh actually and
> > taken out of context appears elitist .  OTOH, 4195 lines of essentially
> > undocumented python code does look like a lot of the Fortran code the
> > Electrical Engineers were writing in University while we in the Comp Sci.
> > stream were writing in structured languages Algol-68.  And those were not
> > for GUI type interfaces which add to complexity.
> >
> > For example:
> > if o.canon:
> > x = (o.canon.min_extents[0] + o.canon.max_extents[0])/2
> > y = (o.canon.min_extents[1] + o.canon.max_extents[1])/2
> > z = (o.canon.min_extents[2] + o.canon.max_extents[2])/2
> > o.set_centerpoint(x, y, z)
> >
> > If you go searching for o.cannon you find:
> >   o.canon = canon = AxisCanon(o, widgets.text, i, progress, arcdivision)
> >
> > Search for AxisCAnon and we find the object definition:
> > class AxisCanon(GLCanon, StatMixin):
> >
> > Now we're into the include side of things where the rs274 library is
> > needed: from rs274.interpret import StatMixin
> > from rs274.glcanon import GLCanon, GlCanonDraw
> >
> > which takes us to here:
> > https://github.com/LinuxCNC/linuxcnc/blob/master/lib/python/rs274/
> glcanon.
> > py which is another 1886 lines of undocumented code.
> >
> > The excuses that will be made for no documentation will be the same ones
> > given for command line operation of Linux and LCNC.   It's much better
> > than windows or it's self documenting. You just have to learn a few
> > commands and you can do so much more than with windows
> >
> > I believe we need to step outside the box and ask ourselves this
> question.
> >  How can we attract more people who just want simple CNC (maybe without
> > limit switches even), a VFD and encoder on the spindle and possibly
> > coolant or a few other outputs.
> >
> > One really simple way is that the companies (or peopl

Re: [Emc-users] Probing

[Kenneth Lerman]

Hi Gene,

I gave up on centering my cheap probe because it really isn't necessary. I
don't need the probe to be concentric with the spindle if I know the
offset. My procedure is:

   - center a hole under the spindle. For a hole, I've created a fixture
   with a magnet holding a bearing. To center it, I put the right size drill
   rod in a collet in the spindle
   - Find the center of the hole with the probe and save the coordinates.
   - Now rotate the probe 180 degrees. To do that, I've added wings to my
   probe that contact a vertical rod on the side of my mill.
   - Find the center of the whole with the probe. The difference in the two
   readings represents twice the X and Y offsets of the probe.
   - Now when you use the probe, you can just subtract that offset from the
   actual measurement.

I've written subroutines to do that and to save the offset values. I also
have probing routines to do things like finding centers, finding edges,
etc. Those routines are invoked by buttons on my pendant. Unlike Verser's
routines all probing motions are "safe". By safe, I mean that all motions
use the probing versions of motion so they stop when the probe hits
something. (I bent my first probe using Verser's routines.) The probing
routines know about the direction of the last motion directed by the
pendant, so they probe in that direction.

See: safe probe source
<https://drive.google.com/file/d/1D7_BacRTk4LwG0izKLDASTxHSK0RL5nM/view?usp=sharing>

Ken


Kenneth Lerman
55 Main Street
Newtown, CT 06470



On Sun, Oct 24, 2021 at 1:19 PM Gene Heskett  wrote:

> On Sunday 24 October 2021 11:30:07 Feral Engineer wrote:
>
> > I use work with probe, but I am going to customize the routines a
> > little to work the way I want them to and Andrew Beck I believe uses
> > his probes.
> >
> > Phil T.
> > The Feral Engineer
> >
> > Check out my LinuxCNC tutorials, machine builds and other antics at
> > www.youtube.com/c/theferalengineer
> >
> > Help support my channel efforts and coffee addiction:
> > www.patreon.com/theferalengineer
> >
> > On Sun, Oct 24, 2021, 11:01 AM andy pugh  wrote:
> > > On Sun, 24 Oct 2021 at 08:02, John Dammeyer 
> > >
> > > wrote:
> > > > Is anyone using
> > > > https://github.com/verser-git/probe_screen_v2
> > > >
> > > > Any comments about it?
> > >
> > > About 50 pages of comments here:
> > >
> > > https://forum.linuxcnc.org/49-basic-configuration/29187-work-with-pr
> > >obe?start=0
> > >
> > > Verser also sells relatively inexpensive touch-probes:
> > > https://vers.by/en/16-touch-probes
>
> I don't think its a verser product, but the plastic one I bought 5 years
> ago, looks just like the right pix but without the usb connector,
> straight wire into it. Despite many repeated attempts to adjust it, has
> never come within 20 thou of making a repeatable finding. The plastic by
> now is cracked like a century old china bowl and was already crazed when
> it was shipped. Worthless when I paid nearly $200 for it several years
> ago, and still worthless at whatever it is selling for today. I left an
> unfavorable review and was threatened with a lawsuit for libel.
>
> 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 <http://geneslinuxbox.net:6309/gene>
>
>
> ___
> 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] Maybe a minimally printed harmonic drive?

[Kenneth Lerman]

Has anyone tried using polypropylene  for the flex component? I believe PP
is used for live hinges.

Ken
Kenneth Lerman
55 Main Street
Newtown, CT 06470



On Fri, Apr 30, 2021 at 11:26 PM  wrote:

> I haven't been following your project recently but am intrigued by "And it
> turns the armature easy enough the 3NM 3 phase motor (those are magic
> folks,
> running 50C cooler than 2 phase stuff) I'll use will not be a bit
> overstressed." Where did you end up getting your motors and what are you
> using for drivers?
>
> -Original Message-
> From: Gene Heskett 
> Sent: April 30, 2021 10:45 PM
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] Maybe a minimally printed harmonic drive?
>
> On Monday 22 March 2021 09:19:19 Sam Sokolik wrote:
>
> > 202,200 for the outside spline and the flex gear is 200.  In this
> > situation - the 202 tooth spline is stationary to the stepper.  The
> > 200 tooth outside spline is mounted to the faceplate.  In this layout
> > - the ratio apears to be 101:1
> >
> > In this situation the stepper motor and the face plate spin the same
> > direction.
> >
> > With the same set of outside spines swapped - the ratio is 100:1
> >
> > I am sure Andy can explain it.  It doesn't make sense to me.
> >
> > Happy with runout...  https://www.youtube.com/watch?v=eLyP2YwdstQ
> >
> > sam
> I am running some behind you Sam, with my project, having printer problems
> kills time and money. Finally settled on an ender 5 Plus, which is working
> passably well but I've wasted $3k getting there.
>
> Any way, I changed the design some from yours, to a 30/1 because those big
> spines print better, and by making my own bearings in openscad, useing
> crosman bb's for balls. I put a huge one with over 150 loose bb's directly
> on the outside of the moving spline, with only the lip of the output
> coupling disc (printed of course) interposed. And the floating spline has 3
> more of those, sized for a good friction fit inside that spline, with both
> the spline and the bearings made as thin as practical to improve the flex
> life, and I just took the eliptical armature off the build plate and
> wiggled
> in into those 3 bearings inside the loose spline, so thats the driver
> armature, no commercial ball bearings anyplace like yours.  I've made the
> 8mm hole in the plastic for the motor shaft into a prominent D-flat, and
> used a cbn wheel to make the flat much wider on the motor shaft, and this
> armature will be driven onto the motor shaft without any grub screws at
> all.
> No clue how long it will run before it bores that hole out and I have to
> make an alu inner for it. :(
>
> But I just now assembled it without the motor, turning the armature by
> hand,
> and it works, with no detectable backlash. And it turns the armature easy
> enough the 3NM 3 phase motor (those are magic folks, running 50C cooler
> than
> 2 phase stuff) I'll use will not be a bit overstressed.  Those bb's will
> pound the plastic smooth and get smoother with use.
>
> So now its time to finish the output shaft, and make the rest of the
> housing. Which will be supported by the big bearing at the spline end, and
> 4
> of the printed bearings at the load end. I've got the motor end gnawed out
> of some 1" stock I had, and I bought a foot of 3.125" thick by 6" wide
> stuff
> so I can make 2 output housings. That showed me the current price for
> extruded alu, scary. I also bought enough rod to make about 4 output
> shafts,
> over $200. And I've a spare 4" chuck from a TLM upgrade to a 5" to use on
> it. Or better yet, buy another 5" from LMS.
> So I'll get there, if I don't fall over first. At my age, thats always a
> possibility.
>
> I'll try to get some pix of what I've got so far, put up on my web page
> over
> the weekend. Along with some of the openscad source files.
>
> As usual, this stuff keeps me alone, safe, and out of the bars. :-)
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>
> ___
> 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] (Off topic) A Question Re: BOBs and Opto-Isolators

[Kenneth Lerman]

They are actually rated from zero Hz (DC) to 100MHz.

Ken

Kenneth Lerman
55 Main Street
Newtown, CT 06470



On Mon, Oct 14, 2019 at 5:27 AM Gene Heskett  wrote:

> On Sunday 13 October 2019 19:46:55 Kenneth Lerman wrote:
>
> > Hello All -- especially Gene,
> >
> > I've seen many posts on the lists regarding breakout boards and
> > dealing with issues regarding slow opto-isolators. I have a question:
> >
> > Is anyone using: ISO776x
> > <http://www.ti.com/lit/ds/symlink/iso7760.pdf> devices?
>
> I've seen that pdf before, but in the cases where I've simply bypassed
> them, I had good solid, noise free sources to start with.  If I use a
> BoB, its a Saintsmart, simply because there is not any opto's in their
> output path, and most outputs goto the input opto's of a stepper driver,
> which I've found is a bit faster than the average bear. A 2M542 for
> instance can, if the drive is good rail to rail stuff, be driven to
> about 375k steps a second before it miss-behaves!  That will turn a
> nema-23  motor rated for 270 oz/in, to over 3000 rpms if the supply
> voltage is pushing the 2M542 at around 42 volts.  Nearly 2000 revs at 28
> volts.
>
> I suspect the reason they aren't used may have something to do with the
> cost, or possibly the fact that they are capacitively coupled and very
> low re-rate signals might drift back to their default state, without any
> change in the input voltage.
>
> But thats, to me, just a SWAG.
>
> The most glaring example of too slow in my stuff is the 1000 line encoder
> sitting on top of the G0704 spindle motor, an ABX encoder, and the
> resultant "scale" is over 14,000 in the .ini file, and thats way too
> fast for an opto.  So I have 2, $2, rs485 convertors to make single
> ended rail to rail logic out of the encoders differential outputs, Those
> 2 single ended signals are now being fed to a sainsmart bob whose optos
> I have bypassed, and on to the 5i25. Works perfectly.
>
> I have switches on the gearshift knob that tell my .hal file which gear
> its in, or no gear in case its between gears, in which case I feed the
> pid just enough offset to make the motor spin maybe 25 rpm when its out
> of gear, making gear shifts slick and painless while its running! When
> its in gear by the last degree and one of the switches is closed, the
> circuit then scales the "scale" by the gear and restores the speed input
> from lcnc, and 200ms later the spindle is back up to the set S speed
> even if its 3000 revs. Thats 800 revs faster than OEM.
>
> The 5i25 encoders x input is still the x input from the original optical
> encoder wheel I made.  And with that high a resolution, quantization
> noise is essentially gone, and I can run the spindle pid's PGain at 40
> or so, but 20 is unconditionally stable.
>
> With 126 volts in the motor supply feeding one of Jon's pwm-servo amps to
> that 90 volt, 9.7 amp rated motor, I'm getting close to 2hp at the
> amplifiers 17 amp limit, rigid tapping in steel with a 3/8's" tap can be
> done by pecking in steel or cast, going about 1/2 turn per peck. No
> change in the speed until that 17 amps limit makes its iron chirp.
>
> And I'm amazed that the plastic gears in that 2 speed head are still
> working, by all rights I should have stripped the teeth  off them by
> now.  Tough stuff.
>
> > They are 100 MHz data rate devices, have high isolation, have six in a
> > package, and look like they would work just fine. The only downside
> > might be that they are limited to 5.5 volts on the output, so you
> > might need to add a transistor driver after them. And all of the ones
> > in a single package share a ground.
> >
> > I hadn't seen them before, so I thought I'd mention them.
> >
> They look like they'd be perfectly usable in an active circuit, but I'd
> have reservations about putting one in a home or limit switch circuit
> until we find out what their dc characteristics are.
>
> > Regards,
> >
> > Ken
> >
> > Kenneth Lerman
> > 55 Main Street
> > Newtown, CT 06470
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>
> ___
> 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] (Off topic) A Question Re: BOBs and Opto-Isolators

[Kenneth Lerman]

Hello All -- especially Gene,

I've seen many posts on the lists regarding breakout boards and dealing
with issues regarding slow opto-isolators. I have a question:

Is anyone using: ISO776x <http://www.ti.com/lit/ds/symlink/iso7760.pdf>
 devices?

They are 100 MHz data rate devices, have high isolation, have six in a
package, and look like they would work just fine. The only downside might
be that they are limited to 5.5 volts on the output, so you might need to
add a transistor driver after them. And all of the ones in a single package
share a ground.

I hadn't seen them before, so I thought I'd mention them.

Regards,

Ken

Kenneth Lerman
55 Main Street
Newtown, CT 06470

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

Re: [Emc-users] Unusual help request.

[Kenneth Lerman]

My suggestion:

Use ethernet to optical fiber: https://www.fs.com/products/35333.html is
$23. An SX module https://www.fs.com/products/11774.html is $6.00. Off
hand, I don't know how much the fiber costs, but it's cheaper than copper.

I've purchased these from fs.com and they are helpful and easy to deal with.

Ken


On Sun, May 19, 2019 at 1:22 PM Peter C. Wallace  wrote:

> On Sun, 19 May 2019, Nicklas Karlsson wrote:
>
> > Date: Sun, 19 May 2019 18:27:44 +0200
> > From: Nicklas Karlsson 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: "Enhanced Machine Controller (EMC)"  >
> > Subject: Re: [Emc-users] Unusual help request.
> >
> >> On Sun, 19 May 2019, Davide wrote:
> >>
> >>> Date: Sun, 19 May 2019 16:26:26 +0200
> >>> From: Davide <77...@tiscali.it>
> >>> Reply-To: "Enhanced Machine Controller (EMC)"
> >>> 
> >>> To: Emc-users@lists.sourceforge.net
> >>> Subject: [Emc-users] Unusual help request.
> >>>
> >>> Hi, I have a strange setup to solve. So I'm asking you an help, on the
> top
> >>> of your knowledge (sorry for any language mistake) Some time ago I have
> >>> built an inverted wire tetrapod, which was made by 4 winches placed at
> a max
> >>> distance of 20 meters one each other in a rectangular shape. So until
> now it
> >>> was ok to have a 48v 20A DC power supply and a parallel bob near my pc
> (an
> >>> asrock q1900b-itx), and transmit step/dir signals thru ethernet cables
> to
> >>> the stepper drivers inside the winches.
> >>>
> >>> Now I have to modify that to make a very little object fly inside a
> soccer
> >>> arena, so the motors will be placed at 80 meters one each other, and
> i'm
> >>> really worried that a step every 10 will arrive to the drivers, if any
> at
> >>> all.. The further motor will be at 150mt if I'm lucky..
> >>>
> >>> An idea can be a mesa ethernet card, but I should use 4 of them, so I'm
> >>> asking you if you think is possible to make 4 of them work with
> linuxcnc?
> >>>
> >>> Another can be convert in some way step dir signals to optic fiber
> >>> transport. But i couldn't find anything to buy.
> >>>
> >>> Any other suggestion?
> >>> Thanks, Davide.
> >>>
> >>
> >>
> >> 150 meters is no problem for 100 KHz RS-422 (Spec is 1220 meters at 100
> KBPS
> >> ~= 50K steps/second) So just using good line drivers/ receivers should
> be fine
> >> It may even work with differential drivers and normal opto-isolated
> step motor
> >> drives driven differentially
> >
> > You might also need terminators to avoid reflections.
>
> Yes, you probably need to know the drives optopcoupler input circuitry
>
> Many Chinese drives get this wrong (no reverse polarity protection diode
> across OPTO LED) In this case, an external reverse diode/resistor pair
> would
> handle the reverse direction oveshoot and prevent OPTO damage in the OPTO
> LED
> off direction
>
> Many drives have 220 ohm series resistors, this would result in less than
> 50%
> overshoot (for say 750 ns with 150 meters ) which should not be harmfull
> in
> the on direction
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
>
> ___
> 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] tool changer with swiveling arm

[Kenneth Lerman]

To clarify the question:
With this type of tool changer, one could speed up the tool change delay:

   1.  when loading a tool
   1. unload the previous tool into one side of the arm
  2. move the chain so that the new tool is ready to be loaded (if not
  already there)
  3. grab the new tool from the chain
  4. put the new tool into the spindle
  5. move the chain to the position of home position of the previous
  tool
  6. put the previous tool back into the chain
   2. lookahead option
  1. Anticipating what the next tool will be, move the chain so that
  the next tool will be ready to be loaded

Is that what you mean by:

> Are there any examples  where the tool is prepared in advance?


(Note that I didn't answer your question.)

Ken

On Sat, Jan 5, 2019 at 3:43 AM nkp  wrote:

> Are there any examples  where the tool is prepared in advance?
>
> Machine : tool changer with swiveling arm.
>
> like this
> http://www.electronicsam.com/images/KandT/conversion/toolchangerspindle.JPG
> (image taken from the forum)
>
>
>
> ___
> 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] Do we have a manpage editor/creator?

[Kenneth Lerman]

Hi Gene,

If you look at http://www.linuxhowtos.org/System/creatingman.htm all will
be clear.

Ken


On Wed, Dec 26, 2018 at 8:51 AM Gene Heskett  wrote:

> Greetings all;
>
> In looking over some of my older subroutine files, its becoming rather
> glaringly apparent that the proper usage needs a manpage (or the .ngc
> needs a lot "more better" comments to refresh my own mind as to exactly
> what the heck I was doing at the time.
>
> So, do we (as in does linux) actually have a manpage creator that can be
> used by an old fart like me?
>
> 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 
>
>
> ___
> 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] sim still broken

[Kenneth Lerman]

I suspect that it will be very lacking in rigidity. The width of the gantry
is very large compared to the distance between the supports. That means the
gantry will tend to cock with respect to the table. Also, as you press down
on the Z axis, the gantry  will want to lift on one side because of the
moment caused by the fact that the tool isn't directly under the gantry.

It's a router. It's not a milling machine. But my understanding is that you
do lots of work in wood. It will probably be fine for that.

Ken

On Fri, Dec 21, 2018 at 8:43 PM Gene Heskett  wrote:

> On Friday 21 December 2018 20:16:04 andy pugh wrote:
>
> > On Fri, 21 Dec 2018 at 20:07, Gene Heskett 
> wrote:
> > > What do you folks think of this:
> > >  >
> > If it is to replace a mildly broken sim config... Don't be daft.
>
> I expect the sim to get fixed, eventually. No hurry but I reserve the
> right to mention it annually. ;-)  Squeaky wheel theory and all that...
>
> No Andy, its to replace the 15+ yo HF I've spent twice that trying yo
> make it usefull, and I unscrewed the x screw out of its ball nut today
> trying to find another 1/4 of x to carve this panel.  But I stepped up
> the the 1500 watt motor with an er-11 collet, and offered him his
> asking, keep the controller but throw in a set of er-11 collets and the
> water tank.  Now I gotta make a lower table to put it on  as I don't
> think the gantry with z up will clear the shelf the keyboard and the
> detrious heap of handy tools etc, that this mill extends its x table
> under when working on its left end.
>
> > If you want it, then go for it.
>
> If he takes it, yep.
>
> 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 
>
>
> ___
> 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] O subroutines limited to 4 parameters, not 30?

[Kenneth Lerman]

Hi Ted,

What is the meaning of "fail" in this context?

Do you get some sort of error message? Or does smoke come out of the
machine? :-)

Ken

On Sat, Dec 15, 2018 at 6:00 PM Ted Hyde  wrote:

> Greets - I'm calling an o sub from python and need to pass 8 parameters
> to it. Per the docs, I'm expecting to be able to pass up to 30
> parameters, not just 4
> Whether I make the call in python, or just in Axis' MDI window, I get
> the same response at the 5th parameter "Interp_error Bad Character '['
> used."
> I can replicate this with any o sub (as external file) and it always
> fails on the 5th parameter, eg:
>
> 300.ngc:
> o<300> sub
> (DEBUG, I actually have 8 params: [#1] [#2] [#3] [#4] [#5] [#6] [#7] [#8])
> o<300> endsub
>
> and calling it via python or just simply in Axis' MDI: o<300> call [1.0]
> [2.0] [3.0] [4.0] [5.0] [6.0] [7.0] [8.0]
> will cause it to fail..
> Calling only o<300> call [1.0] [2.0] [3.0] [4.0]
> will run, but of course a full routine is missing parameters 5-8.
> Running (Axis) 2.7.0 on Wheezy from LiveCD install.
>
> Any help appreciated.
>
> Thanks,
> Ted.
>
>
> ___
> 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] Accuracy of servo gear heads

[Kenneth Lerman]

Well, three arc minutes is a 20th of a degree. There are 20 * 360 = 7200 of
them in a circle. A circle with a diameter of 10 inches has a circumference
of 10 * pi or 31.4 inches. Divide that by 7200 -> .004.

So, you can probably answer the question. Imagine a flat piece of ground
steel 10 inches square by 1/2 inch thick. Indicate it in to be perfectly
horizontal. Then flip if over to the other side. Now run your indicator
over that piece of steel. Is four thousandths too large an error? (The edge
to edge difference will be twice that.)

I think the answer is that is not precise enough, but your answer will
depend on your application.

Ken

On Sun, Nov 4, 2018 at 3:57 PM jeremy youngs  wrote:

> Hello all ,I just purchased several hd brand gear heads . I have a question
> about the backlash call out of 3 arc minutes. One of these is fairly large
> and I would like to use it as an engine block rollover . I have a 10*50
> comet and I want to attach my van Norman boring bar to it . This will
> eliminate having to lift that 250 lbs and allow measurement of bore without
> disturbing the bar.
> My question is , is 3arc minutes too much for this process ? And could
> backlash be effectively reduced by putting a brake at the opposite end of
> the rollover fixture and preloadi g the gear head ? Obviously attention to
> that detail would be required. Thanks fellas
>
> ___
> 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 something like rockhopper, but faster

[Kenneth Lerman]

I believe that issue Gene thinks needs addressing is the following:
Consider component A (say Jon's board) reads the hardware and produces a
signal Sa.
Component B reads Sa and produces Sb
Component C reads Sb and produces Sc
Component A (Jon's board again) reads Sc and writes to the hardware.
This can all take place in one servo cycle.

However, what happens if the components are added (addf) in the order:
Component C, component B, Component A.

In that case:
(cycle 1): Component C reads Sb (no value stored there yet) and produces
Sc-1.
Component B reads Sa (no value stored there yet) and
produces Sb-1.
Component A reads hardware and produces Sa-1. It reads Sc-1
and writes the hardware.
(cycle 2): Component C reads Sb-1 and produces Sc-2
Component B reads Sa-1 and produces Sb-2
   Component A reads hardware and produces Sa-2. It read Sc-1
and writes the hardware.
(cycle 3): Component C reads Sb-2 and produces Sc-3
   Component B reads Sa-2 and produces Sb-3
   Component A reads hardware and produces Sa-3. It reads Sc-2
and writes the hardware.

Look at where the value written to the hardware came from. Sc-2 was
generated in cycle 2 from Sb-1.
Sb-1 was generated in cycle 1 from no value store there, but call it cycle
0.

So the value that is output in cycle 3 is essentially three cycles old.

If instead, the components were addf'd in the order A, B, C, the delay
would be
determined strictly by the processing time.

I first saw this problem in the 1960s in the context of generating a PERT
chart. I later found out that solving it requires doing a topological sort.
There's a slight complication in that topological sorts are done in DAGs
(directed acyclic graphs) and our graph has cycles where a single component
can be both an input and an output. A straightforward solution might be to
arbitrarily break those components into two parts.

At any rate, Gene brings up a real problem should be solvable with a simple
tool.

Ken



On Tue, Oct 23, 2018 at 12:52 AM Nicklas Karlsson <
nicklas.karlsso...@gmail.com> wrote:

> > ...
> > So, this makes sure that the encoders for ALL axes are
> > sampled simultaneously, and then the DACs are updated
> > simultaneously on the next servo cycle.  Thus, there is no
> > variable delay between encoder sampling and DAC update, it
> > is always equal to the servo thread period +/- the jitter at
> > the start of the thread, which is typically less than 10
> > us.  (Much less on a machine with good latency jitter numbers.)
> >
> > Jon
>
> Even though there are jitter on servo thread this jitter make no
> difference, anywhere within period is equally good because signals are
> latched/updated by hardware at period.
>
> Ideally in a good real time operating system there should be a list of all
> real time processes and worst case execution time. Then these exuction
> times and worst case execution of a new thread is known it is possible to
> calculate if enough execution time will be available. It might be hard to
> get an exact number but an upper bound is enough.
>
>
> Nicklas Karlsson
>
>
> ___
> 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] Have You Seen This Absolute Position Sensor?

[Kenneth Lerman]

Kenneth Lerman 
Thu, Oct 4, 7:54 PM (2 days ago)
to Emc-users
...for less than three dollars...
<https://www.idt.com/document/dst/zmid520x-datasheet>

I don't know what I might use it for, but it seems pretty neat.

Ken

Kenneth Lerman
55 Main Street
Newtown, CT 06470

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

Re: [Emc-users] Water or Air cooled spindles

[Kenneth Lerman]

It sounds to me like a car radiator from a junked car would make a perfect
cooling tank and heat radiator.

Ken

On Wed, May 23, 2018 at 8:01 AM, Dave Cole  wrote:

> RV antifreeze works well for things like this.  I have been using it for
> years in my bandsaw coolant tank.  It doesn't seem to go bad even after
> years and it doesn't evaporate much.
>
> For cooling, You might want to consider making a flat tank.  Two sheets of
> steel or alum spaced apart an inch or so and welded at the edges.   That
> would increase your surface area for cooling while not creating a huge tank
> volume wise.  Put the tank on edge and it won't take up much space.
>
>
> On 5/22/2018 5:34 PM, Bruce Layne wrote:
>
>> I've had two of the Chinese 2.2 KW water cooled spindles for the last few
>> years and have had no trouble with them.  I consider them to be a good
>> value.  Well worth the plumbing hassle, in my opinion.
>>
>> Be sure to use good quality very flexible tubing of the correct size.  I
>> think I got 8mm outside diameter tubing from McMaster-Carr (red for supply
>> and blue for return).  I use pink RV antifreeze as the coolant.  It's used
>> full strength and not diluted.  I use it in the hope that it's less
>> corrosive than water.  Neither machine's coolant has had any rust or other
>> issues, although there was a slight film of oil that's flushed out of the
>> spindle motor.  I'm not worried about it freezing because one of the CNC
>> routers is in an attached garage and the other is in my basement, and
>> neither get very cold.  I'd actually be more worried about the machine
>> rusting if it was in a condensing environment, and the CNC routers are
>> mostly aluminum.
>>
>> I mounted a thin liquid crystal thermometer on the spindle facing the
>> operator so I can tell at a glance if the spindle overheats. These liquid
>> crystal strip thermometers are readily available on eBay and are sold for
>> reptile terrariums.  I buy a bunch of them and put them in electrical
>> panels, etc.
>>
>> I haven't finished wiring it yet, but the production machine will have a
>> 130F bimetallic button thermal switch siliconed to the spindle motor
>> housing and wired into the e-stop circuit to shut everything down if the
>> spindle overheats.
>>
>> The Huanyang VFD produces a lot of electrical noise, apparently mostly
>> radiated.  I used ultra flexible shielded four conductor cable (three
>> phases plus ground) to keep the cable from radiating much energy.  The only
>> place I had an RFI problem was the VGA monitor and a good quality VGA cable
>> fixed that problem.
>>
>> On the larger router, I tried to place a five gallon coolant tank under
>> the router and pump the coolant up and then back down to the spindle
>> motor.  I was partly motivated by not wanting a leak that siphoned the five
>> gallon coolant tank empty.  After some experimentation, I gave up and put
>> the coolant tank on top of the CNC router enclosure.  When it was
>> underneath, I needed to use such a large pump to have enough pressure to
>> pump the coolant six feet vertically that the submerged coolant pump was
>> heating the coolant more than the spindle.  It was a spindle heater, not a
>> spindle cooler.
>>
>> We're finally ramping up production, with some programs running
>> unattended for ten hours.  I'm going to need to add a radiator in the
>> coolant return line and a couple of muffin fans to keep the coolant
>> temperature low enough.  The other alternative might be ten or fifteen more
>> gallons of coolant to increase the thermal mass, but that seems to only
>> delay the overheating problem with greater risk of a severe coolant leak.
>>
>>
>>
>>
>>
>>
>> On 05/22/2018 03:18 PM, Roland Jollivet wrote:
>>
>>> I'm looking at getting one of those 2.2kW air or water cooled spindles +
>>> VFD kits out there for a router.
>>> I'm not worried about the noise difference between the two types.
>>>
>>> Has anyone taken apart a water cooled spindle?
>>> How are they doing the cooling? Is it a water jacket or just some copper
>>> tubing inside?
>>> How likely is it to leak in a few months time?
>>> I can only find one video describing leaks and water related shorts etc.
>>> (so they must be good?)
>>>
>>> I actually prefer the idea of using air-cooled and making ducting to take
>>> the exhaust away from the spindle nose. Make a closed loop fan-assisted
>>> air
>>> duct.
>>> The irony is that I want to use flood cooling on the work. (composite
>>> material)  So it won't be a dry environment.
>>>
>>> Regards
>>> Roland
>>> --
>>>
>>> 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] Mesa choices

[Kenneth Lerman]

I wouldn't want to share an ethernet between real time control and ssh,
file transfer, ...

Either buy a PC with two ethernet ports or just add a second cheap one
connected by USB. Then use the USB one for all of the usual stuff where
there is no real time constraint.

Ken

On Sun, Apr 22, 2018 at 1:30 PM, Chris Albertson 
wrote:

> Back to the title subject.   I'm going to need to buy a Mesa card soon.
> Is there any reason to prefer the 7i90 over the 7i92 or other ethernet
> cards.   It seems to me that even if I still owned a PC with a parallel
> port the computer would also have an Ethernet port which is 10X faster and
> uses cheaper cables.Possibly there is something about the 7i90 I'm over
> looking?
>
> On Sun, Apr 22, 2018 at 10:19 AM, John Dammeyer 
> wrote:
>
> > Well said Chris.
> >
> > I worked on a system once where the 24V system bus shared a common ground
> > with a 12V instrument bus.  The system bus could have as much as 20A
> > flowing
> > through it as a Servo motor moved one section.  There was also other
> > equipment that sporadically drew more and less current.   They used one
> > common ground from the battery/charger systm to all the devices tapping
> > onto
> > this ground wire where needed.
> >
> > On a small panel that approach had worked for them.  When the
> > batteries/chargers and 12V power supply along with one instrument were
> 30m
> > away from the rest of the instrumentation they had all sorts of induced
> > noise issues.  They argued that they had measured the noise on the 24V
> > system in the control box with a scope and it was minimal.
> >
> > I demonstrated that if they ran the scope ground 30m back to the battery
> > and
> > measured the ground at the control box they would see lots of noise.
> > Splitting the 12V and 24V  grounds made the problem go away.  The 30
> meter
> > distance was still an issue since it wasn't physically possible to run a
> > star ground for ever device back 30m to the battery.  Add that some of
> the
> > 24V devices had a non-isolated CAN bus and shared their CAN bus ground
> with
> > the 24V system the potential for the 24V return path to take the 12V
> return
> > path.
> >
> > But the major 24V ground separation from the 12V was a big step in the
> > right
> > direction.
> >
> > John
> >
> >
> > > Gene is right.  Many people don't understand grounds.  The star ground
> is
> > > not magic.  It is based on two basic laws of physics.   Just two things
> > to
> > > remember
> > >
> > > 1) It is a fundamental law of electricity the current ONLY flows if
> there
> > > is a loop.   Take a straight piece of wire and connect one end to a
> > battery
> > > and leave the other end free and absolutely zero current flows and the
> > > wires has EXACTLY the same voltage all along it's length.THIS is
> why
> > > you use a star ground.  No current will flow in the ground wire if ONLY
> > one
> > > end of each wire is connected to your ground reference.  Make a loop
> and
> > > you have current.
> > >
> > > 2) Mr. Ohm has a law that says if there is current you have voltage.
>  In
> > > fact the volts are proportional to the current.   So if you make a loop
> > > with your ground wires there will be current and hence different parts
> of
> > > the loop will have different voltages on them.  It will not be zero
> > > everywhere as you might think.
> > >
> > > Basically the combination of Kichoff's  and Ohm's laws.   People try
> can
> > > get around this by using real heavy and thick ground wires.   But they
> > > forget (or never knew) that impedance has an imaginary component and
> the
> > > thick wire only effects the real component.   This noise that is
> > > transmitted is high frequency AC not DC.   you have to make the path
> "low
> > > impedance" if you want to get around Ohm's law.   This noise is
> basically
> > > in the radio spectrum, big wires don't help much there.
> > >
> > > Just make sure ALL you grounds are "dead ends"  There are places where
> > > where loops sneak in.   One of then is shielded cables where the ground
> > > shield is connected to each end of the cable.
> > >
> > > There are more sophisticated systems where they shunt the AC to ground
> > > using capacitive coupling but don't  even try unless you are a
> specialist
> > > engineer.  You do see this in some equipment.  They use a capacitor in
> > > parallel with a high value resister and they connect signal and
> > protective
> > > grounds this way.   What they are doing is making a low impedance path
> > for
> > > AC to ground.
> > >
> > > The other thing you can and should do is try to stop this electrical
> > noise
> > > at the course.   The best way to is again remember  Kichoff.  Current
> > flows
> > > in a loop.  So any time to have a wire with current, say going to a
> > motor,
> > > some place there is another wire with that same current flowing in the
> > > opposite direction.   Always route those to wires as close as possible
> > >  Best way to do that 

Re: [Emc-users] depth stops for R8 while making tap hats?

[Kenneth Lerman]

Hey Gene,

Wouldn't a square R-8 collet make things simpler? Something like this?


Then you could just use square stock for your tap holders.

(Yeah, I know it's a bit late. But the idea just came to me in the middle
of last night.)

Regards,

Ken

On Tue, Apr 10, 2018 at 7:29 PM, Gene Heskett  wrote:

> On Tuesday 10 April 2018 17:05:51 Ken Strauss wrote:
>
> > The next standard size smaller than 3.3mm is #30 which is 0.129 rather
> > than 0.125.
> >
> I meant to say that I had on site. My #30 is already used up in two
> different number drill sets.  The 1/8" is working well after I  wrote a
> peck routine to keep the hole fairly clean. And I've rigged a 5/16" 8
> point socket and a drill with a hammer clutch to run the drawbolt. So
> next is to merge the 3 routines and setup the tool table a little
> better, so I can do the 3 operations for this stage in one swell foop,
> with tool changes separating the operations. It takes me at least 20
> secs to select the next operation from the recent menu. My mouse is too
> fast and goes off target too easily. So that wastes at least a minute as
> opposed to unpausing it after the tool has been changed. Might be a
> keyboard short cut that would be faster, something that opens the recent
> menu, then lets you select #3 because the next in the sequence is always
> #3. But I'm not familiar with 2/3ds of the keyboard stuffs.  Is that in
> the docs?
>
> I've a bunch of taps, so I'm making enough to hold all the good ones, for
> some definition of good. ;-)
>
> Just over half done, out of 52 brass slugs I cut, 25 to go, but its now
> going a lot faster since I rigged up a drill to run the drawbolt. And
> managed to get some go2 to hold the tap at an almost fixed TLO in a 3/16
> R8. Ack ups I should have some more tooling here tomorrow evening.
> Whether its the right stuff is TBD.
>
> Thanks Ken.
>
> > > -Original Message-
> > > From: Gene Heskett [mailto:ghesk...@shentel.net]
> > > Sent: Tuesday, April 10, 2018 4:25 PM
> > > To: Enhanced Machine Controller (EMC)
> > > Subject: [Emc-users] depth stops for R8 while making tap hats?
> > >
> > > Hi guys;
> > >
> > > I find, at least for the remainder of this project, that I need some
> > > sort
> >
> > of a
> >
> > > depth stop to reliable reposition the 4mm tap I'm useing, currently
> > > in a
> >
> > 3/16"
> >
> > > R8 collet. A collar on the tap would work but I've not been able to
> > > locate
> >
> > a
> >
> > > suitable one. I've got the tap in a glob of g02 with the r8
> > > tightened on
> >
> > it, but
> >
> > > the 3/16 R8 will likely spring it loose as theres quite a bit of
> > > collapse
> >
> > by the
> >
> > > time Its got a good enough grip on the tap.
> > >
> > > Anybody else have a better idea for a depth stop?
> > >
> > > And looking around for another 3.3mm tap drill, which is
> > > 0.129921259842519685", its apparent that the next drill down is a
> > > 1/8",
> >
> > and
> >
> > > the tap will tolerate that .004 undersize ok in brass.  But I found
> > > some 3.3mm's over in Andy's stomping grounds on ebay, in 10 packs,
> > > and here about 2 weeks faster than the Chinese versions, but fleabay
> > > has been
> >
> > playing
> >
> > > with their card processing (again), giveing no opportunity to adjust
> > > the number of 10 packs, so I only have 1 pack of 10 coming. I sent
> > > ebay a mild nastygram because I really wanted 2 packs to save a few
> > > cents on postage.
> > >
> > > That teeny little 8mm square butt on the drawbolt is a PITA, too
> > > small to easily spin with fingers after its been loosened with that
> > > watch makers
> >
> > sized
> >
> > > wrench, but I just found a 5/16" 8 point socket on a 1/4" adapter in
> > > an 18
> >
> > volt
> >
> > > sorta hammer drill works, and if I can get the tap depth fixed, then
> > > I can
> >
> > series
> >
> > > all three operations into one file with tool changes between them.
> > > With
> >
> > the
> >
> > > drill to run the drawbolt, that ought to triple the production speed
> > > for
> >
> > these
> >
> > > things.
> > >
> > > If anyone ever designs a tool changer for a G0704 that doesn't
> > > impinge on
> >
> > its
> >
> > > working envelop, plz advise.
> > >
> > > What I've done so far looks good. I'd go on and actually mount this
> > > tap in
> >
> > the
> >
> > > first one, but I'd likely loose the current home+touch-off offsets
> > > of the
> >
> > current
> >
> > > setup. Or maybe I could setup the next 2 or 3 coordinate maps?
> > > Thats a thought... mumble mumble...
> > >
> > > --
> > > 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 communit

Re: [Emc-users] looking for M5mm x .8 5mm long screws

[Kenneth Lerman]

https://www.mcmaster.com/#standard-socket-head-screws/=1c7nzv5

McMaster has them -- stainless only.

Ken


On Sat, Mar 31, 2018 at 3:32 PM, Gene Heskett  wrote:

> And I don't seem to find any shorter than 10mm.
>
> 5mm long would be a great plenty. This is to be installed in the side of
> a 7/8" diameter slug, with about 1/2 the head buried in the slug, and
> the other half to stick up into a cutout the same width as the head of
> the screw, purpose to lock the slug into the R8, which itself is keyed
> into the spindle. With short threads, and a dot of green thread locker,
> it ought to hold more torque that my spindle can muster up. If I machine
> it right, for a snug fit in the slot cut in the R8 to just clear the bit
> of screw head sticking out, the should not be enough slop to dislodge
> the screw.
>
> But where can I find such short 5mm socket head screws?  Need a full box.
>
> Net searchs show 10mm and up, too long.
>
> Thanks.
>
> --
> 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
>
--
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] possibly silly code question

[Kenneth Lerman]

Jon,

I have one question I have that I haven't seen a good answer to.

Why is there a need to do a second touch? Can't you just back off at low
speed and see when the probe is no longer touching?

I didn't see a significant difference when I did some tests. Everyone seems
to do it the way you're doing it, but I'd like to understand if there is
any evidence that way is better.

Regards,

Ken

On Tue, Jan 30, 2018 at 11:47 AM, Jon Elson  wrote:

> Gene,
>
> Here's a hole probe routine I have used with my touch probe.  The constant
> 0.1526 is the effective radius of the probe tip.  Due to the lag in sensing
> the probe, it makes a fairly rapid touch first at F10, backs off, and then
> does it again, from very close, at F1.  It writes out the coordinate offset
> of the center as well as the diameter in that direction.
>
>
> g91 g1 F10 X-0.05
> g91 G38.2 X0.5
> G91 G1 F1 X-0.02
> g91 G38.2 X0.1
> #1001=#5061
> g91 g1 f10 X-0.05
> g91 G38.2 X-1.0
> G91 G1 F1 X0.02
> g91 G38.2 X-0.1
> #1002=#5061
> #1003=[[#1001+#1002]/2]
> #1001=[#1001-#1002+0.1526]
> (debug,X center  #1003)
> (debug,X width #1001)
> G90 G1 F10 X#1003
> g91 g1 F10 Y-0.05
> g91 G38.2 Y0.5
> G91 G1 F1 Y-0.02
> g91 G38.2 Y0.1
> #1004=#5062
> g91 g1 f10 Y-0.05
> g91 G38.2 Y-1.0
> G91 G1 F1 Y0.02
> g91 G38.2 Y-0.1
> #1005=#5062
> #1006=[[#1004+#1005]/2]
> #1004=[#1004-#1005+0.1526]
> (debug,Y center  #1006)
> (debug,Y width #1004)
> G90 G1 F10 Y#1006
> G10 L20 P1 X0 Y0
> M02
>
>
>
> 
> --
> 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] Off topic: wolfrom drive

[Kenneth Lerman]

The issue I see is how to machine this so that it fits "perfectly" so as to
have zero backlash.

An alternative might be to have three sets of planetary gears with some
sort of spring loading so as to take out the "slop."

Ken


On Thu, Dec 21, 2017 at 5:21 AM, Gene Heskett  wrote:

> On Thursday 21 December 2017 04:47:46 Roland Jollivet wrote:
>
> > The video shows only one planetary gear, which is obviously two gears,
> > stacked.
> >
> > Can there be three planetary gears, maybe each with a different
> > top/bottom offset?
> > I can't figure out if it would work, or just jam up?
> >
> I think 3 gears at 120 degrees on the planetary yoke arms would work just
> fine. It would require assembling it so each planetary is in time with
> the offset the moving ring has at that point. Possibly a bit tricky, but
> once in time should just stay in time.
> >
> >
> > On 21 December 2017 at 11:18, Chris Albertson
> > 
> >
> > wrote:
> > > To make this really work for rotary tables you need a very fine
> > > pitch.  I have seen these 3D printed in plastic but they slip and
> > > don't handle much torque because the outer ring deforms
> > > One idea I had was to press fit the plastic ring gear into a short
> > > section of steel pipe.
> > >
> > > Put you can buy these drives already made for about $250.   That is
> > > really not abad price for arc-second level precision and near zero
> > > backlash.
> > >
> > > On Wed, Dec 20, 2017 at 10:15 PM, Lawrence Glaister 
> wrote:
> > > > very cool Gene had some troubles playing the video, but I seem
> > > > to
> > >
> > > have
> > >
> > > > the gist of it. It does seem like a very interesting design for
> > > > rotary tables just have to figure out how to re-purpose some
> > > > rear end ring gears and pinions hmmm... was thinking of
> > > > regearing the jeep anyway!. Lawrence Glaister VE7IT
> > > >
> > > > On 2017-12-20 07:36 PM, Gene Heskett wrote:
> > > >> On Wednesday 20 December 2017 15:06:20 Gene Heskett wrote:
> > > >>
> > > >> On Wednesday 20 December 2017 12:36:57 gru...@manlymail.net wrote:
> > >  I got my first prototype working. It came out to be 60:1.
> > >  sun = 15
> > >  first planet = 15
> > >  first ring = 45
> > >  second planet = 14
> > >  second ring = 45
> > >  I have a short video but can not post it here
> > > >>>
> > > >>> Need more details plz. Like did you make or source the gears
> > > >>> etc.  And there's lots of places on the net to put a video, even
> > > >>> my site (see sig) is available if you send it to me via a pm.
> > > >>> I'll figure where to put it and make a link. Biggest problem is
> > > >>> my upload back to the viewer is only about 2.5 Mbits/Sec. So
> > > >>> playback may stumble. But at least it will be out there...
> > > >>>
> > > >>> Cheers, Gene Heskett
> > > >>
> > > >> Grumpy's video is now on my site in the sig, with a link from the
> > > >> front page.  Enjoy. Sure, its only plywood, but it works as a
> > > >> proof of concept. I may see if I can make one in steel, with
> > > >> bearings. In wood, its certainly compact compared to a worm and
> > > >> eccentric bull gear.
> > > >>
> > > >>
> > > >> Cheers, Gene Heskett
> > > >
> > > > 
> > > > --
> > > > 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
> > >
> > > --
> > >
> > > Chris Albertson
> > > Redondo Beach, California
> > > 
> > > --
> > > 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
>
>
> 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
> _

Re: [Emc-users] HALUI->MDI_COMMAND fails, 4 command limit?

[Kenneth Lerman]

Hi Gene,

It's been a long time since I've looked at the code, and I don't have it in
front of me.

But...


   1. The file is named _clear_offset.ngc -- isn't it (you didn't leave out
   the .ngc)?
   2. As I recall, the file is opened the first time it is referenced (and
   memory mapped). After that, the copy in memory is used. That means if you
   changed the file to make a correction, it won't be noticed until the next
   time linuxcnc is restarted.

Just some possibilities.

Good luck (and happy holidays).

Ken

On Tue, Dec 12, 2017 at 5:33 PM, Gene Heskett  wrote:

> On Tuesday 12 December 2017 12:01:57 Gene Heskett wrote:
>
> > Greetings all;
>
> Not getting anywhere, I have even straced linuxcnc, but the error is
> exactly the same, mixed into the strace output.
>
> Is there a special bit in the DEBUG value that will enable tracing the
> steps it takes to execute a HALUI=halui, MDI_COMMAND=o ?
>
> TASK seems to be the one, but isn't enough noisier to help me.
> Here is what it logs for one of the 5th thru 8th MDI_COMMANDS
>
> Issuing EMC_TASK_PLAN_EXECUTE -- (  +509,+268,
> +18,o<_align_start>\032call,)
> emc/task/emctask.cc 397: interp_error: EOF in
> file:/usr/share/axis/images/axis.ngc seeking o-word: o<_align_start>
> from line: 0
> EOF in file:/usr/share/axis/images/axis.ngc seeking o-word:
> o<_align_start> from line: 0
> emc/task/emctaskmain.cc 2336: error executing command
> 509:EMC_TASK_PLAN_EXECUTE
> emcTaskIssueCommand() returning: -1
>
> So I added the INTERP flag, and then get this:
>
> emcTaskPlanSynch() returned 0
> Issuing EMC_TASK_PLAN_EXECUTE -- (  +509,+268,
> +18,o<_align_start>\032call,)
> emcTaskPlanLevel() returned 0
> emc/task/emctask.cc 397: interp_error: EOF in
> file:/usr/share/axis/images/axis.ngc seeking o-word: o<_align_start>
> from line: 0
> EOF in file:/usr/share/axis/images/axis.ngc seeking o-word:
> o<_align_start> from line: 0
> Interpreter stack:   - int Interp::read_text(const char*, FILE*,
> char*, char*, int*)  - int Interp::_read(const char*)  - int
> Interp::_execute(const char*)
> emcTaskPlanExecute(o<_align_start> call) returned 5
> emcTaskPlanLevel() returned 0
> emc/task/emctaskmain.cc 2336: error executing command
> 509:EMC_TASK_PLAN_EXECUTE
> emcTaskIssueCommand() returning: -1
> emcTaskPlanLevel() returned 0
>
> So what is an error 5?
>
> Another file in the git pull on the rock64 says thats an INTERP_ERROR.
>
> So I am beginning to think this is not my error. However, I moved one of
> them to the top of the list without effecting the text of the error. So
> it must be a syntax error in postgui.hal, or the file itself. So here is
> the shortest of one of these 4 files that cannot be run.
> =
> o<_clear_offset> sub
> ; this subroutine is used to clear the offsets after using align
>   G10 L2 P0 R0
>   G92.1
> ; turn all tallys off
>   m65p8
>   m65p9
>   m65p10
> (msg,alignment offsets cleared)
> o<_clear_offset> endsub
> M2
> ===
>
> And I might have found it, I had renamed the file slightly, on all 4 of
> them, without changing the internal names.  Duh... Goes off to check it
> out. Fixed the internal names to match file names. No diff in the error
> messages. Next, take leading underscores out of all names, ok since I've
> moved them all to a subdir, first in path. But the 1st 4 were treated
> exactly the same, with _leading underscores, and they work just
> fine.
>
>
>
>  .
> So I'll invert the order in postgui.hal one more time for effect. Done,
> no diff, it's simply making no effort to execute MDI_COMMANDS 5-8. But
> moving on of them to first in list does not make it work either.
>
> Its been a while since I found a bug, have I again? At any rate its time
> I go play chief cook and bottle washer while you folks cogitate on how
> to tell me I'm an idiot. :)
>
> > On the 5th command in the list, and all subsequent commands after the
> > first 4, I am not getting the expected result, which is running the
> > command, but instead is logging this in the launching terminal:
> >
> > emc/task/emctask.cc 397: interp_error: EOF in
> > file:/usr/share/axis/images/axis.ngc seeking o-word: o<_align_start>
> > from line: 0
> > EOF in file:/usr/share/axis/images/axis.ngc seeking o-word:
> > o<_align_start> from line: 0
> >
> > The file, just like the first 4, exists in the first listed link in
> > the SUBROUTINE_PATH statement in the .ini file.
> >
> > 4 command limit? Doesn't say anything in the docs but up to 64.
> >
> > Call me puzzled?
> >
> > Cheers, Gene Heskett
>
>
> 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
>

Re: [Emc-users] [Emc-developers] trying to run synaptic-pkexec on the raspian

[Kenneth Lerman]

On Mon, Nov 28, 2016 at 12:32 PM, Gene Heskett  wrote:

> 
>
> None of the /home/user/* are available to the system until you are logged
> in, and then you cannot play with those files in wholesale renaming
> quantities.
>

They are all available (to root) when the system is booted (after the
appropriate disk directory is mounted).
Actually, you can play with those files and do most stuff.
Things that you can do safely (as root):

   1. edit /etc/passwd to change anyone's uid, gid, or change the home
   directory
   2. edit /etc/sudoers to give anyone sudo permission
   3. change the permissions on any file or directory (a directory is just
   another file)
   4. change the owner gid, uid of a file
   5. add users, remove users, ...

Things you better not do:

   1. change the locations, permissions, etc of core utilities (bash, rm,
   chmod, su, ...)
   2. remove core utilities

Things in the first group are normally done when logged in as root. Yes,
you could do it at boot time as a script in rc.local (or elsewhere), but
that would require creating a script, then rebooting to run it, then
removing it (or making it idempotent when it was created.) That's really
not a good idea.

Regards,

Ken

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

Re: [Emc-users] Got "new" PC, some question about setting it up.

[Kenneth Lerman]

Gene said inches per minute. You are saying inches per second.

You are off by a factor of 60.

Ken

On Fri, Sep 16, 2016 at 11:46 PM, Chris Albertson  wrote:

> Gene,
>
> I think I understand now
>
> On Fri, Sep 16, 2016 at 6:07 PM, Gene Heskett 
> wrote:
>
> > On Friday 16 September 2016 12:06:47 Chris Albertson wrote:
> >
> >
> > Lead screw is a 1605, 40 tooth gear on the motor by way of a taperloc hub
> > I made, ditto for the 80 tooth gear on the screw, so the motor is
> > running 2x the speed of the screw.  The motor is running on a 39 volt
> > power supply, with a 2M542 driver set for 16x microstepping. Motor is an
> > 8 wire 432 oz/in, wired in series. I am useing a similar if not
> > identical, direct drive on the smaller x screw, wired parallel. It
> > doesn't move very far, maybe 4" total, but its speed for in and out
> > running a g76 threading routine is way more than enough.
> >
>
> So 200 x 16 x 2 steps per revolution is 6400.
> then 6400 x 5 steps per inch is  3200
> at 60 inches per second you are doing  380,000 steps per second
> or, that is 2.6 microseconds per step.
>
> I am very surprised at the low performance of the opt coupler in the
> breakout board
> unless it was intentional.  The signal might be intentionally low pass
> filtered
> in an attempt to reduce noise.   That would be a reasonable design
> for a breakout board.   The designer never assumed anyone would would
> run steps at 300KHz.
>
> To move 60 IPS coins software I think it looks like I might need a direct
> drive
> using 1/2 steps  for 400 steps per revolution.  But I'd be at only 2,000
> steps per inch
>
> Yes I see the logic in using the FPGA board, plus I've always wanted to
> learn to program
> an FPGA and when not driving a machine tool I'l have one to play with
>
>
> > When asking steppers to run at those speeds, I think 2 things are
> >
>
>
> > demanded:
> > 
> >
> --
>
> Chris Albertson
> Redondo Beach, California
> 
> --
> ___
> 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] Info needed.

[Kenneth Lerman]

Hi Gene,

1 -- I don't think they have bias magnets in them.
2 -- I don't think you will be happy with the repeatability as a limit
switch. Also, the smallest bit of swarf that sticks to the magnet will
cause you problems.

I haven't tried it, but I wouldn't be optimistic.

Regards,

Ken

On Tue, Aug 23, 2016 at 6:18 AM, Gene Heskett  wrote:

> On Tuesday 23 August 2016 05:57:22 Sarah Armstrong wrote:
>
> > yes it,s more than fast enough Gene , they work fine
>
> Good, I'll get a bag of them. Maybe 2, as I'll need home and limit
> switches too.  And I like the non-contact idea. A lot.
>
> Thanks Sarah.
>
> > On 23 August 2016 at 10:37, Gene Heskett  wrote:
> > > Greetings all;
> > >
> > > Does this device, which I see 5 for a dollar on ebay, have a builtin
> > > bias magnet? IOW can it sense gear teeth as is?  And is it fast
> > > enough to handle that bigger gear right behind the spindle bearing
> > > in my Sheldon at 3000 revs? I haven't counted the teeth but its a
> > > bunch, 100 or so.
> > >
> > > A3144 3144E OH3144E Hall Effect Sensor SWITCHES TO-92UA 3pin SIP
> > >
> > > Thanks.
> > >
> > > 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 
> > >
> > > 
> > > --
> > > ___
> > > Emc-users mailing list
> > > Emc-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> 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

Re: [Emc-users] Need some advice

[Kenneth Lerman]

Well, I noticed that the shipping weight is 550# and the machine weight is
600#. Do you suppose they fill the box with helium?

Seriously, though, the thing that drives me crazy about new lathes for CNC
conversion is that you are paying for a bunch of stuff you neither need nor
want.
* change gears -- who cares
* power feed -- don't need it
* left hand threads -- bah - the same with metric threads
* motor and speed control -- may be ok. But I'd rather have a three phase
motor and a VFD.
* 18 speeds (plus variable speed) -- six plus a VFD is probably more than
enough

The belt drive in the picture looks a little flimsy. They say that they are
in Pittsburgh and are machinists. See if you can drop bye and see how deep
a cut you can take with a carbide tool in some steel. The proof is in the
cutting.

Ken

On Sat, May 14, 2016 at 1:55 PM, Gene Heskett  wrote:

> Greetings all;
>
> Since my toy lathe broke itself, again, and its made out of rubber
> anyway, I was watching it fight with a dull chip that actually looked
> good under a strong glass a couple days ago, and the major two sources
> of flex that induce chip breaking chatter are the spindle itself, and
> under pressure from the dull chip, I could see the cross-slide visibly
> bowing in its length. This while taking .25mm off the diameter of that
> piece of cast per pass at about a 20mm per minute feed.
>
> So its a piece of crap in the first place.
>
> Now, knowing that I'll cnc it, and it looks fairly easy, I am considering
> driving up to Pittsburgh and getting a new PM-127VF-LB lathe, ebay link:
>
> <
> http://www.ebay.com/itm/PM1127VF-LB-METAL-WORKING-LATHE-VARIABLE-SPEED-LARGE-BORE-QCTP-/231943772037?hash=item3600ed1785
> >
>
> At that spindle bore, I'd not have any trouble mounting a rifle barrel,
> which is a definite plus. The chuck mount is a minus though, almost
> exactly like this toy, 3 studs in the chuck thru a flange on the end of
> the spindle, so that will definitely need another deer hoist rigged.
> Both chucks are 6", but the motor is a bit puny, running on a 15 amp
> wall outlet.
>
> And a dividing head for my mill at the same time as both are in stock and
> I can put finger prints on them at the dealers location in Pittsburgh,
> ebay link:
>
> <
> http://www.ebay.com/itm/BS-0-Precision-Dividing-Head-With-5-3-jaw-Chuck-Tailstock-part-BS-0-new/311287173608?_trksid=p2047675.c15.m1851&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D1%26asc%3D36142%26meid%3D0fb601c6651b4939ab2189a87f8c75c7%26pid%3D15%26rk%3D2%26rkt%3D6%26sd%3D181674670773
> >
>
> But its $399 there, and the best I can find on ebay wants $40 shipping on
> a $339.95 price. $20 diff. Shrug.  I'll need to replace a missing pulley
> in my deer hoist hanging over the mill now so I can hang the head if I
> have to as it weighs 60 lbs and thats more than whats left of my back
> can do.
>
> This lathe is fairly new on the market I think, no ready made stand, and
> a stand for it would have to be made, weighs about 600 lbs.  That I can
> handle with a neighbors engine crane I think.  Put good castors on the
> stand and I should be able to access all around it.
>
> Comments please, either side of the argument.
>
> 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 
>
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] How to home a joint when position depends on other joint?

[Kenneth Lerman]

What you want to do is perform a topological sort (man tsort) on the graph.

It should be simple enough to write a tool to do that.

Ken


On 12/14/2013 12:18 PM, Gene Heskett wrote:
> On Saturday 14 December 2013 11:38:26 Marius Alksnys did opine:
>
>> Thanks, I will try it.
>> This is something what I was thinking about and even tried to swap pid
>> and offset addf lines, but I never found importance of addf order in
>> documentation, which would be worth noting there..
> It is important. In both threads.
>
> General rule of thumb in base thread,
> addf anything that needs a sample from hdwe (encoder?)
> addf in order, the chain of non-fp stuff the sample flows through
> addf last (for steppers) the parport.N functions
>
> General rule of thumb for servo thread speed stuff:
> addf signal receiver FP stuff (such as an encoder)
> addf the module its "net" output goes to
> addf next module the "net" of the above goes to
> addf continue till this function is completed
>
> That way any changes in the signal are propagated thru the processing chain
> in a single servo cycle.  And when the actual control outputs are updated,
> they are working with the most up to date data they can get.
>
> There are times I expect when you may have another function chain that
> needs to be interleaved with the above, but I haven't run across a case
> where I could test and get a demonstratable advantage. YMMV of course.
> Spindle control servos, based on an encoders velocity, will get very
> unstable if the path is backwards thru the addf's because this severely
> restricts the bandwidth of the control.  Even with what I THINK is all the
> ducks in a row, I found that double the speed of the servo thread from 1
> millisecond to .5 milliseconds was a huge improvement.  Because of non-
> linearity in the pwmgen and controller, I have a linear module between the
> PID.out and the PWMGEN.in, additional time delay, but it sure tames the
> PID.error range.  Decent load torque at creep speeds (50 rpms) without
> hunting at 75% speeds (1200 on up) where its very sensitive.
>
> In retrospect, and I'd have to make additional room for it now, I know I
> would have been schmardter to have used the PMDX-106 (or whatever is being
> sold for that now) in place of the cheaper, too darned cheap and slow &
> needs modification to raise its control bandwidth if its anywhere in a
> feedback chain, CNC4PC C41 for that translation function.  Dumb, but its
> done.  I won't make that mistake again, it, out of the bag, is simply not
> suitable for use in a servo controlled environment.  You have been
> warned...
>
>> On 2013.12.14 13:12, andy pugh wrote:
>>> On 14 December 2013 08:08, Marius Alksnys 
> wrote:
 I tried simple configuration (without offset component) too. And it
 worked perfectly.
>>> If it goes wrong with the offset component but works without it, then
>>> I suspect that the problem is with the execution order of the motion
>>> controller and the offset component.
>>> If you change the sequence of the "addf" statements in the HAL then
>>> you can probably make it work.
>> 
>> -- Rapidly troubleshoot problems before they affect your business.
>> Most IT organizations don't have a clear picture of how application
>> performance affects their revenue. With AppDynamics, you get 100%
>> visibility into your Java,.NET, & PHP application. Start your 15-day
>> FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.cl
>> ktrk ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>
> Cheers, Gene

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Drill sharpening Re: G33.1 probem

[Kenneth Lerman]

A friend of mine, John Moran has been working on drill sharpeners for 
the home shop for many years. See: 
http://www.gadgetbuilder.com/DrillSharp.html for a great article on the 
subject.

If you have any questions, I'm sure John would be happy to answer them.

Regards,

Ken


On 11/4/2013 8:12 PM, Gene Heskett wrote:
> On Monday 04 November 2013 20:10:50 Gregg Eshelman did opine:
>
>> On 11/4/2013 7:53 AM, Gene Heskett wrote:
>>> Hell, I'd pay
>>> another $200 for a Drill Doctor that could do a 1/16" bit RIGHT.  But
>>> that beast isn't made, the drill bits, sloppy as they are, are too
>>> cheap to be a target for the DD.  Dammit.
>> Buy one of the sharpeners from Darex, the company that makes the Drill
>> Dr.
> Nice try, but the base line $1,450 model only goes down to 1/8".  And I did
> say +$200, not +1,200.  ;-)
>
> Cheers, Gene

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Talking of taps

[Kenneth Lerman]

On 11/5/2013 1:08 PM, John Thornton wrote:
> WOW the cheapest rate with the USPS is $45 to ship to England...
I see:
* Priority mail flat rate envelope: $23.95
* First-Class Mail International Letter (max thickness 1/4 inch) $3.20

Ken
>
> JT
>
> On 11/5/2013 10:29 AM, andy pugh wrote:
>> Would anyone like to volunteer to do me a favour?
>> I want a No 8 x 30 tpi tap. I can't find one in the UK. I have found
>> them on the US Amazon site, but they won't ship to the UK.
>> I found one here, and they will ship to the UK, but want to charge
>> $99.15 to do so:
>> http://www.biscotoolsupply.com/8-30-special-hand-taps
>>
>> If someone in the US was willing to receive an order then re-ship to
>> me, that would help.
>> (Though I do still have a couple of feelers out more locally)
>>
>
> --
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linux question

[Kenneth Lerman]

That may depends on the computer configuration. I believe that my Intel 
board has a jumper to enable that. In some environments, you want the 
computer to come back online after a power failure.

Ken

On 10/19/2013 6:38 PM, Terry Christophersen wrote:
> Hi all,
> When I turn on the main power  switch my computer will come on for
> a couple of seconds then shut off.I wait for this to happen then push the
> computer on switch.This is how it been since I switched to a 525.
> Why does the computer come on without me hitting the computer on switch?
>
> Thanks
> Terry
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] JogWhilePaused Proposal - please review planned sequencing

[Kenneth Lerman]

I like it except:

Instead of saving just the initial-pause-position, I would save all of 
the jog positions, too. Then resume could play the positions back in the 
reverse order.

If is more work than is warranted now, at least keep that in mind for an 
enhancement so the the present solution doesn't rule that out.

Regards,

Ken

On 10/9/2013 3:02 PM, Michael Haberler wrote:
> please think through if this sequence sounds generally applicable, and 
> consider my questions below.
>
> the current flow I am thinking of is this:
>
> pause sequence:
> -
> if running, and pause command is issued:
> save the position where pause was detected as initial-pause-position 
> ('IPP')
> if the pause-offset 1) is non-zero:
>   jog to that offset, using a jog-velocity pin 2)
>   stop motion once there
> else
>   just stop motion
>
> ... jogging around...
>
> resume sequence:
> 
> if at the inital pause position:
> wait for at-speed
> resume motion
> else # in some offset
> if the pause-offset is non-zero and not currently at the offset position:
>issue a jog move to the pause offset at jog velocity 2)
>once arrived, wait for spindle at-speed 3)
>issue the reentry move to the IPP at jog velocity 2)
> else
># we are already at the offset position
>wait for spindle at-speed
>issue the reentry move to the IPP at jog velocity 2)
>
> if arrived at IPP:
> resume primary motion queue, program continues.
>   
> During the all pause states (except normal state - program running, not 
> paused) coolant and spindle NML commands will be honored.
>
> --
> 1) defined by a set of motion.pause-offset-x/y/z etc pins
>
> 2) currently NML jog commands needing velocity carry it as a parameter; 
> afaict there is no concept of 'current jog speed' in motion without a jog 
> command issued. But this move happens without an NML command conveying 
> values, so motion has no idea what the 'current jog speed' is. Short term 
> fix: use a pin motion.offset-jog-speed which applies to the initial offset 
> move, and the reentry move. Better long-term solution: make motion remember 
> whatever is 'current jog speed', e.g. by issuing an EMC_JOG_SPEED command at 
> startup and jog speed change in a UI.
>
> 3) doing it in this order (start jog, wait for at-speed when done) enables 
> overlapped spin up and move to the offset position by issuing spindle on, 
> then resume
>
> 
>
> Question 1: is there any use case for the offset used while pausing, and 
> while returning _to be different_?
>
> this would suggest two sets of HAL pins, pause-offset-x etc and 
> return-offset-x etc. Note either of those being zero would avoid the 
> predefined move-on-pause
> and move-on-return respectively.
> Having one set of pins implies that both moves will always be issued if 
> non-zero. The alternative is some mode pin which states which of the
> moves (on-pause, on-return, or both) is to use the pause offset (less 
> elegant, less pins).
>
> Question 2: is there any scenario where the wait-for-at-speed needs to be 
> skipped?
> (note motion.at-speed can be faked by external HAL logic if needed).
>
> Question 3: coolant, spindle, keyboard jog (+ eventually wheel jog): anything 
> to be added to the shopping list?
>
> Question 4: is a separate HAL pin for the on-pause/on-return speed acceptable 
> for the first round?
>
> Question 5: any possible interactions with other commands/modes which could 
> be an issue?
>
>
> this is a nontrivial change, so I would prefer the change is specified, 
> discussed and understood fully beforehand
>
> I attach the description of the various states the pause handling goes 
> through which might help to clarify operation a bit
>
>
> thanks,
> - Michael
>
> -
> // the states of the pause finite state machine
> // current state is exported as 'motion.pause-state'
> enum pause_state {
>  PS_RUNNING=0,  // aka 'not paused', normal execution
>
>  // a pause command was issued and processed by command-handler
>  // looking for the first pausable motion (e.g. not spindle-synced)
>  // the current position is recorded in initial_pause_position
>  PS_PAUSING=1,
>
>  // the initial pause offset is non-zero.
>  // jog to this offset once a pausable motion has been detected;
>  // once this jog completes state transitions to PS_PAUSED_IN_OFFSET
>  PS_JOGGING_TO_PAUSE_OFFSET=2,
>
>  // motion stopped, and position is where the pause command was issued
>  // This state is reached only if pause offset is zero.
>  // on resume, no further move will be issued
>  PS_PAUSED=3,
>
>  // motion stopped, and positon is NOT the initial_pause_position
>  // meaning a reentry sequence is needed before a resume (i.e. switch to 
> the
>  // primary queue) can be executed
>  PS_PAUSED_IN_OFFSET=4,
>
>  // cur

Re: [Emc-users] Machine zero, fixture offsets.

[Kenneth Lerman]

Of course, if you think like a programmer and don't want to know 
anything about G92 or stuff like that, you just write a gcode subroutine 
to make the part. The subroutine takes two arguments, the X and Y 
coordinates of the (center, edge, whatever) the part.

Then call the subroutine once for each place that you want to make the part.

Ken

On 8/14/2013 1:48 PM, John Alexander Stewart wrote:
> Viesturs;
>
>
>> Jon, docs do not say anything about L word in G92 command. Is that just a
>> small typo?
>>
> pre-coffee typo.
>
> Essentially what I want to do is to make 9 copies of a shape, and, thought
>
> "if I make 9 imaginary fixtures, I can simply change to the next fixture
> and machine the part again"
>
> but it might just be easier to move the coordinate system than worry about
> imaginary fixtures.
>
> Right?
>
> Yesterday I did learn that I needed to do a lot more reading and
> experimenting on coordinate systems in Gcode, and actually went through the
> emc.var file to see what was happening, so lots of stuff learnt.
>
> Maybe tonight I'll get more time to play (learn), before I start actually
> machining.
>
> Thanks! - John A. Stewart.
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Code Preview (Was: how long was your longes G-Code program ever?)

[Kenneth Lerman]

On 7/18/2013 11:59 AM, Charles Steinkuehler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 7/18/2013 10:43 AM, andy pugh wrote:
>> The (AXIS, STOP) "magic comment" might be better than increasing
>> the cut size.
> I use this on all my gcode now, and it helps (a LOT), but loads are
> still very slow, particularly on larger files (as in it can take 6-10
> minutes or more), but it's much faster than without the "magic comment".
That seems to be a delay caused by Axis, not by the interpreter. As far 
as the interpreter is concerned, there is no such thing as a load. (Or 
that was the case the last time I looked.)

If you have some subroutines defined near the beginning of the file, 
there is a delay while they are noticed and skipped over. Otherwise, as 
soon as it reads a block it executes it. I could imagine a delay of 6-10 
seconds, but not 6-10 minutes.

My guess is that even when it sees the (AXIS, STOP) comment, it 
continues to interpret the file, it just skips the "motion" -- which in 
this case means it skips the graphics. There's a good chance that it 
even continues to interpret subroutine calls and loops.

(Assuming I'm correct)
I've never looked at the source to Axis, but it might be possible to 
change it so that when is sees the STOP, it starts reading the input 
directly and skips until it sees an (AXIS, START) or end of file.

Ken

>
> I need a faster 'Bone, or easy-to-use profiling tools!  :)
>
> - -- 
> Charles Steinkuehler
> char...@steinkuehler.net
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlHoEP0ACgkQLywbqEHdNFzk/ACgwJM0EysnQgUoh3gkDdMylvMo
> IUIAnj/h8YmEbRv+w00zxTWdGM/uOM+s
> =diiW
> -END PGP SIGNATURE-
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] mail list over forums?

[Kenneth Lerman]

On 7/11/2013 9:00 AM, John Kasunich wrote:
> We've had this discussion before.  Different people prefer to get their
> information in different ways.  That is why we have both email lists
> and a forum.
>
> This topic is a lot like religion or politics - you can have a lot of talk,
> but in the end, everybody is likely to stick with what they preferred
> in the first place.
>
> Any proposal to eliminate the mail list _or_ the forum isn't going to
> get very far, because both forms of communication have very strong
> advocates who have very good reasons for their preferences.
>
>
True.

But I've noticed that the subject always seems to be brought up by the 
new people who prefer the forum format and are unhappy that all of the 
action is on the mailing lists.

It would be neat if we could have a forum topic called emc-users and one 
called emc-developers set up so that if you post to the forum it would 
be sent to the list and if you posted to the list it would appear on the 
forum.

That would permit the forum users to go to only a single place to see 
the real action.

(I suspect that the complaint would then be that the emc-users topic 
contains too much disparate stuff and should be broken into multiple 
topics.)

As far as I recall, most of the people at Wichita were familiar names 
from the list. So I'm happy sticking with just the list, and confident 
that I'm not missing much by avoiding the fora.

Ken

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Servo issue

[Kenneth Lerman]

See below...

On 7/5/2013 11:45 AM, Viesturs Lācis wrote:
> Hello!
>
> I am stuck with a servo motor issue that I have no idea for the cause.
> Machine has 5i23 and 2x 7i39 cards with total of 4 servo motors.
> I set it up 2 months ago and it was working correctly. Machine was idle for
> few weeks until now.
> Motors 0, 1, 2 are working correctly, motor 3 does not move, pid 3 gets
> reaches its max value as soon as I try to jog the motor.
>
> 1) I swapped motor and feedback cables of motor 2 and motor 3 (they are on
> the same 7i39 board). Problem moved with the motor, so 7i39 board is fine.
>
> 2) I attached motor 0 to motor 3 cables on machine, motor 0 did not work; I
> attached motor 3 to motor 1 cables, motor 3 worked correctly; both of these
> things tell that problem is somewhere in motor wires;
>
> 3) so I took multimeter, and checked motor power cable between motor plug
> and 7i39 plug - all the lines are where they are supposed to be;
Checking that every pin goes where it belongs is necessary, but not 
sufficient. You must also test that no pin goes where it doesn't belong. 
Did you check to see if any pins were shorted to each other?

Ken
>
> 4) I tried to spin the motor in "bldc config=n" with bldc.value 0.15 and
> bldc.frequency explicitly set at 0,15 and 3 respectively (motor should
> slowly rotate as soon as pwmgen is enabled), but it moves just a very
> little and stops;
>
> The drive is ok, motor is ok, cable is ok, but now they are not working
> together. Everything was fine few weeks ago.
>
> I would appreciate any suggestions, what else can I try to understand, what
> exactly is wrong.
>

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] takeway from the Wichita meeting

[Kenneth Lerman]

On 6/30/2013 7:37 PM, andy pugh wrote:
> On 30 June 2013 14:11, Michael Haberler  wrote:
>> there's something different at work, namely a rather high ranking of 
>> stability and quality of support being the overriding driving factor. While 
>> that clearly is a more commendable explanation,
>> unfortunately the effect is similar: the focus on a single technical aspect 
>> - quality at a given point in time - drives other aspects into the 
>> background - for instance: even if it is not 100%
>> ready for use, is it an important or at least first step into a new (and 
>> eventually important) direction.
> I think that there is possibly too much of an expectation that "Master
> must never be broken", but at the same time I can see why that is seen
> as important, because a lot of people routinely run it. (including
> me).
>
> I have always been of the opinion that creating a new branch was a
> mistake (and, to be honest, the times I have done that it has
> definitely been both a mistake and an accident). Having talked to folk
> at Wichita I am now seeing that this was largely a problem with my
> understanding of how things are meant to work, and I very much expect
> to be pushing a new (and explicitly, knowingly broken) tooltable
> branch this week.
>
> Part of my misunderstanding might stem from the fact that JA3 has been
> stuck in a separate, unmerged, branch for all the time that I have
> been involved. I haven't noticed anything from an experimental branch
> get merged. I may not have been watching at the right time. I can see
> an argument for deleting (or tagging) branches that got merged. (and
> possibly for tagging the "rejected/superceeded" branches.
>
> To merge threads, is it possible to set up a multi-level access to our
> Git server, where almost anyone can create a new branch, people like
> me can create a branch or push to master, and the folk who actually
> know what they are doing can push to the release branches?
>
> I don't think we need to migrate to Github to make ourselves more open
> to contributions, I just think we need to make it clearer how to
> contribute. (and to make it harder to lose contributions, and, as a
> consequence, the contributors).
>
> Case in point: 
> http://thread.gmane.org/gmane.linux.distributions.emc.devel/4043/focus=4239
> The current 2-ratio gearchange component is rather limited (and not
> just in the sense it only supports two gears). I know of at least
> three better versions that have been passed by.
>
Regarding your case in point:

We should be able to have user loadable (at run time) components -- 
running everything in user space would make that trivial.

That would mean we could have as many gear change components as people 
cared to write. A broken component would only affect those who tried to 
use it. It would be marked as a contributed component (use at your own 
risk).

Modularization is good.

[BTW (Andy): It was good meeting you in Wichita. I'll remember you as 
(among other things) the guy who knew what Flemish bond was -- any why 
it was.]

Regards,

Ken

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Brain-Dead LinuxCNC G-Code Interface?

[Kenneth Lerman]

IANAL,

But as far as I know, the only part of a patent that *really* matters is 
the claims. So even though the description seems obvious, the claims 
might say something like: where the insulator is made of pure 
unobtainium. That might be non-obvious.

Ken

On 6/27/2013 3:53 PM, Charles Buckley wrote:
> Well, yes, I would expect that to be the case.
>
> http://www.google.com/patents/US6722872
>
> "Disclosed is a three-dimensional modeling apparatus (*10*) that builds up
> three-dimensional objects in a heated build chamber (*24*) by dispensing
> modeling material from a dispensing head (*14*) onto a base (*16*) in a
> pattern determined by control signals from a controller (*140*). The motion
> control components (*18, 20*) of the apparatus (*10*) are external to and
> thermally isolated from the build chamber (*24*). A deformable thermal
> insulator (*132*) forms a ceiling of the building chamber, allowing motion
> control of the dispensing head (*14*) in an x, y plane by an x-y gantry (*18
> *) located outside of and insulated from the build chamber (*24*). In the
> preferred embodiment, a material dispensing outlet (*66*) of the dispensing
> head is inside the chamber. Thermal isolation of the motion control
> components from the build chamber allows the chamber to be maintained at a
> high temperature."
>
> I am still trying to determine what part of that meets the "not obvious to
> someone versed in the field" that was part of the law creating the patent
> system, but its the world we live in now..
>
> That particular patent is good until Apr 20, 2021
>
>
>
> On Thu, Jun 27, 2013 at 1:01 PM, Gene Heskett  wrote:
>
>> On Thursday 27 June 2013 14:59:37 Charles Buckley did opine:
>>
>>> Well, on January 28th, 2014 the next generation of stereolithography
>>> patents expire. That will increase the resolution a ridiculous amount.
>> Interesting, until some troll crawls out of the swamp.  Are there any other
>> gotchas that will fall through to, to bite the unwary?
>>
>>> Linuxcnc is a much more adaptable baseline for any of these machines. I
>>> would expect to see a lot of UI changes and movement with it.
>>>
>>> On Thu, Jun 27, 2013 at 10:49 AM, Bari  wrote:
 I agree with you. When the GGG (Glorified Glue Gun) fad started a few
 years ago many of the maker folk looked at Linuxcnc since it had been
 used to control multi-axis machines for over a decade. Some of them
 felt that it was too complicated and expensive to control their GGG
 made mostly of threaded rods, nuts and low resolution PLA printed
 parts. They then decided to just use an Arduino and make some custom
 IO stepper boards to control the 3-axis Cartesian stage and glue
 gun/extrude and write all the software from scratch. The printers
 still needed a PC for the user interface, but I guess you weren't
 supposed to notice that.

 Later they decided to move from Arduino to all-in-one 120MHhz ARM
 cortex M3/4 boards and write all new libraries for the new
 architecture. The new all-in-one boards sell for $120-200 and combine
 the micro with stepper drivers, GPIO and mosfet outputs. A PC is
 still required for the UI but they can run stand alone with the
 G-code stored on an SD-Card.

 Now TI has released a $45 BeagleBone Black with a 1GHz ARM Cortex A8
 that can host the machine control and suddenly there is interest in
 Linuxcnc again. The UI can be directly off the GPU or over he network.
 The Beaglebone Black still needs some expansion IO to drive the
 steppers and extruder but the BOM is <$30.

 The GGG's only use one or two nozzles to deposit material so the
 process is very slow and they have difficulty with producing features
 under 200um. It's become popular since the original patents expired a
 few years ago and you can build your own printer for only a few
 hundred dollars.

 The reasons I have heard from the "maker guys" for not aspiring to
 other additive manufacturing technologies have been the complexity
 and the high costs involved for DIY. There are a few DIY projects
 that use SLA with DLP (B9) or laser (SLAMPS) but they have chosen
 slow methods mostly due to the problems with "It's the patents
 stupid!" or just ignorance of the technology and SLS, Inkjet and
 micronozzle DIY is practically non-existent.

 On 06/27/2013 10:29 AM, Dave wrote:
> I have been randomly watching the 3D printer efforts from the
> sidelines and for the most part I have not been impressed at all.
>
> I think you are right ...  they are way, way behind.  To many, it
> seems that reinventing the wheel is how they learn but at the
> expense of making any meaningful
> progress.
>
>>>Loading an SD card works because it
>
> is pretty bullet-proof and easy to manage as is just pressing a
> button.<<
>
> I guess that is fine if you want to duplic

Re: [Emc-users] What is the Wichita meeting?

[Kenneth Lerman]

On 6/12/2013 9:41 AM, Matt Shaver wrote:
> On Wed, 12 Jun 2013 13:17:05 +0200
> Sven Wesley  wrote:
>
>> ...and why isn't it promoted at http://linuxcnc.org?
> Mostly because we're a bunch of knuckleheads. Is this you?
> https://www.facebook.com/sven.wesley I ask because if it is, you
> probably don't live in the US (if you're wondering, it was the
> diacritical marks that gave you away).
>
> Anyway, Wichita, Kansas is where Stuart Stevenson has his airplane
> parts making shop. Every once in a while he (and Roland Friestad
> in Galesburg, Illinois before him) has a get together of the linuxcnc
> developers. It's hard to recommend that someone attend these meetings
> unless they are a hard core linuxcnc enthusiast. If you've never
> been to one, whatever you imagine these meetings to be like is probably
> wrong. Let's just say they are a rather singular experience, kind of
> like Burning Man but a lot smaller and without girls.
>
> Anyway, if I have the right Sven Wesley, you seem to be one of those
> X-Games/Extreme Sports guys so I can't rule out the possibility that
> you might own an airplane. If so, and you decide to show up, call me on
> my cell at (443)789-4628 and I'll get you picked up from the airport
> (ICT). If you come, I'll buy you a steak dinner (apologies if you're
> vegan).
If you are vegan, I'll buy you a carrot. :-)

Ken
> Thanks,
> Matt
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Licensing Questionaire

[Kenneth Lerman]

I've snipped stuff from the top and bottom of Steve's post. My comments 
are below.

On 6/8/2013 8:12 PM, Steve Stallings wrote:
>
> We should be so lucky.
>
> The LinuxCNC (nee EMC) community is a very diverse bunch.
>
> Some folks have been involved for only a few months, others
> have been around since 1996.
>
> Some are only modestly involved. Some devote most of their
> waking hours to working with it, even if they never actually
> run a real machine with it.
>
> Some believe that LinuxCNC should be a religion and needs
> to be actively promoted to the unwashed masses. Others feel
> that it just IS and should be left alone to exist in peace.
>
> Some come to it as a free and excellent body of code that
> is available for their own personal use and others see it as
> part of what provides their livelihood. (Disclaimer, I hope
> to be among the latter.)
>
> Some believe that the code must be protected by strong licensing
> from those who might attempt to use it without contributing
> back to the community. Others believe that it should be sown
> upon the earth freely for anyone to use in any fashion they
> wish without the hassles of legal contracts.
>
> Some want there to be a formal organization that manages the
> future of LinuxCNC. Others are allergic to any form of control.
>
> That LinuxCNC has continued to be developed proves that people
> do like it and find it worthy of their time and effort to improve
> it, despite the different view points on how it should evolve.
>
> I do hope that the session in Wichita continues in the same
> spirit as past versions and functions as an opportunity to
> improve the code while going lightly upon the substance of
> governance. The chance to have a significant number of
> people face to face in Wichita to discuss and work on
> LinuxCNC is a great opportunity, but lets not forget that
> the community is much larger than the fortunate ones who
> can attend in person.
>
>
Steve's post raises the important question of how we will proceed 
considering the disparate views of this group. My personal view is that 
the major stakeholders should have the major say. I would define the 
major stakeholders as:
1 -- The people who have contributed the most
2 -- The people who have the most invested

Since most of us will not be in Wichita, or will only be there part of 
the time, I think it important that we try to characterize the 
stakeholders and their views prior to the meeting. For that reason, I'd 
like to suggest that people who consider themselves stakeholders answer 
the following questions (which I've based on Steve's thoughtful post -- 
and used many of his words without a license to do so).

1 -- How long have you been involved in LinuxCNC?

2 -- Do you consider yourself to be heavily involved or only modestly 
involved? What is the nature of your involvement? As a developer? As a 
user?

3 -- So you believe that LinuxCNC should be actively promoted or that it 
should be left alone to exist in peace?

4 -- Do you come to it as a free and excellent body of code available 
for your own use or do you see it as part of what provides their livelihood?

5 -- Should it be protected by strong licensing from those who might 
attempt to use it without contributing back to the community? Or should 
it be sown upon the earth freely for anyone to use in any fashion they 
wish without the hassles of legal contracts?

6 -- Should there be a formal organization that manages the future of 
LinuxCNC?

If you come to Wichita, it would be helpful if you've thought about 
these questions. If you don't (and if you care) you should make your 
opinions heard.

[For those who will be in Wichita, I have an additional question. What 
is the difference between a meeting and a bull session? My answer is below.]

I'm cross posting this to emc-developers and emc-users.

Regards,

Ken














[Ken's answer to the question -- A meeting starts with an agenda and 
ends with minutes. Consider this a suggestion for the Wichita 
participants in the licensing/governance/... meetings. -- KL]


--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Correct use of subroutines

[Kenneth Lerman]

On 5/10/2013 4:18 PM, Viesturs Lācis wrote:
> Hello!
>
> Today I was helping my client to prepare a g-code for their new machine I
> built.
> The particular code was manually optimized for faster performance and I
> thought that having a code for one part in subroutine and then creating
> another file, which just moves around material and calls subroutine in
> appropriate places would be easier than hand-optimizing one big and long
> g-code file.
>
> Since I have not had any experience with subroutines so far, I looked in
> manuals. Based on them I was able to define subroutine and call it from the
> master file.
>
> What I do not know, how to do properly, is when the subroutine has been
> called once and is finished, machine moves to next point to call the
> subroutine again. How do I move subroutine's coordinate origin to the new
> spot?
>
> I tried 2 things:
> 1) G55 is specified at the beginning of subrouting file;
> in master file I had:
>   G21
>   G54
>   G40 G90
>   G64 P0.02
>   G0 Z15
>   G0 x0 y0
>   G10 L2 P2 X0 Y0 Z15
>   o101 call
>   G54
>   G0 Z15
>   G0 X0 Y200
>   G10 L2 P2 X0 Y0 Z15
>   o101 call
> 
>
> 2) then I tried to move G10 L2 P2 X0 Y0 Z15 to subroutine so that it is
> done in subroutine
>
> Anyway, none of these 2 approaches work properly, G55 origin is not moved
> and as soon the subroutine was called for the second time, machine started
> to move somewhere. Z axis was moving down too much, so I never allowed it
> to finish as it really seemed to be willing to crash the tool in material
> (I tested it in the air some 100 mm above material).
>
> I would appreciate, if someone could share some working example of how to
> do these things properly.
>
I usually just specify the coordinates as arguments to the subroutine. 
For example, if I have a subroutine that mills a circular pocket, I pass 
the center of the pocket as the first two arguments to the subroutine.

Ken

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Beaglebone LinuxCNC starterkit: ready-to-run SD card image

[Kenneth Lerman]

On 4/28/2013 5:15 PM, Jon Elson wrote:
> Eric Keller wrote:
>> On Sun, Apr 28, 2013 at 1:55 PM, Jon Elson  wrote:
>>
>>
>>> Is there a consensus about BeagleBone vs. Raspberry Pi?
>>>
>>>  
>> I think it's a no-brainer myself.  I have a Raspi, but I just don't see it
>> competing with the bbb
> OK, this was my take on the hardware, but there was so much RPi
> discussion here, I thought that might be the way development was headed.
> I support the Beagle direction, too, and hope much of what I have
> learned on the original Beagle will port over to the Bone.
>
> So, if I were going to make something for the Bone, should it be
> like a PC parallel port, or some other kind of breakout board?
> I'd like to make something that allows my parport-connected
> devices to be used with the Bone, but maybe others would
> rather have a much "wider" I/O device, maybe a couple
> dozen inputs and outputs from the PRU-accessible pins.
>
> So, any thoughts would be welcome.
>
> Jon
Jon,

I think if you look at the capabilities of the Bone, it might be hard to 
justify adding your board. (Note that I haven't looked at the detailed 
specs.)

The Bone has multiple encoders support. How does the rate supported 
compare with the rate of your boards? The Bone can drive multiple 
steppers at a high rate. Compare with your boards. The Bone has multiple 
pwm outputs. How do the number of outputs, resolution, and rate compare 
to your boards?

I think that those are key questions you will need to be able to answer.

Regards,

Ken

>
> --
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Beaglebone LinuxCNC starterkit: ready-to-run SD card image

[Kenneth Lerman]

Beaglebone -- TI chip. Intended for industrial use. Family will be 
available forever. The boards are open source.

Raspberry Pi -- Broadcom chip. Intended for cell phone use. A new model 
every year. The boards are open source -- you just can't buy the chips 
for them.

The PRU on the Beaglebone is a deal maker.

Ken

On 4/28/2013 1:55 PM, Jon Elson wrote:
> Michael Haberler wrote:
>> As promised, I have prepared an SD card image for the beaglebone 
>> ready-to-run.
>>
> Fantastic work, many thanks!
>>partition 2 - ext4, size 3.8GB or greater,
>>
> In a number of places, ext4 has been reported to be associated with
> early failure
> of SD cards.  I'm not sure whether to believe this, but I have seen so
> many reports,
> I worry about it.
>
> Is there a consensus about BeagleBone vs. Raspberry Pi?  I have been
> thinking
> about redoing my old BeagleBoard EPP converter for one of these boards,
> but didn't want to start until it was decided which way to go.
>
> Jon
>
> --
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] LinuxCNC would be very nice on the UDOO board.

[Kenneth Lerman]

The Beagle Bones are so cheap, that we shouldn't be worrying about how 
many pins we can drive. Just connect a few together using etherCAT or 
real time ethernet, or whatever the thing supported by the hardware is 
called.

As far as I'm concerned, the problem of no parallel port has been solved 
with these devices and an ethernet. Sure we need a driver, but that 
isn't rocket science.

We do have some significant open questions for the next few decades though.

-- How will are functionality be divided among hardware units?
-- How many (and what) platforms will we support?
-- How can we distribute HAL (and should we) among multiple components?

We KNOW we will lose the parallel port. We know that PCs will become 
less deterministic when it comes to real-time operation. (Modern office 
machines MUST play games with their clock speed to use power efficiently.)

-- Does our future architecture include a PC?

Ken


On 4/23/2013 11:03 AM, Charles Steinkuehler wrote:
> On 4/22/2013 11:40 AM, Matt Shaver wrote:
>> On Sun, 21 Apr 2013 19:30:23 +0200
>> Michael Haberler  wrote:
>>   
>>> We'll have a ready-to-go SD card image with xenomai, all prerequisite
>>> packages and linuxcnc installed in a week or two; that will include
>>> Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should
>>> reduce the guru requirements to get things going
>> So, I'm ordering a new Beagle Bone Black this morning & I was wondering
>> what you guys are doing for a field I/O interface for this computer. Is
>> there a cape I should get? Or are we at the perfboard and wire-wrap
>> wire stage? :)
> The BeBoPr board is available now and has support for both the Pololu
> drivers common in the 3D printer world and a header to drive out-board
> stepper drivers with a more "oomph".  From the BeBoPr maunal:
>
>J5 – all stepper signals are present on this connector. It connects
>directly to the 15 pin sub-D connector of a TB6560-4V5 3A stepper
>driver board sold on e-Bay.
>
> There's also the Replicape, but AFAIK it's on-board stepper driver only
> (Pololu class, but using TI driver chips).
>
> There's nothing I'm aware of yet that works for analog servos, but it
> should be possible, at least for a few channels (the CPU has 3 hardware
> encoder inputs, and the PRU could support more in "software" at lower
> pulse rates).
>

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Poor CV

[Kenneth Lerman]

On 4/10/2013 5:01 PM, andy pugh wrote:
> On 10 April 2013 21:50, dave  wrote:
>
>> No panacea anywhere in sight.
> Something I saw somewhere on the Internet (possibly a link from mah)
> was an article about different approaches.
> One very interesting idea was that every "move" as well as being an
> end-point also includes an "end velocity"
> I think that these "end velocities" need to propagate backwards back
> up the queue.
>
While we are looking at this, we should be sure to consider adding jerk 
limits to the system.

Since computers are (approximately) infinitely fast and have infinite 
memory, we should be able to look ahead to the next stop point (which 
might be the end of the program).

I don't think this is rocket science. (Having worked on the Lunar Module 
project, I have a chance of recognizing rocket science.)

Ken

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] missing man 9 hal

[Kenneth Lerman]

On 12/9/2012 6:31 AM, John Thornton wrote:
> Yea, there is nothing intuitive about man pages... either you know the
> magic names or your lost.
Well, if you more or less know the subject, "apropos" usually helps. 
(But often gives too many false positives.)

Ken

>
> On 12/8/2012 4:14 PM, Sebastian Kuzminsky wrote:
>> On 12/08/2012 02:25 PM, Gene Heskett wrote:
>>> What we need is a short man page that describes the syntax of the various
>>> "first word" of a line settings, loadrt, addf, setp, net, etc.
>> This may not be intuitive or obvious, but loadrt, net, and friends are
>> all handled by a command called "halcmd", which does have a manpage.
>>
>>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT - CNC Workshop not to be hosted by Digital

[Kenneth Lerman]

On 10/19/2012 9:23 PM, Jon Elson wrote:
> ed wrote:
>> I talked to a vendor there in the mid 90's and he said it was $60K for
>> the show. His booth was a 20 by 20 in the basement behind the stairwell
>> in the old South building, the least prime spot you could find in the
>> whole show. He could not even plug in his own equipment, had to call the
>> "electrician" for everthing.
>>
> Oh, you're not allowed to move anything yourself, either, except for a
> single copy of a brochure.
> Everything has to be done by union workers, and they bill you for an
> hour to move one box
> of flyers from your car.  But, all the trade shows are like that.
No. Not all. I've exhibited at Veterinary trade shows in San Diego, 
Kansas City, Denver, Louisville, and Baltimore.

In Louisville we carried our entire booth in. In Denver, we carried five 
large boxes in. At all of them, if you could carry it with one hand 
(like a small suitcase), you could do it yourself.

We generally shipped a 2x3x4 foot box containing everything we needed 
for our booth. That included floor covering, three chairs, an eight foot 
table, table covering, etc. We used battery power so as to avoid paying 
for an electric outlet.

If you don't do something like that, you pay $60 per chair, $100+ for 
floor covering, $100 for a table + $50 to cover it, ...

The booths at the shows we were at ran about $1600 for the show.

Ken
>
> Jon
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Book Recommendation

[Kenneth Lerman]

On 9/8/2012 5:22 AM, andy pugh wrote:
> Rather off-topic, but I think a lot of us will feel a commonality with
> the main character in
> "Trustee from the Toolroom" by Nevil Shute.
> (Available on Kindle)
>
Thanks for the recommendation. I enjoyed it.

Ken


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] worsk: sim parport component

[Kenneth Lerman]

On 9/3/2012 4:51 PM, Michael Haberler wrote:
> well, that seems to work just fine - no major surprises
>
> here's as screenshot from a logic analyzer connected to an Intel D5252 
> parport, running the userland parport driver in sim mode
>
> http://static.mah.priv.at/public/uparport.png
>
> it's a 1kHz square; there are delays of up to 4ms in this trace.
>
> it will be interesting to see how well that performs once the RT_PREEMPT 
> incantations are added
>
> - Michael
...

OT:
What is it about plotting software? Why can't they make the time axis 
have reasonable offsets? Why is it T+413, T+433, T+453 instead of T+410, 
T+430, T+450? Or better yet, T+400, T+420, T+440. I saw the same issue 
with a different plotting package while working on a recent contract.

We cared about details like this 45 years ago when plots were done on a 
Calcomp plotter. It's not rocket science. (Actually, I was working at 
Grumman on the Lunar Module at the time -- maybe it was rocket science.)

Ken


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ubuntu from live-CD does not shut down or restart

[Kenneth Lerman]

I had the same problem. Or at least a similar problem having to do with 
hanging on restart.

I reflashed bios with a newer version and that fixed it.

Ken

On 9/3/2012 1:15 PM, Viesturs Lācis wrote:
> Hello!
>
> I am stuck with a strange problem that I see for the first time:
> Ubuntu from liveCD of 2.5.0 version does not shut down or restart, it
> just logs off.
> It is D525MW + 2gb ram + 160gb hdd PC.
>
> I have searched the web for a solution and I have found 2 fixes:
> 1) disable OpenOffice quickstarter
> the thing is that I do not see that OpenOffice is actually installed
> on the system and "startup applications" do not have any OO related
> entries;
> 2) in terminal I executed
> sudo gedit /etc/default/grub
> then I changed this line
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash isolcpus=1"
> to this one
> GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi=force isolcpus=1"
>
> The problem with this one is that Ubuntu started to freeze up,
> LinuxCNC also froze, mouse was working, but I could not open any menu,
> not in LinuxCNC, not in taskbar. Once I changed back, everything works
> perfectly.
>
>
> Has anyone else encountered something like this?
> Could it be that I should not remove "splash" from that grub command
> line in the second option?
>
> In the meantime I shut the PC down with "sudo shutdown now", but I do
> not think that this is an option I want to keep permanently.
>


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] moglice, another note

[Kenneth Lerman]

On 8/27/2012 12:03 PM, Kirk Wallace wrote:
> On Mon, 2012-08-27 at 08:48 -0500, Martin Dobbins wrote:
>> I'm not sure if this would work for you, I haven't tried it myself, but it 
>> may be worth a look:
>>
>> http://bbs.homeshopmachinist.net/threads/43645-Making-Acetal-leadscrew-nuts-the-easy-way
>>
>> Martin
> I tend to prefer a more traditional method. Machine a pair of plastic or
> metal nuts and create a mount that allows for a preload similar to
> double nut ballscrews. Or better, I'd like to find a way to make DIY
> ballscrews. Maybe using a DIY centerless grinder (roller?) on a lathe
> carriage?
>
> This might be another DIY solution:
> http://en.wikipedia.org/wiki/Roller_screw
>
>
An acme screw with a (home made substitute) moglice lined nut should 
approach the low friction and low backlash of a ballscrew.

I previously posted a note on DIY "moglice".

Regards,

Ken


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G71 lathe roughing cycle

[Kenneth Lerman]

On 8/27/2012 9:16 AM, Ralph Stirling wrote:
> I have wished for a long time for a general mechanism for
> defining a path (profile) once, then using that path multiple
> times in functions.  This reinvention of G71/G70 looks like
> a good opportunity to create such a mechanism.  I use G71/G70
> often in code for our Mori Seiki lathe (Fanuc 0i control).  I see
> no particular reason to slavishly implement the Fanuc syntax
> though, as it is very peculiar.  I have to study the manual
> carefully every time I write a new program using it.  Something
> more general and intuitive for LinuxCNC would be great.
>
> -- Ralph
I've done that by writing a subroutine that traces the path. The 
subroutine takes a single argument that represents the offset from the 
path. Then call it in a loop with appropriate values.

Ken


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] General question about gibs

[Kenneth Lerman]

On 8/24/2012 8:41 AM, Kent A. Reed wrote:
> On 8/24/2012 5:43 AM, Gene Heskett wrote:
>> Oh no!  Last I knew he only had 3 legs left cuz they weren't going to eat
>> him all at once.:)
> I thought I was the only one left who knew that joke. People who grow up
> in farm country have a different view of animals than the 3-rd
> generation suburban folks around me. I'm not saying it's a better view,
> just different.
>
> Regards,
> Kent
Count me in as one of the ones who is left. (Brought up on Long Island, NY).

Ken
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Hey Gene! Hand held O'scope for ya.

[Kenneth Lerman]

On 8/16/2012 2:00 PM, Jason Burton wrote:
> On Aug 14, 2012 10:16 PM, "Gene Heskett"  wrote:
>> On Tuesday 14 August 2012 23:09:35 Jason Burton did opine:
>>
>>> On Aug 14, 2012 9:08 AM, "Gene Heskett"  wrote:
 On Tuesday 14 August 2012 10:00:30 Mark Wendt did opine:
> Ebay auction #160861790127
>
> Mark
 A bit rich ($330) for my budget.  I bought one of the DSO NANO's.  For
>>> what
>>>
 I want to use it for its adequate.  Unplug the usb charging cable and
 its fully isolated.

 Cheers, Gene
 --
 "There are four boxes...
>>> How do you like the DSO Nano? I've been eyeing them for a while.
>>>
>> About the only thing I haven't mastered is getting the sweep trigger set
> so
>> I can see the actual trigger.  Other than that, and a miss-match between
>> the probe and its frequency comp that distorts a square wave somewhat, it
>> Just Works(TM).
>>
>> I didn't expect it to match my Hitachi V-1065, but at 5% of the cost ...
>>
>> Cheers, Gene
>> --
>>
> I have a 100 mhz HP scope for the bench, but it takes a bit to warm up (if
> you follow the manual's guideline). That and no one-shot event capture have
> me looking for another scope.
>
> Doing some very short transient pulse measurements. Good news is they are
> audio frequency range so no great strain on most worth-anything scopes.
>
> Looking for a good bang for the buck rig with either digital capture that
> can be downloaded for analysis, or even old school one-shot hold memory
> (and i'll take a photo of the screen).
>
> I left off looking at the Tek 2200 series with memory added when the Nanos
> came around.
>
> Think it might be a good fit?
>
> Jason
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

See: http://www.saelig.com/PSBE100/PSPC017.htm for what appears to be a 
pretty good deal. $399 includes shipping.

Ken


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] just a note

[Kenneth Lerman]

On 8/12/2012 9:36 AM, Stuart Stevenson wrote:
> Yesterday I was wondering what had triggered the action. I can hardly keep
> up with the reading. I agree - WOW
> The topics are very interesting also. I have spent so much time reading
> this list my wife is wondering if I have a girlfriend. :)
An architect, an artist, and an engineer are discussing why one should 
have a mistress.

The architect says he has a mistress for inspiration.
The artist says he has a mistress as a muse.
The engineer says he has a mistress so that he can tell his wife he is 
with his mistress, tell his mistress he is with his wife, and then go to 
the office and get some work done.

Ken

>
>
> On Sat, Aug 11, 2012 at 11:12 PM, jeremy youngs wrote:
>
>> It seems since that whole mach3 episode this list is flat out bustlin wow
>> that awesome!!!
>>
>>
>> --
>> jeremy youngs
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>
>


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] moglice, another note

[Kenneth Lerman]

On 8/11/2012 2:15 PM, Jon Elson wrote:
> jeremy youngs wrote:
>> http://www.moglice.com/
>>
>> has anybody got experience wit this stuff? im thinking about lining my
>> lead nuts with it as ti seems less involved (read expensive) than
>> ballscrews and would help to eliminate the .006 backlash thats
>> destroying my nice circles. just wondering
>> jeremy youngs
>>
> I used it on the bottom of the carriage when I rebuilt a 15" Sheldon
> lathe, it worked VERY
> well.  It is quite expensive stuff, though.  Devitt Machinery does show
> some uses like
> this in their manual.  You can call them and consult on the application.
>
> Oh, if there is any variation in the thread thickness due to wear in the
> middle of
> the leadscrews, this will cause binding at the ends of travel.
>
> Jon

For a DIY moglice substitute see:

http://www.cnczone.com/forums/showthread.php?p=396591&highlight=moglice#post396591

(I haven't tried it.)

Ken

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] long set screw

[Kenneth Lerman]

Hi Gene,

McMaster has long set screws -- sort of.

They have "swivel pad set screws" --

Steel 10 Degree Swivel Pad Set Screw for Angled Surfaces, 1/4"-20 
Thread, 3-3/8" Length

Regards,

Ken


On 7/16/2012 5:08 AM, Gene Heskett wrote:
> On Monday 16 July 2012 04:43:01 jeremy youngs did opine:
>
>>> Greetings all;
>>> This need for a long allen set screw as the starting material for
>>> this differential screw that Andy reminded me of is being a problem.
>>> fleabay searches don't seen to be getting any hits tonight.
>> how long gene and what thread flavor? a piece of drill rod could be
>> milled to make a broach, with pilot and steps cuti in a lathe then
>> hadened and used in bridgeport to make the shaped hole? and you could
>> use the same piece of drill rod as your screw and neck it slightly for
>> a ways so as to leesen the likely ]hood of it breaking just thoughts
> Any 'thought' may contain the seeds of a solution idea, thanks.
>
> I have a couple sticks of 1/2" drill rod for raw material, and I have a few
> grade 12 bolts that also work well as raw material. I'm still cogitating on
> it, but the torx socket is the stronger of the two, and I think I can drill
> that with pcb bits on my mill.   The smaller end is already fixed at 10-32
> by drilling and tapping the end of the ball screw.  The larger end I may
> make metric at about 7mm as my access through hole in the extension is
> already .247" (6.2738mm).  Due to wall thickness vs strength
> considerations, that thread will have to be cut from the tapered socket end
> anyway.  That tap I have.  Match fitting the screw with G76 is fairly
> trivial for both thread sections.
>
> Cheers, Gene


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] ideas for "bumpless" transfer between encoders

[Kenneth Lerman]

On 7/12/2012 3:15 PM, Chris Radek wrote:
> On Thu, Jul 12, 2012 at 02:25:48PM -0400, Kenneth Lerman wrote:
>> I understand that you are "...not very worried about a couple of counts
>> every 75mm." It would be nice to have a cleaner solution.
> I didn't want to harp on it...  but I would want to determine
> whether the error was cumulative or not.  I even agree that 2um is
> nothing, but several 2um errors that accumulate every time you rapid
> across the table makes it totally unusable.  If you drill a few
> hundred holes in a circuit board, and the last ones are off my a mm
> or two, well, it's not going to be a usable board.
>
>> On the other hand, "There are things worth doing that aren't worth doing
>> right." This might be one of them.
>> (Particularly since I haven't seen a "right" solution.)
> The "right" solution is to use one long track and one read head.  If
> you want the track on the carriage so there are no moving wires, so be
> it - it will stick out past the ends of travel.  Protecting those
> sticky-out parts would not be rocket science...?  Not as pretty, but
> it would have the advantage of working correctly.
Is the track flexible? If so, could it be looped around a pulley at each 
end?

Ken
>
> Chris
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] ideas for "bumpless" transfer between encoders

[Kenneth Lerman]

Hi Ralph,

I forget who said it, but... "It is not sufficient that there be no 
obvious bugs. It should be obvious that there are no bugs." (Probably 
Hoare or Dikstra or some other pioneer.) I believe your solution fails 
that test.

I could easily imagine a small amount of servo hunting in normal 
operation. That might happen just at the transition between encoders and 
have an extra count in one direction, but not the other. That might 
cause a gradual zero drift.

I understand that you are "...not very worried about a couple of counts 
every 75mm." It would be nice to have a cleaner solution.

On the other hand, "There are things worth doing that aren't worth doing 
right." This might be one of them.
(Particularly since I haven't seen a "right" solution.)

Regards,

Ken

On 7/12/2012 2:03 PM, Ralph Stirling wrote:
> I solved my multiple-encoder problem for my linear motor.  It turned
> out to be almost trivial.  The encoder counter doesn't care where it
> is getting A and B signals from, just so each pulse represents a fixed
> amount of movement of the carriage.  So I connect all my A&B outputs
> together with tri-state buffers and enable each pair in succession as
> the "valid" signal of a new encoder becomes active.  I can now make
> my motor indefinitely long, with as many encoder modules as I want, at
> essentially arbitrary spacing (no calibration needed), and no special
> hal modules.  Hal just thinks it is an ordinary brushless motor setup
> with a single encoder.  My logic (as currently implemented) consists
> of two TTL logic chips per encoder head.
>
> It is possible to have a tiny glitch at the transitions, but since these
> AS5311 encoder sensors have 2um resolution per count, I'm not very
> worried about a couple of counts every 75mm.
>
> -- Ralph
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: and Soapbox: 3D Printer Mods?

[Kenneth Lerman]

On 06/04/2012 08:31 PM, Jeshua Lacock wrote:
> On Jun 4, 2012, at 5:41 PM, dave wrote:
>
>> It has always been my understanding that you can make a patented
>> device; you just can't sell it. I don't think this precludes using that
>> patented device to make things which you sell.
IANAL and I don't play one on TV. It is my understanding that in the US, 
you may NOT use a process or make a patented device without a license. 
It does not matter whether you sell it or not. At one point there was a 
patent for deactivating hydrogen peroxide for cleaning contact lenses by 
means of a (very small) platinum catalyst. The cleaning kit included a 
license to use that process.

You could not just do it yourself without the license. (Well, you could, 
but you would be infringing on the patent.)

Ken
> Good point.
>
> Also, as far as I know, Makerbot et al have not had much of a legal battle so 
> far. The only incidents I am aware of is a handful of big companies have sent 
> them cease and desist letters for "things" online at thingverse that were 
> essentially 3D scans of "copyrighted" geometry.
>
>
> Best,
>
> Jeshua Lacock
> Founder/Engineer
> 3DTOPO Incorporated
> 
> Phone: 208.462.4171
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] [Emc-developers] move-while-paused in action: video

[Kenneth Lerman]

Thank you Michael.

Once upon a time (6/22/2009), I suggested:
==

One way to approach this would be to use HAL to add a position offset to
each joint. Normally, this would be set to zero. While paused, one could
then have jog functions that changed those offsets. That could manually
position the cutter where you wanted.

Then when you are done, use the jog functions to get back to where you
started (all offsets zero). Then hit continue.

Notice that no MDI functions would be used. Coolant, etc would be
unchanged. You would probably want a manual coolant switch to turn off
the coolant.

==

I still believe that would be the way to go.  (Although I would add some 
more automation.)

A new HAL component could connect to N jog inputs (one for each axis). 
In feed hold mode, the joggers would become active. The new component 
would pass the jogs as offsets to the various axes and *memorize* the 
jogs in the order that they occurred. When the user was done clearing 
swarf or whatever, he could then push a special resume button. That 
would cause the new component to play back the jogs in reverse. The tool 
would move back to where it originated, and the program could be 
resumed. Since memory is cheap, an arbitrary path could be memorized at 
little cost. Coolant settings, etc, could also be memorized, changed, 
and restored.

I think this would be pretty simple to implement. It requires one new 
component and a bunch of HALfu.

Regards,

Ken
_
_
On 4/24/2012 6:27 PM, Michael Haberler wrote:
> Am 24.04.2012 um 21:00 schrieb andy pugh:
>
>> On 24 April 2012 18:53, Michael Haberler  wrote:
>>> I decided to ignore the conventional wisdom that it cannot be done, and 
>>> gave it a try.
>> To be fair, it was only ever described as "hard" not "impossible" and
> yes, but 'impossible' sounded infinitely better in the feature pissing 
> contest;)
>
>> I think you have made some changes to the underlying structure?
> The basic idea is to snapshot a motion queue state on 'retract', including 
> current position within a move, and switch to an alternate motion queue where 
> you can do arbitrary moves, like the retract or recovery move. On 'recover', 
> when you are where you left off, switch to the primary queue, and continue. 
> Currently task doesnt even notice that something happened, it's all just a 
> motion which tooks it tool a long time to complete. The whole thing assumes 
> coordinated mode and remains in it.
>
> I think jogging can be sled in without much damage. For the bigger picture, 
> one could take the 'keep this completely isolated within motion' or 'make 
> task aware of it' views. Not sure yet.
>
>> Is changing the tool length possible when retracted. or does that
>> invalidate the original queue?
> This would be nice but cant be exclusively solved at the motion level right 
> now; I just discussed this with Chris on linuxcnc-devel irc.
>
> The issue is that offsets are currently applied during interpreter runs in 
> the canon layer; once they reach task and motion everything's said and done 
> wrt offsets; changing it there to compensate against the earlier decision is 
> bound to be a hit-and-miss game.
>
> However we agreed this is too early, and moving offsetting to the task/motion 
> area would help. That means offsets would be applied in motion, and could be 
> changed there. Once that is done, that should be possible. I dont think it is 
> that hard, but some aspects I dont understand yet, like how rotation would 
> fit in.
>
> It also affects how tool information is used (aka 'who sees what'): the 
> interpreter starts out with some view of tool information, then proceeds; 
> then motion might change some offsets; then interpreter mght continue as it 
> was held up by queue full. It needs to be clearly thought through and spelled 
> out. This was no issue so far.
>
> - Michael
>
>
>> -- 
>> atp
>> The idea that there is no such thing as objective truth is, quite simply, 
>> wrong.
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___

Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)

[Kenneth Lerman]

On 04/22/2012 08:31 PM, Steve Blackmore wrote:
> On Sun, 22 Apr 2012 20:48:56 +0100, you wrote:
>
>> On 22 April 2012 16:07, Michael Haberler  wrote:
>>> gents, you are busily inventing path queueing mechanism number 3. The 
>>> existing ones are: CRC offset curve aka queued_canon, and NCD aka 
>>> chained_points.
>> I think CRC is "Cutter Radius Compensation" and NCD os "Naive CAM detection"?
>> I suspect that very few people know enough about how LinuxCNC works
>> now to realise that is what it being implied. However, my
>> understanding was that we were talking about ways to "fix" the
>> existing behaviour.
>>
>>> I would also think the effort is considerable, and would not necessarily 
>>> recommend grafting this onto the current code. But then it's time to start 
>>> collecting ideas for Linuxcnc3.
>> I think this is the approach to take, and it probably ought to include
>> (at the least) the changes in ja3 too.
>>
>> However, I don't think anyone has EMC3 as a trademark, we could change
>> the name back :-)
> What the f^^^ is ja3? Is it any wonder that Joe Public has such a poor
What does f^^^ mean? That's not the level of discourse we expect from 
our colleagues. I'd suggest that if you can't be civil, you should be gone.

Please.

Ken
> opinion of EMC/LinuxCNC!! - I've been here 4 years and you've yet to
> convince me it's not a closed shop speaking in a secret language.
> Sigh...
>
>
> Steve Blackmore
> --
>
> --
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)

[Kenneth Lerman]

Here is something that just popped into my head. Could we:

 1. Tag each segment with the maximum velocity at the end of the
segment. The current scheme always sets it to zero. For the first
segment, this will still be zero. For subsequent segments it will be
the maximum velocity at the beginning of the previous segment.
 2. Based on the maximum end velocity for the segment, compute the
maximum velocity at the beginning of the segment. The velocities
will be computed so as to allow for possible overshoot in the
desired position consistent with the target accuracy.
 3. Output the segment to the trajectory queue.
 4. Feed override must be limited to the smaller of the beginning and
ending velocities. (Actually, we could be smarter than that. It
could be limited to the maximum velocity that will allow
deceleration to the velocity at the end of the segment.)
 5. Queue busters start the process over again.

This algorithm:

  * Runs in constant time.
  * Is no worse than the current scheme.

It seems too simple. What am I missing?

Regards,

Ken




--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)

[Kenneth Lerman]

On 4/20/2012 4:52 AM, Erik Christiansen wrote:
> On 20.04.12 09:53, Viesturs Lācis wrote:
>> I was thinking about Kenneth's idea:
>>
>> 2012/4/19 Kenneth Lerman:
>>> Is anyone here interested in writing a filter that takes as input a
>>> tolerance (error band) and a sequence of motions (arcs and line
>>> segments) and generates a new sequence of motions that duplicates the
>>> original within the error band? It sounds like that would be one way to
>>> address the problem.
>> Is there a way to create a filter that would convert those small, tiny
>> G1s into a 3D Nurbs lines?
> ...
>
>> It does not seem to be problem finding formulas on the web to
>> calculate a coordinates of a point on a described line. But reversing
>> that seems difficult.
> Curve fitting to an arbitrary bunch of points is an approximate art,
> AIUI, with tolerance calculation at all points probably taking a bit of
> time. Admittedly, I don't know whether nurbs make that faster/slower or
> easier/harder to achieve algorithmically. But it does look "non-trivial".
>
> But isn't the LinuxCNC dictum "Must be able to come to a dead stop
> within the current line segment" unnecessary and unhelpful when
> following a piecewise linear approximation of a smooth curve? If a curve
> of ten thousand linear segments were instead one continuous nurb (or
> whatever), then LinuxCNC would not be expected to stop in a thousandth
> of an inch at any irrelevant point along the single-segment curve, IIUC.
> (That's in fact where the much-desired speed improvement would come from.)
The job of the system is to follow a path *exactly* or within specified 
limits. In the usual case, the limits are zero. That means if there are 
two non-colinear line segments, a machine with finite acceleration 
machine *must* stop at the end of the first. This causes two types of 
problems:
1 -- The system is slower than it could be
2 -- Uneven speed causes undesirable artifacts

Let's consider the alternatives:
1 -- Change the CAM system so that it generates better code. Since there 
are multiple CAM systems over which we have little control, this us not 
feasible.
2 -- Modify LinuxCNC so that it can follow a gcode path within a 
specified tolerance at a higher, more consistent rate.
3 -- Provide a filter (whether integrated with LinuxCNC or completely 
separate) that convert bad paths to good paths using a specified tolerance.

Given a standalone LinuxCNC compatible parser, I suggest that #3, would 
provide a basis for experimentation and development that could later be 
more closely integrated into Linux CNC.

Regards,

Ken
>
> If it is impossible to increase LinuxCNC's look-ahead, to allow it to
> see that it need not radically decelerate, then why not put the
> look-ahead in the gcode? Gcode allows Feedrate setting amongst the
> "axes" terms in a G1. Would it not be possible to add a Gwhiz gcode to
> turn off the stopping-within-a-segment hesitancy, and set a nice fast
> initial Feedrate along with the G1. A lower Feedrate setting would then
> be inserted prior to any sharp corner or the end of the curve.
>
> Manual insertion of Feedrate tweaks is immediately available¹. Holding
> one's breath waiting for this facility in CAM software is probably
> inadvisable. But it is not a difficult task for a gcode filter to do
> nothing but look for a G1 with a Gwhiz, then calculate the deceleration
> needed to negotiate corners or stop at the end, and bang in a Feedrate
> adjustment. (For the end, just add up micro-segment lengths until
> there's enough decelerating distance, then insert the lower feedrate.
> The gcode filter can look ahead to the end of the longest G1 list of
> points, if system RAM permits, but a few hundred segments might do.)
>
> This is engineering, and we're here to make swarf, with reasonable
> accuracy, and optimal speed. I don't think that there's any extra merit
> in a complex mathematical solution. So would something akin to the above
> let us scoot faster over irregularly curvaceous workpieces?
>
> Erik
>
> ¹ OK, inserting far enough before the corner to allow deceleration
>distance would entail totting up roughly the length of the trailing
>path segments, or allowing plenty. A gcode filter would be a boon.
>

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)

[Kenneth Lerman]

On 4/19/2012 1:53 PM, Jon Elson wrote:
> Viesturs Lācis wrote:
>> 2012/4/19 Stephen Dubovsky:
>>
>>>   Around tight curves, that requires lots of short sections w/
>>> high changes in velocity.  But you have to go slow within the limits of the
>>> machine around those anyway.
>>>
>> Just like Andy said - if there is curve in the part, then that is why
>> there are G2 and G3 commands in g-code. Period. Doing arcs with linear
>> moves is _wrong_ approach by definition.
>>
> But, LinuxCNC does not do arbitrary arcs, but only arcs in one of the three
> orthogonal planes. Also, if your arc is not a segment of a circle but
> some other
> curve, it has to be broken into multiple arcs anyway to approximate the
> desired
> curve.
>
> Jon
I think the real issue is that the CAM programs are breaking the target 
shape into a sequence of short arcs so as to stay within some error 
band. Instead, the program could break the target shape into a sequence 
of arcs with common exit and entry tangents.  The program could maintain 
the same error limits.

By doing that,  linuxcnc would never have to come to a full stop. The 
approximation as a sequence of arcs would generally (always?) have fewer 
(or the same number of) lines of gcode than the approximation as a 
sequence of line segments.

Others have stated that arcs must be in one of three orthogonal planes. 
Since linuxcnc can do helices, that isn't precisely true.

Is anyone here interested in writing a filter that takes as input a 
tolerance (error band) and a sequence of motions (arcs and line 
segments) and generates a new sequence of motions that duplicates the 
original within the error band? It sounds like that would be one way to 
address the problem.

Regards,

Ken

Ken

>
> --
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] C Compiler - MPLAB

[Kenneth Lerman]

On 4/16/2012 3:06 PM, Stephen Dubovsky wrote:
>> I don't mean to offend anybody, but AVR's are cheap and fall down easy
>> to get started with. Why bother with PIC's? The only reason I can think
>> of, is to fill time with the challenge at hand.
>>
>>
> Haha.  I think the same thing now, but my suggestion is ARM.  We've used
> PIC for over a decade at the office (+ TI dsp, + Motorola/freescale, +etc)
> and have recently gone 100% ARM.  The Cortex M4(F) is bigger, faster&
> cheaper than a TI 28xx fixed pt dsp and the Cortex M0 is faster&  cheaper
> than a tiny freescale HC08.  Whatever peripherals you need, someone prob
> makes an ARM w/ just what you want.
As far as I can tell, ARMs are in a different class. (Price, complexity, 
performance, etc.)

Ken

> --
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Has Anyone Heard From Stuart Stevenson?

[Kenneth Lerman]

Hi Stuart,

The weather reports from you neck of the woods have some of us worried.

Please let us know that all is well with you and yours.

Regards,

Ken

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] State of Wizards/Druids for simple machining.

[Kenneth Lerman]

Yup. I'm here.

It's been a while since I touched GWiz -- or EMC ^H^H^H^H LinuxCNC, for 
that matter.

I've been thinking about a slightly different model for manual (or 
perhaps I should call it interactive) machining. Imagine:
0 -- select a tool from a menu (also feed rate, etc -- or possibly material)
1 -- select a wizard -- rectangular surface, pocket, bolt hole, or whatever
2 -- follow directions (for rectangular surface):
3 -- move the tool to the upper left corner (using jog, mpg, keyboard, 
whatever).
4 -- push the select button on the screen, panel, mpg...
5,6 -- now do the same thing for the lower right corner
7 -- now select a stepover
8 -- hit go...
The machine then just does what you told it to do.

I think this would be pretty straightforward using the existing 
subroutine capabilities, mdi interface, etc.

Ken


On 3/8/2012 2:56 PM, gene heskett wrote:
> On Thursday, March 08, 2012 02:53:49 PM Frank Tkalcevic did opine:
>
>> Don't forget GWiz
>> (http://wiki.linuxcnc.org/cgi-bin/wiki.pl?GWiz_-_A_Gcode_Wizard_Framewor
>> k) - it needs a screen shot - that page doesn't sell it well.
>>
>> I've build some lathe wizards, and I've just converted my router
>> (although I usually use visual mill for cam)  It is just waiting for
>> someone to start adding mill wizards.
>>
>> If it could be enhanced to easily distribute wizards, maybe python
>> support (it only does gcode programs at the moment), and It would be
>> super cool if the linuxcnc preview could be integrated.
>>
> I followed that link on over to Kenneth L.'s page&  grabbed the latest debs
> and put then into my copy of 10.04.  Which wasn't cleanly don as linuxcnc
> was running at the time.
>
> 5 minutes later the update-manager wants to rip them out.
>
> I think I need a clue.
>
> Ken, are you "copying the mail" here?
>
> Cheers, Gene

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] linuxcnc, possibly bug, or global isn't global

[Kenneth Lerman]

Hi Gene,

Remember that a variable must be defined (assigned to) before it is 
used. In this case, before means at run time; not necessarily lexically.

I don't know if that is the problem, but it is a place to look.

Regards,

Ken

On 03/05/2012 05:46 PM, gene heskett wrote:
> On Monday, March 05, 2012 05:45:02 PM gene heskett did opine:
>
>> linuxcnc is now complaining that a named var isn't defined, after it has
>> been used quite a few times:
>>
>> gene@shop:~/linuxcnc/nc_files$ grep -n "#<_loop_rad>" taper_hub.ngc
>> 42:#<_loop_rad>  = [#<_tmp_rad>  + abs[#<_tempz>] * tan[#<_tpr_angle>]]
>> 45:o301 if [#<_loop_rad>  lt #<_start_rad>]
>> 46:(debug, o301 loop_rad=#<_loop_rad>)
>> 49:g1f#<_feedrate>  x[0. - #<_loop_rad>] y0.0
>> 51:g2f#<_feedrate>  i#<_loop_rad>  z#<_tempz>
>> 60:#<_old_rad>   = #<_loop_rad>
>> 63:#<_new_start> = [#<_loop_rad>  -0.002]
>> 93:#<_loop_rad>  = [#<_tmp_rad>  + abs[#<_tempz>] * tan[#<_tpr_angle>]]
>> 96:o501 if [#<_loop_rad>  lt #<_new_start>]
>> 99:g1f#<_feedrate>  x[0. - #<_loop_rad>] y0.0
>> 100:g2f#<_feedrate>  i#<_loop_rad>  z#<_tempz>
>>
>> It is complaining about line 60.  I have stared at this for an hour&
>> cannot see the reason.
>>
>> Code is at the usual place in the sig.
>>
>> Thanks for looking.
>>
>> Cheers, Gene
> Except my web page seems to be missing, and I've checked the router, I've
> pinged it, and restarted httpd several time without error.  Reboot is next
> I guess.
>
> Cheers, Gene

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Why APT

[Kenneth Lerman]

On 3/4/2012 6:58 PM, Jon Elson wrote:
> Kenneth Lerman wrote:
>> Answering my own question, I found the source on sourceforge.
>>
>> Now, if I had an IBM 360, with an operating system, assembler and
>> fortran compiler, I could build it.
>>
>>
> GAG!  No, you really DON'T want the 360, even by emulation.  You don't
> need a 360 to run FORTRAN, I developed a LOT of FORTRAN code
> decades ago on PDP-11 and VAX computers.  There are for-pay FORTRAN
> compilers available for Linux, I'm not sure the GNU compiler is really
> standard.  There is also f2c that converts FORTRAN source to the
> c language.
>
> What do you need the assembler for?  Is part of the package in 360
> assembly language?
I, too, wrote a lot of FORTRAN (in the 60's). CDC 3200, CDC 6400, and 
some 360.

This has lots of assembly code -- solution of polynomial equations for 
example.

Ken

>
> I worked on one project that simulated stellar astrophysics and was written
> for the VAX.  Some guys at a different university were trying to run it
> on a 370, and getting garbage.  The 360/370 series used a really awkward
> floating point scheme where the exponent could only represent the
> binary radix in 4-bit steps.  This lost enough precision that the program
> wouldn't work.  Of course, they were representing things in nuclear-sized
> units over the size of a whole star, which the VAX format with an exponent
> range of +/- 300 decimal places could handle, the 360 thought anything
> below about 10 ^ -30 was effectively zero.
>
> But, I suspect that sort of hardware detail would not come into play
> in APT360 code, so it ought to cross-compile without great attention,
> except OS-specific details like file name conventions, FORTRAN I/O
> units (file numbers) and, of course, if there is assembler code.
> Have to watch out about little/big endian issues, too.
>
> Jon
>
> --
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Why APT

[Kenneth Lerman]

On 3/4/2012 5:07 PM, Kenneth Lerman wrote:
> Does anyone (on the list) have a link to the FORTRAN 77 source for P-APT?
>
> I'd be interested in taking a look at it.
>
> Ken
Answering my own question, I found the source on sourceforge.

Now, if I had an IBM 360, with an operating system, assembler and 
fortran compiler, I could build it.

Well, here is an IBM 360.

http://en.wikipedia.org/wiki/Hercules_(emulator) 
<http://en.wikipedia.org/wiki/Hercules_%28emulator%29>

That might be a fun project.

But not for me. At least not this week.

Ken


--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Why APT

[Kenneth Lerman]

Does anyone (on the list) have a link to the FORTRAN 77 source for P-APT?

I'd be interested in taking a look at it.

Ken

On 3/4/2012 4:31 PM, Thomas Powderly wrote:
> I was sorry to learn Mr. Ross had passed on. He was looking for an
> interested CNC OEM/Mfctr to embed APT into the control when  we met.
> My employer cheaped out at that point. It was my opine that APT would
> be a great addition to the control we were using at that time. I have
> a working Apt&  post processor from his company ( dos based ) and a
> working APT-360 ( using hardy 8.04 ). The concept was: make the CNC
> simple (and therefore fast) and bundle a powerful CAM. regards, TomP
>
> --
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] CAM Post-processors: how much of the specification(s) do they span?

[Kenneth Lerman]

On 2/19/2012 5:31 PM, Kent A. Reed wrote:
> Gentle persons:
>
> Eric said of my recent bout of pneumonia, "[A]nd the antibiotics leave
> you like a wrung-out dishrag too, ISTR."
>
> Truer words were never spoken.
>
> While lazing about, I visited www.camzone.org for the first time. As I
> understand it, the site was created by and most of the blog entries are
> written by a person named Daniel who would seem to be German and living
> in Brazil (but maybe I was just too wrung out when I visited the site).
> I like the way Daniel thinks, the way he writes, and the topics he
> chooses to write about. His blog entry "Why PLM is killing the
> innovation in CAD/CAM" made me wish I'd known him while I was still
> working. The entry on Component Technology should be required background
> reading for all of us.
>
> I was induced to compose this email by his blog entry "Post-processors
> --- What you should know about them." I commend it to you.
>
> My question is, how much of the total (choose your favorite spec
> here---RS274D, RS274X, RS274/NGC, LinuxCNC) capability do these
> commercial post-processors span?
>
> A first step in answering this question would be to tabulate all the
> codes that can possibly be emitted by specific post-processors. I tried
> searching the web but couldn't find any tabulation more specific than
> http://www.enotes.com/topic/G-code which speaks of "Fanuc and similarly
> designed controls" and is pretty schematic. I looked at the websites of
> several CAM programs and see they typically claim to support a number
> CNC controller dialects in their post-processors, but that is the color
> of a different horse.
>
> And, yes, I own a copy of the Machinery's Handbook and a copy of Smid's
> CNC Programming Handbook should be in my hands soon.
>
> In my experience with neutral-format data exchange standards in the CAD
> world, the variations in the capabilities of various CAD systems led to
> standards with large scopes. Despite the resulting smorgasbord of
> capabilities, the post-processor writers tended to stick to a relatively
> small number of entities within those scopes. We achieved very good
> interoperability over a relatively limited span of the total capability
> supported by the standards.
>
> Of course, in the world of CAD, many of the data exchanges occur between
> CAD systems, so the pre- and post-processor writers face a different
> problem that in our world where we are most concerned about moving data
> between some CAM system and some CNC controller. Still, I suspect the
> CAM post-processor writers also work with a relatively small number of
> entities (e.g., G-Codes).
>
> At the outset, it seems likely that our O-codes are completely outside
> the ken of post-processor writers, but that's just one aspect.
Thank you for the pun -- although I'm not a post-processor writer.

Ken
>
> Any thoughts?
>
> Regards,
> Kent
>
>
> --
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Is there a way to get the D525MW to boot up when the AC power is applied?

[Kenneth Lerman]

I had a problem when rebooting the system that was solved by flashing to 
the newest version of the BIOS.

Ken

On 2/17/2012 10:52 PM, Don Stanley wrote:
> Hi All;
> I just assembled my new D525MW computer system.
> When I apply power to the system the D525MW powers up
> for two seconds then powers down again.
>
> One of the INTERNET stores selling that computer stated;
> they were not reliable for boot up on power up.
>
> Is anyone having this problem?
>
> It is kind of a bother to apply power to the system, then
> have to open the electronics cabinet and push that funny little button.
>
> I tried a jumper across the power switch pens on the
> computer board with the same results.
>
> The power switch seems to be a momentary contact with some
> smarts and/or an led built in?
>
> Any suggestions?
>
>  Thanks
>  Don
> --
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] New dialects [Was: Do CAM instead? ]

[Kenneth Lerman]

On 2/11/2012 11:13 PM, Erik Christiansen wrote:
> Here's Brian's post, as it came through this end of the email pipe:
>
> » » »
> Subject:  Re: New dialects [Was: Do CAM instead? ]
>
> Yes, much more readable. The downside is that you can't do a "restart at
>
>> line" without specifying which iteration of the outer loop to restart
>> from. And neither the GUIs nor the "runtime" support that.
>>
> For me, I simply go back to the oword call and  rerun the particular
> string.  I am a hobbyist so its ok for it to cut air for several passes
> until it gets back to the particular Z depth where it was stopped.
>
> Brian
> « « «
>
> All of the first three lines of text are actually a quote of Kenneth
> Lerman's prior post. So let's go with this understanding:
>
> On 11.02.12 11:57, BRIAN GLACKIN wrote:
>> Before that, Kenneth Lerman wrote:
>>> Yes, much more readable. The downside is that you can't do a "restart at
>>> line" without specifying which iteration of the outer loop to restart
>>> from. And neither the GUIs nor the "runtime" support that.
>>>
>> For me, I simply go back to the oword call and  rerun the particular
>> string.  I am a hobbyist so its ok for it to cut air for several passes
>> until it gets back to the particular Z depth where it was stopped.
> I'll drink to that, if we're only talking about a few passes over a
> short toolpath, on an amateur job.
>
> But there is a way to get the best of both worlds. A gcode filter
> program can unroll e.g. a 20-iteration loop programmed in the input
> source, so that it is passed on to LinuxCNC as 20 consecutive copies of
> the loop, with individual values inserted for each run. The iteration
> number can be added in comments, for good measure. Now we can "restart
> at line", anywhere we choose, because AXIS isn't given any loops to deal
> with.
>
> I haven't yet thought through exactly how much work it is, but unrolling
> one loop (so there's one variable to increment and substitute) isn't too
> bad, except for the trick of feeding the loop gcode back through the
> filter again. One option is to just do it in the lexer, keeping
> everything within a single process. (Fortunately, flex has a mechanism
> we could use.)
>
> It is an interesting task, and if it is of significant use, then it's
> something to add to the list of things to do.
>
> Erik
>
The right way to do it, though (IMHO), is for the system (including GUI 
and interpreter) to keep and display the call stack and history let you 
unwind at each level. Instead of looking at the linear sequence of lines 
that were executed, I should be able to look at the structure.

Just as a debugger lets me step into a subroutine or over a subroutine, 
I should be able to do this in a backwards direction from my GUI.

Ken



--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] New dialects [Was: Do CAM instead? ]

[Kenneth Lerman]

On 2/11/2012 10:51 AM, BRIAN GLACKIN wrote:
> "One question, from someone who hasn't used CAM. The CAM package would
> provide a way to specify the number of tool passes, to reach the final
> depth of a machining operation?"
>
> I recently went away from redundant gcode lines with the added tool paths
> for each z
> by passing a file with the xy cut to a subroutine that parsed through the z
> depths.  I pass to the subroutine; filename, final z, and z increment.
>
> This means I generate more files with the single toolpath, but it is
> infintely more readable to me.
>
> Brian
Yes, much more readable. The downside is that you can't do a "restart at 
line" without specifying which iteration of the outer loop to restart 
from. And neither the GUIs nor the "runtime" support that.

Ken

> --
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Workpiece is longer than the mill travel

[Kenneth Lerman]

On 2/4/2012 3:08 PM, dave wrote:
> On Sat, 4 Feb 2012 12:21:16 -0500
> Przemek Klosowski  wrote:
>
>> On Sat, Feb 4, 2012 at 12:11 PM, Erik Friesen  wrote:
>>
>>> Make two programs, with the second program zeroing on the last hole
>>> of the first.
>>   On Sat, Feb 4, 2012 at 12:16 PM I wrote
>>
>>> In any case, I would write two CNC programs, one for each half of
>>> the holes, in such a way that the home position for the second half
>>> would be the last hole of the first half.
> I end up doing this all the time since my current small mill is limited
> to 16" X travel. However I define Y with respect to the upper jaw of
> the vise so all I have to do is slide the part in x to get the dowel
> pin aligned.
I'll bet that Stuart does it all the time, too. His table is limited to 
16 feet in X travel. :-)

Ken
>
> With no vise one could always use two dowel pins as y index and then
> clamp when you get X aligned.
>
> People with machining skills come up will all sorts of ways to adapt.
> Most work. ;-)
>
> Dave
>>
>> Funny, how we've been sitting perhaps thousands of miles away and
>> simultaneously writing up the same idea.
>> --
>> Try before you buy = See our experts in action!
>> The most comprehensive online learning library for Microsoft
>> developers is just $99.99! Visual Studio, SharePoint, SQL - plus
>> HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when
>> you subscribe now! http://p.sf.net/sfu/learndevnow-dev2
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>
> --
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] parsing the current language dialect, and describing as EBNF

[Kenneth Lerman]

The use of matching labels to resolve ambiguity was just a cheap trick 
to lower the cost of implementation. There is no reason that we should 
keep the labels on control structures. We should then follow the same 
rules that C uses.

Ken

On 2/4/2012 10:25 AM, Michael Haberler wrote:
> {this is a bit of language/compiler theory, but then the thread started here; 
> sorry;)}
>
> One of ideas floating around was to to document the current language as an 
> EBNF, or an equivalent railroad diagram. An EBNF is a notation for a 
> context-free languages.
>
> That will not work, because the current LinuxCNC RS274NGC dialect cannot be 
> described by a context-free grammar in the first place, and hence not as an 
> EBNF, if one tries to include the control structures as language elements.
>
> This is different from the original language: the pre-oword syntax was 
> context-free, which is why there's a meaningful EBNF in the Tom Kramer 
> report, and working context-free parsers based on ANTLR and bison like here: 
> http://fennetic.net/irc/emc3/src/emc/interpreter/)
>
> To see why the current language is context-sensitive, consider just one 
> example:
>
> <>
> o label1 do
> ...
> o label2 while ..
> ...
> o label3 endwhile
> ...
> o label4 while ..
> <>
>
> You cannot determine by looking at a context-free grammar alone wether the 
> interpretation should be either:
>
> 1: (do ... while) (endwhile...while)  or:
> 2: (do ... (while ... endwhile) ... while)
>
> To resolve the ambiguity in scope, one needs to match the label *values*:
>
> (label1 == label4)&&  (label2 == label3) ->  interpretation 1 (in the current 
> language)
> (label1 != label2) ->  an error at 'endwhile'
>
> This also applies to if/then/elsif/else and repeat/endrepeat.
>
> So the labels constitute the context. Technically, since the labels are 
> variable keywords, this means a language with a theoretically infinite 
> alphabet.
>
> This has a couple of consequences:
>
> - writing an EBNF is only possibly on a line-by-line basis, not including the 
> control structures . But then such an EBNF will not tell you wether a given 
> program is correct wrt current scoping rules, or not, and as such fairly 
> useless.
>
> - it also means explains why my first attempt at a bison/flex parser *for the 
> current language* failed to properly recognize current control structures 
> because as it the stands the parser fails at the above ambiguities. This also 
> applies to other tools.
>
> This does not mean these tools are unusable, it just means the scanner needs 
> to tie into the parser or scope stack. It does however mean an EBNF will not 
> fully encompass all aspects of the language. This might be useful already.
>
> - Michael
>
> ps: this is a clarification of what we have, not a critique - C, and C++ have 
> similar issues and work just fine, too.
>
> psps: so much for the comment 'G-code is extremely easy to parse.' ;)
>
>
> --
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] rs274ngc bison/flex parser

[Kenneth Lerman]

On 02/01/2012 10:45 AM, Michael Haberler wrote:
>
> Am 01.02.2012 um 13:36 schrieb Erik Christiansen:
>
>> On 01.02.12 11:48, Michael Haberler wrote:
>>> Am 01.02.2012 um 09:23 schrieb Erik Christiansen:
 The grammar specifies expression and control flow constructs, but seems
 100% devoid of any explicit gcode grammar. I've scrolled up and down
 twice now, but still can't see any rapids, moves, feedrates, or
 toolchanges. Nuffin!
>>> Yes, and that is a feature.
>> At some point, LinuxCNC needs to interpret the gcode. The "parser"
>> you've put up does not do that.
>
> Probably folks use the term 'parser' to mean different things, which might be 
> part of the confusion. I use in the Dragonbook/Compilers 101 sense - a 
> program which recognizes certain syntactic constructs and nothing else.
>
> For me the term 'parser' does NOT include static semantic checks, or 
> executable semantics. The term 'interpreter' for me denotes executable 
> semantics, which is different from 'parser', which is a context-free affair 
> so to speak.
>
>> Does it have any purpose, if it does not
>> do that?
> A better definition of the language than we currently have it, executable or 
> in the manual? For instance, we dont have anything like a railroad diagram or 
> a current BNF. And it would be great to have that in particular for 
> beginners. Also an executable version at least as point of reference, and as 
> a vehicle for other software.
>
> Some examples:
>
> 1. Expression syntax
> my parser actually found an error, or rather my misunderstanding of the 
> current language, in one of the files in emc2-dev/nc_files
> see line 30 of 
> http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=nc_files/m6demo.ngc;h=85a3c0f7f031a7735e1660403f22beee90302b4e;hb=50d82f006b489a0e2795e60bd617759c902fdafd#l30
>  :
>   
> O  if [#] EQ 0
>
> now if you read http://www.linuxcnc.org/docs/devel/html/gcode/o-code.html, 
> the 'if' examples have bracketed expressions.
> So I though, gee, must be in the language.
> Well guess what, it isnt - the current interpreter (at least at that point) 
> accepts the above line just fine, and I think it skips from the closing 
> bracket to end-of-line - one would have to read the source code to determine 
> acceptable language.
>
> Incidentally the interpretation of 'if [#]' and 
> 'if [[#] EQ 0]' happen to be the same, but one 
> can do better.
Blame me. Part of my "specification" (which was never written) is that 
the interpreter executes correct programs correctly. I did not implement 
complete error detection. Oword handling is particularly nasty. A "call" 
will execute from the first matching oword sub up to and including the 
matching oword that might be a return or a endsub.
> 2. Is a (comment) whitespace?
> Whitespace is squashed, we hear. Comments are removed, so I assumed they are 
> gone at the language execution level, and are de-facto whitespace.
> Really? let's see:
>
> $ rs274 -g
> ...
> READ =>  s100m3
>17 N. SET_SPINDLE_SPEED(100.)
>18 N. START_SPINDLE_CLOCKWISE()
> READ =>  s 100 m 3
>19 N. SET_SPINDLE_SPEED(100.)
>20 N. START_SPINDLE_CLOCKWISE()
> READ =>  s 100 (on) m 3
>21 N. COMMENT("on")
>22 N. SET_SPINDLE_SPEED(100.)
>23 N. START_SPINDLE_CLOCKWISE()
> READ =>  s(hundred) m 3
> bad number format (conversion failed) parsing ''
> s(hundred) m 3
>
> That kind of 'language spec' can stand improvement.. so my parser doubles as 
> a reverse-engineering tool;)
I believe that the comment IS being ignored. The objection isn't to the 
comment; it is to the letter m.

Regards,

Ken
> 3. backplot for CAM programs
> HeeksCad sports some minimalistic understanding of the Gcode it generates, 
> for backplotting the generated tool path. Guess what it uses: a regexp-based 
> 'parser'. Sure.
>
>> A user need which has been expressed in this thread is for a documented
>> gcode grammar. We'd like to know what is legal gcode, and what is not.
>> If no grammar policing exists in the so-called parser, then either
>> almost any input is accepted, or the real parser is elsewhere.
> You'd be suprised on what incredible junk gcc accepts as 'legit grammar' once 
> you amputate the backend ;)
>
> Currently I dont see a formal way to describe the interdependencies of 
> several words on a block. You can do the optional parameter words in the 
> language but you cant recogize the conflicts and multiple uses within a block 
> that way. It would be nice to have.
>
>>> b) the language we have *is already runtime extensible* at the word level
>> According to the documentation here:
>> http://www.linuxcnc.org/docview/devel/html/remap/structure.html#_introduction_extending_the_rs274ngc_interpreter_by_remapping_codes
>>
>> you're almost wholly correct in saying:
>>
>>> and your idea kills this property by downgrading it to a compile-time 
>>> affair.
>> because having a documented grammar in the parser would only allow
>> run-time _exten

Re: [Emc-users] Passing file names into a subroutine

[Kenneth Lerman]

On 02/01/2012 10:01 AM, BRIAN GLACKIN wrote:
> Hi all.
>
> I tried to ask this question on IRC last eve and had trouble staying in
> channel.
>
> equipment - 25" X 49" X 4" gantry router  for wookwork - all cutting is 2.5D
>
> I have a subroutine o100 that at present, I pass three values too
> Value 1 is the total depth of cut
> Value 2 is the incremental depth of cut
> Value 3 is the feed rate
>
> My past practice has been to cut and paste the gcode of a part into this
> subroutine.  This has been fine for multiples of a single part.  I recently
> started calling a gcode file directly from inside the subroutine which
> worked fine.
>
> What I would like avoid constantly cutting and pasting code (or
> filenames) into my "parts program" subroutine. I thought I could send via
> the subroutine a fourth value with the file name.  The thought being that I
> can have a series of calls for different parts that I can cut out from the
> same sheet without having to mash up a massive gcode file.
>
> So I modified the O100 to add that fourth value.
>
> In the subroutine, I tried calling the file with O<#4>  call.
>
> ON loading the code into Linuxcnc, I get the error "Near Line XXX urnary
> operation expected ."  Or something to that effect.  I typed the exact
> error in IRC channel last eve if anyone saw that.
>
>
> Can I pass a filename through a subroutine call??
>
> I did try renaming the file to a numer (1.ngc)  and tried passing both
> 1 and 1.ngc.

I believe the answer is yes (I've done it in the past).

You can pass a numeric argument. Then:
O#4 call ...
Will call O100 if argument 4 is 100. When this is called, I believe the 
interpreter will look for O100 in the usual way. That includes looking 
for o100 in a file named o100.ngc (I think). I believe that the o in 
o100 must be lower case because the interpret converts everything to 
lowercase as the first step in the parsing. At any rate, the O#4 should 
be treated EXACTLY as if the code was written as O100 call if #4 has the 
value 100.

BTW: That's another place where it would be nice to have variables with 
string values.

Ken
>
> Brian
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] question on gcode parsing

[Kenneth Lerman]

On 02/01/2012 03:34 AM, Erik Christiansen wrote:
> On 31.01.12 21:45, dave wrote:
>
>> To my uncluttered mind ... read blank ...
>> is this a good way to set the state of a machine at any given line as a
>> precursor to "restart from line no"?
> IIUC¹, running an interpreter through the code from line 1 to a given
> line, with all external actions suppressed, ought to "set the state of a
> machine" for that line, if the gcode takes no input, and does no
> probing. i.e. state is dependent only on the running of the gcode.
> (But that's just theory, aka a WAG. Experts may differ.)
>
> Erik
>
> ¹ I'm not sure what part of the 129 lines quoted constitute "this". ;-)
>
Unfortunately, if you have control structures that include loops and 
subroutines, the statement "restart from line no" may have no real 
meaning for some places in the code. "Restart from the Nth execution of 
line no" might be more meaningful, although it might be difficult for 
the user to determine the appropriate value of N.

A better way to get the desired functionality might be to jog backwards 
along the previously executed path until the desired place in the code 
has been reached. The display could show the runtime subroutine stack 
and any important variables with an ability for the user to select items 
of interest. Of course, the "current" line would be highlighted.

Then the user could "say" run from the current position.

Ken

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] question on gcode parsing

[Kenneth Lerman]

On 01/31/2012 11:14 PM, Erik Christiansen wrote:
> On 30.01.12 07:54, Kenneth Lerman wrote:
>> On 01/30/2012 12:28 AM, Erik Christiansen wrote:
>>> What is being missed here is that the present parser does all that you
>>> fear above, just without the maintainability and documentation benefits
>>> conferred by a higher level implementation, using powerful tools.
>>>
>>> Erik
>>>
>> No.  I don't think so.
>>
>> The current implementation does it; not the current parser. If we go
>> back to the compilation/execution analogy, some error conditions are
>> detected at run time; not at compile time.
> There is no compile time. Both the current and future parsers are
> interpreters only, AIUI.
>
>> I don't see how the parser can require that G1 has an Fn clause
>> defined on the same or some previously executed line.
> Nor can I. It doesn't. AIUI, gcode executes with whatever value of that
> modaility is current. It does that now, and any new interpreter easily
> does the same. The grammar then _permits_ an Fn clause where we choose.
>
>> The parser knows nothing about execution order; only about lexical
>> order. Since the Fn might be hidden away in some subroutine, the parse
>> might not have seen it. I would think that knowing whether an Fn is
>> active is a difficult problem when looking from the outside, but a
>> simple problem from the inside of the run time environment. (Of
>> course, feel free to prove me wrong.)
> Any "need" to know the run-time state of a modality before run-time is
> illusory. That which needs to be known at run-time needs to be known at
> run time, not before. It is worth understanding that the run-time value
> of a modality is not part of the grammar. I'm not sure what you're
> basing these imaginary concerns on, but I can't relate them to reality,
> despite some effort  :-)

In the past you've implied this, and roughly three or four posts in the 
future, you bemoan the fact that Haberler's trial grammar "is devoid of 
any explicit gcode grammar."  My concerns were based on previous 
statements that you thought this should be done. While you could put 
some grammar rules in place, it is my contention that no matter how good 
the grammar, you will need some semantic analysis. Once we have that 
requirement, I believe that a framework that tests for appropriate 
semantics (including for example, that there MUST have been a previous 
-- in the execution sense, not the lexical sense -- Fword for G1) will 
be both necessary. If that exists, and I believe that it must, there is 
little extra benefit to having the formal grammar handle some of the cases.

In short, I'm suggesting that:
1 -- An automated lexer would be useful
2 -- An automated parser might be useful (if it can give reasonable 
error messages, etc AND be reasonably modified.) If minor changes 
require digging through shift/reduce conflicts and trying to resolve 
them, that might be reason to avoid such technology.
3 -- A semantic analyzer (whether rule based or coded) will be necessary.

Regards,

Ken
>> Don't get me wrong. I agree that we need a better definition of the
>> grammar and a more structured implementation. In general, though, I
>> prefer recursive descent parsers such as the present parser that is used
>> for each line. I consider the ability to generate excellent diagnostic
>> and error messages to be worth the effort of hand coding.
> We usually prefer what we're good at. I'm as guilty of that as the next
> bloke. The actual merits of the alternatives have been kicked about
> upthread.
>
> I wouldn't propose replacing the current parser in the forseeable
> future. Since there is interest in a more readable input syntax,
> expressed several times per year by a subset of LinuxCNC users, I have
> upthread already discussed implementing a filter which supplements the
> existing parser, but does not replace it. That way, there is scope for
> pleasing two groups.
>
>> I recognize that my control structure (o-word) implementation leaves a
>> lot to be desired -- to say the least. About its only saving grace is
>> that it enables us to do a lot of things we couldn't do before. It must
>> be redone in a way that is obviously correct and maintainable.
> As they say, "The perfect is the enemy of the good." An available
> practical implementation is superior to any imagined "perfection" which
> does not yet exist. If the limitations of the current parser have forced
> clutter upon the user, just to get the parser to work, not to improve
> readability, then no-one could do a better job with the current tools.
>
> And I sincerely wan

Re: [Emc-users] question on gcode parsing

[Kenneth Lerman]

On 01/30/2012 12:28 AM, Erik Christiansen wrote:
> On 29.01.12 23:05, Kenneth Lerman wrote:
>> Are you suggesting that a three axis machine where there is
>> no A axis should have a different grammar than a four axis machine that
>> does have an A axis.
> No, there is no such constraint in the current parser, and there is no
> reason to imagine that there might be in the new. A language like C does
> not constrain whether the user can count by twos or threes, and nor is
> there any connection between a gcode grammar and the peculiarities of a
> specific machine. One grammar handles them all. I think most users
> understand that the machine specifics are entirely dealt with by
> run-time configuration and the gcode input.
>
> It is worth understanding that the current parser _does_ have a fixed
> grammar, just like the proposed alternative. The significant difference
> is that in the current parser, it is not revealed in a concise
> human-readable form.
>
> As far as grammars go, the only structural change is transition from an
> amorphous hand-coded parser to a structured auto-generated parser, using
> a formal BNF grammar specification, instead of an undocumented one.
>
>> How would you specify that G1 can have X Y Z values in any order, but
>> only one of each? And that in some cases the X Y or Z values are
>> optional if they use the same value as a previous line?
> That is trivial, and is achieved without writing any program code to do
> it. Multiple alternatives, independent of order, and optional
> parameters, are the most basic meat of writing a BNF grammar.
>
> A prior post today shows how a BNF grammar allows alternatives, in any
> order. Here is an example of how to allow an optional parameter:
>
> tool_options:  /* Empty */
>  |  ',' spindle_directive
>
> As with the rest of the grammar, the code to implement our wishes is
> auto-generated. We just have to get the grammar right. ;-)
>
> If you read the early chapters in O'Reilly's "Lex&  Yacc" book, you'll
> see how completely straightforward these simple cases are. :-)
>
>> Remember, of course, that when we have subroutines, a previous
>> line means a previously executed line.
> An interpreter must retain the state of any modal directive. That's
> rather simple. A translator benefits from doing the same, since it can
> then generate better error messages. The grammar example posted earlier
> today includes an example of this. It's also pretty simple.
>
> What is being missed here is that the present parser does all that you
> fear above, just without the maintainability and documentation benefits
> conferred by a higher level implementation, using powerful tools.
>
> Erik
>
No.  I don't think so.

The current implementation does it; not the current parser. If we go 
back to the compilation/execution analogy, some error conditions are 
detected at run time; not at compile time. I don't see how the parser 
can require that G1 has an Fn clause defined on the same or some 
previously executed line. The parser knows nothing about execution 
order; only about lexical order. Since the Fn might be hidden away in 
some subroutine, the parse might not have seen it. I would think that 
knowing whether an Fn is active is a difficult problem when looking from 
the outside, but a simple problem from the inside of the run time 
environment. (Of course, feel free to prove me wrong.)

Don't get me wrong. I agree that we need a better definition of the 
grammar and a more structured implementation. In general, though, I 
prefer recursive descent parsers such as the present parser that is used 
for each line. I consider the ability to generate excellent diagnostic 
and error messages to be worth the effort of hand coding.

I recognize that my control structure (o-word) implementation leaves a 
lot to be desired -- to say the least. About its only saving grace is 
that it enables us to do a lot of things we couldn't do before. It must 
be redone in a way that is obviously correct and maintainable.

I haven't looked closely at modern automated tools for doing this in a 
few decades. If they let us generate effective diagnostic information in 
a straightforward way, we should be using them. On the other hand, the 
grammar should be simple enough that a hand generated recursive descent 
parser should do fine.

Regards,

Ken

Ken

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] question on gcode parsing

[Kenneth Lerman]

On 01/29/2012 10:40 PM, Erik Christiansen wrote:
> On 29.01.12 13:30, Kenneth Lerman wrote:
>> On 1/29/2012 10:55 AM, Erik Christiansen wrote:
>>> What further simplifies the task is that we can, for example, group the
>>> clauses which are common to G0, G1, etc., and give them a name. The part
>>> of the grammar tree for G1 then gets the handling of the common clauses
>>> for free, and we only need to tack on the stuff that G0 doesn't have.
>>> Not only does this reduce coding and testing effort, but it ensures
>>> consistency across commands, where it should exist. i.e. Anything which
>>> is even moderately common in gcode should be specified only once in the
>>> grammar.
>> I'd rather NOT have the details of what is mandatory and what is
>> optional for various g-codes be part of the grammar. Right now, it is
>> pretty straightforward to add a new g-code. I don't think we should
>> require modifying the grammar to be necessary to add (or change) a g-code.
> Oh Deeearr, that's a bit of a problem.
> You see, having a BNF grammar specification to eliminate any confusion
> over what is legal syntax, is a major purpose of the improvement.
> (I believe it is broadly considered a defect in the current parser.)
I would put the details of what letter codes are valid for which gcodes 
in the semantics of the implementation of the particular code (the way 
it is  now). Are you suggesting that a three axis machine where there is 
no A axis should have a different grammar than a four axis machine that 
does have an A axis.

I don't believe it would be reasonable to specify the total grammar the 
way you suggest using BNF. How would you specify that G1 can have X Y Z 
values in any order, but only one of each? And that in some cases the X 
Y or Z values are optional if they use the same value as a previous 
line? Remember, of course, that when we have subroutines, a previous 
line means a previously executed line.

Ken
> It is worth understanding that it is not possible to intelligently
> generate error messages if the grammar fails to specify "what is
> mandatory and what is optional for various g-codes". Clearly, that is
> the explicit _purpose_ of the grammar.
>
> Having that BNF grammar specification embedded in the new parser means
> that it abides by the language specification. A coder cannot diddle the
> parsing significantly in a corner of the code.
>
> Changing the BNF specification, and filling in the blanks in the leaf
> code, _is_ adding or changing the legal gcode. Nothing else needs to be
> done, other than update the documentation, since the parser is
> auto-generated from the few keystrokes we have added.
>
> The process is disciplined, highly structured, and minimises hand coding
> to the nth degree. There's not a lot of code to wade through.
> (Some people will hate it. ;-)
> ...
>
>>> The purpose of the proposed changes is expressly to eliminate such
>>> useless visual clutter. My expectation is that if we proceed to
>>> implementation, then users will choose to use one syntax or the other.
>>> The two need to be equivalent in function, but the old clutter need not
>>> adhere to the more readable alternative syntax.
>> I find it interesting that you consider removing (what you refer to as)
>> the clutter makes the code more readable. I consider having the clutter
>> more readable. Removing the clutter makes it easier to write (there are
>> fewer keystrokes).
> The "change nothing" preference is admirably handled by the existing
> parser. The alternative syntax can be expected to be alternative. ;-)
>
> My interest in this was reawakened by others expressing distaste at the
> obfuscating clutter in the current gcode syntax, yet again. When there's
> enough interest, we'll do something about it.
>
>> A typography analogy might be useful. My understanding is that fonts
>> with serifs are easier to read than san-serif fonts. I'm sure that it
>> has been suggested that serifs be removed to eliminate clutter.
> I prefer to avoid that clutter too, and don't use serif fonts.
>
> If syntax highlighting is used to impose different colours on different
> parts of some code within a line, then I have trouble reading it.
>
>> Redundundancy is sometimes useful. :-)
> Hmmm, I don't think it exists in mathematical or programming
> expressions, and I abhor it in gcode. To my mind, it only introduces
> potential conflict between the parts of the unnecessary duplication.
> However, what we have in gcode is not redundancy, but clutter lacking in
> any information content of any kind. The variable and

Re: [Emc-users] question on gcode parsing

[Kenneth Lerman]

On 1/29/2012 10:55 AM, Erik Christiansen wrote:
> On 29.01.12 14:20, andy pugh wrote:
>> On 29 January 2012 14:02, Erik Christiansen  wrote:
>>
 oo = 1
>>> OK, "O Codes". They'll all go in a declutter, replaced by their naked
>>> keywords,
>> No, that is creating a second named parameter in order to be more
>> ambiguous later:
> Yes, the variable assignment is unmistakable, but the sneaky intent
> wasn't. :-)
>
 g1fooZ100
>>> Is there an axis identifier missing here? If it's supposed to be:
>>>
>>> g1YfooZ100
>> And here is the question? What did I mean?
>>
>> I was actually meaning feed at the rate defined by the parameter oo,
>> but how is the parser to know that is what I wanted rather than there
>> being a missing S (for example) in G1 Sfoo Z100 (not a totally random
>> case, my machine has a very reluctant S key, I very often type M31000
>> in MDI)
> As it should, a parser slavishly applies its grammar to the input which
> we _do_ provide, not what we didn't. In the BNF grammar, we need to
> specify that a feedrate_clause may appear after a g1, as an alternative
> to an axis_motion. That causes the 'f' to be recognised as a keyword,
> which in turn causes "oo" to be detected as a variable name. It is
> equally straightforward to allow and optional 'S' clause to this part of
> the grammar.
>
> What further simplifies the task is that we can, for example, group the
> clauses which are common to G0, G1, etc., and give them a name. The part
> of the grammar tree for G1 then gets the handling of the common clauses
> for free, and we only need to tack on the stuff that G0 doesn't have.
> Not only does this reduce coding and testing effort, but it ensures
> consistency across commands, where it should exist. i.e. Anything which
> is even moderately common in gcode should be specified only once in the
> grammar.
I'd rather NOT have the details of what is mandatory and what is 
optional for various g-codes be part of the grammar. Right now, it is 
pretty straightforward to add a new g-code. I don't think we should 
require modifying the grammar to be necessary to add (or change) a g-code.
>
> To allow removal of the square brackets currently containing an
> axis_motion clause, we need alternative clause termination. Upthread I
> suggested ';', as is used between elements of a for loop in most
> languages. Your line then becomes:
>
> g1foo;Z100
>
> Or if we are in industry, and someone else might need to read it:
>
> g1 foo; z100   # Either G&F&Z or g&f&z is easier on humans.
>
> Now a LALR(1) parser can deal not only with that, but also with a
> variable named "foo" or "Foo", so long as we configure a stateful lexer,
> which is able to look for only a keyword immediately after the G1, and
> resume seeing a variable name after the "f" keyword is consumed.
>
>> I think we should keep the # for all variables. It is what humans
>> reading G-code expect to see.
> That is admirably achieved by changing nothing, fully maintaining
> historical authenticity. I respect such a preference.
>
> The purpose of the proposed changes is expressly to eliminate such
> useless visual clutter. My expectation is that if we proceed to
> implementation, then users will choose to use one syntax or the other.
> The two need to be equivalent in function, but the old clutter need not
> adhere to the more readable alternative syntax.

I find it interesting that you consider removing (what you refer to as) 
the clutter makes the code more readable. I consider having the clutter 
more readable. Removing the clutter makes it easier to write (there are 
fewer keystrokes).

A typography analogy might be useful. My understanding is that fonts 
with serifs are easier to read than san-serif fonts. I'm sure that it 
has been suggested that serifs be removed to eliminate clutter.

Redundundancy is sometimes useful. :-)
>
>> A linked point is that we seem to be discussing mainly human-generated
>> G-code, whereas a large proportion of G-code executed by EMC2 machines
>> is machine-generated. As well as discussing machine-parsing we also
>> might need to consider machine-generation.
> Yes, it needs to be considered, but I don't quite see an impact.
> Compatible machine-generated gcode is currently in the historical
> format, and it is adequately handled by the existing parser.
>
> The purpose of the decluttered parser is to allow human-generated gcode
> to become human readable. If, in time, some machine-generated gcode should
> transition to the more readable format, then that's OK too.
>
> One thing with a lex/bison based interpreter is that the implementation
> itself contains a BNF specification of the legal grammar. Whether input
> is legit or not is easily looked up in one place. And if error messages
> are not sufficiently explicit, then it's fairly easy to see if steps can
> easily be taken to fix it.
>
> Erik
>

Regards,

Ken

--
Try before you buy = See 

Re: [Emc-users] question on gcode parsing

[Kenneth Lerman]

On 1/29/2012 9:20 AM, andy pugh wrote:
> On 29 January 2012 14:02, Erik Christiansen  wrote:
>
>>> oo = 1
>> OK, "O Codes". They'll all go in a declutter, replaced by their naked
>> keywords,
> No, that is creating a second named parameter in order to be more
> ambiguous later:
>
>>> g1fooZ100
>> Is there an axis identifier missing here? If it's supposed to be:
>>
>> g1YfooZ100
> And here is the question? What did I mean?
>
> I was actually meaning feed at the rate defined by the parameter oo,
> but how is the parser to know that is what I wanted rather than there
> being a missing S (for example) in G1 Sfoo Z100 (not a totally random
> case, my machine has a very reluctant S key, I very often type M31000
> in MDI)
>
> I think we should keep the # for all variables. It is what humans
> reading G-code expect to see.
>
> A linked point is that we seem to be discussing mainly human-generated
> G-code, whereas a large proportion of G-code executed by EMC2 machines
> is machine-generated. As well as discussing machine-parsing we also
> might need to consider machine-generation.
>

I like the point that you bring out. Not only does this have to be 
ambiguous, it has to be robust in the case of common errors. One could 
imagine a language where every utterance was grammatically legal. That 
would mean that you could never write an illegal program.

I don't think I would like that. Redundancy in language can be very useful.

Ken


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] question on gcode parsing

[Kenneth Lerman]

On 1/29/2012 9:02 AM, Erik Christiansen wrote:
> On 29.01.12 12:59, andy pugh wrote:
>> On 29 January 2012 12:29, Erik Christiansen  wrote:
>>
>>> While that could be 'de-hashed' without an alternative numbered
>>> parameter identifier, I don't see how you'd propose to handle:
>>>
>>> #43 = foo / #44
>> I am puzzled how you would handle
>> foo = 10
> If the concern is that it could be confused with "F 10", then I'll
> cheerfully admit that "F" should be a keyword in the grammar, as it is
> to us, and so no variable may be named "F". Thus, there is no problem.
>
> If we imagine a case where disambiguation were not so simple, then a
> quick way out is manually coded lookahead. That's not needed here.
>
>> oo = 1
> OK, "O Codes". They'll all go in a declutter, replaced by their naked
> keywords, "sub", "call", "endsub", etc. Each is easily recognised by the
> lexer, and a unique token ID passed to the parser, so that it
> immediately knows which grammar subclauses apply.
>
> We won't be able to have a variable called "call", or a function called
> "endsub", but "oo" isn't a keyword, so here it's unambiguously a
> variable name, since it is preceded by neither "sub" nor "call".
>
>> g1fooZ100
> Is there an axis identifier missing here? If it's supposed to be:
>
> g1YfooZ100
>
> Then the gcode ends at the numeric - alpha transition. The grammar then
> demands some {axis_identifier,magnitude} pairs, optionally with embedded
> stuff like feedrate. Thus "Y foo" and "Z 100" are easily picked out,
> whether spaced or not. Since there is no '#' in front of "100", it is a
> literal numeric.
>
> There is no parsing complexity in any of these cases.
>
>> Is it not a significant problem that every single letter of the
>> alphabet is already a G-code command?
> No, not of itself. So long as we have an unambiguous grammar, then the
> parser has no trouble. The grammar tells the parser when a
> [xXyYZzUuVvWw] is to be interpreted as an axis ID, rather than the first
> letter of a name. To avoid the constraint that a name could not begin
> with one of those letters, I would need to employ a stateful lexer, but
> that is easy. The parser then fine tunes the lexer's eyesight, token by
> token, as it walks along a line of gcode.
>
> Incidentally, spaces in the input are usually eliminated by one line in
> the lexer. The parser never sees spaces, so that one line is all the
> space handling there is. (Well, that's how I do it, 'cos it's easier.)
>
> The parser is automatically generated from the BNF grammar and its
> embedded output actions (coded in C), so it's only necessary to write
> the lexer, the grammar, and the leaf actions. The fun begins if the
> grammar is ambiguous, resulting in conflicts. Debugging that adds to the
> entertainment value.
>
> But I haven't seen a troublesome gcode example yet. :-)
>
> Erik
>
Remember that just because a computer can understand a grammar does not 
mean that a person can. (Consider the C++ grammar.)

Also, I'd like to add a requirement to have variables with "string" 
values (together with some added functions). That's so someone could 
write code that does engraving.

Someone commented about the comment syntax -- using parens to delimit 
comments -- in a somewhat deprecating manner. I'd suggest that it is 
certainly no worse than the /* */ comments in my favorite language. I do 
find it useful to be able to embed a comment in the middle of a line; 
not just at the end.

Ken

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Servo tuning - wtf?

[Kenneth Lerman]

On 1/28/2012 5:05 PM, Jon Elson wrote:
> Viesturs Lācis wrote:
>> 2012. gada 28. janvāris 18:14 noel  rakstīja:
>>
>>> All interested in Servo Tuning.
>>>
>>> Have a look at:
>>> http://support.motioneng.com/Downloads-Notes/Tuning/default.htm
>>>
>>>
>> In the link from Noel I find that all three  (well, the last maybe not
>> that much) PID tuning methods:
>> http://support.motioneng.com/Downloads-Notes/Tuning/3_pid_tune.htm
>>
>> Suggest starting with finding correct D parameter, as opposed to
>> previously expressed opinions that P parameter is the one to start
>> with.
>>
>> Can anyone with experience in servo tuning comment on this?
>>
>>
>> Can anyone comment on this?
>>
> If your P is too high, no amount of D will stop the violent oscllation.
> If your P is too low, there will be no movement at all, and D will
> do nothing.
>
> I think you need to have P within a reasonable band for the particular
> servo drive so that movement happens when it is commanded.
>
> Note that a lot of treatises on PID tuning use an oven and a
> thermometer as the model.  This is a one-quadrant system,
> and not as relevant to a servo motion axis.
>
> Jon

Also, most of the descriptions of PID that I've seen involve what 
happens as process variables change due to outside influences (such as 
room temperature, or feedstock variations). We are concerned with the 
response to a setpoint change.

Ken

>
> --
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] question about tapered threading (etc)

[Kenneth Lerman]

On 1/24/2012 4:52 PM, John Prentice wrote:
> - Original Message -
> From: "Kent A. Reed"
>
>
>> Several items were called out recently as being show stoppers for
>> LinuxCNC. I do not aspire to learn the inner workings of LinuxCNC well
>> enough to contribute to discussion of the first item, "No jog on
>> feedhold".
>>
>> However, the second item "Taper thread pitches are measured along the
>> hypotenuse ???" is an issue I think this bear of limited brain ought to
>> be able to understand without being a LinuxCNC guru.
>>
> (a) The jog in feedhold really is a significant pain. You do need to move
> the tool away from the work when milling or turning "stringy" materials.
> Even something simple like deep-drilling with pecks can snarl up the tool
> with swarf. Of course the general solution could be very complex (e.g. if
> offsets were to be changed while feedheld) but some simple rules would cover
> a lot of cases without obvious risks to a thinking user.
Implementing this should actually be pretty easy if you implement a jog 
at the hal level. In the case of a servo machine, just add an offset to 
the target position of the PID control. Of course, you would probably 
want to have some sort of switch to enable it and cause the "normal" jog 
signals to be used here.

You would also want to save the current position so you could go back to 
where you started.  Most of this is probably doable without writing a 
line of C code. Of course, if you want to change tools and use a tool 
with different offsets, that would be a different problem.

If I were implementing this, I would probably build a new component. The 
new component would "memorize" the jogging that was done so that hitting 
a single button could reverse the motion and have to tool return to the 
original location following the same path in reverse.

I can understand that not everyone is a C programmer. Many EMC^H ^H ^H 
LinuxCNC users are integrators, though, and should be able to build 
something like this using hal.

As far as the threading is concerned, some people just seem to want to 
complain. Alternatives include:
1 -- Do a little trig and convert the numbers.
2 -- Modify the source to (use the same trig) do it the way you like. Be 
generous and add a configuration flag that lets the code do things 
either way.
3 -- Find a friend to do #2.
4 -- Hire someone to do #2. (Don't even ask -- I have two prices for my 
work on LinuxCNC, the first is free and you probably can't afford the 
second.)

Regards,

Ken

>
> (b) For most practical tapered pipe threads no one will notice the pitch
> error. On one hand I think it is unusual CNC behaviour in threading (so
> possible difficulties for CAM users without a special postprocessor). But on
> the other hand the case of the angle not being small but being 90deg does
> appear to allow cutting of scrolls - has anyone ever tried this?
>
> John Prentice
>
> .
>
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] hal taking machine down

[Kenneth Lerman]

On 1/2/2012 2:12 PM, gene heskett wrote:

>
>> Subtotal 230.25
>>
>> Shipping Cost (UPSGR)13.22
>>
>> Total$243.47
>
> Does that include the lpt breakout kit?  And is it time I bought a portable
> dvd writer that plugs into a usb port to do installs&  such with?  Will it
> boot from a usb dvd drive?
It has a db25 for the lpt on the back panel.
I bought a usb drive that I never took out of the box.
It will boot from a usb drive.
Better yet, it will boot and install over the network. I forget the 
precise trickery, but it involved copying the .iso file to my server, 
installing a tftpserver, and mounting the .iso using the loopback device.

I did need to connect a monitor and keyboard to set the appropriate boot 
order.

(Also, I had to reflash the bios. As shipped, when you told it to 
reboot, it would hang. You had to power it down and then back up again 
for it to reboot.)

I'll try to keep better notes when I do this again later in the week 
with my new hardware.

Ken

>
>> I just ordered another one of these -- although the disk price has
>> increased slightly, it is still around $250.
> Disks are hens teeth ATM, although I hear production is ramping back up
> after the tsunami now.
>
>> That will be the third such machine I have. It does have built-in video,
>> but you don't have to use it. It's a nice little package that runs
>> without a fan. Don't forget to order the power cable that is needed to
>> connect the power supply to the motherboard. (I forgot to do this on my
>> first order and got an email telling me that it was needed.)
>>
>> You DO have to assemble it yourself, but that's pretty easy.
>>
>> NOTE -- I am not running EMC on this -- But I am running my phone system
>> on one.
>>
>> Regards,
>>
>> Ken
>>
> Is anyone running emc on this?  How is the latency?
>
> Thanks Ken.
>
> Cheers, Gene

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] hal taking machine down

[Kenneth Lerman]

On 1/2/2012 1:16 PM, gene heskett wrote:


> Maybe I'll even buy a whole new box. If I could find one of those 
> compact models with a usable parport & no built in video. Is anyone 
> actually selling that intel board that has been discussed here in a 
> ready to go package? I'd drop the card for one of those in a 
> heartbeat. Cheers, Gene 

Mini-box has...



ItemQuantityDescription RateAmount  Tax Options
160GB 2.5" SATA HDD 1   160GB 2.5" SATA HDD 45.00   45.00   Yes 
MEM-SO-DDR3-2GB 1   MEM-SO-DDR3-2GB 30.00   30.00   Yes 
ENC-M350-PWR1   M350 Enclosure
WITH PICOPSU-80 and 60W ADAPTER KIT 69.00   69.00   Yes 
MBD-I-D525MWV   1   D525MWV Mini-ITX Motherboard85.00   85.00   Yes 
CAB-P4-POWER-MINI   1   4-Pin P4 Mini Power Cable   1.251.25
Yes 
Subtotal230.25  

Shipping Cost (UPSGR)   13.22   

Total   $243.47 



I just ordered another one of these -- although the disk price has 
increased slightly, it is still around $250.

That will be the third such machine I have. It does have built-in video, 
but you don't have to use it. It's a nice little package that runs 
without a fan. Don't forget to order the power cable that is needed to 
connect the power supply to the motherboard. (I forgot to do this on my 
first order and got an email telling me that it was needed.)

You DO have to assemble it yourself, but that's pretty easy.

NOTE -- I am not running EMC on this -- But I am running my phone system 
on one.

Regards,

Ken


--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] PID & BLDC

[Kenneth Lerman]

Hi Viesturs,

For a cable to be good, it is necessary that all the signals have low 
end to end resistance, but that is not sufficient.

You should also check that no two signals are shorted to each other. 
(But you probably know that.)

Regards,

Ken

On 11/27/2011 5:17 AM, Viesturs Lācis wrote:
> 2011. gada 27. Nov. 09:41 "Viesturs Lācis"
> rakstīja:
>> I will check the cabling with multimeter to see, if they are ok and
>> then proceed with any conclusions.
>>
> I checked all 25 leads in D525-to-7i43 cable, they all are good.
> The only remaining thing, where the problem can be, is the 7i43 card itself
> (or its drivers).
>
> Viesturs
> --
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Need help with servo tuning

[Kenneth Lerman]

On 10/8/2011 5:08 PM, gene heskett wrote:
<<<>>>

> Because, as the above story amply demo's, they live among us, and they 
> even breed! Cheers, Gene 

When discussing a story like this, my son once said, "Have you met the 
average person? And fifty percent of people are dumber than that."

(I then pointed out that technically speaking, fifty percent are dumber 
than the median, not the average.)

Be careful.

Ken

-- 
Kenneth Lerman
55 Main Street
Newtown, CT 06470
203-426-3769

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Chips on Flash

[Kenneth Lerman]

A first class parcel costs $1.05 plus .17 per ounce.

That's pretty cheap.

Ken

On 03/12/2011 09:53 PM, Kent A. Reed wrote:
> On 3/11/2011 11:32 AM, Kirk Wallace wrote:
>> I'm not sure how typical my situation is, but it costs me about $20 to
>> download 1GB of data, so it's not exactly cheap to download the latest
>> EMC2. I wonder if there would be a demand for EMC2 on some sort of flash
>> media? How cheap could it be?
> I didn't see anyone directly address your question, Kirk.
>
> Looking at my latest MicroCenter flyer, 2GB USB flash drives are going
> for about 5USD, retail. I couldn't find anyone advertising quantity
> discounts, but I didn't look very hard.
>
> I'm not sure about the best method for shipment, but the lowest postal
> service rate is 2.38USD for "media mail" up to 1 pound. Let's call it
> 3USD to account for packaging.
>
> Not counting the labor/time to acquire, burn, and test the flash drive,
> that's about 8USD delivered, or about 40 percent of your current cost.
> If you provided your own flash drive, the cost would fall to about
> 5-6USD (e.g., the cost of shipping the drive both ways).
>
> Burning CDs instead would result in a cost somewhere around 3-4USD,
> although more time is required to burn and test the CD.
>
> It seems to me this method is most likely to work well by pairing up
> with a buddy who has better Internet access rather than depending on the
> EMC2 developers.
>
> I'm not sure, though, what you mean by "the latest EMC2." If this means
> the latest LiveCD distribution, then the burden on the buddy is pretty
> minimal. If you mean "EMC2 as of last night" along with an fully patched
> Ubuntu, then the burden on the buddy is greater.
>
> Regards,
> Kent
>
> (willing to be a small-time buddy)
>
>
> --
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle encoder, what scale to use for rigid tapping

[Kenneth Lerman]

On 12/17/2010 09:04 AM, Igor Chudov wrote:
> Yep, I am going to shoot a video. I want to write a subroutine that accepts
> a closure and applies this closure to a rectangular grid of points.
Do you know that you can pass a subroutine number as an argument to 
another subroutine and then invoke it?

O sub

O#3 call [#1] [#2]

O end

O call [2.5] [6.3] [100]

In this example, subroutine O100 will be called with the arguments 2.5 
and 6.3

Unfortunately, you can't pass the name of a routine as an argument. :-(

Ken

> i
>
> On Fri, Dec 17, 2010 at 7:58 AM, sam sokolik  wrote:
>
>> video! :)
>>
>> sam
>>
>> On 12/17/2010 7:55 AM, Igor Chudov wrote:
>>> Thanks guys. It works great now.
>>>
>>> i
>>>
>>> On Fri, Dec 17, 2010 at 5:53 AM, John Thornton   wrote:
>>>
 There are several spindle examples in the Integrators manual.

 John

 Igor Chudov wrote:
> I am realizing that I am not sure what scale should I use for rigid
 tapping.
> Should I configure EMC2 so that a single revolution of the spindle
 results
> in the spindle position of 1.0?
>
> Also, another question. Does anyone who has rigid tapping, have a .ini
 file
> that they can share?
>
> I am specifically not sure how to tie my input to spindle speed. When I
 try
> G33.1, EMC2 errors out and says "spindle is not in motion". I believe
 that I
> need to tie my input somehow to spindle speed that EMC2 knows how to
 read,
> but I am not sure what variable to use.
>
> Thanks
>
> i
>
>> --
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

>> --
 Lotusphere 2011
 Register now for Lotusphere 2011 and learn how
 to connect the dots, take your collaborative environment
 to the next level, and enter the era of Social Business.
 http://p.sf.net/sfu/lotusphere-d2d
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users

>> --
>>> Lotusphere 2011
>>> Register now for Lotusphere 2011 and learn how
>>> to connect the dots, take your collaborative environment
>>> to the next level, and enter the era of Social Business.
>>> http://p.sf.net/sfu/lotusphere-d2d
>>> ___
>>> Emc-users mailing list
>>> Emc-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>
>>>
>>
>> --
>> Lotusphere 2011
>> Register now for Lotusphere 2011 and learn how
>> to connect the dots, take your collaborative environment
>> to the next level, and enter the era of Social Business.
>> http://p.sf.net/sfu/lotusphere-d2d
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
> --
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Watchdog Sizing

[Kenneth Lerman]

I would use a single pin for communication to the host with some variant 
of the one-wire protocol used by iButtons.

It is simple, elegant, and relatively insensitive to timing.

Ken

On 12/04/2010 04:30 AM, Erik Christiansen wrote:
> On Fri, Dec 03, 2010 at 07:54:57PM -0800, Kirk Wallace wrote:
>
>> I really had no idea if the memory would be enough. I would have worked
>> on it until I went blind in one eye.
>>  
> Oh, it's enough for what you want to do now. But ISTR a home switch +
> index filter, on the other thread. It can do that too, if pins can be
> found. But then there's the extra functionality we just have to have,
> when we're nearly finished. ;-)
>
>
>> In looking for something else (small h-bridge) I found this (and
>> ordered):
>> http://www.sparkfun.com/products/9147
>>
>> There is even some code to use as a reference:
>> http://www.sparkfun.com/Code/AVR-Stick_v12.zip
>>  
> Ah, they use the USB frame timing to calibrate the on-board RC
> oscillator.
>
> I saw USB transmit code, but nothing for receive (i.e. for setting
> watchdog timing.) Ah, your last site has projects involving USB output.
>
>
>> http://www.obdev.at/products/vusb/projects.html
>>  
> The "small H-bridge" design I spotted there is another very low power
> example, using the L293D. I'd at the very least put some DPAK FETs on a
> PCB, instead. I'm not sure I'd trust the shoot-through provisions of one
> of those amateur designs. If not using half-bridge drivers with
> dead-time, the ATtiny26's timer1 has complementary outputs with
> dead-time fixed at one prescaler clock interval.
>
> However, if you want to do motor PID, then a reasonable swag of the 1k
> instruction space is eaten. Incidentally, the ATmega8 (used the same
> design) is old. The ATmega48 is a scalable replacement.
>
>
>> I feel a project cascade coming on.
>>  
> The trouble escalates when you succumb do doing "just one more design,
> with just one more layout" to economise on the shipping from the cheap
> PCB places in Asia. :-)
>
> Erik
>
> --
> What happens now with your Lotus Notes apps - do you make another costly
> upgrade, or settle for being marooned without product support? Time to move
> off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
> use, and manage than apps on traditional platforms. Sign up for the Lotus
> Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

--
What happens now with your Lotus Notes apps - do you make another costly 
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus 
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users