Re: [Emc-developers] LinuxCNC is in Debian!

[Jérémie Tarot]

Le mar. 1 mars 2022 à 18:17, andy pugh  a écrit :

>
> I am generally in favour of anything that makes LinuxCNC easier to use
> and more broadly applicable.
> So, I support bundling-in EtherCAT support, as long as we can be sure
> that nobody will be pointing their lawyers in our direction.
>


1000%

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

Re: [Emc-developers] LinuxCNC is in Debian!

[Jérémie Tarot]

Le mar. 1 mars 2022 à 02:31, Chad Woitas  a
écrit :

>
> Exploring a few other options as well for Ethercat.
>


What about those Raspberry Pi EtherCAT HAT and Arduino EtherCAT shields?

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

Re: [Emc-developers] LinuxCNC is in Debian!

[Michael Graichen]

Hey Marc,

Be carefull with this. This code is running in Userspace while etherlabs 
ethercat stack is running as Kernelmodule.

Ethernet Packets in Linux are transfered to the Userspace over a mechanism 
called "Soft IRQ".
This will mess up any Realtime dependency especally on little ARMs like 
Raspberry etc if we want to do something, lets say, every millisecond.

See this link and others on the blog for details about the Linux Network Stack.

https://blog.packagecloud.io/illustrated-guide-monitoring-tuning-linux-networking-stack-receiving-data/

The network stack in Linux is realy not meant to be "realtime". There some 
other mechanisms like "packet collecting" or "pause" on heavy load because all 
was developed to defend "the server" against DOS attacks in the early days not 
for "realtime".

Beckhof actually wrote a special driver for one of there PCs that is using a 
polling mechanism to work around all those DOS defend mechanisms.

https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/ec_bhf.c

I also enjoy this conversation.

Best regards
Michael


 Ursprüngliche Nachricht 
Von: Marc Wang 
Datum: 01.03.22 17:57 (GMT+01:00)
An: EMC developers 
Betreff: Re: [Emc-developers] LinuxCNC is in Debian!

Hi,

FYI, I got interested in the conversation and ended up finding this repository 
on GitHub:

https://github.com/OpenEtherCATsociety/SOEM

The code for the master is released as a GNU General Public License version 2.

Regards,
Marc

-Original Message-
From: Rod Webster 
Sent: March 1, 2022 7:42 AM
To: EMC developers 
Subject: Re: [Emc-developers] LinuxCNC is in Debian!

> From my understanding Beckhoff is very open regarding the master (who
>even does not need a special hardware,  when driven by an RTOS) and are
>very restrictive when it comes to the slave (where a ASIC / FPGA is
>needed in any case)

This was also my understanding when I read the licensing requirements. Heck 
they said they would even share source code with you if you were building a 
master...
I have posted on the ethercat section of the forum calling for technical guys 
to get this done 
https://forum.linuxcnc.org/ethercat/45239-lets-get-ethercat-into-the-linuxcnc-distribution-need-technical-people-to-help

Please send me an email at ether...@vmn.com.au if you can help with the tech 
stuff.

Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au<http://www.vehiclemods.net.au>


On Tue, 1 Mar 2022 at 21:12, Rainer Stelzer 
wrote:

> Hi Gene,
> > So once you've bought the controller, there is no other restriction.
> > And I assume that royalty is 2x per axis, once for each end of the cable.
>
> No, they don't charge twice.
> Part of marketing a Fieldbus-System is to make it widely accepted in
> the industry, so Beckhoff (and others like Siemens with Profinet)
> has/have to find a balance between protection and  easy/low cost
> accessibility.
>
>  From my understanding Beckhoff is very open regarding the master (who
> even does not need a special hardware, when driven by an RTOS) and are
> very restrictive when it comes to the slave (where a ASIC / FPGA is
> needed in any case)
>
> Makes also sense from commercial point of view, because in a typical
> system there are much more slaves needed that masters.
>
> > Or can one receiver handle more than 1 axis with acceptable latency?
>
> A slave in EtherCat's daisy chain topology has an input and an output
> Interface. (the biggest difference to most other ethernet based
> fieldbusses)
>
> The incoming stream is shifted out with 1 bit delay to the output.
>
> At 100Mbit/s -> 10ns delay added up to each slave in the chain.
>
> The difference between one slave 3axis servo pack and three single
> axis servo amps is ~20ns.
> But to synchronise the output, all slaves have to wait for the full
> frame received.
>
> Even on a 10 axis system this does not even come close to the total
> frame time.
> Not to mention the jitter caused by a (soft)RTOS
>
>
> cheers
>
> Rainer
>
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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


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

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

Re: [Emc-developers] LinuxCNC is in Debian!

[andy pugh]

On Tue, 1 Mar 2022 at 13:56, Steffen Möller  wrote:

> *My personal anchors to the community are Seb, Jeff and Andy. I suggest
> that Rod sends whatever we come up with (if we come up with anything)
> directly, but I would like to first have a positive vote by one of them
> and "don't care"s or better from them and everyone else here on the list.*

I am generally in favour of anything that makes LinuxCNC easier to use
and more broadly applicable.
So, I support bundling-in EtherCAT support, as long as we can be sure
that nobody will be pointing their lawyers in our direction.

However, one worry that we had in the past was that, whilst this
organisation might be inside the Beckhoff "rules" if we join ETG,
doing so might accidentally impose an unexpected (by them) licensing
condition or restriction on our users.
I don't know how real a worry that is.

-- 
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-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC is in Debian!

[Marc Wang]

Hi, 

FYI, I got interested in the conversation and ended up finding this repository 
on GitHub:

https://github.com/OpenEtherCATsociety/SOEM

The code for the master is released as a GNU General Public License version 2. 

Regards,
Marc

-Original Message-
From: Rod Webster  
Sent: March 1, 2022 7:42 AM
To: EMC developers 
Subject: Re: [Emc-developers] LinuxCNC is in Debian!

> From my understanding Beckhoff is very open regarding the master (who  
>even does not need a special hardware,  when driven by an RTOS) and are 
>very restrictive when it comes to the slave (where a ASIC / FPGA is 
>needed in any case)

This was also my understanding when I read the licensing requirements. Heck 
they said they would even share source code with you if you were building a 
master...
I have posted on the ethercat section of the forum calling for technical guys 
to get this done 
https://forum.linuxcnc.org/ethercat/45239-lets-get-ethercat-into-the-linuxcnc-distribution-need-technical-people-to-help

Please send me an email at ether...@vmn.com.au if you can help with the tech 
stuff.

Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au


On Tue, 1 Mar 2022 at 21:12, Rainer Stelzer 
wrote:

> Hi Gene,
> > So once you've bought the controller, there is no other restriction. 
> > And I assume that royalty is 2x per axis, once for each end of the cable.
>
> No, they don't charge twice.
> Part of marketing a Fieldbus-System is to make it widely accepted in 
> the industry, so Beckhoff (and others like Siemens with Profinet) 
> has/have to find a balance between protection and  easy/low cost 
> accessibility.
>
>  From my understanding Beckhoff is very open regarding the master (who 
> even does not need a special hardware, when driven by an RTOS) and are 
> very restrictive when it comes to the slave (where a ASIC / FPGA is 
> needed in any case)
>
> Makes also sense from commercial point of view, because in a typical 
> system there are much more slaves needed that masters.
>
> > Or can one receiver handle more than 1 axis with acceptable latency?
>
> A slave in EtherCat's daisy chain topology has an input and an output 
> Interface. (the biggest difference to most other ethernet based
> fieldbusses)
>
> The incoming stream is shifted out with 1 bit delay to the output.
>
> At 100Mbit/s -> 10ns delay added up to each slave in the chain.
>
> The difference between one slave 3axis servo pack and three single 
> axis servo amps is ~20ns.
> But to synchronise the output, all slaves have to wait for the full 
> frame received.
>
> Even on a 10 axis system this does not even come close to the total 
> frame time.
> Not to mention the jitter caused by a (soft)RTOS
>
>
> cheers
>
> Rainer
>
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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


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

Re: [Emc-developers] LinuxCNC is in Debian!

[Rod Webster]

> From my understanding Beckhoff is very open regarding the master (who
> even does not need a special hardware,
> when driven by an RTOS) and are very restrictive when it comes to the
>slave (where a ASIC / FPGA is needed in any case)

This was also my understanding when I read the licensing requirements. Heck
they said they would even share source code with you if you were building a
master...
I have posted on the ethercat section of the forum calling for technical
guys to get this done
https://forum.linuxcnc.org/ethercat/45239-lets-get-ethercat-into-the-linuxcnc-distribution-need-technical-people-to-help

Please send me an email at ether...@vmn.com.au if you can help with the
tech stuff.

Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au


On Tue, 1 Mar 2022 at 21:12, Rainer Stelzer 
wrote:

> Hi Gene,
> > So once you've bought the controller, there is no other restriction. And
> > I assume that royalty is 2x per axis, once for each end of the cable.
>
> No, they don't charge twice.
> Part of marketing a Fieldbus-System is to make it widely accepted in the
> industry, so Beckhoff
> (and others like Siemens with Profinet) has/have to find a balance
> between protection and  easy/low cost accessibility.
>
>  From my understanding Beckhoff is very open regarding the master (who
> even does not need a special hardware,
> when driven by an RTOS) and are very restrictive when it comes to the
> slave (where a ASIC / FPGA is needed in any case)
>
> Makes also sense from commercial point of view, because in a typical
> system there are much more slaves needed that masters.
>
> > Or can one receiver handle more than 1 axis with acceptable latency?
>
> A slave in EtherCat's daisy chain topology has an input and an output
> Interface. (the biggest difference to most other ethernet based
> fieldbusses)
>
> The incoming stream is shifted out with 1 bit delay to the output.
>
> At 100Mbit/s -> 10ns delay added up to each slave in the chain.
>
> The difference between one slave 3axis servo pack and three single axis
> servo amps is ~20ns.
> But to synchronise the output, all slaves have to wait for the full
> frame received.
>
> Even on a 10 axis system this does not even come close to the total
> frame time.
> Not to mention the jitter caused by a (soft)RTOS
>
>
> cheers
>
> Rainer
>
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

On 01.03.22 10:59, Les Newell wrote:



So once you've bought the controller, there is no other restriction.


As far as I can tell from their docs, that is the case. It's a pretty
sound business model.


I assume that royalty is 2x per axis, once for each end of the cable.


From what I can tell, it would be one royalty per axis. Daisy chaining
is part of the hardware spec.



The industry pays such patent taxes to microsoft/google/... about
everywhere. I am relaxed about that since all we want to have is an open
source access to use these devices. Here an idea for the three lines,
now asking for membership as the operational action to allow us to
redistribute whatever Open Source drivers there are through whatever
channel. I am starting with an introduction since my two contacts did
not know who we are and it is somewhat polite :)

I started some text on
https://docs.google.com/document/d/1LFtgxDwE2tQRFjFGu_AAlBCuqBEoW6CaXoSWiaJrFkM/edit?usp=sharing
. Send me an email address that Google is allowed to see for direct
editing (only comments via the link). Here what I came up with so far:

*

Sehr geehrte Damen und Herren, [their office is in Germany, I prefer
this over Dear Madam/SIr or To whom this may concern, but direct me]

We contact you in the name of the LinuxCNC community to investigate how
we could integrate public EtherCAT drivers with our software
infrastructure. We are a 20+ years Open Source project to control CNC
machines that has found frequent adoptions also to control a diverse set
of robots up to 9 axes. LinuxCNC interprets G-code and some like to
program their hardware directly with it. Please find use cases and our
documentation on https://linuxcnc.org or YouTube.

Since Open Source, and with a nice hardware abstraction layer, LinuxCNC
is commonly used by enthusiasts with access to machines from the late
1900s to retrofit these with modern technology. And others take modern
parts home to explain their dayjob to their kids or to edutain
themselves as a hobby. That spirit prevails to bring LinuxCNC to
whatever is existing, and extend LinuxCNC when it encounters something new.

A few days ago, LinuxCNC became a regular package of Debian Linux and
will soon also be on Ubuntu. Works on Fedora (the free companion to
RedHat) are on their way. No hardware projects are performed within
LinuxCNC, but we would like to be complete when it comes to software
compatibility, just like you expect Linux to run everywhere. Upstream we
look at CAD/CAM, and downstream, it is the communication from the Linux
machine to the servos and steppers, that is you.

