Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

I agree there are all sorts of ways of doing this.  Only Peter at MESA or 
perhaps Jon could explain what they do but I don't know if it's proprietary to 
their hardware.

LinuxCNC knows the accel rate of the motors.  Take for example the Parallel 
port version.
setp stepgen.0.position-scale [AXIS_0]SCALE
setp stepgen.0.steplen 1
setp stepgen.0.stepspace 0
setp stepgen.0.dirhold 45000
setp stepgen.0.dirsetup 45000
setp stepgen.0.maxaccel [AXIS_0]STEPGEN_MAXACCEL

There's an assumption that regardless of the type of motor that the motor can 
keep up with this.  If not then in the case of a stepper motor it will lock up 
and make noise.  In that open loop mode something will eventually crash.

For a DC Servo it the acceleration is higher than what he motor can do 
eventually the number of steps in won't match the encoder and when the overrun 
threshold is reached the motor will fault and halt the system if it's wired 
that way.

The hal file values determine the step rate for a given inches per second or mm 
per second as determined by the G-code F parameter.  Simple trig determines 
what the X and Y values will be to follow the hypotenuse of the target speed.  
A bit more math will determine how far both X and Y move while accelerating and 
decelerating to create the move along their hypotenuse.   

Remember the point is to move the correct distance, and, maintain as best as 
possible the target speed.   That's using a method called exact stop.  The 
assumption is that each move is an independent move with a start and end 
position.   But when you do that the milling cutter slows down and stops 
changing the SFM and chip load.  Then it has to accelerate up to speed again in 
the new direction for the next move.  Very jerky if you are milling an arc.

An alternative method is constant velocity.  Now at each corner the XY motion 
is adjusted so the change in direction is a curve that maintains the X and Y 
motion such that the combined velocity remains as close as possible to the 
original F Parameter.  This doesn't result in square corners but then a mill 
cutter isn't square so it's not such a big deal.  And the XY axis never really 
stop so the machine shakes less.

So now you have a clear set of way points for each change in velocity within 
the distance parameter.  Next if your maximum step rate is 25kHz that's a step 
every 40 uS.  If the step length is 5 uS you need to assert the step, wait 5 uS 
and then remove it.  If the direction changes there are extra time delays 
involved: dirsetup; dirhold. And the system values BASE_PERIOD and SERVO_PERIOD 
drive how often the code deals with these step length and dir numbers.

How does that translate to hardware.  Well if there's a step every 40uS (25kHz) 
then you can have an 16 bit unsigned integer array that is 25k  words long.  
And the array words are an image of the Parallel Port step and direction bits.  
10 of those bits represents 5 axis.  All the stepper engine has to do now is 
once every 40 uSec read a word out of the array and write it to a port.  Then 
increment a pointer wrapping around.

In reality this would be a structure with more information like start of accel, 
move, end of accel, for each axis, but for now just think of it as a simple 
array.  For an RTOS based machine a task would be set to wake in 5 uSec (Step 
length) and its sole purpose would be to clear the step bits in that image and 
write that out.   Or grab a timer value, add the step length and then wait for 
the timer to roll past that time and clear the step pins.

Now you've created a step pulse.  It's a dumb engine.  It has no clue what it's 
doing.  The trajectory planner filled in this array of step/dir information.   
If you are dealing with intelligent drives they are then told to do sequences 
of moves based on perhaps acceleration/velocity/distance.  The whole point is 
the acceleration is known.  The velocity is known.  The distance is known.  The 
rest is simple linear algebra to create a series of velocity with acceleration 
commands that keep the XY moving along the target trajectory

Change to a 5 or 6 axis robot arm and all that changes is the size of the array 
use for the linear algebra geometric calculations for position in space and how 
to get there.

I don’t know what LinuxCNC does since I've not looked at the code.  But one 
second is a really long.  If you can guarantee that the update interval is 40 
milliseconds you only need 1000 possible steps stored and/or calculated for a 
40 kHz step rate.   Less if you are sending out way points with desired 
accel/velocity/distance to each motor. 

The LinuxCNC trajectory planner is already stable and working.  And not really 
hard real time as long as you can fill a ping pong buffer within every 40 
milliseconds or so.  Or however big it is.An Ethernet TCP/IP packet is 1550 
bytes IIRC.  So along with motion overhead parameters one packet every 40 
milliseconds is loafing for a 100MBPS Ethernet.  

If 

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Saturday 25 January 2020 00:56:18 Chris Albertson wrote:

> On Fri, Jan 24, 2020 at 8:29 PM Alan Condit  
wrote:
> > Chris,
> >
> > If I send 1 steps to a smart X-axis controller, how does it stay
> > in sync with a smart
> > y-axis controller without someone controlling the synchronization
> > between the two?
>
> As said, "steps" are the wrong thing to send.   What they do is send
> time, tagged points.  Each point has a time tag on it.It is not
> hard to synchronize clocks at the microsecond level.
>
> What they send is a list of target points.Assuming the machine
> works in (x, y, z) space each point, you have "time", (x, y, z) and
> (x', y', z') and (x'', y'', z'').   A machine might have more or fewer
> axis with different names, but same idea.   Each controller can
> handle up to some maximum number of axis and it wold not be until you
> are over that limit that you'd have to split things.  Doing six axis
> on one controller is reasonable.
>
> The controller tries its best to hit the target points.  It can happen
> that a target is impossible.  Also, some of ths data can be omitted. 
> Doing so wuld free the controller to do what it "wants".  I think you
> always want x,y,z but could maybe omit the prime (velocity) or double
> prime (acceleration)  This kind of path planning is what LinuxCNC
> already does, but today it is reasonable to push this down into a $5
> chip.
>
> LinuxCNC is originally written used the exact oposite aproach and move
> all the "smarts" upstream into a PC.
>
> The non-real-time part has to read the g-code or the conversational
> interface or the hand pendant or video data and convert to a stream of
> target points.
>
> That said, "steps" could work if each one had a time tag.  But that
> pushes the planning upstream and I think the better plan is to move as
> much "smarts" as possible as close to the physical motor as possible. 
>  So let the motor driver figure out what rate to drive each otor so
> the targets are reached.
>
> Alan

I like this idea. But the com path must be two way so the planner can 
know if that target was reached for each time point, and must know also 
each axis;s limits for accel and top speed so the it can issue 
attainable targets. But wait, isn't that what lcnc is doing now?

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 


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

Re: [Emc-users] Real-time OS for machine controllers

[Chris Albertson]

On Fri, Jan 24, 2020 at 8:29 PM Alan Condit  wrote:

> Chris,
>
> If I send 1 steps to a smart X-axis controller, how does it stay in
> sync with a smart
> y-axis controller without someone controlling the synchronization between
> the two?
>

As said, "steps" are the wrong thing to send.   What they do is send time,
tagged points.  Each point has a time tag on it.It is not hard to
synchronize clocks at the microsecond level.

What they send is a list of target points.Assuming the machine works in
(x, y, z) space each point, you have "time", (x, y, z) and (x', y', z') and
(x'', y'', z'').   A machine might have more or fewer axis with different
names, but same idea.   Each controller can handle up to some maximum
number of axis and it wold not be until you are over that limit that you'd
have to split things.  Doing six axis on one controller is reasonable.

The controller tries its best to hit the target points.  It can happen that
a target is impossible.  Also, some of ths data can be omitted.  Doing so
wuld free the controller to do what it "wants".  I think you always want
x,y,z but could maybe omit the prime (velocity) or double prime
(acceleration)  This kind of path planning is what LinuxCNC already does,
but today it is reasonable to push this down into a $5 chip.

LinuxCNC is originally written used the exact oposite aproach and move all
the "smarts" upstream into a PC.

The non-real-time part has to read the g-code or the conversational
interface or the hand pendant or video data and convert to a stream of
target points.

That said, "steps" could work if each one had a time tag.  But that pushes
the planning upstream and I think the better plan is to move as much
"smarts" as possible as close to the physical motor as possible.   So let
the motor driver figure out what rate to drive each otor so the targets are
reached.



Alan
>
> > From: Chris Albertson 
> > Subject: Re: [Emc-users] Real-time OS for machine controllers
> > Date: January 24, 2020 at 9:48:27 AM PST
> > To: "Enhanced Machine Controller (EMC)"  >
> >
> >
> > If you can tolerate latency, then your "hub" does not need what we call
> > "hard" real-time capability.  It only needs to keep up with the average
> > workload, averaged over whatever latency you can tolerate.  Video
> streaming
> > works this way.They can't reliably send video and the 60 Hz frame
> rate
> > so they buffer a few seconds of video on your phone and the real-time
> > viewer lives on the phone  not the server.
> >
> > g-code could be the same way.   The penalty is that when you press the
> "go"
> > button the milling machine would take a few seconds the start working
> while
> > the data buffers into the low-level motor controllers. Today a
> > step/direction controller has no memory so it must be fed steps in real
> > time.  But if it has a 10,000 step memory you could just transfer blocks
> > ever half second and the controller would work down the queue."Steps"
> > are the wrong kind of data for this but "states" are what is used.
> >
> > You are correct in that some real-time ability is needed at every level.
> > But we could design things so the requirements are VEY loose at the
> highest
> > level for 0.5-second latencies being acceptable.   One you need only
> that,
> > then even an iPhone is a good enough platform.
> >
> > On Thu, Jan 23, 2020 at 11:32 AM Peter C. Wallace 
> wrote:
> >
> >> On Thu, 23 Jan 2020, Chris Albertson wrote:
> >>
> >>> Date: Thu, 23 Jan 2020 10:17:44 -0800
> >>> From: Chris Albertson 
> >>> Reply-To: "Enhanced Machine Controller (EMC)"
> >>>
> >>> To: "Enhanced Machine Controller (EMC)" <
> emc-users@lists.sourceforge.net
> >>>
> >>> Subject: Re: [Emc-users] Real-time OS for machine controllers
> >>>
> >>> The trouble with the Mesa FPGA design is that it depends on a computer
> >> with
> >>> good real-time performance.   It can generate steps but I don't thing
> you
> >>> can run a position or velocity PID control loop on the FPGA.
> >>
> >> LinuxCNCs design paradigm requires realtime, this is a design decision
> >> that is
> >> supported by our Hostmot2 real time firmware. We have other firmware
> that
> >> implements motion in the FPGA but this is not suited to LinuxCNCs model.
> >>
> >>
> >> You might argue that its an old fashioned model but many high
> performance
> >> CNC
> >> systems and Robotics controllers use LinuxCNCs model of a capable real
> >> time host
> >> (real OS with file I/O loadable modules, unlimited memory, massive
> >> floating
> >> point performance etc etc) Some of these use Linux and others use real
> >> time
> >> windows varients often with Ethercat Peripherals. This makes for a
> >> powerful
> >> extensible realtime toolkit (like LinuxCNCs HAL) and complex realtime
> >> responsive coordinated motion. Basically for this type of system you
> still
> >> need a very capable real time controller hub even if the motor
> controllers
> >> implement torque, velocity, or position 

Re: [Emc-users] Real-time OS for machine controllers

[R C]

That makes perfect sense   if never anything goes wrong


what if one motor stalls, what if one signal needs to be re-transmitted?

If neither of that is corrected...  one axis is off "time shifted" 
relative to the other.


For precision sake, you would need feedback from one axis to the other.


On 1/24/20 10:14 PM, Erik Christiansen wrote:

On 24.01.20 20:27, Alan Condit wrote:

Chris,

If I send 1 steps to a smart X-axis controller, how does it stay in sync 
with a smart
y-axis controller without someone controlling the synchronization between the 
two?

One way could be for the host to pulse the x and y step pins in
synchronism at a suitable multiple of the steps needed for the longer
run. If we need a slope of 0.167, then tell one smart controller
to divide by 1, the other by 6.

Even pi can be approximated to 1 part in ten million by 355/113, so a
bit of smarts in the host could keep the axis controllers simple yet
flexible, I figure.

Motion commands could be sent on RS485 serial, before the primary step
sequence begins.

Erik
(Who hasn't read the whole thread, unfortunately. There's a 1 foot
diameter branch down in the front garden, and it needs to go before its
ute-load of eucalyptus leaves dries to a pyromaniac's dream.)


___
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] Real-time OS for machine controllers

[Erik Christiansen]

On 24.01.20 20:27, Alan Condit wrote:
> Chris,
> 
> If I send 1 steps to a smart X-axis controller, how does it stay in sync 
> with a smart
> y-axis controller without someone controlling the synchronization between the 
> two?

One way could be for the host to pulse the x and y step pins in
synchronism at a suitable multiple of the steps needed for the longer
run. If we need a slope of 0.167, then tell one smart controller
to divide by 1, the other by 6.

Even pi can be approximated to 1 part in ten million by 355/113, so a
bit of smarts in the host could keep the axis controllers simple yet
flexible, I figure.

Motion commands could be sent on RS485 serial, before the primary step
sequence begins.

Erik
(Who hasn't read the whole thread, unfortunately. There's a 1 foot
diameter branch down in the front garden, and it needs to go before its
ute-load of eucalyptus leaves dries to a pyromaniac's dream.)


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

Re: [Emc-users] Real-time OS for machine controllers

[R C]

exactly


That is what is called inter process communication  (IPC)  in the 
computing world.  There are all kinds of systems to deal with that in 
large scale supercompters.   individual compute nodes have a means to 
communicate with other compute nodes


In this case it would mean,   "hey axis Y I am axis X and and I am at 
this position blabla,  what position are you at?"   That is not science 
fiction, it


has been around for a long while and exists and works very well.


Ron



On 1/24/20 9:27 PM, Alan Condit wrote:

Chris,

If I send 1 steps to a smart X-axis controller, how does it stay in sync 
with a smart
y-axis controller without someone controlling the synchronization between the 
two?

Alan


From: Chris Albertson 
Subject: Re: [Emc-users] Real-time OS for machine controllers
Date: January 24, 2020 at 9:48:27 AM PST
To: "Enhanced Machine Controller (EMC)" 


If you can tolerate latency, then your "hub" does not need what we call
"hard" real-time capability.  It only needs to keep up with the average
workload, averaged over whatever latency you can tolerate.  Video streaming
works this way.They can't reliably send video and the 60 Hz frame rate
so they buffer a few seconds of video on your phone and the real-time
viewer lives on the phone  not the server.

g-code could be the same way.   The penalty is that when you press the "go"
button the milling machine would take a few seconds the start working while
the data buffers into the low-level motor controllers. Today a
step/direction controller has no memory so it must be fed steps in real
time.  But if it has a 10,000 step memory you could just transfer blocks
ever half second and the controller would work down the queue."Steps"
are the wrong kind of data for this but "states" are what is used.

You are correct in that some real-time ability is needed at every level.
But we could design things so the requirements are VEY loose at the highest
level for 0.5-second latencies being acceptable.   One you need only that,
then even an iPhone is a good enough platform.

On Thu, Jan 23, 2020 at 11:32 AM Peter C. Wallace  wrote:


On Thu, 23 Jan 2020, Chris Albertson wrote:


Date: Thu, 23 Jan 2020 10:17:44 -0800
From: Chris Albertson 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
with

good real-time performance.   It can generate steps but I don't thing you
can run a position or velocity PID control loop on the FPGA.

LinuxCNCs design paradigm requires realtime, this is a design decision
that is
supported by our Hostmot2 real time firmware. We have other firmware that
implements motion in the FPGA but this is not suited to LinuxCNCs model.


You might argue that its an old fashioned model but many high performance
CNC
systems and Robotics controllers use LinuxCNCs model of a capable real
time host
(real OS with file I/O loadable modules, unlimited memory, massive
floating
point performance etc etc) Some of these use Linux and others use real
time
windows varients often with Ethercat Peripherals. This makes for a
powerful
extensible realtime toolkit (like LinuxCNCs HAL) and complex realtime
responsive coordinated motion. Basically for this type of system you still
need a very capable real time controller hub even if the motor controllers
implement torque, velocity, or position loops


Peter Wallace
Mesa Electronics



___
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

Re: [Emc-users] Real-time OS for machine controllers

[Alan Condit]

Chris,

If I send 1 steps to a smart X-axis controller, how does it stay in sync 
with a smart
y-axis controller without someone controlling the synchronization between the 
two?

Alan

> From: Chris Albertson 
> Subject: Re: [Emc-users] Real-time OS for machine controllers
> Date: January 24, 2020 at 9:48:27 AM PST
> To: "Enhanced Machine Controller (EMC)" 
> 
> 
> If you can tolerate latency, then your "hub" does not need what we call
> "hard" real-time capability.  It only needs to keep up with the average
> workload, averaged over whatever latency you can tolerate.  Video streaming
> works this way.They can't reliably send video and the 60 Hz frame rate
> so they buffer a few seconds of video on your phone and the real-time
> viewer lives on the phone  not the server.
> 
> g-code could be the same way.   The penalty is that when you press the "go"
> button the milling machine would take a few seconds the start working while
> the data buffers into the low-level motor controllers. Today a
> step/direction controller has no memory so it must be fed steps in real
> time.  But if it has a 10,000 step memory you could just transfer blocks
> ever half second and the controller would work down the queue."Steps"
> are the wrong kind of data for this but "states" are what is used.
> 
> You are correct in that some real-time ability is needed at every level.
> But we could design things so the requirements are VEY loose at the highest
> level for 0.5-second latencies being acceptable.   One you need only that,
> then even an iPhone is a good enough platform.
> 
> On Thu, Jan 23, 2020 at 11:32 AM Peter C. Wallace  wrote:
> 
>> On Thu, 23 Jan 2020, Chris Albertson wrote:
>> 
>>> Date: Thu, 23 Jan 2020 10:17:44 -0800
>>> From: Chris Albertson 
>>> Reply-To: "Enhanced Machine Controller (EMC)"
>>>
>>> To: "Enhanced Machine Controller (EMC)" >> 
>>> Subject: Re: [Emc-users] Real-time OS for machine controllers
>>> 
>>> The trouble with the Mesa FPGA design is that it depends on a computer
>> with
>>> good real-time performance.   It can generate steps but I don't thing you
>>> can run a position or velocity PID control loop on the FPGA.
>> 
>> LinuxCNCs design paradigm requires realtime, this is a design decision
>> that is
>> supported by our Hostmot2 real time firmware. We have other firmware that
>> implements motion in the FPGA but this is not suited to LinuxCNCs model.
>> 
>> 
>> You might argue that its an old fashioned model but many high performance
>> CNC
>> systems and Robotics controllers use LinuxCNCs model of a capable real
>> time host
>> (real OS with file I/O loadable modules, unlimited memory, massive
>> floating
>> point performance etc etc) Some of these use Linux and others use real
>> time
>> windows varients often with Ethercat Peripherals. This makes for a
>> powerful
>> extensible realtime toolkit (like LinuxCNCs HAL) and complex realtime
>> responsive coordinated motion. Basically for this type of system you still
>> need a very capable real time controller hub even if the motor controllers
>> implement torque, velocity, or position loops
>> 
>> 
>> Peter Wallace
>> Mesa Electronics
>> 
>> 
>> 
>> ___
>> 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

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

> -Original Message-
> > Where the beagle falls down on the Linux side of things, say compared to a
> Pi or a PC, is the video processing just isn't as good.  And it shows even 
> when
> just running normal Linux compared to normal Linux on a Pi.
> Well, I DO see a bit of sluggishness compared to a fast
> Intel CPU with graphics card, but it is
> completely tolerable, to me.  And, LinuxCNC has been run on
> a Pi, but that port is apparently not
> ready for prime time, yet.
> > Where my LinuxCNC box falls apart is with the parallel port for stepping
> with very high latency issues and that one time warning when LinuxCNC
> starts up that I've basically got my motion parameters set too high for the
> system.
> There are desktop PCs that have horrible real time
> performance, for a variety of reasons, and some that have
> amazingly good RT latency.  I make a line of 3 different
> motion controllers that use the parallel port as a
> communications
> path to an FPGA.  On a variety of CPUs, the entire servo
> thread cycle takes from 100 - 200 us to service up to 4 axes,
> so a 1 KHz servo thread is totally reliable.  With these
> units, there is NO base thread, essentially the base thread is
> moved out to the hardware.  These devices support
> step/direction systems, and PWM and analog servo systems.
> I've been making these since 2002.
> >Might well be video drivers.
> There are clearly video drivers combined with certain video
> chips/cards that totally trash the realtime performance.
> Partly, that is do to trying to do software-generated
> stepping on a multi-purpose CPU.  That's why I just don't
> recommend doing that.
> 
> Jon

Hi Jon,
But that's my point.  If I go through 4 different PCs from different sources 
and each has latency issues at some point I'm going to say the heck with direct 
control and let's use an Ethernet driven device.  At this point the step 
generation and closed loop has moved out of the PC hasn't it?

And  BTW, these PCs are 1.8GHz and 2.4GHz.  Given we were doing EMACs back in 
the 90's with 33MHz PCs (maybe with Fedora?  Don't remember) a fact of almost 
100 times faster strikes me that these real time ports of Linux onto PCs isn't 
what it's cracked up to be.   Otherwise the suggestion that it must be the 
other hardware seems iffy.  And if the hardware cannot be controlled to that 
extent because the drivers etc. are in the way then the solution is as the 
subject line suggests, a separate open source hardware/software platform 
running an RTOS that creates deterministic outputs.But that would also make 
products like yours dated and that's not my intention.

I'd certainly be up for having someone modify my HAL and INI files so that I 
can do the 50kHz step rates out the parallel port.  After all WIN-XP and MACH3 
can do it.But like I said, I have trouble understanding how a 2.4Ghz 
machine can't do what was done with smaller micros running much slower.

John Dammeyer



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

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

Hi Ron,
I was contemplating your reply and this whole RTOS for Machine Control while I 
was assembling this small module.
http://www.autoartisans.com/mill/PWMSpindle-1.jpg
It's a carrier and I/O interface for a PWM to 10V board from China.  It also 
translates that same PWM signal as step/dir into RS422 to drive the 1.8kW 
Bergerda AC Servo I purchased to turn my spindle from 0 to 3000 RPM.

The reason for this is to be able to still swap back and forth between MACH3 
and LinuxCNC using the parallel port for I/O.  Part of my research into all 
this.  The Windows Parallel Port interface (or Smooth Stepper) and MACH3 with a 
simple check box can make the STEP pin a PWM pin for spindle speed.   The HAL 
file also lets me do that with the parallel port although I've not tried the 
STEP option on that pin yet.

The MESA 7i92H cannot do this.  It can be programmed with a different FPGA file 
to have a STEP Generator on that pin instead of the PWM but it requires 
reprogramming the 7i92H and of course a restart of LinuxCNC.  Not as easy as a 
checkbox. 

Anyway, while I was assembling this board, the expression "If all you have is a 
hammer, everything looks like a nail" popped into my head.   I'm sure there are 
tens of thousands of mills out there that are manual with no power feed.  
Others with a single or dual power feed.   Then there's DRO's/

An article I read today in the #288 Model Engineer's Workshop magazine 
discussed adding a spindle RPM readout and another on switching the DRO head 
between a mill and a lathe. 

The very first thing I did with my mill 13 years ago was add a Shumatech DRO 
kit and some inexpensive scales.  I've never looked back.  Nor looked at the 
hand wheel scales.A few years later I added a stepper motor to the knee to 
give it power feed.  I used a surplus ELS I had lying around to move it up and 
down.  And since it was calibrated to the knee I could set zero and even move 
to predefined positions.  All still manually though.  Plus the mill had a power 
feed on the X axis.

I've seen other articles on adding power feed to mills using anything from 
electric drills to quite sophisticated operations.  Those mill owners aren't 
running LinuxCNC or MACH.  So if all you have is LinuxCNC the idea that there 
might be other types of fasteners and not just nails can appear to dominate 
one's thinking without even realizing it.

Now that I'm adding CNC to the mill I've noticed something about the way I work 
on it and at times I miss that 'manual' operation.  After all with a DRO 
cutting a bolt circle is a no brainer.  But cutting an arc without a rotary 
table (my previous approach) is virtually impossible.  So I'm wondering if 
maybe we are all overthinking this.

A standalone box that drives 3 to 5 axis, detects/controls spindle RPM and 
other I/O like a power draw bar, even tool changer carousel.  Buttons like the 
one on the Axis screen or the MACH flyout tab that let you step/jog increments 
and an MPG input for that sort of interface.  Like the AXIS and MACH screens,  
a DRO showing positions so we need at least 4 lines and 20 characters or maybe 
a midsize LCD display.  Perhaps touch screen and like the DRO the ability to do 
a predefined series of assists like hole circles perhaps even arcs.

At this point about the only thing missing is G-Code interpretation.  Or am I 
missing something?  

So this box, has one or two DB-25 output connectors that match a PC along with 
a couple of RS232/RS485 ports.Connected to that is the standard, custom for 
the machine, BoB drive hardware.  On the other end of the box an Ethernet port 
for connection to something...  And perhaps a USB port for installing updated 
firmware.  What you now have is a standalone DRO c/w power feed on all axis 
that is up and running within a second of power being applied with time 
sensitive stuff running under RTOS control.  

I believe that this is the concept that was initially introduced with this 
subject line.  And the PC, if even connected and powered up services as the 
visual user interface with graphical display of tool path etc.  Not only that, 
remove this box and connect the DB-25 cables to the back of a PC or MESA 7i92H 
and you have that PC based CNC system without the hardware by just selecting a 
different HAL INI file set.

So why have the box at all if you're prepared to also power up a PC that runs 
LinuxCNC?  One might ask the question the other way.  Why aren't all the manual 
mills in the world running LinuxCNC with a PC and monitor on a stand right by 
the mill?  Maybe because some one-of  tasks are just easier with a manual mill 
and many mills in the world are used for one-of tasks.  So perhaps a box with 
an RTOS and limited automation fills a void.

Just throwing ideas up in the air.
John Dammeyer




> -Original Message-
> From: R C [mailto:cjv...@gmail.com]
> Sent: January-24-20 12:55 PM
> To: linuxcnc-users-list
> Subject: Re: [Emc-users] Real-time OS for machine 

[Emc-users] Multiple LinuxCNC instances and a shared HAL

[bari]

Looks like the machinekit folks did some work on this.

https://groups.google.com/forum/#!topic/machinekit/8LHvtyol2PQ

Haltalk stuff using Zero-MQ messaging. 

It was specifically written to enable connecting various HAL "islands"
which may or may not have a shared memory space.  The messaging protocol
is transport agnostic, so you can setup HAL nodes that communicate via
shared memory, Ethernet, serial, or whatever.

The existing haltalk may not do everything you want, but it's probably
the best place to start:

https://machinekoder.com/machinetalk-explained-part-4-hal-remote/


An example of what I might want to do is control two pick and place
gantry robots that share the same gantry. They can't occupy the same
space at the same time (well not without some fancy physics yet to be
invented) but they pass parts to each other and from place to place
synchronized to conveyors that bring material in and unload processed
parts. This is getting more into process control or SCADA.


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

Re: [Emc-users] Question regarding power requirements for 7i76 Spindle+ and Spindle-

[Gene Heskett]

On Friday 24 January 2020 16:00:06 Brent Loschen wrote:

> I currently power a 7i76 from the 5i25/cable, and am wondering if it's
> OK to power the Spindle + and - (TB4 pins 1 and 3) using that 5v
> source, or if it requires a separate 5v supply?  If current draw from
> the cable is no problem, are there any other drawbacks to using that
> 5v source? (i.e. noise, stability, etc.)  And finally, Spindle + and -
> pins appear to be isolated from the rest of the card, and it seems
> like I should connect Spindle - to 5v neutral regardless of which 5v I
> use.  Do I have that right? (it will be connected to a VFD with 0-5
> input requirement)
>
> Thanks,
> Brent
>
No. Those 3 terminals are an isolated electronic resistor intended to 
replace a manual speed potentiometer controlling a vfd, using the vfd's 
own 10 volt supply to the + and its ground reference to the -.  That 
generally is totally isolated from the rest of the world in a vfd 
control world.

This is all explained well in the 7i76 manual.

It can also control one of the Pico pwm-servo amps for dc spindle motors, 
but you need to invert (IIRC) the enable line between the spindle enable 
out and the pwm-servo amp.  And can do that control much faster than a 
spinx1 as the pwm-servo amp can also be controlled by a dc voltage 
input.

For that, and most of those dc motors, like the one on the G0704, are 90 
volt motors rated to use 9.7 amps at 1 hp full load. My dc supply makes 
126 volts and can do 20+ amps. With the pwm-servo set for a 17 amp peak, 
i'm getting considerably more than that 1 horse by the time I hear the 
current limiter kick in but normal cutting load is under 3 amps.  Its 
been doing that for around 4 years now with no indication of impending 
trouble. 

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 


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

Re: [Emc-users] Question regarding power requirements for 7i76 Spindle+ and Spindle-

[Peter C. Wallace]

On Fri, 24 Jan 2020, Brent Loschen wrote:


Date: Fri, 24 Jan 2020 14:00:06 -0700
From: Brent Loschen 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: [Emc-users] Question regarding power requirements for 7i76 Spindle+
and Spindle-


I currently power a 7i76 from the 5i25/cable, and am wondering if it's 
OK to power the Spindle + and - (TB4 pins 1 and 3) using that 5v source, 
or if it requires a separate 5v supply?  If current draw from the cable 
is no problem, are there any other drawbacks to using that 5v source? 
(i.e. noise, stability, etc.)  And finally, Spindle + and - pins appear 
to be isolated from the rest of the card, and it seems like I should 
connect Spindle - to 5v neutral regardless of which 5v I use.  Do I have 
that right? (it will be connected to a VFD with 0-5 input requirement)


Thanks,
Brent




VFD Spindle drives are often very noisy so its much better to use their
10V potentiometer power if possible, next choice is a floating 5V or 10V supply



___
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

Re: [Emc-users] Real-time OS for machine controllers

[Andy Pugh]

> On 24 Jan 2020, at 22:06, bari  wrote:
> 
> One thing that has come up when using LinuxCNC to control robots in an
> automation cell is controlling more than one robot or machine at a time.

That feels like a low-hanging fruit. Multiple LinuxCNC instances and a shared 
HAL area on one PC. 




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

Re: [Emc-users] Real-time OS for machine controllers

[R C]

On 1/24/20 1:27 PM, Gene Heskett wrote:

On Friday 24 January 2020 15:03:46 bari wrote:


One thing that has come up when using LinuxCNC to control robots in an
automation cell is controlling more than one robot or machine at a
time. Or having LinuxCNC control the hand-off of parts between
machines and/or robots.


I don't believe hal would have a problem doing that, although for serious
lengths of queues I think I'd put a pile between the machines for a
buffer. That would complexify the hal, but no more than any other flow
control scheme. And it could be done right now plus fabbing the
mechanics.



If you are controlling more than one CNC machine, or robots at a time, 
you are actually talking


about a parallel system. (Work gets done in parallel.) That is exactly 
what HPCs/Supercomputers do,


And in parallel/HPC computing it is very well understood that you have 
to offload hardware/time dependent


work. That was figured out after the first (original) Cray 
supercomputers (SGI tried not to but failed). If you want


scalable parallel production, you have to offload work, and you start to 
need equipment that manages that too.



The issues with running different and/or multiple machines running in 
parallel, from what I hear, sounds very similar  to the what


HPC/Supercomputing has been dealing with all the time, scalability. (oh 
and :) all these parallel computers use some sort of Linux, because


it scales really well).





On 1/24/20 1:33 PM, Stuart Stevenson wrote:

Integration into ERP systems?
Integration into metrology?
Machine cell controller?
Focus on lights out operation. I know one shop owner that claims
most of his operators already run 'lights out'.

Other ideas?

Thanks
Stuart

On Fri, Jan 24, 2020, 1:29 PM Stuart Stevenson 

wrote:

What should be the roll of LinuxCNC going forward?

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


Cheers, Gene Heskett



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

[Emc-users] Question regarding power requirements for 7i76 Spindle+ and Spindle-

[Brent Loschen]

I currently power a 7i76 from the 5i25/cable, and am wondering if it's 
OK to power the Spindle + and - (TB4 pins 1 and 3) using that 5v source, 
or if it requires a separate 5v supply?  If current draw from the cable 
is no problem, are there any other drawbacks to using that 5v source? 
(i.e. noise, stability, etc.)  And finally, Spindle + and - pins appear 
to be isolated from the rest of the card, and it seems like I should 
connect Spindle - to 5v neutral regardless of which 5v I use.  Do I have 
that right? (it will be connected to a VFD with 0-5 input requirement)


Thanks,
Brent


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

Re: [Emc-users] Real-time OS for machine controllers

[R C]

How are you going to do ethernet, wifi or "what ever communication"  
that is reliable (which means the process has to be able to take 
priority), without using PCI or anything like it on PC style hardware, 
or even non-PC computing hardware?


If you'd use anything affordable (which means Intel/ARM/'other' based 
stuff, you are just moving the problem around, because


at some point in the process you need a very well timed/orchestrated 
mechanism to make steppermotors (or even servos) do what you want them 
to do.


Whatever the approach, at some point somewhere you need some hardware 
function that does that, even if you'd have a specific controller, FPGA, 
whatever, then


that piece has to take that function over, the problem didn't go away.


Can you make that "hardware function" more reliable or less intrusive?  
Of course, that is why there are these special controllers, but that 
also costs more money for the


hardware/software. (It is possible to do that with networking too, by 
replacing ethernet with IB (InfiniBand) or so, however again...  that is 
expensive and does not


make the hardware dependency go away, you just relocate it).


Maybe a "good way forward" for those that are looking for that "forward" 
for LinuxCNC is, besides using PCI/Parallel port hardware, also support 
other hardware, where you can just select a device/protocol to do your 
stepping with. (if that doesn't already exist).



just another 2cnts,


Ron


On 1/24/20 12:15 PM, John Dammeyer wrote:

Hi Jon,

-Original Message-
From: Jon Elson [mailto:el...@pico-systems.com]

On 01/23/2020 11:45 PM, John Dammeyer wrote:

I really don't know what is going on under the covers for
either the MESA Ethernet 7i92H or the Ethernet Smooth
Stepper for MACH. But considering the power of the
processors running machines back in the 90's or early
2000's and that the mechanics for the metal cutting
haven't changed much, my guess is that some 32 bit
processor _not_ running Linux so that the
graphics/USB/etc. doesn't cripple the real time behaviour
will be the solution.

You keep going around and around saying that LinuxCNC
doesn't work. Thousands of people are using it daily, and
know it DOES work!  If you want to do software stepping, how
about Machinekit on the Beagle Bone, using the PRU
to do the step generation?  This works amazingly well, and
costs about $145 plus keyboard, mouse and LCD screen.
Or, you can network into the Beagle and use some other
machine for the man-machine interface.

Jon

I'm _not_ saying LinuxCNC doesn't work.
The opposite in fact and I've run the BBB with the Xylotex cape so I can attest 
that it does especially with the dual PRU I/O processors.  Even posted a 
youtube video on that.

Where the beagle falls down on the Linux side of things, say compared to a Pi 
or a PC, is the video processing just isn't as good.  And it shows even when 
just running normal Linux compared to normal Linux on a Pi.

Where my LinuxCNC box falls apart is with the parallel port for stepping with 
very high latency issues and that one time warning when LinuxCNC starts up that 
I've basically got my motion parameters set too high for the system.

The solution is of course the MESA 7 I92H which solves that problem.

Or when I run MACH3 on WIN-XP with the parallel port with a 65KHz clock rate.   
Then that exact same PC doesn't have any high speed step rate issues.

Now like the BBB I/O, the PC parallel port is directly coupled to the processor 
motherboard and therefore the processor.  That LinuxCNC cannot run the same 
step rates as the WIN-XP system on identical hardware (dual boot PC remember) 
shows that there is some sort of issue with PC hardware that LinuxCNC is not 
able to solve.  Might well be video drivers.  USB drivers.  Network Drivers.  
Might be how it handles the BIOS parameters.

Offload that I/O to a USB/Ethernet smooth stepper for MACH or the MESA 7i92H 
for LinuxCNC and the latency problems (there are others in Windows) go away.

And that, I think, is the point that everyone is making.  It's not like the PC 
parallel port is used with SPI or I2C on each output pin to expand I/O.  Some 
of the LinuxCNC solutions involve plugging a board into the PCI bus and using 
either co-processors or FPGA (which could have a co-processor built into them) 
to handle the heavy lifting.  The others involve using Ethernet and processing 
outside the box again.

I agree there are probably thousands if not tens of thousands of LinuxCNC 
systems out there running from the parallel port.  And odds are they are 
running micro-steppers that, if they are lucky, require at most 15kHz to 18kHz 
step rates before the stepper motor torque falls off so badly that they lock 
up.  So the Parallel port version of LinuxCNC has no issues on those systems.

But the latency warning for 50khz step rates for the DC Servos under LinuxCNC 
that doesn't happen on WIN-XP and MACH3 suggests that I've reached the upper 
limit of the LinuxCNC OS and 

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Friday 24 January 2020 15:03:46 bari wrote:

> One thing that has come up when using LinuxCNC to control robots in an
> automation cell is controlling more than one robot or machine at a
> time. Or having LinuxCNC control the hand-off of parts between
> machines and/or robots.
>
I don't believe hal would have a problem doing that, although for serious 
lengths of queues I think I'd put a pile between the machines for a 
buffer. That would complexify the hal, but no more than any other flow 
control scheme. And it could be done right now plus fabbing the 
mechanics.
> On 1/24/20 1:33 PM, Stuart Stevenson wrote:
> > Integration into ERP systems?
> > Integration into metrology?
> > Machine cell controller?
> > Focus on lights out operation. I know one shop owner that claims
> > most of his operators already run 'lights out'.
> >
> > Other ideas?
> >
> > Thanks
> > Stuart
> >
> > On Fri, Jan 24, 2020, 1:29 PM Stuart Stevenson  
wrote:
> >> What should be the roll of LinuxCNC going forward?
>
> ___
> 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 


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

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Friday 24 January 2020 13:47:38 Les Newell wrote:

> >> On 24 Jan 2020, at 19:51, Chris Albertson
> >>  wrote:
> >>
> >> But we could design things so the requirements are VEY loose at the
> >> highest level for 0.5-second latencies being acceptable.
> >
> > Not rigid tapping.
>
> And jogging would be horrible.
>
> Les
>
Strike 2.

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 


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

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Friday 24 January 2020 13:46:37 Les Newell wrote:

> > Humm pcbshopper.com, got a project "code" I can order and a doc &
> > BOM I can DL?
>
> Pcbshopper is just a price comparison site. You enter the board
> details and they poll various suppliers for the best price.
>
> Currently all I have are the KiCad project and the Gerbers. I need to
> write some docs. I designed this board a couple of years ago so I need
> to look back through my records to see exactly what I have.
>
> Where would be the best place for the files? Is there a place on the
> LCNC website? Maybe on Github?
>
> Les
>
Because I'm somewhat spooked by the all eggs in one basket that github 
uses, I think I'd use our wiki.

Thanks Les.

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 


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

Re: [Emc-users] Real-time OS for machine controllers

[bari]

One thing that has come up when using LinuxCNC to control robots in an
automation cell is controlling more than one robot or machine at a time.
Or having LinuxCNC control the hand-off of parts between machines and/or
robots.

On 1/24/20 1:33 PM, Stuart Stevenson wrote:
> Integration into ERP systems?
> Integration into metrology?
> Machine cell controller?
> Focus on lights out operation. I know one shop owner that claims most of
> his operators already run 'lights out'.
>
> Other ideas?
>
> Thanks
> Stuart
>
> On Fri, Jan 24, 2020, 1:29 PM Stuart Stevenson  wrote:
>
>> What should be the roll of LinuxCNC going forward?
>>
>>



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

Re: [Emc-users] Real-time OS for machine controllers

[bari]

On 1/24/20 12:47 PM, Les Newell wrote:
>
>>> On 24 Jan 2020, at 19:51, Chris Albertson
>>>  wrote:
>>>
>>> But we could design things so the requirements are VEY loose at the
>>> highest
>>> level for 0.5-second latencies being acceptable.
>> Not rigid tapping.
>>
> And jogging would be horrible.
>

When the issue comes up for a replacement for LinuxCNC with a more
modern software it is always for stepper only systems and not servo.
They have not thought through the issues of 5+ axis servo or rigid
tapping or synchronizing axis motion with lasers , galvos or inkjet
printheads, all of which I do with LCNC. I know that I work on lots of
hybrid systems that combine different technologies and LinuxCNC lets me
do that pretty easily. That is why we (we being mostly the guy down the
hall from me) have been keeping RTAI alive.

If there is a way to move to a different system architecture with the
GUI on a 12 inch (30.5cm) plus display and have the motion control
offloaded to a separate real-time processor that gives me more features
and flexibility than I have now I might be interested.

Moving to a different system architecture with the GUI on one device and
the motion control offloaded to a separate real-time processor that just
gives me "more modern" isn't worth my development time.  It will also
take lots more work than making the mods I do now or keeping RTAI going.
Changing the system architecture will have to give me more than I have
now to make such development worthwhile.

The display will have to be large enough to display all the controls
plus be rugged and reliable, so NOT a smartphone. I also don't want to
control any machine that can easily kill someone or me over a wireless
connection.




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

Re: [Emc-users] Real-time OS for machine controllers

[Stuart Stevenson]

Integration into ERP systems?
Integration into metrology?
Machine cell controller?
Focus on lights out operation. I know one shop owner that claims most of
his operators already run 'lights out'.

Other ideas?

Thanks
Stuart

On Fri, Jan 24, 2020, 1:29 PM Stuart Stevenson  wrote:

> What should be the roll of LinuxCNC going forward?
>
> Regards
> Stuart
>
> On Fri, Jan 24, 2020, 1:18 PM John Dammeyer 
> wrote:
>
>> Hi Jon,
>> > -Original Message-
>> > From: Jon Elson [mailto:el...@pico-systems.com]
>> >
>> > On 01/23/2020 11:45 PM, John Dammeyer wrote:
>> > > I really don't know what is going on under the covers for
>> > > either the MESA Ethernet 7i92H or the Ethernet Smooth
>> > > Stepper for MACH. But considering the power of the
>> > > processors running machines back in the 90's or early
>> > > 2000's and that the mechanics for the metal cutting
>> > > haven't changed much, my guess is that some 32 bit
>> > > processor _not_ running Linux so that the
>> > > graphics/USB/etc. doesn't cripple the real time behaviour
>> > > will be the solution.
>> > You keep going around and around saying that LinuxCNC
>> > doesn't work. Thousands of people are using it daily, and
>> > know it DOES work!  If you want to do software stepping, how
>> > about Machinekit on the Beagle Bone, using the PRU
>> > to do the step generation?  This works amazingly well, and
>> > costs about $145 plus keyboard, mouse and LCD screen.
>> > Or, you can network into the Beagle and use some other
>> > machine for the man-machine interface.
>> >
>> > Jon
>>
>> I'm _not_ saying LinuxCNC doesn't work.
>> The opposite in fact and I've run the BBB with the Xylotex cape so I can
>> attest that it does especially with the dual PRU I/O processors.  Even
>> posted a youtube video on that.
>>
>> Where the beagle falls down on the Linux side of things, say compared to
>> a Pi or a PC, is the video processing just isn't as good.  And it shows
>> even when just running normal Linux compared to normal Linux on a Pi.
>>
>> Where my LinuxCNC box falls apart is with the parallel port for stepping
>> with very high latency issues and that one time warning when LinuxCNC
>> starts up that I've basically got my motion parameters set too high for the
>> system.
>>
>> The solution is of course the MESA 7 I92H which solves that problem.
>>
>> Or when I run MACH3 on WIN-XP with the parallel port with a 65KHz clock
>> rate.   Then that exact same PC doesn't have any high speed step rate
>> issues.
>>
>> Now like the BBB I/O, the PC parallel port is directly coupled to the
>> processor motherboard and therefore the processor.  That LinuxCNC cannot
>> run the same step rates as the WIN-XP system on identical hardware (dual
>> boot PC remember) shows that there is some sort of issue with PC hardware
>> that LinuxCNC is not able to solve.  Might well be video drivers.  USB
>> drivers.  Network Drivers.  Might be how it handles the BIOS parameters.
>>
>> Offload that I/O to a USB/Ethernet smooth stepper for MACH or the MESA
>> 7i92H for LinuxCNC and the latency problems (there are others in Windows)
>> go away.
>>
>> And that, I think, is the point that everyone is making.  It's not like
>> the PC parallel port is used with SPI or I2C on each output pin to expand
>> I/O.  Some of the LinuxCNC solutions involve plugging a board into the PCI
>> bus and using either co-processors or FPGA (which could have a co-processor
>> built into them) to handle the heavy lifting.  The others involve using
>> Ethernet and processing outside the box again.
>>
>> I agree there are probably thousands if not tens of thousands of LinuxCNC
>> systems out there running from the parallel port.  And odds are they are
>> running micro-steppers that, if they are lucky, require at most 15kHz to
>> 18kHz step rates before the stepper motor torque falls off so badly that
>> they lock up.  So the Parallel port version of LinuxCNC has no issues on
>> those systems.
>>
>> But the latency warning for 50khz step rates for the DC Servos under
>> LinuxCNC that doesn't happen on WIN-XP and MACH3 suggests that I've reached
>> the upper limit of the LinuxCNC OS and the parallel port with this
>> particular configuration.
>>
>> But as I've been saying, the moment you add some sort of external FPGA or
>> processor based external card that offloads the heavy processing for high
>> speed encoder/step/SSERIAL etc. then it's not just LinuxCNC anymore but a
>> PC  dependent on outside hardware.   And that's what the subject line and
>> discussion was about I thought.  If the motion control was offloaded to a
>> separate processor then just about any PC remote or right there can load
>> G-Code, display tool paths and control the machine.
>>
>> Without a PCI plug in card.  So we really are talking about Ethernet
>> Based control; perhaps even WiFi.  Now we're back to the question as to why
>> should it be LinuxCNC when it could be a dedicated processing I/O module
>> with Ethernet connectivity running an 

Re: [Emc-users] Real-time OS for machine controllers

[Stuart Stevenson]

What should be the roll of LinuxCNC going forward?

Regards
Stuart

On Fri, Jan 24, 2020, 1:18 PM John Dammeyer  wrote:

> Hi Jon,
> > -Original Message-
> > From: Jon Elson [mailto:el...@pico-systems.com]
> >
> > On 01/23/2020 11:45 PM, John Dammeyer wrote:
> > > I really don't know what is going on under the covers for
> > > either the MESA Ethernet 7i92H or the Ethernet Smooth
> > > Stepper for MACH. But considering the power of the
> > > processors running machines back in the 90's or early
> > > 2000's and that the mechanics for the metal cutting
> > > haven't changed much, my guess is that some 32 bit
> > > processor _not_ running Linux so that the
> > > graphics/USB/etc. doesn't cripple the real time behaviour
> > > will be the solution.
> > You keep going around and around saying that LinuxCNC
> > doesn't work. Thousands of people are using it daily, and
> > know it DOES work!  If you want to do software stepping, how
> > about Machinekit on the Beagle Bone, using the PRU
> > to do the step generation?  This works amazingly well, and
> > costs about $145 plus keyboard, mouse and LCD screen.
> > Or, you can network into the Beagle and use some other
> > machine for the man-machine interface.
> >
> > Jon
>
> I'm _not_ saying LinuxCNC doesn't work.
> The opposite in fact and I've run the BBB with the Xylotex cape so I can
> attest that it does especially with the dual PRU I/O processors.  Even
> posted a youtube video on that.
>
> Where the beagle falls down on the Linux side of things, say compared to a
> Pi or a PC, is the video processing just isn't as good.  And it shows even
> when just running normal Linux compared to normal Linux on a Pi.
>
> Where my LinuxCNC box falls apart is with the parallel port for stepping
> with very high latency issues and that one time warning when LinuxCNC
> starts up that I've basically got my motion parameters set too high for the
> system.
>
> The solution is of course the MESA 7 I92H which solves that problem.
>
> Or when I run MACH3 on WIN-XP with the parallel port with a 65KHz clock
> rate.   Then that exact same PC doesn't have any high speed step rate
> issues.
>
> Now like the BBB I/O, the PC parallel port is directly coupled to the
> processor motherboard and therefore the processor.  That LinuxCNC cannot
> run the same step rates as the WIN-XP system on identical hardware (dual
> boot PC remember) shows that there is some sort of issue with PC hardware
> that LinuxCNC is not able to solve.  Might well be video drivers.  USB
> drivers.  Network Drivers.  Might be how it handles the BIOS parameters.
>
> Offload that I/O to a USB/Ethernet smooth stepper for MACH or the MESA
> 7i92H for LinuxCNC and the latency problems (there are others in Windows)
> go away.
>
> And that, I think, is the point that everyone is making.  It's not like
> the PC parallel port is used with SPI or I2C on each output pin to expand
> I/O.  Some of the LinuxCNC solutions involve plugging a board into the PCI
> bus and using either co-processors or FPGA (which could have a co-processor
> built into them) to handle the heavy lifting.  The others involve using
> Ethernet and processing outside the box again.
>
> I agree there are probably thousands if not tens of thousands of LinuxCNC
> systems out there running from the parallel port.  And odds are they are
> running micro-steppers that, if they are lucky, require at most 15kHz to
> 18kHz step rates before the stepper motor torque falls off so badly that
> they lock up.  So the Parallel port version of LinuxCNC has no issues on
> those systems.
>
> But the latency warning for 50khz step rates for the DC Servos under
> LinuxCNC that doesn't happen on WIN-XP and MACH3 suggests that I've reached
> the upper limit of the LinuxCNC OS and the parallel port with this
> particular configuration.
>
> But as I've been saying, the moment you add some sort of external FPGA or
> processor based external card that offloads the heavy processing for high
> speed encoder/step/SSERIAL etc. then it's not just LinuxCNC anymore but a
> PC  dependent on outside hardware.   And that's what the subject line and
> discussion was about I thought.  If the motion control was offloaded to a
> separate processor then just about any PC remote or right there can load
> G-Code, display tool paths and control the machine.
>
> Without a PCI plug in card.  So we really are talking about Ethernet Based
> control; perhaps even WiFi.  Now we're back to the question as to why
> should it be LinuxCNC when it could be a dedicated processing I/O module
> with Ethernet connectivity running an RTOS with pre-emptive scheduling.  A
> small BoB sized board with a single cable (antenna or Ethernet) out to the
> outside world.  And with a clearly documented interface the software that
> connects to this no longer has to run on a particular PC running a
> particular OS.
>
> I hope that clears it up.
> John Dammeyer
>
>
>
>
>
>
>
>
> 

Re: [Emc-users] Real-time OS for machine controllers

[John Dammeyer]

Hi Jon,
> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> 
> On 01/23/2020 11:45 PM, John Dammeyer wrote:
> > I really don't know what is going on under the covers for
> > either the MESA Ethernet 7i92H or the Ethernet Smooth
> > Stepper for MACH. But considering the power of the
> > processors running machines back in the 90's or early
> > 2000's and that the mechanics for the metal cutting
> > haven't changed much, my guess is that some 32 bit
> > processor _not_ running Linux so that the
> > graphics/USB/etc. doesn't cripple the real time behaviour
> > will be the solution.
> You keep going around and around saying that LinuxCNC
> doesn't work. Thousands of people are using it daily, and
> know it DOES work!  If you want to do software stepping, how
> about Machinekit on the Beagle Bone, using the PRU
> to do the step generation?  This works amazingly well, and
> costs about $145 plus keyboard, mouse and LCD screen.
> Or, you can network into the Beagle and use some other
> machine for the man-machine interface.
> 
> Jon

I'm _not_ saying LinuxCNC doesn't work.  
The opposite in fact and I've run the BBB with the Xylotex cape so I can attest 
that it does especially with the dual PRU I/O processors.  Even posted a 
youtube video on that.  

Where the beagle falls down on the Linux side of things, say compared to a Pi 
or a PC, is the video processing just isn't as good.  And it shows even when 
just running normal Linux compared to normal Linux on a Pi.

Where my LinuxCNC box falls apart is with the parallel port for stepping with 
very high latency issues and that one time warning when LinuxCNC starts up that 
I've basically got my motion parameters set too high for the system.  

The solution is of course the MESA 7 I92H which solves that problem.

Or when I run MACH3 on WIN-XP with the parallel port with a 65KHz clock rate.   
Then that exact same PC doesn't have any high speed step rate issues.

Now like the BBB I/O, the PC parallel port is directly coupled to the processor 
motherboard and therefore the processor.  That LinuxCNC cannot run the same 
step rates as the WIN-XP system on identical hardware (dual boot PC remember) 
shows that there is some sort of issue with PC hardware that LinuxCNC is not 
able to solve.  Might well be video drivers.  USB drivers.  Network Drivers.  
Might be how it handles the BIOS parameters.  

Offload that I/O to a USB/Ethernet smooth stepper for MACH or the MESA 7i92H 
for LinuxCNC and the latency problems (there are others in Windows) go away.

And that, I think, is the point that everyone is making.  It's not like the PC 
parallel port is used with SPI or I2C on each output pin to expand I/O.  Some 
of the LinuxCNC solutions involve plugging a board into the PCI bus and using 
either co-processors or FPGA (which could have a co-processor built into them) 
to handle the heavy lifting.  The others involve using Ethernet and processing 
outside the box again.

I agree there are probably thousands if not tens of thousands of LinuxCNC 
systems out there running from the parallel port.  And odds are they are 
running micro-steppers that, if they are lucky, require at most 15kHz to 18kHz 
step rates before the stepper motor torque falls off so badly that they lock 
up.  So the Parallel port version of LinuxCNC has no issues on those systems.

But the latency warning for 50khz step rates for the DC Servos under LinuxCNC 
that doesn't happen on WIN-XP and MACH3 suggests that I've reached the upper 
limit of the LinuxCNC OS and the parallel port with this particular 
configuration.

But as I've been saying, the moment you add some sort of external FPGA or 
processor based external card that offloads the heavy processing for high speed 
encoder/step/SSERIAL etc. then it's not just LinuxCNC anymore but a PC  
dependent on outside hardware.   And that's what the subject line and 
discussion was about I thought.  If the motion control was offloaded to a 
separate processor then just about any PC remote or right there can load 
G-Code, display tool paths and control the machine.  

Without a PCI plug in card.  So we really are talking about Ethernet Based 
control; perhaps even WiFi.  Now we're back to the question as to why should it 
be LinuxCNC when it could be a dedicated processing I/O module with Ethernet 
connectivity running an RTOS with pre-emptive scheduling.  A small BoB sized 
board with a single cable (antenna or Ethernet) out to the outside world.  And 
with a clearly documented interface the software that connects to this no 
longer has to run on a particular PC running a particular OS.

I hope that clears it up.
John Dammeyer








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

Re: [Emc-users] Real-time OS for machine controllers

[Les Newell]

On 24 Jan 2020, at 19:51, Chris Albertson  wrote:

But we could design things so the requirements are VEY loose at the highest
level for 0.5-second latencies being acceptable.

Not rigid tapping.


And jogging would be horrible.

Les



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

Re: [Emc-users] Real-time OS for machine controllers

[Les Newell]

Humm pcbshopper.com, got a project "code" I can order and a doc & BOM I
can DL?



Pcbshopper is just a price comparison site. You enter the board details 
and they poll various suppliers for the best price.


Currently all I have are the KiCad project and the Gerbers. I need to 
write some docs. I designed this board a couple of years ago so I need 
to look back through my records to see exactly what I have.


Where would be the best place for the files? Is there a place on the 
LCNC website? Maybe on Github?


Les



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

Re: [Emc-users] Real-time OS for machine controllers

[Andy Pugh]

> On 24 Jan 2020, at 19:51, Chris Albertson  wrote:
> 
> But we could design things so the requirements are VEY loose at the highest
> level for 0.5-second latencies being acceptable.

Not rigid tapping. 




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

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Friday 24 January 2020 12:14:01 Les Newell wrote:

> Hi Gene,
>
> > Opto stuff, with their speed limits, are much more trouble than
> > they're worth, I've cut many of them out of bobs. A limiting
> > resistor and a schotkey diode to each rail s/b be input protection
> > limit enough.
>
> I have to disagree. Unless you need high speed, such as for encoders,
> optos are very worthwhile. Their slow speed helps mask out any short
> duration noise on the line. The isolation is also good for reducing
> noise.
>
> > And yes, I'd be interested in something that I could run thru
> > pcb2gcode and make myself, and I suspect I am not alone.
>
> The layout is pretty tight for mechanical etching. If I remember
> correctly some track gaps are only 0.006". Making the board very
> configurable had the down side of also making it pretty tight in
> places. It's a 100mm x 100mm board and some Chinese PCB manufacturers
> are offering crazy low prices to build this size board. I used to make
> my own boards but these days it is so cheap to get them made it is not
> worth the effort. I've found the Chinese made boards to be very good
> quality. I just checked on pcbshopper.com and you can get 5 delivered
> to your door for a total of $8.33 in 23 days or if you are in more of
> a hurry how about $13.38 in 16 days?
>
Humm pcbshopper.com, got a project "code" I can order and a doc & BOM I 
can DL? Currently using a 5i25 with a 7i76D on p3 on two of my mills but 
any sneeze of the power crashes the sserial link requiring a full power 
down, count to ten reboot.  All supplies must die totally to recover.

And I'd like to see if the 7i90HD thru the parport could run it more 
dependably. So I have the cost of three 7i42TA's as impetus to look at 
building your board instead.

> >   I've even done the drill
> > holes at only 40 thou into the board from each side and made them
> > meet in the middle of the board.  And I've got lots of board. The
> > 7i90HD is a good start on a do anything board, but it sure needs
> > protection, its very easily damaged by stray noise.
>
> I've used quite a few of the Mesa FPGA boards and I've only ever
> killed one - that was by feeding 24V back down one of the outputs.
> Maybe you should consider using optos ;-)

I wound up fixing my admittedly hasty original layout/hookup, which was 
giving me switching noise from the stepper drivers at around 40 volts 
p-p and 3ns rise times. With everything on a single point ground bolt, 
the noise fell into a black hole and is now under 100mv. But I have also 
fitted 3 7i42TA's because that also gave me std screw terminals to wire 
it up with. No more jumpers jumping off an unmarked pin in the 50 
pinners just cause I opened the garage door. 

Best.  Fix.  Ever.

And I'm still running on a 7i90 with 2 blown stepgens. But with 8 to 
choose from, the hal file reassignments were trivial, and has been 
working for 2 years now.  Switched from an rpi3 which was dragging its 
tongue on the floor to an rpi4 last fall, sweet. No latency overruns, 
none!  And I still have about 30 spare outputs/inputs if I ever get a 
tool turret carriage.

> Les
>
Thanks Les.

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 


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

Re: [Emc-users] Real-time OS for machine controllers

[Chris Albertson]

If you can tolerate latency, then your "hub" does not need what we call
"hard" real-time capability.  It only needs to keep up with the average
workload, averaged over whatever latency you can tolerate.  Video streaming
works this way.They can't reliably send video and the 60 Hz frame rate
so they buffer a few seconds of video on your phone and the real-time
viewer lives on the phone  not the server.

g-code could be the same way.   The penalty is that when you press the "go"
button the milling machine would take a few seconds the start working while
the data buffers into the low-level motor controllers. Today a
step/direction controller has no memory so it must be fed steps in real
time.  But if it has a 10,000 step memory you could just transfer blocks
ever half second and the controller would work down the queue."Steps"
are the wrong kind of data for this but "states" are what is used.

You are correct in that some real-time ability is needed at every level.
But we could design things so the requirements are VEY loose at the highest
level for 0.5-second latencies being acceptable.   One you need only that,
then even an iPhone is a good enough platform.

On Thu, Jan 23, 2020 at 11:32 AM Peter C. Wallace  wrote:

> On Thu, 23 Jan 2020, Chris Albertson wrote:
>
> > Date: Thu, 23 Jan 2020 10:17:44 -0800
> > From: Chris Albertson 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: "Enhanced Machine Controller (EMC)"  >
> > Subject: Re: [Emc-users] Real-time OS for machine controllers
> >
> > The trouble with the Mesa FPGA design is that it depends on a computer
> with
> > good real-time performance.   It can generate steps but I don't thing you
> > can run a position or velocity PID control loop on the FPGA.
>
> LinuxCNCs design paradigm requires realtime, this is a design decision
> that is
> supported by our Hostmot2 real time firmware. We have other firmware that
> implements motion in the FPGA but this is not suited to LinuxCNCs model.
>
>
> You might argue that its an old fashioned model but many high performance
> CNC
> systems and Robotics controllers use LinuxCNCs model of a capable real
> time host
> (real OS with file I/O loadable modules, unlimited memory, massive
> floating
> point performance etc etc) Some of these use Linux and others use real
> time
> windows varients often with Ethercat Peripherals. This makes for a
> powerful
> extensible realtime toolkit (like LinuxCNCs HAL) and complex realtime
> responsive coordinated motion. Basically for this type of system you still
> need a very capable real time controller hub even if the motor controllers
> implement torque, velocity, or position loops
>
>
> Peter Wallace
> Mesa Electronics
>
>
>
> ___
> 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

Re: [Emc-users] Real-time OS for machine controllers

[Les Newell]

Hi Gene,


Opto stuff, with their speed limits, are much more trouble than they're
worth, I've cut many of them out of bobs. A limiting resistor and a
schotkey diode to each rail s/b be input protection limit enough.


I have to disagree. Unless you need high speed, such as for encoders, 
optos are very worthwhile. Their slow speed helps mask out any short 
duration noise on the line. The isolation is also good for reducing noise.



And yes, I'd be interested in something that I could run thru pcb2gcode
and make myself, and I suspect I am not alone.


The layout is pretty tight for mechanical etching. If I remember 
correctly some track gaps are only 0.006". Making the board very 
configurable had the down side of also making it pretty tight in places. 
It's a 100mm x 100mm board and some Chinese PCB manufacturers are 
offering crazy low prices to build this size board. I used to make my 
own boards but these days it is so cheap to get them made it is not 
worth the effort. I've found the Chinese made boards to be very good 
quality. I just checked on pcbshopper.com and you can get 5 delivered to 
your door for a total of $8.33 in 23 days or if you are in more of a 
hurry how about $13.38 in 16 days?



  I've even done the drill
holes at only 40 thou into the board from each side and made them meet
in the middle of the board.  And I've got lots of board. The 7i90HD is a
good start on a do anything board, but it sure needs protection, its
very easily damaged by stray noise.


I've used quite a few of the Mesa FPGA boards and I've only ever killed 
one - that was by feeding 24V back down one of the outputs. Maybe you 
should consider using optos ;-)