We understand that EtherCAT has a “GPL-2 if you OKed it and make us an
ETG-member”-license, which we do not understand and did not find more
information about. As a community, we decided not to preoccupy ourselves
with the legal details, we are all techies after all, if you could give
us such a membership-carte-blanche to create, modify and redistribute
EtherCAT drivers directly via our website and/or via Linux Distributions
(Fedora, Debian, OpenSuSE and its derivative distributions). All our
developments/modifications will be Open Source and once available via
regular Linux distributions this will lower the setup costs for your
existing and new members.

We have a technical coordinator of this effort with access to a series
of EtherCAT devices

and these developers who feel associated with the project

, … , 

who agreed that you may contact them. If there are other members in the
ETG with an interest in combining LinuxCNC with EtherCAT then we would
very much like to get in touch with them.

*

*Looking forward to a fruitful collaboration*

*Rod in the name of the LinuxCNC community
*

*
*

*My personal anchors to the community are Seb, Jeff and Andy. I suggest
that Rod sends whatever we come up with (if we come up with anything)
directly, but I would like to first have a positive vote by one of them
and "don't care"s or better from them and everyone else here on the list.*

*Best,
Steffen
*

*
*


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

Re: [Emc-developers] LinuxCNC is in Debian!

[gene heskett]

On Tuesday, March 1, 2022 5:29:51 AM EST Rainer Stelzer wrote:
> Hi Gene,
> 
> > So once you've bought the controller, there is no other restriction.
> > And I assume that royalty is 2x per axis, once for each end of the
> > cable.
> No, they don't charge twice.
> Part of marketing a Fieldbus-System is to make it widely accepted in
> the industry, so Beckhoff
> (and others like Siemens with Profinet) has/have to find a balance
> between protection and  easy/low cost accessibility.
> 
>  From my understanding Beckhoff is very open regarding the master (who
> even does not need a special hardware,
> when driven by an RTOS) and are very restrictive when it comes to the
> slave (where a ASIC / FPGA is needed in any case)
> 
> Makes also sense from commercial point of view, because in a typical
> system there are much more slaves needed that masters.
> 
> > Or can one receiver handle more than 1 axis with acceptable latency?
> 
> A slave in EtherCat's daisy chain topology has an input and an output
> Interface. (the biggest difference to most other ethernet based
> fieldbusses)
> 
> The incoming stream is shifted out with 1 bit delay to the output.
> 
> At 100Mbit/s -> 10ns delay added up to each slave in the chain.
> 
> The difference between one slave 3axis servo pack and three single axis
> servo amps is ~20ns.
> But to synchronise the output, all slaves have to wait for the full
> frame received.
> 
> Even on a 10 axis system this does not even come close to the total
> frame time.
> Not to mention the jitter caused by a (soft)RTOS
> 
Which is usually much higher than that. 20ns doesn't even register on my 
rpi4 with its 12 u-secs of jitter. And that runs my 11x54 Sheldon like 
Casper the ghost with its new 3 phase stepper/servo's. Its eirie watching 
it move dead silently at normal cutting speeds.

> cheers
> 
> Rainer
 
Thanks Rainer.

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





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

Re: [Emc-developers] LinuxCNC is in Debian!

[Rainer Stelzer]

Hi Gene,

So once you've bought the controller, there is no other restriction. And
I assume that royalty is 2x per axis, once for each end of the cable.


No, they don't charge twice.
Part of marketing a Fieldbus-System is to make it widely accepted in the 
industry, so Beckhoff
(and others like Siemens with Profinet) has/have to find a balance 
between protection and  easy/low cost accessibility.


From my understanding Beckhoff is very open regarding the master (who 
even does not need a special hardware,
when driven by an RTOS) and are very restrictive when it comes to the 
slave (where a ASIC / FPGA is needed in any case)


Makes also sense from commercial point of view, because in a typical 
system there are much more slaves needed that masters.



Or can one receiver handle more than 1 axis with acceptable latency?


A slave in EtherCat's daisy chain topology has an input and an output 
Interface. (the biggest difference to most other ethernet based fieldbusses)


The incoming stream is shifted out with 1 bit delay to the output.

At 100Mbit/s -> 10ns delay added up to each slave in the chain.

The difference between one slave 3axis servo pack and three single axis 
servo amps is ~20ns.
But to synchronise the output, all slaves have to wait for the full 
frame received.


Even on a 10 axis system this does not even come close to the total 
frame time.

Not to mention the jitter caused by a (soft)RTOS


cheers

Rainer




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

Re: [Emc-developers] LinuxCNC is in Debian!

[Les Newell]

So once you've bought the controller, there is no other restriction.


As far as I can tell from their docs, that is the case. It's a pretty 
sound business model.



I assume that royalty is 2x per axis, once for each end of the cable.


From what I can tell, it would be one royalty per axis. Daisy chaining 
is part of the hardware spec.



That no doubt makes the cheese more binding.  Or can one receiver handle
more than 1 axis with acceptable latency?


At the end of the day it's just a communications protocol. What you send 
down it is up to you. Ethernet has a pretty high bandwidth so you can 
stuff quite a lot down there before latency becomes an issue.


Les



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

Re: [Emc-developers] LinuxCNC is in Debian!

[gene heskett]

On Tuesday, March 1, 2022 4:27:21 AM EST Les Newell wrote:
> > I was not specificaly seeking the monetary cost, more the loss of
> > rights, which could be far more costly than the monetary cost. As
> > always, keep TANSTAAFL in mind.
> 
> As far as Beckhoff are concerned this isn't a free lunch. Similar to
> Mesa they make their money on the hardware. Supporting the software is
> simply a cost of doing business.
> 
> Obviously they sell their own hardware but they also charge a royalty
> fee for every Ethercat slave device manufactured. For instance
> Microchip sell Ethercat device controllers. For each controller chip
> they sell, they pay a royalty to Beckhoff.
> 
> Les

So once you've bought the controller, there is no other restriction.  And 
I assume that royalty is 2x per axis, once for each end of the cable. 
That no doubt makes the cheese more binding.  Or can one receiver handle 
more than 1 axis with acceptable latency?

Thanks Les, take care & stay well.

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





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

Re: [Emc-developers] LinuxCNC is in Debian!

[Les Newell]

I was not specificaly seeking the monetary cost, more the loss of rights,
which could be far more costly than the monetary cost. As always, keep
TANSTAAFL in mind.


As far as Beckhoff are concerned this isn't a free lunch. Similar to 
Mesa they make their money on the hardware. Supporting the software is 
simply a cost of doing business.


Obviously they sell their own hardware but they also charge a royalty 
fee for every Ethercat slave device manufactured. For instance Microchip 
sell Ethercat device controllers. For each controller chip they sell, 
they pay a royalty to Beckhoff.


Les



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

Re: [Emc-developers] LinuxCNC is in Debian!

[Rod Webster]

Well there is another thread  dealing with the admin side so keep
the chatter here :)
Yes Rtelligent have  both open loop ECR series and closed loop ECT series
drives. Dominik's CIA402 component is effective here.
The ECT series seems quite solid, Their NEMA24 motor offers amazing
performance based on our stepper motor model but I have not tried one for
real.
It should keep up with small Nema 34's

Intelligent also have the ECR1616 I/O slave and its working well for me.
Rtelligent's products are very well documented in English
There are a number of other Chinese I/O modules available. I have one with
an Encoder input coming. Wish me luck!

I was unable to get Sittner's repo working on Debian 11 (Bullseye) but it
was flawless on Debian 10. I think it was a Etherlabmaster issue.
I was able to install Etherlabmaster on Bullseye using a .deb file another
member  provided. This bypassed  the need for Stttner's repo.
So there is a little bit of work to get this operational on Debian
11/12/unstable

Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au


On Tue, 1 Mar 2022 at 11:29, Chad Woitas 
wrote:

> Well, this is already off topic:
>
> For the hobbyists: These seem promising
> http://www.rtelligent.net/ECR60.html
>
>
> For the Commerical Applications:
> Sittners repo works well with Bosch/Beckhoff/SMC, there hasn't been any
> updates in almost a year but a few MR's are up.
>
> Beckhoff will recommend a PLC/Safety PLC control talking to linuxcnc
> through a bridge.
> This seems to works albeit a 15-20 ms latency from command to movement.
>
>
> Exploring a few other options as well for Ethercat.
>
>
> 
> From: Bernt Hustad Hembre 
> Sent: February 28, 2022 2:40 PM
> To: EMC developers 
> Subject: Re: [Emc-developers] LinuxCNC is in Debian!
>
> Hi all,
>
> I have not used EtherCAT equipment  with LinuxCNC. But I’ve used a Beckhoff
> PLC running TC/BSD and TwinCAT. Controlling a whole lot of servomotors.
>
> The equipment from Beckhoff is priced quite a bit over the hobbyist budget.
> But is well worth the money for commercial application. And the wide range
> of controllers and I/O modules makes it a good choice for any CNC machine.
>
> The modules I’ve used clicks together on a DIN rail. They have a buildt in
> bus for etherCAT, 24V and 5V for the electronics. This keeps the need for
> additional wiring to a minimum.
>
> I would love to upgrade one of my machines to Beckhoff control systems, but
> it is to expencive for my budget. I could borrow some unused equipment from
> work to test it out though. That would be fun to try.
>
> Beckhoff love to brag about their eqipment on LinkedIn etc. I guess an
> article about LinuxCNCs support for Beckhoff hardware could both «buy» us
> good support from Beckhoff, and possible get some more comercial activity
> with LinuxCNC. I think we all could benefit from that.
>
>
> Cheers!
> Bernie
>
> man. 28. feb. 2022 kl. 20:34 skrev gene heskett :
>
> > On Monday, February 28, 2022 2:03:30 PM EST Steffen Möller wrote:
> > > On 28.02.22 19:44, gene heskett wrote:
> > > > On Monday, February 28, 2022 12:53:21 PM EST Steffen Möller wrote:
> > > >> On 28.02.22 18:40, gene heskett wrote:
> > > >>> On Monday, February 28, 2022 8:28:36 AM EST andy pugh wrote:
> > > >>>> On Mon, 28 Feb 2022 at 13:22, Steffen
> > > >>>> Möller
> > > >>>
> > > >>> wrote:
> > > >>>>>> ie, "rtapi" is relevant to uspace and rt builds.
> > > >>>>>
> > > >>>>> Can you guide me (or someone else surfacing) towards what would
> > > >>>>> be
> > > >>>>> required to have LinuxCNC readily compatible with that external
> > > >>>>> EtherCAT package on Debian?
> > > >>>>
> > > >>>> Personally I know nothing about EtherCAT. I have always been a
> > > >>>> little
> > > >>>> afraid of the licensing complexities mentioned here:
> > > >>>>
> > > >>>> https://etherlab.org/en/ethercat/
> > > >>>>
> > > >>>> Etherlab itself is GPLv2, but _using_ it seems to bring a
> > > >>>> different
> > > >>>> licensing restriction into play. And I don't know enough about
> > > >>>> licensing to know if that's a problem.
> > > >>>
> > > >>> I followed this link, and couldn't find an obvious link to the
> > > >>> licensing docs. Am I going bli

Re: [Emc-developers] LinuxCNC is in Debian!

[Chad Woitas]

Well, this is already off topic:

For the hobbyists: These seem promising http://www.rtelligent.net/ECR60.html


For the Commerical Applications:
Sittners repo works well with Bosch/Beckhoff/SMC, there hasn't been any updates 
in almost a year but a few MR's are up.

Beckhoff will recommend a PLC/Safety PLC control talking to linuxcnc through a 
bridge.
This seems to works albeit a 15-20 ms latency from command to movement.


Exploring a few other options as well for Ethercat.



From: Bernt Hustad Hembre 
Sent: February 28, 2022 2:40 PM
To: EMC developers 
Subject: Re: [Emc-developers] LinuxCNC is in Debian!

Hi all,

I have not used EtherCAT equipment  with LinuxCNC. But I’ve used a Beckhoff
PLC running TC/BSD and TwinCAT. Controlling a whole lot of servomotors.

The equipment from Beckhoff is priced quite a bit over the hobbyist budget.
But is well worth the money for commercial application. And the wide range
of controllers and I/O modules makes it a good choice for any CNC machine.

The modules I’ve used clicks together on a DIN rail. They have a buildt in
bus for etherCAT, 24V and 5V for the electronics. This keeps the need for
additional wiring to a minimum.

I would love to upgrade one of my machines to Beckhoff control systems, but
it is to expencive for my budget. I could borrow some unused equipment from
work to test it out though. That would be fun to try.

Beckhoff love to brag about their eqipment on LinkedIn etc. I guess an
article about LinuxCNCs support for Beckhoff hardware could both «buy» us
good support from Beckhoff, and possible get some more comercial activity
with LinuxCNC. I think we all could benefit from that.


Cheers!
Bernie

man. 28. feb. 2022 kl. 20:34 skrev gene heskett :

> On Monday, February 28, 2022 2:03:30 PM EST Steffen Möller wrote:
> > On 28.02.22 19:44, gene heskett wrote:
> > > On Monday, February 28, 2022 12:53:21 PM EST Steffen Möller wrote:
> > >> On 28.02.22 18:40, gene heskett wrote:
> > >>> On Monday, February 28, 2022 8:28:36 AM EST andy pugh wrote:
> > >>>> On Mon, 28 Feb 2022 at 13:22, Steffen
> > >>>> Möller
> > >>>
> > >>> wrote:
> > >>>>>> ie, "rtapi" is relevant to uspace and rt builds.
> > >>>>>
> > >>>>> Can you guide me (or someone else surfacing) towards what would
> > >>>>> be
> > >>>>> required to have LinuxCNC readily compatible with that external
> > >>>>> EtherCAT package on Debian?
> > >>>>
> > >>>> Personally I know nothing about EtherCAT. I have always been a
> > >>>> little
> > >>>> afraid of the licensing complexities mentioned here:
> > >>>>
> > >>>> https://etherlab.org/en/ethercat/
> > >>>>
> > >>>> Etherlab itself is GPLv2, but _using_ it seems to bring a
> > >>>> different
> > >>>> licensing restriction into play. And I don't know enough about
> > >>>> licensing to know if that's a problem.
> > >>>
> > >>> I followed this link, and couldn't find an obvious link to the
> > >>> licensing docs. Am I going blind? Or are they acting like a
> > >>> submarine, ala the compuserve debacle from about 25 years back?
> > >>
> > >> It is in the "Notice" section below that copyright thingy:
> > >> The license above concerns the source code only. Using the EtherCAT
> > >> technology and brand is only permitted in compliance with the
> > >> industrial property and similar rights ofBeckhoff Automation GmbH
> > >> <http://beckhoff.com/>.
> > >>
> > >> Best,
> > >> Steffen
> > >
> > > Yes, I read that too, Steffen, but failed to find a statement
> > > describing those rights.
> >
> > They did not put anything there, I agree.
> >
> > > Thats precisely why I mentioned the GIF debacle. I'm a
> > > genuine old fart, my history starts in late 1934, with a good memory
> > > about such dishonest goings on. It took maybe 20 hours for gifs to
> > > disappear from the net, totally and completely then, and maybe a week
> > > to fine tune png and get the first version out the door. Where is
> > > compuserve today? A footnote in history at best, but not remembered
> > > with loving thoughts.  We invented the distastefull term "submarine
> > > patent" to describe what happened.
> > >
> > > I don't really want to be involved with an entity that references
> > 

Re: [Emc-developers] LinuxCNC is in Debian!

[Bernt Hustad Hembre]

Hi all,

I have not used EtherCAT equipment  with LinuxCNC. But I’ve used a Beckhoff
PLC running TC/BSD and TwinCAT. Controlling a whole lot of servomotors.

The equipment from Beckhoff is priced quite a bit over the hobbyist budget.
But is well worth the money for commercial application. And the wide range
of controllers and I/O modules makes it a good choice for any CNC machine.

The modules I’ve used clicks together on a DIN rail. They have a buildt in
bus for etherCAT, 24V and 5V for the electronics. This keeps the need for
additional wiring to a minimum.

I would love to upgrade one of my machines to Beckhoff control systems, but
it is to expencive for my budget. I could borrow some unused equipment from
work to test it out though. That would be fun to try.

Beckhoff love to brag about their eqipment on LinkedIn etc. I guess an
article about LinuxCNCs support for Beckhoff hardware could both «buy» us
good support from Beckhoff, and possible get some more comercial activity
with LinuxCNC. I think we all could benefit from that.


Cheers!
Bernie

man. 28. feb. 2022 kl. 20:34 skrev gene heskett :

> On Monday, February 28, 2022 2:03:30 PM EST Steffen Möller wrote:
> > On 28.02.22 19:44, gene heskett wrote:
> > > On Monday, February 28, 2022 12:53:21 PM EST Steffen Möller wrote:
> > >> On 28.02.22 18:40, gene heskett wrote:
> > >>> On Monday, February 28, 2022 8:28:36 AM EST andy pugh wrote:
> >  On Mon, 28 Feb 2022 at 13:22, Steffen
> >  Möller
> > >>>
> > >>> wrote:
> > >> ie, "rtapi" is relevant to uspace and rt builds.
> > >
> > > Can you guide me (or someone else surfacing) towards what would
> > > be
> > > required to have LinuxCNC readily compatible with that external
> > > EtherCAT package on Debian?
> > 
> >  Personally I know nothing about EtherCAT. I have always been a
> >  little
> >  afraid of the licensing complexities mentioned here:
> > 
> >  https://etherlab.org/en/ethercat/
> > 
> >  Etherlab itself is GPLv2, but _using_ it seems to bring a
> >  different
> >  licensing restriction into play. And I don't know enough about
> >  licensing to know if that's a problem.
> > >>>
> > >>> I followed this link, and couldn't find an obvious link to the
> > >>> licensing docs. Am I going blind? Or are they acting like a
> > >>> submarine, ala the compuserve debacle from about 25 years back?
> > >>
> > >> It is in the "Notice" section below that copyright thingy:
> > >> The license above concerns the source code only. Using the EtherCAT
> > >> technology and brand is only permitted in compliance with the
> > >> industrial property and similar rights ofBeckhoff Automation GmbH
> > >> .
> > >>
> > >> Best,
> > >> Steffen
> > >
> > > Yes, I read that too, Steffen, but failed to find a statement
> > > describing those rights.
> >
> > They did not put anything there, I agree.
> >
> > > Thats precisely why I mentioned the GIF debacle. I'm a
> > > genuine old fart, my history starts in late 1934, with a good memory
> > > about such dishonest goings on. It took maybe 20 hours for gifs to
> > > disappear from the net, totally and completely then, and maybe a week
> > > to fine tune png and get the first version out the door. Where is
> > > compuserve today? A footnote in history at best, but not remembered
> > > with loving thoughts.  We invented the distastefull term "submarine
> > > patent" to describe what happened.
> > >
> > > I don't really want to be involved with an entity that references
> > > additional rights, but doesn't make those readily available.
> > >
> > > Maybe I didn't look hard enough but I did look with the idea of
> > > learning what those additional rights might cost.
> >
> > Nothing, so I was assured.
> >
> I was not specificaly seeking the monetary cost, more the loss of rights,
> which could be far more costly than the monetary cost. As always, keep
> TANSTAAFL in mind.
>
> > I propose we describe what we want to do and then they either agree and
> > make LinuxCNC.org a member or they don't.
>
> That is likely the best idea at this time. If their gear is competitively
> priced it adds another src of good gear.
>
> OTOH, Peter has been very good to us and it doesn't bither me a bot to
> recommend mesa interfaces. Generally they Just Work which is more than I
> can say about others in the field.
>
> Take care Steffen.
>
> > Best,
> > Steffen
> >
> > >> ___
> > >> Emc-developers mailing list
> > >> Emc-developers@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> > >
> > > Cheers, Gene Heskett.
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
> Cheers, Gene Heskett.
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. 

Re: [Emc-developers] LinuxCNC is in Debian!

[gene heskett]

On Monday, February 28, 2022 2:03:30 PM EST Steffen Möller wrote:
> On 28.02.22 19:44, gene heskett wrote:
> > On Monday, February 28, 2022 12:53:21 PM EST Steffen Möller wrote:
> >> On 28.02.22 18:40, gene heskett wrote:
> >>> On Monday, February 28, 2022 8:28:36 AM EST andy pugh wrote:
>  On Mon, 28 Feb 2022 at 13:22, Steffen
>  Möller
> >>> 
> >>> wrote:
> >> ie, "rtapi" is relevant to uspace and rt builds.
> > 
> > Can you guide me (or someone else surfacing) towards what would
> > be
> > required to have LinuxCNC readily compatible with that external
> > EtherCAT package on Debian?
>  
>  Personally I know nothing about EtherCAT. I have always been a
>  little
>  afraid of the licensing complexities mentioned here:
>  
>  https://etherlab.org/en/ethercat/
>  
>  Etherlab itself is GPLv2, but _using_ it seems to bring a
>  different
>  licensing restriction into play. And I don't know enough about
>  licensing to know if that's a problem.
> >>> 
> >>> I followed this link, and couldn't find an obvious link to the
> >>> licensing docs. Am I going blind? Or are they acting like a
> >>> submarine, ala the compuserve debacle from about 25 years back?
> >> 
> >> It is in the "Notice" section below that copyright thingy:
> >> The license above concerns the source code only. Using the EtherCAT
> >> technology and brand is only permitted in compliance with the
> >> industrial property and similar rights ofBeckhoff Automation GmbH
> >> .
> >> 
> >> Best,
> >> Steffen
> > 
> > Yes, I read that too, Steffen, but failed to find a statement
> > describing those rights.
> 
> They did not put anything there, I agree.
> 
> > Thats precisely why I mentioned the GIF debacle. I'm a
> > genuine old fart, my history starts in late 1934, with a good memory
> > about such dishonest goings on. It took maybe 20 hours for gifs to
> > disappear from the net, totally and completely then, and maybe a week
> > to fine tune png and get the first version out the door. Where is
> > compuserve today? A footnote in history at best, but not remembered
> > with loving thoughts.  We invented the distastefull term "submarine
> > patent" to describe what happened.
> > 
> > I don't really want to be involved with an entity that references
> > additional rights, but doesn't make those readily available.
> > 
> > Maybe I didn't look hard enough but I did look with the idea of
> > learning what those additional rights might cost.
> 
> Nothing, so I was assured.
> 
I was not specificaly seeking the monetary cost, more the loss of rights, 
which could be far more costly than the monetary cost. As always, keep 
TANSTAAFL in mind.

> I propose we describe what we want to do and then they either agree and
> make LinuxCNC.org a member or they don't.

That is likely the best idea at this time. If their gear is competitively  
priced it adds another src of good gear.

OTOH, Peter has been very good to us and it doesn't bither me a bot to 
recommend mesa interfaces. Generally they Just Work which is more than I 
can say about others in the field.

Take care Steffen.

> Best,
> Steffen
> 
> >> ___
> >> Emc-developers mailing list
> >> Emc-developers@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> > 
> > Cheers, Gene Heskett.
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


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





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

Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

On 28.02.22 19:44, gene heskett wrote:

On Monday, February 28, 2022 12:53:21 PM EST Steffen Möller wrote:

On 28.02.22 18:40, gene heskett wrote:

On Monday, February 28, 2022 8:28:36 AM EST andy pugh wrote:

On Mon, 28 Feb 2022 at 13:22, Steffen Möller

wrote:

ie, "rtapi" is relevant to uspace and rt builds.

Can you guide me (or someone else surfacing) towards what would be
required to have LinuxCNC readily compatible with that external
EtherCAT package on Debian?

Personally I know nothing about EtherCAT. I have always been a
little
afraid of the licensing complexities mentioned here:

https://etherlab.org/en/ethercat/

Etherlab itself is GPLv2, but _using_ it seems to bring a different
licensing restriction into play. And I don't know enough about
licensing to know if that's a problem.

I followed this link, and couldn't find an obvious link to the
licensing docs. Am I going blind? Or are they acting like a
submarine, ala the compuserve debacle from about 25 years back?

It is in the "Notice" section below that copyright thingy:
The license above concerns the source code only. Using the EtherCAT
technology and brand is only permitted in compliance with the
industrial property and similar rights ofBeckhoff Automation GmbH
.

Best,
Steffen


Yes, I read that too, Steffen, but failed to find a statement describing
those rights.

They did not put anything there, I agree.

Thats precisely why I mentioned the GIF debacle. I'm a
genuine old fart, my history starts in late 1934, with a good memory
about such dishonest goings on. It took maybe 20 hours for gifs to
disappear from the net, totally and completely then, and maybe a week to
fine tune png and get the first version out the door. Where is compuserve
today? A footnote in history at best, but not remembered with loving
thoughts.  We invented the distastefull term "submarine patent" to
describe what happened.