Les



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

Re: [Emc-users] Erik Chrstiansen, the Aussie?

[Robert Murphy]

I wouldn’t trust those overlay maps, one of those shown by ABC America had 
parts of Central Australia on fire, which truth be told is just sand and a lot 
of Very Hot. If it was flammable the Black Fellas would have set on fire 50k 
years ago or however long they have been here.
The facts for the 3 Eastern states are.
Victoria: they have had much worse in the past
Queensland: As per Victoria
NSW: About the largest area burnt

On a more serious note 3 Americans lost their lives when one of planes used to 
quell the fires went down, a bunch of young blokes in their 40’s. No reason for 
the crash yet, that will take a while to sort out.
Rest In Peace, and our sympathies to their families. 

Composed with my Crayons 

> On 24 Jan 2020, at 23:13, Gene Heskett  wrote:
> 
>> On Friday 24 January 2020 05:16:48 Erik Christiansen wrote:
>> 
>>> On 18.01.20 00:08, Gene Heskett wrote:
>>> With all the fires down under, he hasn't posted since 12 October.
>>> 
>>> Wondering if he and his new place is ok?
>> 
>> Many thanks, Gene, for the thoughts. (I only come back to town, and
>> the internet two weekends per month, while trying to push the build
>> along - insulating, then painting in Nov/Dec.)
>> 
>> So far, the only strife at the farm is choking smoke when the wind's
>> in the wrong direction - but that is also colouring New Zealand
>> glaciers and making the sky grey in Chile, so it's pretty useless to
>> bitch when I'm only 60 km from the western edge of the big patch (1.4
>> million hectares (3.5 million acres¹) of fires around Mallacoota,
>> Sarsfield, etc. (I am a bit stiff from putting in 150 m of 40 mm poly
>> pipe for a fire main with hydrants at the building corners, and a
>> demountable petrol driven fire pump, so it's harder to pinch. I've
>> bought a Grundfos electric variable speed boost pump for domestic
>> supply from 21,000 gallons of tanks (when they're filled - arrived
>> yesterday, just _after_ we had over 100 mm of rain in 2 days, a third
>> of what we had all last year, or the year before. The electric pump
>> can be cranked up to 62m head, hopefully enough for standing off hours
>> of ember attack prior to fire arrival. I'm adding a valve so it can
>> feed the fire main instead of the house. A fire fighting pump must
>> have continuous flow to keep it cool, which is not good with a finite
>> water supply, but the electric one shuts down when you close off the
>> nozzle on the fire hose. We'll see how it works out.)
>> 
>> Even several weeks after the fire peak, the only way through on the
>> only highway between the east of Victoria and the rest of the state is
>> with the military in Bushmaster armoured cars, as the clearing of
>> fallen and dangerous trees is ongoing. An escorted convoy was allowed
>> out to the north, into New South Wales, then back via Canberra for
>> those wanting back to Victoria - a helluva drive.
>> 
>> Today we lost a 3-man retardant-bombing crew from USA when a C130 went
>> in.
> 
> Ouch. My sympathies for the mens families. I'm reading of quite a few in 
> the entertainment business here who have collectively donated quite a 
> few millions to the firefighting efforts.  Probably just a drop in the 
> bucket compared to whats needed though. 
> 
>> Quite a few firefighters have given their all and then some this 
>> season, one when a fire tornado flipped an 8 tonne firetruck onto its
>> roof. I think we have about a hundred really experienced American
>> firefighters here to rotate with our strike team leaders and managers.
> 
>> The glorious rain didn't put the fires out, but it really reduces the
>> rate of spread.
>> 
>> Much of the burnt country is forest, but there's a lot of stock with
>> nothing but charcoal and ash to eat, so there's a lot of stock feed
>> going past our farm on the highway. I was in town on Saturday, and a
>> convoy of 30 semitrailers loaded to the gunwales with hay went east,
>> and at the petrol station they said another of 15 semitrailers had
>> gone through earlier in the day. A few days before I met a convoy of
>> 15 loads of donated hay. How much is going through the rest of the
>> time?
> I don't have a clue, but I don't imagine theres enough to keep it going 
> for long enough to save all the stock.
> 
>> The rain makes the rest of us at a distance much safer. Heck, for the
>> first time in a year, there's a foot of water in the bottom of the
>> best dam on the property,
> 
> Not much in the grand scheme of things.
> 
>> and there's green grass shooting up all 
>> over. If there's a bit of follow-up rain here and there, we could
>> start farming again. (The only animals on the place are kangaroos,
>> wallabies, and wombats, now. One of the latter started digging a 2
>> foot diameter burrow in the soft sand of the fill pad under the new
>> build. I've twice chased him across the paddock after midnight at 25
>> km/h in the ute, with headlights on high beam and honking the horn. I
>> didn't know they could run that fast on those stubby 

Re: [Emc-users] Real-time OS for machine controllers

[Jon Elson]

On 01/23/2020 11:45 PM, John Dammeyer wrote:
I really don't know what is going on under the covers for 
either the MESA Ethernet 7i92H or the Ethernet Smooth 
Stepper for MACH. But considering the power of the 
processors running machines back in the 90's or early 
2000's and that the mechanics for the metal cutting 
haven't changed much, my guess is that some 32 bit 
processor _not_ running Linux so that the 
graphics/USB/etc. doesn't cripple the real time behaviour 
will be the solution.
You keep going around and around saying that LinuxCNC 
doesn't work. Thousands of people are using it daily, and
know it DOES work!  If you want to do software stepping, how 
about Machinekit on the Beagle Bone, using the PRU
to do the step generation?  This works amazingly well, and 
costs about $145 plus keyboard, mouse and LCD screen.
Or, you can network into the Beagle and use some other 
machine for the man-machine interface.


Jon


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

Re: [Emc-users] Backlash comp monitoring

[Jon Elson]

On 01/23/2020 11:07 PM, David Berndt wrote:

Hello All,

I'm having a bit of an issue with some geometry not coming 
out as expected. I suspect it's related to backlash and 
cutting forces moving the table a bit but I don't have 
linear scales to monitor/correct for that sort of thing so 
I'm left wondering a bit. I was hoping that being able to 
see what backlash comp is doing on screen as my toolpaths 
run might enlighten me some. Is there any pin or ?? that 
can be monitored to give me more insight?
What motion control system are you using?  Mesa, Pico, 
software stepping?
In any case, there is some position output that can be fed 
into Halscope to read

the real-time position and graph it.

The problem with backlash compensation is that you are 
trying to cover up a defect (usually slack in the leadscrew)
with software that can't actually read the slack.  So, any 
force from the cutting tool can put the table on either side
of the slack, and the computer can't sense it.  Also, when 
changing directions, it requires the motor to instantaneously
jump from one side of the slack to the other.  So, the best 
fix is to remove the slack.  Depending on the mechanism,
Acme nuts can often be sliced in half and compressed or 
otherwise adjusted to reduce backlash.  One problem with
Acme screws is that there can be more wear in the middle of 
travel, making it hard to adjust out the slack throughout the

range of travel.  Dual ballnuts can be set up with a preload.

Jon


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

Re: [Emc-users] Backlash comp monitoring

[andy pugh]

On Fri, 24 Jan 2020 at 07:40, David Berndt  wrote:
>
>Is there any pin or ?? that can be monitored to give me
> more insight?

2.8 has:
joint.N.backlash−corr OUT FLOAT (DEBUG) - Backlash or screw
compensation raw value
joint.N.backlash−filt OUT FLOAT (DEBUG) - Backlash or screw
compensation filtered value (respecting motion limits)
joint.N.backlash−vel OUT FLOAT (DEBUG) - Backlash or screw compensation velocity

2.7 has:

axis.N.backlash−corr OUT FLOAT - Backlash or screw compensation raw value
axis.N.backlash−filt OUT FLOAT  - Backlash or screw compensation
filtered value (respecting motion limits)
axis.N.backlash−vel OUT FLOAT - Backlash or screw compensation velocity


-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


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

Re: [Emc-users] LinuxCNC 2.7.15 release

[Sebastian Kuzminsky]

On 1/23/20 7:09 PM, Dale Ertley via Emc-users wrote:

Hello all,I was going to try the new LinuxCNC 2.7.15 releace but I
can not find the download.The page is there with a list of the new
contributors and the many things that have been fixed.Just can't seem
to find where to download.Also is 2.7.15 setup to be put on a USB
drive to install?Thank you to all for your great work.Dale


The release is distributed as an updated debian package from 
www.linuxcnc.org.  Details on the process are here:


http://linuxcnc.org/docs/2.7/html/getting-started/updating-linuxcnc.html


--
Sebastian Kuzminsky


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

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Friday 24 January 2020 07:34:27 Les Newell wrote:

> > Not all, the 7i90 being a rather glaring exception, it's cheap for
> > it capabilities but needs another $135 in 7i42TA's to protect it. I
> > suspect that any of the Mesa cards that output via 50 pin scsi
> > connectors have similar restrictions.
>
> Yes, the FPGA boards do need buffering but any logic level I/O device
> needs buffering to control relays etc. You also need to protect
> inputs. If you want to roll your own I have a design for a Mesa
> compatible I/O buffer board that has opto isolated inputs and 100mA
> Darlington outputs that can be configured to drive high side or low
> side. I/Os are configurable at build time in groups of 8. Each group
> can be input or output, high side or low side. All thru hole
> components for ease of hand soldering. I originally designed it as a
> practice project when transitioning to using Kicad and have used it on
> a couple of machines now. I've been meaning to release it as open
> source hardware but never found the round tuits. If anyone is
> interested I'll knock up some docs and stick it on the wiki page or
> something.
>
> Les

Opto stuff, with their speed limits, are much more trouble than they're 
worth, I've cut many of them out of bobs. A limiting resistor and a 
schotkey diode to each rail s/b be input protection limit enough.

And yes, I'd be interested in something that I could run thru pcb2gcode 
and make myself, and I suspect I am not alone. I've even done the drill 
holes at only 40 thou into the board from each side and made them meet 
in the middle of the board.  And I've got lots of board. The 7i90HD is a 
good start on a do anything board, but it sure needs protection, its 
very easily damaged by stray noise.
>
>
> ___
> 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 


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

Re: [Emc-users] Real-time OS for machine controllers

[Les Newell]

Not all, the 7i90 being a rather glaring exception, it's cheap for it
capabilities but needs another $135 in 7i42TA's to protect it. I suspect
that any of the Mesa cards that output via 50 pin scsi connectors have
similar restrictions.



Yes, the FPGA boards do need buffering but any logic level I/O device 
needs buffering to control relays etc. You also need to protect inputs. 
If you want to roll your own I have a design for a Mesa compatible I/O 
buffer board that has opto isolated inputs and 100mA Darlington outputs 
that can be configured to drive high side or low side. I/Os are 
configurable at build time in groups of 8. Each group can be input or 
output, high side or low side. All thru hole components for ease of hand 
soldering. I originally designed it as a practice project when 
transitioning to using Kicad and have used it on a couple of machines 
now. I've been meaning to release it as open source hardware but never 
found the round tuits. If anyone is interested I'll knock up some docs 
and stick it on the wiki page or something.


Les



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

Re: [Emc-users] Real-time OS for machine controllers

[Les Newell]

On 23/01/2020 18:17, Chris Albertson wrote:

The trouble with the Mesa FPGA design is that it depends on a computer with
good real-time performance.


It's rare to find a PC that can't maintain the 1kHz timing loop. Most 
can even do this using Ethernet to communicate with the Mesa board. I 
have 4 machines using this exact arrangement. Two are running off cheap 
thin clients picked up off eBay. I think the other two mini PCs came 
from Ali Express. My lathe used to run off a Dell until that failed and 
was replaced by a HP machine I happened to have laying around. It now 
runs a Wyse thin client.



It can generate steps but I don't thing you
can run a position or velocity PID control loop on the FPGA.


The Mesa FPGA is easily powerful enough to run a PID loop but there is 
no need to do so. Let's face it PID loops are pretty simple and can be 
implemented with basic fixed point math.


There is some merit in moving the whole real-time section to a dedicated 
hardware platform and this is what most commercial CNC machines do. 
However that leaves you tied in to whatever hardware platform you have 
selected. My Hurco mill is a good example. It's motion controller board 
failed and Hurco could not supply a replacement or repair the board. The 
owner ended up selling it to me for pretty much scrap price. It is in 
pretty much perfect mechanical condition.


Will your $2 board be available in 10 years? I wouldn't be surprised if 
it becomes difficult to obtain within 2 years. Short of the planet being 
hit by an asteroid or similar disaster, you can be sure hardware running 
Linux will be available in 10+ years.


If Mesa were to go out of business tomorrow it would not be a huge task 
to develop a replacement for the FPGA board because it does not have to 
do all that much.




You asked about "my controler".  No this is not my idea, this is how most
current designs work today.  You "push" the real-time control down stram as
close to the physical motor as possible.


By 'your controller' I wasn't really referring to your specific 
hardware. I guess I should have said 'the controller'.


Most of the CNC machines I have worked on use a PC based GUI and a PLC 
or similar motion controller. That then talks to the drives, which are 
usually relatively dumb (velocity or torque control). The exact 
implementation varies but the basic topology remains pretty much the 
same. Having intelligent drives with built in trajectory planning causes 
more problems than it solves.



So how complex is the controller?  Very complex.  It is an entire 32-bit
computer with FLASH memory and USB running an RTOS.


I'm not talking about the complexity of modern microcontrollers. The 
complexity is in the software.


When it comes to debugging there is no comparison between Linux/Windows 
and embedded hardware. Arduino has virtually no real debugging support. 
You can't even use breakpoints. Want to see the value of a variable at a 
certain point? You can't set a watch or a breakpoint so your only 
alternative is to write some code to print that value to a terminal, 
recompile, download etc. Even when using JTAG or other dedicated 
debugging interfaces, debugging tends to be flaky and limited on most 
microcontrollers. I've worked with embedded processors for many years, 
everything from 8051 in assembly to various ARMs in C++. I've developed 
all sorts of stuff from DSP harmonic synthesis to networked I/O 
controllers with many hundreds of I/Os so I have a pretty good knowledge 
of what is involved in embedded development.


Open source projects have to have a very low barrier for entry to 
succeed. The harder it is to start developing the fewer developers you 
will have that are willing to work on it and therefore the less likely 
that project is to succeed. There are far more developers who are 
familiar with Windows/Linux than there are that are familiar with STM32 
development. Is LinuxCNC the perfect solution? Maybe not but it works 
and it works well. I've used Mach, UCCNC, Eding CNC and even developed 
my own hardware and software. If I want something that is reliable, 
versatile and keeps working LinuxCNC is the best I've found without 
spending huge amounts of money.



As a reference, I have a few quadcopter racing drones.  These use four
three-phas brushless motors that must be controled VERY accuratly using an
8000 Hz PID loop.



The drives may be using pretty powerful processors but if you take a 
step back they aren't much different from the 30+ year old 'dumb' 
Siemens analog drives in my router. You send them velocity or torque 
commands and the return velocity or position data. How they actually do 
that is merely an implementation detail.




The main
computer runs an RTOS and talks to the two digital radio, IMU and GPS.
  Fits in a 32mm space and costs maybe $30.  Again VERY complex but they are
easy to use.


Easy for the end user but not the developers. I have been involved in 
tri and quad copters since the 

Re: [Emc-users] Erik Chrstiansen, the Aussie?

[Gene Heskett]

On Friday 24 January 2020 05:16:48 Erik Christiansen wrote:

> On 18.01.20 00:08, Gene Heskett wrote:
> > With all the fires down under, he hasn't posted since 12 October.
> >
> > Wondering if he and his new place is ok?
>
> Many thanks, Gene, for the thoughts. (I only come back to town, and
> the internet two weekends per month, while trying to push the build
> along - insulating, then painting in Nov/Dec.)
>
> So far, the only strife at the farm is choking smoke when the wind's
> in the wrong direction - but that is also colouring New Zealand
> glaciers and making the sky grey in Chile, so it's pretty useless to
> bitch when I'm only 60 km from the western edge of the big patch (1.4
> million hectares (3.5 million acres¹) of fires around Mallacoota,
> Sarsfield, etc. (I am a bit stiff from putting in 150 m of 40 mm poly
> pipe for a fire main with hydrants at the building corners, and a
> demountable petrol driven fire pump, so it's harder to pinch. I've
> bought a Grundfos electric variable speed boost pump for domestic
> supply from 21,000 gallons of tanks (when they're filled - arrived
> yesterday, just _after_ we had over 100 mm of rain in 2 days, a third
> of what we had all last year, or the year before. The electric pump
> can be cranked up to 62m head, hopefully enough for standing off hours
> of ember attack prior to fire arrival. I'm adding a valve so it can
> feed the fire main instead of the house. A fire fighting pump must
> have continuous flow to keep it cool, which is not good with a finite
> water supply, but the electric one shuts down when you close off the
> nozzle on the fire hose. We'll see how it works out.)
>
> Even several weeks after the fire peak, the only way through on the
> only highway between the east of Victoria and the rest of the state is
> with the military in Bushmaster armoured cars, as the clearing of
> fallen and dangerous trees is ongoing. An escorted convoy was allowed
> out to the north, into New South Wales, then back via Canberra for
> those wanting back to Victoria - a helluva drive.
>
> Today we lost a 3-man retardant-bombing crew from USA when a C130 went
> in.

Ouch. My sympathies for the mens families. I'm reading of quite a few in 
the entertainment business here who have collectively donated quite a 
few millions to the firefighting efforts.  Probably just a drop in the 
bucket compared to whats needed though. 

> Quite a few firefighters have given their all and then some this 
> season, one when a fire tornado flipped an 8 tonne firetruck onto its
> roof. I think we have about a hundred really experienced American
> firefighters here to rotate with our strike team leaders and managers.

> The glorious rain didn't put the fires out, but it really reduces the
> rate of spread.
>
> Much of the burnt country is forest, but there's a lot of stock with
> nothing but charcoal and ash to eat, so there's a lot of stock feed
> going past our farm on the highway. I was in town on Saturday, and a
> convoy of 30 semitrailers loaded to the gunwales with hay went east,
> and at the petrol station they said another of 15 semitrailers had
> gone through earlier in the day. A few days before I met a convoy of
> 15 loads of donated hay. How much is going through the rest of the
> time?
I don't have a clue, but I don't imagine theres enough to keep it going 
for long enough to save all the stock.

> The rain makes the rest of us at a distance much safer. Heck, for the
> first time in a year, there's a foot of water in the bottom of the
> best dam on the property,

Not much in the grand scheme of things.

> and there's green grass shooting up all 
> over. If there's a bit of follow-up rain here and there, we could
> start farming again. (The only animals on the place are kangaroos,
> wallabies, and wombats, now. One of the latter started digging a 2
> foot diameter burrow in the soft sand of the fill pad under the new
> build. I've twice chased him across the paddock after midnight at 25
> km/h in the ute, with headlights on high beam and honking the horn. I
> didn't know they could run that fast on those stubby little legs.)
>
And I'm told you can't kill them for any reason.  Even if they are 
killing you.

> Erik
>
> ¹ Add in NSW and the other states, and the total is over 10 million
> hectares (25 million acres) nationally so far this season. Current
> estimates for the CO2 emissions is over 900 million tonnes. It's a
> climate disaster which doubles or triples our national emissions. (Not
> finished yet.)

We've had overlay maps published on the net here with the fire drawn to 
scale over the north american continent, which puts nearly 40% of our 
land mass under the areas of your fires. That gives us a very scary map 
of our climate future, and makes the Kalifornia fires look a backyard 
BBQ.

We've enough mature forest here in WV that we'd be gone in two weeks, 
burned to a crisp under those conditions.  And we've not had enough snow 
here, about an inch total so 

Re: [Emc-users] Erik Chrstiansen, the Aussie?

[Erik Christiansen]

On 18.01.20 00:08, Gene Heskett wrote:
> With all the fires down under, he hasn't posted since 12 October.
> 
> Wondering if he and his new place is ok?


Many thanks, Gene, for the thoughts. (I only come back to town, and the
internet two weekends per month, while trying to push the build along -
insulating, then painting in Nov/Dec.)

So far, the only strife at the farm is choking smoke when the wind's
in the wrong direction - but that is also colouring New Zealand glaciers
and making the sky grey in Chile, so it's pretty useless to bitch when
I'm only 60 km from the western edge of the big patch (1.4 million
hectares (3.5 million acres¹) of fires around Mallacoota, Sarsfield, etc.
(I am a bit stiff from putting in 150 m of 40 mm poly pipe for a fire
main with hydrants at the building corners, and a demountable petrol
driven fire pump, so it's harder to pinch. I've bought a Grundfos
electric variable speed boost pump for domestic supply from 21,000
gallons of tanks (when they're filled - arrived yesterday, just _after_
we had over 100 mm of rain in 2 days, a third of what we had all last
year, or the year before. The electric pump can be cranked up to 62m
head, hopefully enough for standing off hours of ember attack prior to
fire arrival. I'm adding a valve so it can feed the fire main instead of
the house. A fire fighting pump must have continuous flow to keep it
cool, which is not good with a finite water supply, but the electric one
shuts down when you close off the nozzle on the fire hose. We'll see how
it works out.)

Even several weeks after the fire peak, the only way through on the only
highway between the east of Victoria and the rest of the state is with
the military in Bushmaster armoured cars, as the clearing of fallen and
dangerous trees is ongoing. An escorted convoy was allowed out to the
north, into New South Wales, then back via Canberra for those wanting
back to Victoria - a helluva drive.

Today we lost a 3-man retardant-bombing crew from USA when a C130 went in.
Quite a few firefighters have given their all and then some this season,
one when a fire tornado flipped an 8 tonne firetruck onto its roof.
I think we have about a hundred really experienced American firefighters
here to rotate with our strike team leaders and managers.

The glorious rain didn't put the fires out, but it really reduces the
rate of spread.

Much of the burnt country is forest, but there's a lot of stock with
nothing but charcoal and ash to eat, so there's a lot of stock feed
going past our farm on the highway. I was in town on Saturday, and a
convoy of 30 semitrailers loaded to the gunwales with hay went east, and
at the petrol station they said another of 15 semitrailers had gone through
earlier in the day. A few days before I met a convoy of 15 loads of
donated hay. How much is going through the rest of the time?

The rain makes the rest of us at a distance much safer. Heck, for the
first time in a year, there's a foot of water in the bottom of the best
dam on the property, and there's green grass shooting up all over. If
there's a bit of follow-up rain here and there, we could start farming
again. (The only animals on the place are kangaroos, wallabies, and
wombats, now. One of the latter started digging a 2 foot diameter burrow in
the soft sand of the fill pad under the new build. I've twice chased him
across the paddock after midnight at 25 km/h in the ute, with headlights
on high beam and honking the horn. I didn't know they could run that
fast on those stubby little legs.)

Erik

¹ Add in NSW and the other states, and the total is over 10 million
hectares (25 million acres) nationally so far this season. Current
estimates for the CO2 emissions is over 900 million tonnes. It's a
climate disaster which doubles or triples our national emissions. (Not
finished yet.)


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

Re: [Emc-users] Real-time OS for machine controllers

[Gene Heskett]

On Friday 24 January 2020 00:45:17 John Dammeyer wrote:

> Comments between.
>
> > -Original Message-
> > From: bari [mailto:bari00...@gmail.com]
> > The guy down the hall from me has been keeping RTAI alive for LCNC
> > the past few years. I'm not sure if real time performance would be
> > much better using QNX vs Linux + RTAI on a PC.
>
> I think one first has to define exactly what needs to be real time.  I
> doubt QNX is free.
>
> > http://blackberry.qnx.com/en/software-solutions/embedded-
> > software/industrial/qnx-nuetrino-rtos
> >
> > There would be trade-offs on hardware support to port LCNC to QNX,
> > especially when it comes to GPU acceleration. RTAI and preempt_rt
> > perform pretty well on many low cost PC's with base threads down in
> > the few microseconds range for software stepping.
>
> One of the reasons to use Linux or Windows is that as the motherboards
> (CPUs) change from one core to 2 cores to 8 cores to 1 core with two
> peripheral processors etc. the basic work to make the system has been
> done.  When you plug in that USB WiFi dongle it's usually possible to
> find a driver.  Same with a parallel port card or camera card or a
> second Ethernet card
>
> If you are using Ethernet and UDP then it's a launch and forget method
> on a private Ethernet.  Or if TCP/IP then reliable ordered messaging. 
> So the workhorse for screen and outside world communications is there.
>
> > Going with a motion controller where the real time control is closer
> > to the motors give us what? I still need a GUI on some display at
> > least 12" across. A smartphone display might be OK for a CNC glue
> > gun but not to control my 2 ton+ VMC or lathe.
>
> And there's the rub.  In the past, connecting all the
> encoder/resolvers and motor input into a PCI card and having the PC do
> all the work made sense.  Especially since the only other option was
> an 8 or maybe 16 bit processor that used EPROMs.  (I'm talking 1990's
> here).
>
> > The ~$2 STM32 boards gives you an ARM processor with unprotected IO.
> > You need many more parts around that to buffer, level shift and ESD
> > suppress.
>
> This will be true for anything regardless of where the I/O begins. 
> Note the MESA cards have buffers.

Not all, the 7i90 being a rather glaring exception, it's cheap for it 
capabilities but needs another $135 in 7i42TA's to protect it. I suspect 
that any of the Mesa cards that output via 50 pin scsi connectors have 
similar restrictions.

> The Xylotex Cape for the Beagle has 
> buffers.  The question to ask or answer is where do you want that to
> be.  At one point it was on the PC motherboard and came out as a
> DB-25.  Thousands of machines still run with that interface.  At the
> moment mine does.
>
> I really don't know what is going on under the covers for either the
> MESA Ethernet 7i92H or the Ethernet Smooth Stepper for MACH.  But
> considering the power of the processors running machines back in the
> 90's or early 2000's and that the mechanics for the metal cutting
> haven't changed much,  my guess is that some 32 bit processor _not_
> running Linux so that the graphics/USB/etc. doesn't cripple the real
> time behaviour will be the solution.
>
> For example a PIC32 with USB (for firmware upgrades) and Ethernet (for
> Control) along with a CAN bus (CANopen control of non-real time
> peripherals) and the Free RTOS could be the building block. The
> software on the PC written in say Lazarus (Object Pascal, write once,
> compile anywhere) which is available free with graphical capabilities
> on machine for Linux (PCs and Pi and Beaglebone) , Windows and MACs.
>
> This approach doesn't get mentioned.  A small 32 bit processor like
> this could even have a small LCD display with a few buttons for basic
> machine operation.  Enough to move axis, turn on/off spindle etc. 
> Simple switch with local/remote mode.  I look at the world this way
> because that's the type of stuff I've been designing and writing
> software for over the last 25 years or so.
>
> If I understand the Hardware Abstraction Layer correctly this is, in
> effect, already being done on the LinuxCNC PC.  But when I run the
> stress test on my PC the machine has some pretty long latencies.  But
> it's not needed.
>
> IMHO
> John Dammeyer
>
> > On 1/23/20 12:17 PM, Chris Albertson wrote:
> > > The trouble with the Mesa FPGA design is that it depends on a
> > > computer
> >
> > with
> >
> > > good real-time performance.   It can generate steps but I don't
> > > thing you can run a position or velocity PID control loop on the
> > > FPGA.
> > >
> > > You asked about "my controler".  No this is not my idea, this is
> > > how most current designs work today.  You "push" the real-time
> > > control down stram
> >
> > as
> >
> > > close to the physical motor as possible. In the old days
> > > computers where expensive and you wanted to minimize their number
> > > but tocay a 32-
> >
> > bit
> >
> > > computer with floating point math, RAM 

Re: [Emc-users] Backlash compensation monitoring

[Gene Heskett]

On Friday 24 January 2020 00:07:07 David Berndt wrote:

> Hello All,
>
> I'm having a bit of an issue with some geometry not coming out as
> expected. I suspect it's related to backlash and cutting forces moving
> the table a bit but I don't have linear scales to monitor/correct for
> that sort of thing so I'm left wondering a bit. I was hoping that
> being able to see what backlash comp is doing on screen as my
> toolpaths run might enlighten me some. Is there any pin or ?? that can
> be monitored to give me more insight?
>
cutting forces vs backlash compensation are not a problem when digging 
cutting as the cutting farces are against the direction of travel, so 
backlash compensation always follows the direction. So when calibrating 
the scales, always do that with dig cutting.

Cutting tools OTOH, generally cut better and last longer when the bit is 
chopping down into fresh cut as it engages the metal approaching, but 
this means the cutting force may pull the table ahead, to the other side 
of the backlash. 

if the backlash is substantial then you will have errors. Generally I try 
to keep my own machinery at less than .002" for backlash compensation. 
That will often involve tearing down the thrust bearings which are the 
major source of that slop and adding some Reynolds wrap in the assembly 
to add just enough preload to get effectively zero backlash from that 
source. I bought a cheap C7 grade screw for z on the Sheldon, and wound 
up shimming almost 7 thou out of its thrust bearing.

Thats what you get for buying a C7 grade 25mm Diameter. Chinese screw 
1450mm long for under 200 dollars.  And they are even cheaper today. I 
also put bellows over it to keep the swarf out of it so it s/b good for 
a long time. I also sealed up both above and below the bare x screw for 
the same reason. Yes, I am using z derived screw compensation, but its 
cross coupled to move the x, compensating for bed wear in a 70 yo lathe. 
Works well.

> Thanks,
> -Dave
>
>
> ___
> 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 


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