I don't really want to be involved with an entity that references
additional rights, but doesn't make those readily available.

Maybe I didn't look hard enough but I did look with the idea of learning
what those additional rights might cost.


Nothing, so I was assured.

I propose we describe what we want to do and then they either agree and
make LinuxCNC.org a member or they don't.

Best,
Steffen



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


Cheers, Gene Heskett.



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

Re: [Emc-developers] LinuxCNC is in Debian!

[gene heskett]

On Monday, February 28, 2022 12:53:21 PM EST Steffen Möller wrote:
> On 28.02.22 18:40, gene heskett wrote:
> > On Monday, February 28, 2022 8:28:36 AM EST andy pugh wrote:
> >> On Mon, 28 Feb 2022 at 13:22, Steffen Möller
> > 
> > wrote:
>  ie, "rtapi" is relevant to uspace and rt builds.
> >>> 
> >>> Can you guide me (or someone else surfacing) towards what would be
> >>> required to have LinuxCNC readily compatible with that external
> >>> EtherCAT package on Debian?
> >> 
> >> Personally I know nothing about EtherCAT. I have always been a
> >> little
> >> afraid of the licensing complexities mentioned here:
> >> 
> >> https://etherlab.org/en/ethercat/
> >> 
> >> Etherlab itself is GPLv2, but _using_ it seems to bring a different
> >> licensing restriction into play. And I don't know enough about
> >> licensing to know if that's a problem.
> > 
> > I followed this link, and couldn't find an obvious link to the
> > licensing docs. Am I going blind? Or are they acting like a
> > submarine, ala the compuserve debacle from about 25 years back?
> 
> It is in the "Notice" section below that copyright thingy:
> The license above concerns the source code only. Using the EtherCAT
> technology and brand is only permitted in compliance with the
> industrial property and similar rights ofBeckhoff Automation GmbH
> .
> 
> Best,
> Steffen
> 
Yes, I read that too, Steffen, but failed to find a statement describing 
those rights. Thats precisely why I mentioned the GIF debacle. I'm a 
genuine old fart, my history starts in late 1934, with a good memory 
about such dishonest goings on. It took maybe 20 hours for gifs to 
disappear from the net, totally and completely then, and maybe a week to 
fine tune png and get the first version out the door. Where is compuserve 
today? A footnote in history at best, but not remembered with loving 
thoughts.  We invented the distastefull term "submarine patent" to 
describe what happened.

I don't really want to be involved with an entity that references 
additional rights, but doesn't make those readily available.

Maybe I didn't look hard enough but I did look with the idea of learning 
what those additional rights might cost.

Take care and stay well, Steffen. 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


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





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

Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

On 28.02.22 18:40, gene heskett wrote:

On Monday, February 28, 2022 8:28:36 AM EST andy pugh wrote:

On Mon, 28 Feb 2022 at 13:22, Steffen Möller

wrote:

ie, "rtapi" is relevant to uspace and rt builds.

Can you guide me (or someone else surfacing) towards what would be
required to have LinuxCNC readily compatible with that external
EtherCAT package on Debian?

Personally I know nothing about EtherCAT. I have always been a little
afraid of the licensing complexities mentioned here:

https://etherlab.org/en/ethercat/

Etherlab itself is GPLv2, but _using_ it seems to bring a different
licensing restriction into play. And I don't know enough about
licensing to know if that's a problem.

I followed this link, and couldn't find an obvious link to the licensing
docs. Am I going blind? Or are they acting like a submarine, ala the
compuserve debacle from about 25 years back?

It is in the "Notice" section below that copyright thingy:
The license above concerns the source code only. Using the EtherCAT
technology and brand is only permitted in compliance with the industrial
property and similar rights ofBeckhoff Automation GmbH
.

Best,
Steffen


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

Re: [Emc-developers] LinuxCNC is in Debian!

[gene heskett]

On Monday, February 28, 2022 8:28:36 AM EST andy pugh wrote:
> On Mon, 28 Feb 2022 at 13:22, Steffen Möller  
wrote:
> > > ie, "rtapi" is relevant to uspace and rt builds.
> > 
> > Can you guide me (or someone else surfacing) towards what would be
> > required to have LinuxCNC readily compatible with that external
> > EtherCAT package on Debian?
> 
> Personally I know nothing about EtherCAT. I have always been a little
> afraid of the licensing complexities mentioned here:
> 
> https://etherlab.org/en/ethercat/
> 
> Etherlab itself is GPLv2, but _using_ it seems to bring a different
> licensing restriction into play. And I don't know enough about
> licensing to know if that's a problem.

I followed this link, and couldn't find an obvious link to the licensing 
docs. Am I going blind? Or are they acting like a submarine, ala the 
compuserve debacle from about 25 years back?

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





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

Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

On 28.02.22 14:28, andy pugh wrote:

On Mon, 28 Feb 2022 at 13:22, Steffen Möller  wrote:


ie, "rtapi" is relevant to uspace and rt builds.

Can you guide me (or someone else surfacing) towards what would be
required to have LinuxCNC readily compatible with that external EtherCAT
package on Debian?

Personally I know nothing about EtherCAT. I have always been a little
afraid of the licensing complexities mentioned here:

https://etherlab.org/en/ethercat/

Etherlab itself is GPLv2, but _using_ it seems to bring a different
licensing restriction into play. And I don't know enough about
licensing to know if that's a problem.


Let me see if I can get some sort of contact to them. This sounds all a
bit weird. Wrt Debian all it asks is if it can build, modify and
redistribute the package, I am not worried about that part. But about
all the other parts, indeed.

Steffen



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

Re: [Emc-developers] LinuxCNC is in Debian!

[andy pugh]

On Mon, 28 Feb 2022 at 13:22, Steffen Möller  wrote:

> > ie, "rtapi" is relevant to uspace and rt builds.
>
> Can you guide me (or someone else surfacing) towards what would be
> required to have LinuxCNC readily compatible with that external EtherCAT
> package on Debian?

Personally I know nothing about EtherCAT. I have always been a little
afraid of the licensing complexities mentioned here:

https://etherlab.org/en/ethercat/

Etherlab itself is GPLv2, but _using_ it seems to bring a different
licensing restriction into play. And I don't know enough about
licensing to know if that's a problem.

-- 
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-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

On 28.02.22 13:44, andy pugh wrote:

On Mon, 28 Feb 2022 at 12:20, Steffen Möller  wrote:


+rtapi_timespec_advance(task->nextstart, task->nextstart,
task->period + task->pll_correction);

which patches LinuxCNC's src/rtapi/rtapi.h and I have no idea if we can
just ignore this for our uspace setup on Debian

It sounds like there may be some confusion, but it might be me
misunderstanding the question.

"rtapi" is a wrapper that abstracts the differences between rtai,
preempt-rt and xenomai.

ie, "rtapi" is relevant to uspace and rt builds.


Can you guide me (or someone else surfacing) towards what would be
required to have LinuxCNC readily compatible with that external EtherCAT
package on Debian?

Best,
Steffen



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

Re: [Emc-developers] LinuxCNC is in Debian!

[andy pugh]

On Mon, 28 Feb 2022 at 12:20, Steffen Möller  wrote:

> +rtapi_timespec_advance(task->nextstart, task->nextstart,
> task->period + task->pll_correction);
>
> which patches LinuxCNC's src/rtapi/rtapi.h and I have no idea if we can
> just ignore this for our uspace setup on Debian

It sounds like there may be some confusion, but it might be me
misunderstanding the question.

"rtapi" is a wrapper that abstracts the differences between rtai,
preempt-rt and xenomai.

ie, "rtapi" is relevant to uspace and rt builds.


-- 
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-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

Rod,

Thank you tons for these pointers. This is a nice examples for a) and b)
of my motivation coming togther.

I'd love to see EtherCAT properly hooked up with LinuxCNC (I actually
thought this was the case already) and I happily help to get there. The
problem: I am not competent to make any decisions and have no hardware
to test (which would be the easiest to fix). I would hence need someone
to direct me or preferably we find someone who wants to grow into
maintaining it and then that individual gets help from all sides.

To describe my difficulty, I looked at
https://github.com/sittner/linuxcnc-ethercat/blob/3a25fc9cd5a52cd51fefcd152c92b860a90b3a11/patches/add-task-pll-functions-2.8.patch#L125
:

+    rtapi_timespec_advance(task->nextstart, task->nextstart,
task->period + task->pll_correction);

which patches LinuxCNC's src/rtapi/rtapi.h and I have no idea if we can
just ignore this for our uspace setup on Debian or if this needs some
further discussion.

So, Petter or me as Debian-Developers (and we likely find more DDs
teaming up over time) happily help to get this all into Debian, but the
nitty-gritty is too difficult for either of us, I presume. So, maybe we
can come up with sort of "development plan" and match that against the
skills we have at our disposal?

Best,
Steffen


On 28.02.22 02:56, Rod Webster wrote:

Stefan,
One area that could reduce dependency on Mesa hardware would be to bring
Ethercat into the Debian repos. We mention it is being supported in our
shiny new repository entry but it's not and it's difficult to install on
newer distros.
There is an ethercat driver for linuxcnc here:
See:https://github.com/sittner/linuxcnc-ethercat

Previously, it was determined that this was not possible due to incorporate
this to possible licensing restrictions with Beckhoff but from what I can
see that license is for hardware devices only and the driver links to the
Etherlabmaster open source software library
See:https://etherlab.org/en/ethercat/
Perhaps with our greater understanding of licensing and the many licences
we have uncovered in Linuxcnc, perhaps this decision could be reviewed.

And you would also probably want to capture this component for managing
CIA402 servo devices
https://github.com/dbraun1981/hal-cia402

Recently one of the etherlab developers created an unofficial buildbot for
Debian debs here so the project may be fully complete if they came on board
https://build.opensuse.org/project/show/home:bone1:branches:science:EtherLab

Currently supporting Ethercat devices is far more difficult than it should
be.

This would be an awesome and worthy addition to the project if it were
possible.

Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au


On Mon, 28 Feb 2022 at 10:38, Steffen Möller  wrote:


I have asked this myself. Why did I want this to happen - and I think
the answer is two-fold:

a) community-forming - not necessarily I am after contributors to
LinuxCNC but I see the extra stimulus to package other CNC-related
software for Debian from which then LinuxCNC benefits

b) less stress to "keep everything together". There are several LiveCDs
that likely would just go and add LinuxCNC, such that there may not be
an ultimate need for LinuxCNC to maintain its own. LinuxCNC in my
understanding is a bit of a distribution in itself: It has amalgamated
several projects (ladder comes to mind) that have been developed
independently before. If this all works out nicely then LinuxCNC could
consider to present some of its internals as independent packages.

Something else I see is that LinuxCNC has the Mesa cards as closely tied
hardware. There could be more. I could imagine that have LinuxCNC
integrated with Debian (now) and Ubuntu (soon) will ease the internal
decision making for hardware companies that today only address Mach3 et
al..

We'll see :)

Best,
Steffen

On 28.02.22 01:01, Sam Sokolik wrote:

This is amazing...   This will make Linuxcnc even easier to access..

  Game

changer?  Maybe!

sam

On Sun, Feb 27, 2022 at 1:32 PM Nicklas SB Karlsson  wrote:


Metoo use debian. Great!

On Sun, 27 Feb 2022 11:36:37 -0700
Sebastian Kuzminsky  wrote:


On 2/27/22 04:00, Debian FTP Masters wrote:
   > Accepted:
   >

Format: 1.8
Date: Fri, 25 Feb 2022 18:40:12 +0100
Source: linuxcnc
Binary: linuxcnc-doc-en linuxcnc-doc-es linuxcnc-doc-fr

linuxcnc-doc-zh-cn linuxcnc-uspace linuxcnc-uspace-dbgsym
linuxcnc-uspace-dev

Architecture: source all amd64
Version: 2.9.0~pre0+git20220224.3ba0951743-1
Distribution: unstable

Yayyy!  Thank you Steffen, and Petter and everyone who's been working

on

getting LinuxCNC into Debian!

If you're running sid/unstable you can now just `apt-get install
linuxcnc-uspace`, right from the debian.org package archive:

   


It'll hopefully make it into bookworm/testing in a couple of days.
We'll work on bullseye after that.  :-)


--
Sebastian Kuzminsky

Re: [Emc-developers] LinuxCNC is in Debian!

[Rod Webster]

Stefan,
One area that could reduce dependency on Mesa hardware would be to bring
Ethercat into the Debian repos. We mention it is being supported in our
shiny new repository entry but it's not and it's difficult to install on
newer distros.
There is an ethercat driver for linuxcnc here:
See: https://github.com/sittner/linuxcnc-ethercat

Previously, it was determined that this was not possible due to incorporate
this to possible licensing restrictions with Beckhoff but from what I can
see that license is for hardware devices only and the driver links to the
Etherlabmaster open source software library
See: https://etherlab.org/en/ethercat/
Perhaps with our greater understanding of licensing and the many licences
we have uncovered in Linuxcnc, perhaps this decision could be reviewed.

And you would also probably want to capture this component for managing
CIA402 servo devices
https://github.com/dbraun1981/hal-cia402

Recently one of the etherlab developers created an unofficial buildbot for
Debian debs here so the project may be fully complete if they came on board
https://build.opensuse.org/project/show/home:bone1:branches:science:EtherLab

Currently supporting Ethercat devices is far more difficult than it should
be.

This would be an awesome and worthy addition to the project if it were
possible.

Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au


On Mon, 28 Feb 2022 at 10:38, Steffen Möller  wrote:

> I have asked this myself. Why did I want this to happen - and I think
> the answer is two-fold:
>
> a) community-forming - not necessarily I am after contributors to
> LinuxCNC but I see the extra stimulus to package other CNC-related
> software for Debian from which then LinuxCNC benefits
>
> b) less stress to "keep everything together". There are several LiveCDs
> that likely would just go and add LinuxCNC, such that there may not be
> an ultimate need for LinuxCNC to maintain its own. LinuxCNC in my
> understanding is a bit of a distribution in itself: It has amalgamated
> several projects (ladder comes to mind) that have been developed
> independently before. If this all works out nicely then LinuxCNC could
> consider to present some of its internals as independent packages.
>
> Something else I see is that LinuxCNC has the Mesa cards as closely tied
> hardware. There could be more. I could imagine that have LinuxCNC
> integrated with Debian (now) and Ubuntu (soon) will ease the internal
> decision making for hardware companies that today only address Mach3 et
> al..
>
> We'll see :)
>
> Best,
> Steffen
>
> On 28.02.22 01:01, Sam Sokolik wrote:
> > This is amazing...   This will make Linuxcnc even easier to access..
>  Game
> > changer?  Maybe!
> >
> > sam
> >
> > On Sun, Feb 27, 2022 at 1:32 PM Nicklas SB Karlsson  wrote:
> >
> >> Metoo use debian. Great!
> >>
> >> On Sun, 27 Feb 2022 11:36:37 -0700
> >> Sebastian Kuzminsky  wrote:
> >>
> >>> On 2/27/22 04:00, Debian FTP Masters wrote:
> >>>   > Accepted:
> >>>   >
>  Format: 1.8
>  Date: Fri, 25 Feb 2022 18:40:12 +0100
>  Source: linuxcnc
>  Binary: linuxcnc-doc-en linuxcnc-doc-es linuxcnc-doc-fr
> >> linuxcnc-doc-zh-cn linuxcnc-uspace linuxcnc-uspace-dbgsym
> >> linuxcnc-uspace-dev
>  Architecture: source all amd64
>  Version: 2.9.0~pre0+git20220224.3ba0951743-1
>  Distribution: unstable
> >>> Yayyy!  Thank you Steffen, and Petter and everyone who's been working
> on
> >>> getting LinuxCNC into Debian!
> >>>
> >>> If you're running sid/unstable you can now just `apt-get install
> >>> linuxcnc-uspace`, right from the debian.org package archive:
> >>>
> >>>   
> >>>
> >>>
> >>> It'll hopefully make it into bookworm/testing in a couple of days.
> >>> We'll work on bullseye after that.  :-)
> >>>
> >>>
> >>> --
> >>> Sebastian Kuzminsky
> >>>
> >>>
> >>> ___
> >>> Emc-developers mailing list
> >>> Emc-developers@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>
> >> ___
> >> Emc-developers mailing list
> >> Emc-developers@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] LinuxCNC is in Debian!

[Steffen Möller]

I have asked this myself. Why did I want this to happen - and I think
the answer is two-fold:

a) community-forming - not necessarily I am after contributors to
LinuxCNC but I see the extra stimulus to package other CNC-related
software for Debian from which then LinuxCNC benefits

b) less stress to "keep everything together". There are several LiveCDs
that likely would just go and add LinuxCNC, such that there may not be
an ultimate need for LinuxCNC to maintain its own. LinuxCNC in my
understanding is a bit of a distribution in itself: It has amalgamated
several projects (ladder comes to mind) that have been developed
independently before. If this all works out nicely then LinuxCNC could
consider to present some of its internals as independent packages.

Something else I see is that LinuxCNC has the Mesa cards as closely tied
hardware. There could be more. I could imagine that have LinuxCNC
integrated with Debian (now) and Ubuntu (soon) will ease the internal
decision making for hardware companies that today only address Mach3 et al..

We'll see :)

Best,
Steffen

On 28.02.22 01:01, Sam Sokolik wrote:

This is amazing...   This will make Linuxcnc even easier to access..   Game
changer?  Maybe!

sam

On Sun, Feb 27, 2022 at 1:32 PM Nicklas SB Karlsson  wrote:


Metoo use debian. Great!

On Sun, 27 Feb 2022 11:36:37 -0700
Sebastian Kuzminsky  wrote:


On 2/27/22 04:00, Debian FTP Masters wrote:
  > Accepted:
  >

Format: 1.8
Date: Fri, 25 Feb 2022 18:40:12 +0100
Source: linuxcnc
Binary: linuxcnc-doc-en linuxcnc-doc-es linuxcnc-doc-fr

linuxcnc-doc-zh-cn linuxcnc-uspace linuxcnc-uspace-dbgsym
linuxcnc-uspace-dev

Architecture: source all amd64
Version: 2.9.0~pre0+git20220224.3ba0951743-1
Distribution: unstable

Yayyy!  Thank you Steffen, and Petter and everyone who's been working on
getting LinuxCNC into Debian!

If you're running sid/unstable you can now just `apt-get install
linuxcnc-uspace`, right from the debian.org package archive:

  


It'll hopefully make it into bookworm/testing in a couple of days.
We'll work on bullseye after that.  :-)


--
Sebastian Kuzminsky


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


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


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



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

Re: [Emc-developers] LinuxCNC is in Debian!

[Sam Sokolik]

This is amazing...   This will make Linuxcnc even easier to access..   Game
changer?  Maybe!

sam

On Sun, Feb 27, 2022 at 1:32 PM Nicklas SB Karlsson  wrote:

> Metoo use debian. Great!
>
> On Sun, 27 Feb 2022 11:36:37 -0700
> Sebastian Kuzminsky  wrote:
>
> > On 2/27/22 04:00, Debian FTP Masters wrote:
> >  > Accepted:
> >  >
> > > Format: 1.8
> > > Date: Fri, 25 Feb 2022 18:40:12 +0100
> > > Source: linuxcnc
> > > Binary: linuxcnc-doc-en linuxcnc-doc-es linuxcnc-doc-fr
> linuxcnc-doc-zh-cn linuxcnc-uspace linuxcnc-uspace-dbgsym
> linuxcnc-uspace-dev
> > > Architecture: source all amd64
> > > Version: 2.9.0~pre0+git20220224.3ba0951743-1
> > > Distribution: unstable
> >
> > Yayyy!  Thank you Steffen, and Petter and everyone who's been working on
> > getting LinuxCNC into Debian!
> >
> > If you're running sid/unstable you can now just `apt-get install
> > linuxcnc-uspace`, right from the debian.org package archive:
> >
> >  
> >
> >
> > It'll hopefully make it into bookworm/testing in a couple of days.
> > We'll work on bullseye after that.  :-)
> >
> >
> > --
> > Sebastian Kuzminsky
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] LinuxCNC is in Debian!

[Nicklas SB Karlsson]

Metoo use debian. Great!

On Sun, 27 Feb 2022 11:36:37 -0700
Sebastian Kuzminsky  wrote:

> On 2/27/22 04:00, Debian FTP Masters wrote:
>  > Accepted:
>  >
> > Format: 1.8
> > Date: Fri, 25 Feb 2022 18:40:12 +0100
> > Source: linuxcnc
> > Binary: linuxcnc-doc-en linuxcnc-doc-es linuxcnc-doc-fr linuxcnc-doc-zh-cn 
> > linuxcnc-uspace linuxcnc-uspace-dbgsym linuxcnc-uspace-dev
> > Architecture: source all amd64
> > Version: 2.9.0~pre0+git20220224.3ba0951743-1
> > Distribution: unstable
> 
> Yayyy!  Thank you Steffen, and Petter and everyone who's been working on 
> getting LinuxCNC into Debian!
> 
> If you're running sid/unstable you can now just `apt-get install 
> linuxcnc-uspace`, right from the debian.org package archive:
> 
>  
> 
> 
> It'll hopefully make it into bookworm/testing in a couple of days. 
> We'll work on bullseye after that.  :-)
> 
> 
> -- 
> Sebastian Kuzminsky
> 
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


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

Re: [Emc-developers] LinuxCNC is in Debian!

[Valerio Bellizzomi]

Great work !

On Sun, 2022-02-27 at 11:36 -0700, Sebastian Kuzminsky wrote:
> On 2/27/22 04:00, Debian FTP Masters wrote:
>  > Accepted:
>  >
> > Format: 1.8
> > Date: Fri, 25 Feb 2022 18:40:12 +0100
> > Source: linuxcnc
> > Binary: linuxcnc-doc-en linuxcnc-doc-es linuxcnc-doc-fr linuxcnc-
> > doc-zh-cn linuxcnc-uspace linuxcnc-uspace-dbgsym linuxcnc-uspace-
> > dev
> > Architecture: source all amd64
> > Version: 2.9.0~pre0+git20220224.3ba0951743-1
> > Distribution: unstable
> 
> Yayyy!  Thank you Steffen, and Petter and everyone who's been working
> on 
> getting LinuxCNC into Debian!
> 
> If you're running sid/unstable you can now just `apt-get install 
> linuxcnc-uspace`, right from the debian.org package archive:
> 
>  
> 
> 
> It'll hopefully make it into bookworm/testing in a couple of days. 
> We'll work on bullseye after that.  :-)
> 
> 



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

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[andy pugh]

On 6 May 2013 21:44, Christophe Grellier c...@grellier.fr wrote:

 - What is a stepper motor or a servo ? In french, a moteur can be a
 stepper motor, a handrill motor, or even a car engine. Those are quite
 different things.

One approach to answering such questions that I find works well is to
search Wikipedia in the language being used,  and then switch
languages. This gives us:
http://fr.wikipedia.org/wiki/Servomoteur
http://fr.wikipedia.org/wiki/Moteur_pas_%C3%A0_pas

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

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

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[Dave]

Christophe,

It's hard to be everything to everyone - regarding howtos and LinuxCNC.

Don't overlook websites like CNCZone.com.   They can often times offer 
specifics for your particular CNC application
Knee Mill vs Plasma Cutter vs ?  etc.

Also, questions such as this are probably better on the EMC Users list 
rather than the Devel list as you will probably get more replies.

Dave

On 5/7/2013 1:27 AM, Christophe Grellier wrote:
 Clear explanation. Thank you, Jon.
 I will try to make a page on the wiki, with your answers, if you're OK.

 Christophe


 Le 07/05/2013 04:31, Jon Elson a écrit :

 Christophe Grellier wrote:
  
 - What is a stepper motor or a servo ? In french, a moteur can be a
 stepper motor, a handrill motor, or even a car engine. Those are quite
 different things.


 A stepper motor has fixed positions built into it, and will move to a
 particular
 position when commanded.  Feeding it more power will just make it
 hold that position more rigidly.  It is normally used with no position
 sensing
 device.  A servo motor generally moves smoothly when power is
 applied, and will move faster when more power is applied.  It must be
 used with a position sensing device, as feeding power to the motor gives
 you no idea how much it has actually moved, due to variations in
 inertia and friction.
  
 - What are these pulses you are talking about ?
 - Why the pulses need to have a good speed and rythm ?


 A stepper motor responds a bit like a mass with a spring attached.
 With the winding current in a particular pattern, it will fall into
 magnetic lock every four full step positions.  If the loads are
 excessive, or sudden speed changes are commanded, the motor
 can jump from one locked position to another.  If the step timing
 is not continuous, it can be hard for the magnetics in the motor
 to follow the apparent sudden changes in the speed of the
 electrical poles, and these jumps become more likely.
  
 - Why does Linuxcnc need a realtime kernel, while Mach3 can run on a
 stock Windows install ?


 Mach uses a realtime driver that attempts to do the same thing, for a
 very small part of the Mach system.  It runs into many of the same
 problems with interrupt latency.
  
 - What is the difference between software stepgen and hardware stepgen ?
 - Is one better than the other ?


 Ragged step timing makes it hard for the stepper motors to follow the
 desired movement.  If the timing jitter exceeds some amount depending
 on mass, stiffness, the motor and the stepper drive, the motor will skip
 steps of fall out of sync completely, leading to a stalled motor for the
 rest
 of the movement.  it will pull back into sync when the commanded move
 comes to a stop, leaving the machine at a different position than commanded.
 Software step generation has a fundamental limit on the precision of
 timing of the steps.  For instance, the interrupt period on the base thread
 in a LinuxCNC system might be 20 us.  The equivalent time is 100 ns
 on the Pico Systems Universal Stepper Controller board, or 200 times
 finer resolution.  The 20 us granularity of step timing is not such a great
 deal at modest speeds, but if you need to produce step pulses at
 10,000 per second (rather fast for full-step drives) then the 20 us
 granularity means that the next faster or slower speed is a 20% jump
 in speed.  So, acceleration and deceleration at 10K steps/second
 is quite coarse.  With our step generator at the same speed, the granularity
 is only 1 part per thousand, which the motor will never notice.

 Jon

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

  

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




--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and 
their 

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[Jon Elson]

Christophe Grellier wrote:
 Clear explanation. Thank you, Jon.
 I will try to make a page on the wiki, with your answers, if you're OK.
   
Oh, cool!  I'd like to proof that and maybe improve the explanation, too,
when the page is there.  Thanks for doing the work.

Jon

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

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[Michael Haberler]

Christophe -

Am 06.05.2013 um 11:16 schrieb Christophe Grellier c...@grellier.fr:
 
 So I installed a Debian Wheezy with the rt_preempt kernel

 So my main question is : what version of LinuxCNC can I install ?
 - the stable 2.5.2 ? From what I understood, it is RTAI-only.

wont help you - as you say: RTAI only

 - master branch ?

same thing

 - rtos-integration-preview3 ?

or its master equivalent rtos-integration-preview3-merged-into-master

 I am looking for something pretty stable, that can work with the 
 rt_preempt kernel.

I think these branches are quite stable.

 
 Would I gain anything at using a xenomai or rtai kernel that have better 
 latency numbers ?

Yes, RTAI and Xenomai have significantly better latency behaviour than 
RT-PREEMPT. I think this is relevant mostly for software stepgen setups,

 The new version that will run with multiple rt kernels looks like a 
 major step forward. Shouldn't this upcoming version be granted a 
 LinuxCNC 3.0 name ?

Actually I dont think so, since this work changes internal plumbing, but next 
to nothing at the user level; plus version numbers arent a reward system - at 
least my ego will come out unchanged visavis the version number eventually 
chosen ;)

There will be a more radically reworked version later this year which does away 
with NML and enables a split of RT (HAL/RTAPI/motion) and non-RT (UI, 
interpreter, task) onto different machines and hence possibly different 
architectures; that includes a 'non-PC' option for the non-RT part. That 
probably warrants a major number change.

- Michael


--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[EBo]

On May 6 2013 3:16 AM, Christophe Grellier wrote:

 ...

 I am looking for something pretty stable, that can work with the
 rt_preempt kernel.

 Would I gain anything at using a xenomai or rtai kernel that have 
 better
 latency numbers ?

There are people poking at RT-PREEMPT, and depending on your exact 
setup getting very good results.  Like others have said, RTAI and 
Xenomai get better latencies and will probably always do so because of 
technical reasons of their implementation.  That being said, if the 
rt-preempt latencies is good enough for your application I personally go 
for that -- rt-preempt is now part of the stock kernel and there is a 
variant which is now supposed to provide hard real-time.  Anyway, them's 
my thoughts on the matter.

   EBo --

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[Charles Steinkuehler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 5/6/2013 4:16 AM, Christophe Grellier wrote:
 Hello, First, let me say that I am pretty new to CNC. I use a 3
 axis mill (like this one http://www.cnc-shop.ch/cnc6040.htm) for
 2 years now And English is not my native language ( i'm french ) so
 I may have misunderstood things. Please feel free to correct me if
 I'm wrong.
 
 My current breakout board died because of a motor short-circuit. I
 was running it with ubuntu 12.04, xenomai kernel and 
 rtos-integration-preview3 branch. So I decided to go for a more
 reliable, better quality hardware, and bought a Mesa 5i25 / 7i76
 and Gecko G203V drives.
 
 From what I understood, the 5i25 does what you call hardware
 stepgen and the computer latency numbers are much less critical
 than software stepgen. right ? So I installed a Debian Wheezy
 with the rt_preempt kernel ( I was fed up with ubuntu 12.04 /
 xenomai that didn't let me install fglrx graphic driver ).
 
 So my main question is : what version of LinuxCNC can I install ? -
 the stable 2.5.2 ? From what I understood, it is RTAI-only. -
 master branch ? - rtos-integration-preview3 ? I am looking for
 something pretty stable, that can work with the rt_preempt kernel.

Then I would stick with the rtos-integration-preview3 branch you were
using previously.  Build details for Debian Wheeze with an rt kernel
are on the wiki:

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Debian_Wheezy_Linux-Rt_Compile_LinuxCNC

 Would I gain anything at using a xenomai or rtai kernel that have
 better latency numbers ?

Yes, but if you've got a Mesa card, you don't gain that much on an x86
platform.  Unless you're really pushing your servo rate, rtai and
xenomai are IMHO really only necessary on x86 if you're trying to do
software stepgen.  But make sure you test your board, latency numbers
for rt_preempt can vary a *LOT* based on BIOS settings and your
particular hardware (since for rt_preempt to work well, the driver
code needs to be written to work well under SMP).

Now if you were on an ARM, rt_preempt still has horrid worst-case
latency (milliseconds, or 100+ nS), so you need something like
xenomai *and* hardware help.

- -- 
Charles Steinkuehler
char...@steinkuehler.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlGHnmwACgkQLywbqEHdNFw2bQCgpPayoWBEYQUfDKKygqSabTD0
YBUAoNfGd3bjamEty8AX2x9henRpJ7/d
=itD/
-END PGP SIGNATURE-

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[Kent A. Reed]

On 5/6/2013 8:13 AM, Charles Steinkuehler wrote:
 Yes, but if you've got a Mesa card, you don't gain that much on an x86
 platform.  Unless you're really pushing your servo rate, rtai and
 xenomai are IMHO really only necessary on x86 if you're trying to do
 software stepgen.  But make sure you test your board, latency numbers
 for rt_preempt can vary a*LOT*  based on BIOS settings and your
 particular hardware (since for rt_preempt to work well, the driver
 code needs to be written to work well under SMP).

and, just prior, Ebo wrote:

 There are people poking at RT-PREEMPT, and depending on your exact
 setup getting very good results.  Like others have said, RTAI and
 Xenomai get better latencies and will probably always do so because of
 technical reasons of their implementation.  That being said, if the
 rt-preempt latencies is good enough for your application I personally go
 for that -- rt-preempt is now part of the stock kernel and there is a
 variant which is now supposed to provide hard real-time.  Anyway, them's
 my thoughts on the matter.


and, just prior to that, Michael wrote:

 Yes, RTAI and Xenomai have significantly better latency behaviour than 
 RT-PREEMPT. I think this is relevant mostly for software stepgen setups

The question of what is good enough has intrigued me since I first 
started reading LinuxCNC nee EMC2 documentation. For many years we have 
had essentially only one quantitative criterion. IIRC correctly it shows 
up several places but this particular quote comes from the Latency-Test 
page on the Wiki:

 If the numbers are 100 uS or more (100,000 nanoseconds), then the PC 
is not a good candidate for software stepping. Numbers over 1 
millisecond (1,000,000 nanoseconds) mean the PC is not a good candidate 
for LinuxCNC, regardless of whether you use software stepping or not.

Is this still the best we can do for guidance to prospective users? I 
realize that details matter so it's difficult to get very specific about 
what is good enough for your application but I keep hoping we could 
say more. For that matter, we could say more about the impact of high 
jitter. Currently, we say only : ...your maximum step rate might be a 
bit disappointing If I thought I had the knowledge I would write 
more about the impact myself, but I don't and I haven't. MIchael and I 
briefly discussed the subject a year ago in the context of stepper 
drives and I realized after considerable Internet searching that little 
useful information is available (one limited calculation by Proctor et 
al and some postings by Mariss) so maybe it's just too hard a subject?

As a practical matter, we haven't collected much latency/jitter data for 
the Xenomai and RT-PREEMPT kernels on different CPU-motherboard-BIOS 
combinations. It feels like it is time to start gathering such data in 
new tables on the Latency-test page on the Wiki. If I get time later 
today (and if the Wiki is more responsive than it was yesterday),  I'll 
copy in my Xenomai results for several systems and Charles' RT-PREEMPT 
results for several other systems which have been posted elsewhere. 
Maybe the presence of new tables will embolden others to contribute 
their results.


Regards,
Kent

PS - if new material on this subject already has been added to the LCNC 
documentation please point it out. My blind spots are widening with age.

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[Lars Segerlund]

 check the data on osadl.org ... with RT-Preempt you should be able to
get worstcase jitters of less than 50 us ... or you have a 'bad'
system / bad drivers.

 With a 'good' RT-Preempt system you get  20 us  as worstcase.

 osadl  is good since they are really hammering the systems while measuring.

 / regards, Lars Segerlund.




2013/5/6 Kent A. Reed kentallanr...@gmail.com:
 On 5/6/2013 8:13 AM, Charles Steinkuehler wrote:
 Yes, but if you've got a Mesa card, you don't gain that much on an x86
 platform.  Unless you're really pushing your servo rate, rtai and
 xenomai are IMHO really only necessary on x86 if you're trying to do
 software stepgen.  But make sure you test your board, latency numbers
 for rt_preempt can vary a*LOT*  based on BIOS settings and your
 particular hardware (since for rt_preempt to work well, the driver
 code needs to be written to work well under SMP).

 and, just prior, Ebo wrote:

 There are people poking at RT-PREEMPT, and depending on your exact
 setup getting very good results.  Like others have said, RTAI and
 Xenomai get better latencies and will probably always do so because of
 technical reasons of their implementation.  That being said, if the
 rt-preempt latencies is good enough for your application I personally go
 for that -- rt-preempt is now part of the stock kernel and there is a
 variant which is now supposed to provide hard real-time.  Anyway, them's
 my thoughts on the matter.


 and, just prior to that, Michael wrote:

 Yes, RTAI and Xenomai have significantly better latency behaviour than 
 RT-PREEMPT. I think this is relevant mostly for software stepgen setups

 The question of what is good enough has intrigued me since I first
 started reading LinuxCNC nee EMC2 documentation. For many years we have
 had essentially only one quantitative criterion. IIRC correctly it shows
 up several places but this particular quote comes from the Latency-Test
 page on the Wiki:

  If the numbers are 100 uS or more (100,000 nanoseconds), then the PC
 is not a good candidate for software stepping. Numbers over 1
 millisecond (1,000,000 nanoseconds) mean the PC is not a good candidate
 for LinuxCNC, regardless of whether you use software stepping or not.

 Is this still the best we can do for guidance to prospective users? I
 realize that details matter so it's difficult to get very specific about
 what is good enough for your application but I keep hoping we could
 say more. For that matter, we could say more about the impact of high
 jitter. Currently, we say only : ...your maximum step rate might be a
 bit disappointing If I thought I had the knowledge I would write
 more about the impact myself, but I don't and I haven't. MIchael and I
 briefly discussed the subject a year ago in the context of stepper
 drives and I realized after considerable Internet searching that little
 useful information is available (one limited calculation by Proctor et
 al and some postings by Mariss) so maybe it's just too hard a subject?

 As a practical matter, we haven't collected much latency/jitter data for
 the Xenomai and RT-PREEMPT kernels on different CPU-motherboard-BIOS
 combinations. It feels like it is time to start gathering such data in
 new tables on the Latency-test page on the Wiki. If I get time later
 today (and if the Wiki is more responsive than it was yesterday),  I'll
 copy in my Xenomai results for several systems and Charles' RT-PREEMPT
 results for several other systems which have been posted elsewhere.
 Maybe the presence of new tables will embolden others to contribute
 their results.


 Regards,
 Kent

 PS - if new material on this subject already has been added to the LCNC
 documentation please point it out. My blind spots are widening with age.

 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[Kent A. Reed]

On 5/6/2013 9:16 AM, Lars Segerlund wrote:
   check the data on osadl.org ... with RT-Preempt you should be able to
 get worstcase jitters of less than 50 us ... or you have a 'bad'
 system / bad drivers.

   With a 'good' RT-Preempt system you get  20 us  as worstcase.

   osadl  is good since they are really hammering the systems while measuring.

   / regards, Lars Segerlund.


Lars:

I'm not looking to open a discussion about the definition of jitter and 
the appropriate methodology for measuring it (we've had some of those in 
the past on this list, and some of us are quite familiar with OSADL).

What I'm looking for is better guidance to our CNC users, most of whom 
find the details about latency as understandable as details about the 
fuel-injection algorithm used in their car's computer. What we have seen 
in the time I've been reading the emc2- lists amounts to constant 
schoolyard taunting, my latency is better than your latency. Look how 
excited we get when the latest Atom board yields 1us lower or higher 
jitter results than another. If the better guidance includes pointing to 
the OSADL as another source of data (along with suggestions on how to 
interpret those data) so much the better for the folks who wish to use 
RT-PREEMPT enabled kernels (and my thanks to those on this list who have 
been making it possible for the average user to even consider using them).

Regards,
Kent


--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[Lars Segerlund]

 +1 one that !

 It's really hard to pick good hardware  unless you buy  try !

 Cheers ! / Lars


2013/5/6 Kent A. Reed kentallanr...@gmail.com:
 On 5/6/2013 9:16 AM, Lars Segerlund wrote:
   check the data on osadl.org ... with RT-Preempt you should be able to
 get worstcase jitters of less than 50 us ... or you have a 'bad'
 system / bad drivers.

   With a 'good' RT-Preempt system you get  20 us  as worstcase.

   osadl  is good since they are really hammering the systems while measuring.

   / regards, Lars Segerlund.


 Lars:

 I'm not looking to open a discussion about the definition of jitter and
 the appropriate methodology for measuring it (we've had some of those in
 the past on this list, and some of us are quite familiar with OSADL).

 What I'm looking for is better guidance to our CNC users, most of whom
 find the details about latency as understandable as details about the
 fuel-injection algorithm used in their car's computer. What we have seen
 in the time I've been reading the emc2- lists amounts to constant
 schoolyard taunting, my latency is better than your latency. Look how
 excited we get when the latest Atom board yields 1us lower or higher
 jitter results than another. If the better guidance includes pointing to
 the OSADL as another source of data (along with suggestions on how to
 interpret those data) so much the better for the folks who wish to use
 RT-PREEMPT enabled kernels (and my thanks to those on this list who have
 been making it possible for the average user to even consider using them).

 Regards,
 Kent


 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[andy pugh]

On 6 May 2013 15:06, Kent A. Reed kentallanr...@gmail.com wrote:

 What I'm looking for is better guidance to our CNC users, most of whom
 find the details about latency as understandable as details about the
 fuel-injection algorithm used in their car's computer.

I would say that many of the people I know, and the vast majority of
my work colleagues know lots about the latter subject :-)

But your point is a good one.

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

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[Christophe Grellier]

Thank you so much for your answers.
I will go for rtos-integration-preview3-merged-into-master

Christophe

Christophe Grellier
Guitares acoustiques
8 rue de Rouans - 44680 Chéméré
Tél. 02.40.64.17.96
www.grellier.fr http://www.grellier.fr





--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[EBo]

On May 6 2013 8:06 AM, Kent A. Reed wrote:
 On 5/6/2013 9:16 AM, Lars Segerlund wrote:
   check the data on osadl.org ... with RT-Preempt you should be able 
 to
 get worstcase jitters of less than 50 us ... or you have a 'bad'
 system / bad drivers.

   With a 'good' RT-Preempt system you get  20 us  as worstcase.

   osadl  is good since they are really hammering the systems while 
 measuring.

   / regards, Lars Segerlund.


 Lars:

 I'm not looking to open a discussion about the definition of jitter 
 and
 the appropriate methodology for measuring it (we've had some of those 
 in
 the past on this list, and some of us are quite familiar with OSADL).

 What I'm looking for is better guidance to our CNC users, most of 
 whom
 find the details about latency as understandable as details about the
 fuel-injection algorithm used in their car's computer. What we have 
 seen
 in the time I've been reading the emc2- lists amounts to constant
 schoolyard taunting, my latency is better than your latency. Look 
 how
 excited we get when the latest Atom board yields 1us lower or higher
 jitter results than another. If the better guidance includes pointing 
 to
 the OSADL as another source of data (along with suggestions on how to
 interpret those data) so much the better for the folks who wish to 
 use
 RT-PREEMPT enabled kernels (and my thanks to those on this list who 
 have
 been making it possible for the average user to even consider using 
 them).

Kent,

What I would like to see, and will help generate as my limited time 
allows, generate some basic formulas to help guide people.  This is off 
the top of my head, and is likely wrong given that I am spacey as hell 
with allergies...

max_pulse_rate (in Hz) = 1.0 /(maxjitter * Const)

where Const is probably something from 3 to 10 and denotes some 
fraction of base time period that you can put up with the jitter.  
Knowing how fast you can run the stepgen thread (assuming stepgen) will 
then allow you to calculate your max speed using a given piece of 
mechanics/electronics/etc.  For example, if you are using something like 
the Gecko G540, and motors that can do just over 300RPM, and typically 
have 200 steps/rev.  We know that the G540 is hard-wired to 10 
microsteps/step.  So, we have 300*200*10 maximum steps/rev that the 
motors can do, and 10KHz for the step/sec.  So if we back calculate 
that, we are talking 100us for the max step rate, and you want your 
jitter to be a very small portion of that (for argument lets say 1/5 or 
20%).  So, if we have a latency of 20us we can easily keep up with the 
G540.  If I am not mistaken, the latest RT_PREEMPT is able to do that on 
all my hardware.  Not sure about yours.

Sometime back I remember reading a paper that looked at the %jitter to 
duty-cycle and the overall effect on power loss.  I do not have an 
intuitive feel for that or what implies for the current discussion but 
this is a start.  I am sure that others will tare this apart but so be 
it.  This is intended to start a reasoned discussion on spec'ing the max 
speed of a setup given the jitter and other considerations.

   EBo --

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[Michael Haberler]

EBo,


Am 06.05.2013 um 19:44 schrieb EBo e...@sandien.com:

 On May 6 2013 8:06 AM, Kent A. Reed wrote:
 On 5/6/2013 9:16 AM, Lars Segerlund wrote:
  check the data on osadl.org ... with RT-Preempt you should be able 
 to
 get worstcase jitters of less than 50 us ... or you have a 'bad'
 system / bad drivers.
 
  With a 'good' RT-Preempt system you get  20 us  as worstcase.
 
  osadl  is good since they are really hammering the systems while 
 measuring.
 
  / regards, Lars Segerlund.
 
 
 Lars:
 
 I'm not looking to open a discussion about the definition of jitter 
 and
 the appropriate methodology for measuring it (we've had some of those 
 in
 the past on this list, and some of us are quite familiar with OSADL).
 
 What I'm looking for is better guidance to our CNC users, most of 
 whom
 find the details about latency as understandable as details about the
 fuel-injection algorithm used in their car's computer. What we have 
 seen
 in the time I've been reading the emc2- lists amounts to constant
 schoolyard taunting, my latency is better than your latency. Look 
 how
 excited we get when the latest Atom board yields 1us lower or higher
 jitter results than another. If the better guidance includes pointing 
 to
 the OSADL as another source of data (along with suggestions on how to
 interpret those data) so much the better for the folks who wish to 
 use
 RT-PREEMPT enabled kernels (and my thanks to those on this list who 
 have
 been making it possible for the average user to even consider using 
 them).
 
 Kent,
 
 What I would like to see, and will help generate as my limited time 
 allows, generate some basic formulas to help guide people.  This is off 
 the top of my head, and is likely wrong given that I am spacey as hell 
 with allergies...
 
 max_pulse_rate (in Hz) = 1.0 /(maxjitter * Const)

from a user perspective I think measures like latency or perceived maximum 
pulse rates are useless as guidance, for the simple reason that they do not 
express what a user might be interested in, but happen to be some low-level 
number which happens to be measurable easily

what _I_ would be interested in isnt what happens to be easily measurable, but 
what a given setup can do for me

for example:

given a configuration, what is the quality of tracking the commanded path, and 
the speed/speed deviation at which that can be done

tracking quality (I just made that term up) might translate into either a 
maximum path deviation (hard limit), or a distribution with percentiles plus a 
boundary

this probably has both a spatial and a temporal dimension

example for spacial accuracy: for test path X, results are within A uM 95% of 
the time with a maximum deviation of B uM

I admit this probably cant be expressed as easily - I'm lacking theory and 
literature know how here but I would bet there is actually work in the area (or 
in related weapons or rocket research ;)

maybe even there is a way to compute such values on the fly and mirror them in 
(a) pin(s); again that is blue sky and pure speculation


from that perspective, messages like 'unexpected realtime delay' are about as 
useful as dashboard message in my car saying 'cylinder #3 took 0.7mS too long 
to fire':

very interesting detail, now what bearing has that on my goals - do I need to 
stop, can I continue driving or will I bump into another car?

---

at times it might be useful to lean back and ask yourself: does this make sense 
or can we do better than that

- Michael


 
 where Const is probably something from 3 to 10 and denotes some 
 fraction of base time period that you can put up with the jitter.  
 Knowing how fast you can run the stepgen thread (assuming stepgen) will 
 then allow you to calculate your max speed using a given piece of 
 mechanics/electronics/etc.  For example, if you are using something like 
 the Gecko G540, and motors that can do just over 300RPM, and typically 
 have 200 steps/rev.  We know that the G540 is hard-wired to 10 
 microsteps/step.  So, we have 300*200*10 maximum steps/rev that the 
 motors can do, and 10KHz for the step/sec.  So if we back calculate 
 that, we are talking 100us for the max step rate, and you want your 
 jitter to be a very small portion of that (for argument lets say 1/5 or 
 20%).  So, if we have a latency of 20us we can easily keep up with the 
 G540.  If I am not mistaken, the latest RT_PREEMPT is able to do that on 
 all my hardware.  Not sure about yours.
 
 Sometime back I remember reading a paper that looked at the %jitter to 
 duty-cycle and the overall effect on power loss.  I do not have an 
 intuitive feel for that or what implies for the current discussion but 
 this is a start.  I am sure that others will tare this apart but so be 
 it.  This is intended to start a reasoned discussion on spec'ing the max 
 speed of a setup given the jitter and other considerations.
 
   EBo --
 
 --
 Introducing 

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[EBo]

Michael,

I just tried to give you what was asked for.  You can reexpress it 
however seems most clear to you or your users.  What I was getting at is 
that the answer depends on your give setup, but if you give me a couple 
of specs of your hardware then I can give you some guidance.  I picked 
the g540 because it is a give piece of equiptment that some people use.  
You could just as well write up the same ting for the Mesa hardware, 
etc.  Expressing it in terms of % or raw numbers is fundamentally the 
same -- for a given spec and use you need a jitter no worse than JERR.  
You can generate such a table give the original specs.

On May 6 2013 12:24 PM, Michael Haberler wrote:
 EBo,


 Am 06.05.2013 um 19:44 schrieb EBo e...@sandien.com:

 On May 6 2013 8:06 AM, Kent A. Reed wrote:
 On 5/6/2013 9:16 AM, Lars Segerlund wrote:
  check the data on osadl.org ... with RT-Preempt you should be 
 able
 to
 get worstcase jitters of less than 50 us ... or you have a 'bad'
 system / bad drivers.

  With a 'good' RT-Preempt system you get  20 us  as worstcase.

  osadl  is good since they are really hammering the systems while
 measuring.

  / regards, Lars Segerlund.


 Lars:

 I'm not looking to open a discussion about the definition of jitter
 and
 the appropriate methodology for measuring it (we've had some of 
 those
 in
 the past on this list, and some of us are quite familiar with 
 OSADL).

 What I'm looking for is better guidance to our CNC users, most of
 whom
 find the details about latency as understandable as details about 
 the
 fuel-injection algorithm used in their car's computer. What we have
 seen
 in the time I've been reading the emc2- lists amounts to constant
 schoolyard taunting, my latency is better than your latency. Look
 how
 excited we get when the latest Atom board yields 1us lower or 
 higher
 jitter results than another. If the better guidance includes 
 pointing
 to
 the OSADL as another source of data (along with suggestions on how 
 to
 interpret those data) so much the better for the folks who wish to
 use
 RT-PREEMPT enabled kernels (and my thanks to those on this list who
 have
 been making it possible for the average user to even consider using
 them).

 Kent,

 What I would like to see, and will help generate as my limited time
 allows, generate some basic formulas to help guide people.  This is 
 off
 the top of my head, and is likely wrong given that I am spacey as 
 hell
 with allergies...

 max_pulse_rate (in Hz) = 1.0 /(maxjitter * Const)

 from a user perspective I think measures like latency or perceived
 maximum pulse rates are useless as guidance, for the simple reason
 that they do not express what a user might be interested in, but
 happen to be some low-level number which happens to be measurable
 easily

 what _I_ would be interested in isnt what happens to be easily
 measurable, but what a given setup can do for me

 for example:

 given a configuration, what is the quality of tracking the commanded
 path, and the speed/speed deviation at which that can be done

 tracking quality (I just made that term up) might translate into
 either a maximum path deviation (hard limit), or a distribution with
 percentiles plus a boundary

 this probably has both a spatial and a temporal dimension

 example for spacial accuracy: for test path X, results are within A
 uM 95% of the time with a maximum deviation of B uM

 I admit this probably cant be expressed as easily - I'm lacking
 theory and literature know how here but I would bet there is actually
 work in the area (or in related weapons or rocket research ;)

 maybe even there is a way to compute such values on the fly and
 mirror them in (a) pin(s); again that is blue sky and pure 
 speculation


 from that perspective, messages like 'unexpected realtime delay' are
 about as useful as dashboard message in my car saying 'cylinder #3
 took 0.7mS too long to fire':

 very interesting detail, now what bearing has that on my goals - do I
 need to stop, can I continue driving or will I bump into another car?

 ---

 at times it might be useful to lean back and ask yourself: does this
 make sense or can we do better than that

 - Michael



 where Const is probably something from 3 to 10 and denotes some
 fraction of base time period that you can put up with the jitter.
 Knowing how fast you can run the stepgen thread (assuming stepgen) 
 will
 then allow you to calculate your max speed using a given piece of
 mechanics/electronics/etc.  For example, if you are using something 
 like
 the Gecko G540, and motors that can do just over 300RPM, and 
 typically
 have 200 steps/rev.  We know that the G540 is hard-wired to 10
 microsteps/step.  So, we have 300*200*10 maximum steps/rev that the
 motors can do, and 10KHz for the step/sec.  So if we back calculate
 that, we are talking 100us for the max step rate, and you want your
 jitter to be a very small portion of that (for argument lets say 1/5 
 or
 20%).  So, if we have a 

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[andy pugh]

On 6 May 2013 19:48, Michael Haberler mai...@mah.priv.at wrote:

 in the case of latency, I am rather sure this is the case, which is why I 
 suggested to think outside the box

Typically we set base period == latency test result. Which is clearly bogus.
2x or 3x latency test result has also been suggested.

I doubt that in general the jitter leads to significant path
deviation, as it can (as far as I can see) only ever be a single step
wrong.

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

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

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[EBo]

does anyone remember the paper that was posted to the group that 
measured the loss in torque as a function of speed and jitter?  That 
might give us a more principled start to develop guidelines.  As a note, 
when you get anywhere close to the jitter threshold the apparent 
acceleration/deceleration is greater than what the motor can handle.

   hope that helps.

On May 6 2013 1:00 PM, andy pugh wrote:
 On 6 May 2013 19:48, Michael Haberler mai...@mah.priv.at wrote:

 in the case of latency, I am rather sure this is the case, which is 
 why I suggested to think outside the box

 Typically we set base period == latency test result. Which is clearly 
 bogus.
 2x or 3x latency test result has also been suggested.

 I doubt that in general the jitter leads to significant path
 deviation, as it can (as far as I can see) only ever be a single step
 wrong.

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

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


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

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[Christophe Grellier]

Hi,

Sorry to come back in the discussion : I first posted my question on the 
forum and I was suggested to come here to ask my initial question.
I know this is a devel mailing list, and that I may not have my place 
here ( direct translation from french to english, don't know if it 
sounds right )
Since you are talking about the user, I am what we could call a dumb 
user ;-)
I think the linuxcnc website lacks a CNC for the newbies page that 
would explain a few things with simple words.
If I consider my own example, even though I read your discussions for a 
few months, even though I am a linux user for about 10 years and even 
though I really enjoy computers, I must admit that I still don't get 
some simple things about how all this software and hardware work together.
- What is a stepper motor or a servo ? In french, a moteur can be a 
stepper motor, a handrill motor, or even a car engine. Those are quite 
different things.
- What are these pulses you are talking about ?
- Why the pulses need to have a good speed and rythm ?
- Why does Linuxcnc need a realtime kernel, while Mach3 can run on a 
stock Windows install ?
- What is the difference between software stepgen and hardware stepgen ?
- Is one better than the other ?
And so on ...
I think that I found my own answers on some of these questions, but I am 
still in a blury fog about it.
I know that some of the answers can be found here and there on the web, 
or on the Linuxcnc website.
Linuxcnc already has a lot of documentation on the wiki, but Linuxcnc is 
so powerful and has so much capabilities that a lot of this 
documentation is like chinese for the newbie.
Maybe a tagging the pages with easy, intermediate, advanced might 
help.

Please don't misunderstand my words : there is no critics or complaining 
here. ( English is not my native language, so I may not have formulated 
my thoughts the right way ).
But since you are talking about the user, this is simply the point of 
view of a dumb user, that don't have a clear overview of how all these 
complex lego things work together.
I started using a CNC 2 years ago, milling pieces of wood several times 
a week, and I must admit that I am a bit frustrated that I still don't 
really understand how all this work together.
I know this is not your problem : you are already doing so much.
Thanks for amazing work !

Christophe
--
Christophe Grellier
Guitares acoustiques
8 rue de Rouans - 44680 Chéméré
Tél. 02.40.64.17.96
www.grellier.fr http://www.grellier.fr

Le 06/05/2013 21:00, andy pugh a écrit :
 On 6 May 2013 19:48, Michael Haberler mai...@mah.priv.at wrote:

 in the case of latency, I am rather sure this is the case, which is why I 
 suggested to think outside the box
 Typically we set base period == latency test result. Which is clearly bogus.
 2x or 3x latency test result has also been suggested.

 I doubt that in general the jitter leads to significant path
 deviation, as it can (as far as I can see) only ever be a single step
 wrong.



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

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[Jon Elson]

Christophe Grellier wrote:
 - What is a stepper motor or a servo ? In french, a moteur can be a 
 stepper motor, a handrill motor, or even a car engine. Those are quite 
 different things.
   
A stepper motor has fixed positions built into it, and will move to a 
particular
position when commanded.  Feeding it more power will just make it
hold that position more rigidly.  It is normally used with no position 
sensing
device.  A servo motor generally moves smoothly when power is
applied, and will move faster when more power is applied.  It must be
used with a position sensing device, as feeding power to the motor gives
you no idea how much it has actually moved, due to variations in
inertia and friction.
 - What are these pulses you are talking about ?
 - Why the pulses need to have a good speed and rythm ?
   
A stepper motor responds a bit like a mass with a spring attached.
With the winding current in a particular pattern, it will fall into
magnetic lock every four full step positions.  If the loads are
excessive, or sudden speed changes are commanded, the motor
can jump from one locked position to another.  If the step timing
is not continuous, it can be hard for the magnetics in the motor
to follow the apparent sudden changes in the speed of the
electrical poles, and these jumps become more likely.
 - Why does Linuxcnc need a realtime kernel, while Mach3 can run on a 
 stock Windows install ?
   
Mach uses a realtime driver that attempts to do the same thing, for a
very small part of the Mach system.  It runs into many of the same
problems with interrupt latency.
 - What is the difference between software stepgen and hardware stepgen ?
 - Is one better than the other ?
   
Ragged step timing makes it hard for the stepper motors to follow the
desired movement.  If the timing jitter exceeds some amount depending
on mass, stiffness, the motor and the stepper drive, the motor will skip
steps of fall out of sync completely, leading to a stalled motor for the 
rest
of the movement.  it will pull back into sync when the commanded move
comes to a stop, leaving the machine at a different position than commanded.
Software step generation has a fundamental limit on the precision of
timing of the steps.  For instance, the interrupt period on the base thread
in a LinuxCNC system might be 20 us.  The equivalent time is 100 ns
on the Pico Systems Universal Stepper Controller board, or 200 times
finer resolution.  The 20 us granularity of step timing is not such a great
deal at modest speeds, but if you need to produce step pulses at
10,000 per second (rather fast for full-step drives) then the 20 us
granularity means that the next faster or slower speed is a 20% jump
in speed.  So, acceleration and deceleration at 10K steps/second
is quite coarse.  With our step generator at the same speed, the granularity
is only 1 part per thousand, which the motor will never notice.

Jon

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

Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?

[Christophe Grellier]

Clear explanation. Thank you, Jon.
I will try to make a page on the wiki, with your answers, if you're OK.

Christophe


Le 07/05/2013 04:31, Jon Elson a écrit :
 Christophe Grellier wrote:
 - What is a stepper motor or a servo ? In french, a moteur can be a
 stepper motor, a handrill motor, or even a car engine. Those are quite
 different things.

 A stepper motor has fixed positions built into it, and will move to a
 particular
 position when commanded.  Feeding it more power will just make it
 hold that position more rigidly.  It is normally used with no position
 sensing
 device.  A servo motor generally moves smoothly when power is
 applied, and will move faster when more power is applied.  It must be
 used with a position sensing device, as feeding power to the motor gives
 you no idea how much it has actually moved, due to variations in
 inertia and friction.
 - What are these pulses you are talking about ?
 - Why the pulses need to have a good speed and rythm ?

 A stepper motor responds a bit like a mass with a spring attached.
 With the winding current in a particular pattern, it will fall into
 magnetic lock every four full step positions.  If the loads are
 excessive, or sudden speed changes are commanded, the motor
 can jump from one locked position to another.  If the step timing
 is not continuous, it can be hard for the magnetics in the motor
 to follow the apparent sudden changes in the speed of the
 electrical poles, and these jumps become more likely.
 - Why does Linuxcnc need a realtime kernel, while Mach3 can run on a
 stock Windows install ?

 Mach uses a realtime driver that attempts to do the same thing, for a
 very small part of the Mach system.  It runs into many of the same
 problems with interrupt latency.
 - What is the difference between software stepgen and hardware stepgen ?
 - Is one better than the other ?

 Ragged step timing makes it hard for the stepper motors to follow the
 desired movement.  If the timing jitter exceeds some amount depending
 on mass, stiffness, the motor and the stepper drive, the motor will skip
 steps of fall out of sync completely, leading to a stalled motor for the
 rest
 of the movement.  it will pull back into sync when the commanded move
 comes to a stop, leaving the machine at a different position than commanded.
 Software step generation has a fundamental limit on the precision of
 timing of the steps.  For instance, the interrupt period on the base thread
 in a LinuxCNC system might be 20 us.  The equivalent time is 100 ns
 on the Pico Systems Universal Stepper Controller board, or 200 times
 finer resolution.  The 20 us granularity of step timing is not such a great
 deal at modest speeds, but if you need to produce step pulses at
 10,000 per second (rather fast for full-step drives) then the 20 us
 granularity means that the next faster or slower speed is a 20% jump
 in speed.  So, acceleration and deceleration at 10K steps/second
 is quite coarse.  With our step generator at the same speed, the granularity
 is only 1 part per thousand, which the motor will never notice.

 Jon

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



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