Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Dewey Garrett]

>  Thanks for correcting my outdated information!

My statement:
" The commit 2dbb2f640f changed the interface between
EMCIO and TASK to use a memory mapped interface."
was incomplete and not really accurate.

To clarify:

The tooldata interface was altered to use a memory mapped
interface reducing the size of the NML EMC_STAT message
which was greatly increased when the number of tools
(pockets actually) was changed to 1000 (CANON_POCKETS_MAX=1001).

NML is still used for TASK <--> EMCIO communication 
for commands and status but the status message is now
small in size as it does not contain data for all possible
1000 tools (pockets).

apologies for the confusion.
-- 
Dewey Garrett



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

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Bari]

On 12/5/22 16:18, Steffen Möller wrote:


I see a distributed control system. Many units that know the units that are 
neighboured (i.e. that they cooperate with) but do not need to see the complete 
world. And if the neighbours are allowed to be dynamic, then tis would then 
even work with mobile systems, but this is where ROS kicks in, right?



Yes, ROS2 would be for controlling the mobile roving platform. The 
machine tool mounted on a mobile platform would use LCNC to control the 
axis motors and spindles.


Also this has been done:

https://github.com/zultron/hal_ros_control/

This package provides interfaces to Machinekit  
HAL from ROS. It is expected to realize these benefits:


 * Bring real-time control to ROS with Machinekit RTAPI
 * Run on inexpensive PC and ARM hardware
 * Enable setting up many robot hardware interfaces with configuration
   only, no programming
 * Leverage Machinekit's wide variety of real-time components:
 o Hardware drivers: EtherCAT, BeagleBone GPIO, Mesa Electronics
   AnythingI/O FPGA cards, PC parallel port
 o Motor control: quadrature encoders, step/direction, PWM
   generators, PID controllers
 o Arithmetic: limit position/velocity/acceleration, scale/offset,
   low-pass filter, derivative/integral, multiplexer
 o Logic: and/or/xor/not, look-up tables, debouncer, flip-flop
 o And many more, plus simple tools to write custom components in C



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

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Sebastian Kuzminsky]

On 12/5/22 15:18, Steffen Möller wrote:


It would make some good sense to me not to use DDS that currently runs in the 
base thread.


The base thread and servo thread both currently do not communicates via 
NML, and I don't think anyone(?) is suggesting changing that.


NML communication is currently used between Task (which is a sort of 
central coordinator of the LinuxCNC processes & components) and the 
GUIs.  NML is used for non-realtime communications only.


Latency in this communication channel is still important, for example 
when a user lets go of the jog button on the keyboard the GUI should 
communicate that promptly to Task so Task can tell the motion controller 
to stop jogging.



--
Sebastian Kuzminsky


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

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Steffen Möller]

> Gesendet: Montag, 05. Dezember 2022 um 21:12 Uhr
> Von: "Bari" 
> An: emc-developers@lists.sourceforge.net
> Betreff: Re: [Emc-developers] A vision for working now to LinuxCnc version 10
>
> On 12/5/22 10:57, Steffen Möller wrote:
> 
> >
> > I guess any such industrial decision making is equally based on the 
> > "unknown" when it comes to interoperability. The EU funds (did fund?) COST 
> > actions for this purpose - bring industrial and academic partners together 
> > and squeeze something like a joint standard out of them. Since quite a 
> > number of CNC companies are located in Europe, it seems like worthwhile to 
> > write something up with them. Any such COST action pays for travel, not for 
> > people, except some smallish side projects when someone visits cross 
> > country. Opinions?
> >
> Good idea. Do you have any more info on COST. Unfortunately they chose 
> an acronym that makes it difficult to search for.

https://www.cost.eu/

In 2010 or so I had helped writing a successful application. They have an open 
call.

> Interesting to see some DDS performance testing. Looks like we might use 
> what they call "local delivery" for latency <1mS .
> 
> https://www.rti.com/blog/latest-connext-dds-ros-2-performance-benchmarks

It would make some good sense to me not to use DDS that currently runs in the 
base thread. 

I see a distributed control system. Many units that know the units that are 
neighboured (i.e. that they cooperate with) but do not need to see the complete 
world. And if the neighbours are allowed to be dynamic, then tis would then 
even work with mobile systems, but this is where ROS kicks in, right?

Steffen


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

Re: [Emc-developers] Bug#1025433: Bug#1025433: Copyright issue

[Alec Ari via Emc-developers]

Both of these files are different, all authors are arguably correct. Paolo 
doesn't work on LinuxCNC, he didn't write the one in LinuxCNC. The LinuxCNC one 
is based off other work, and Paolo's as well.

My vote is on not a bug, not an issue.

Alec





On Monday, December 5, 2022 at 08:37:28 AM CST, andy pugh  
wrote: 





On Mon, 5 Dec 2022 at 14:14, Adam Ant  wrote:

> Source: linuxcnc
>
> src/rtapi/procfs_macros.h incorrectly attributes copyright.
>
> The original file can be found here:
>
> http://svn.savannah.gnu.org/viewvc/rtai/magma/base/include/rtai_proc_fs.h?view=markup


At what point does a file become a new file? The file in LinuxCNC appears
to be a sub-set of an original file contributed to RTAI by Erwin Roll.

So who would be the correct copyright holder?  It is possibly not Paulo
either,

-- 
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


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

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Johannes P Fassotte]

On 12/5/2022 6:10 AM, Bari wrote:
A pdf that explains where DDS fits in to industry 
https://www.dds-foundation.org/sites/default/files/RTILunchAddressOMG2014v2.pdf


If we use DDS it might make LCNC compatible with the industry of the 
future. Is everyone jumping onto the DDS bandwagon? Which messaging 
system will gives us the best chance at fitting into factory 
automation, CNC machines and robotics of the near future (next 20 
years)? Will this best solve the issues of separating the controls 
from the GUI over the network as well as connect LCNC to factory 
controls and robot material handlers? Is this mission creep or killing 
two birds with one stone?


Bari,

I tend to agree that this is a good solution. In looking at the openDDS 
project I see that the project has been forked 408 times on github 
including my own fork. It also has a good developers guide that contains 
some 249 pages of information and also has the required support package 
for TOA available which has development guide that has some 1262 pages. 
OpenDDS seems like it has good documentation on its own and thus only 
requires LinuxCnc documentation to be added on how to get it to install 
and get it working  with LinuxCnc.


I think that working on this is much more beneficial to LinuxCnc than my 
previous concept which obviously does not have a lot of support so I may 
as well forget about working on that. But that does not mean that the 
requirement for improved network capability does not exist.


OpenDDS has its own own development team which thus requires less 
support from the LinuxCnc development team. All that needs to be done is 
to get it working within LinuxCnc. So my intention is to work on helping 
to accomplishing that. OpenDDS uses CorBa instead of Redis so Redis will 
most likely not be required.


My starting point for this project is to get openDDS  working inside and 
in parrallel with current LinuxCnc master code, without changing 
LinuxCnc  code and to only add the code required to make openDDS 
functional within LinuxCnc. Once it is functioning and able to run 
simple self tests then  start working on routing individual LinuxCnc 
commands along with the status data of those into openDDS and route 
those to an prior developed Labview based UI running on a Windows10 
computer. That will be helpful with checking the networking functions 
and any debugging work. Labview has some tools that are very handy for 
doing that but others joining the project could decide use any UI that 
has remote ability for there own testing.


This seems like an excellent project to undertake and I'm somewhat 
excited about getting started on this project.  OpenDDS appears to have 
good support and is already being used for such purposes. I have 
downloaded what I believe to be all required items for installation and 
will get my Debian development system set up to start doing work on this 
before the end of the year.






___
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] A vision for working now to LinuxCnc version 10

[gene heskett]

On 12/5/22 10:10, Bari wrote:
A pdf that explains where DDS fits in to industry 
https://www.dds-foundation.org/sites/default/files/RTILunchAddressOMG2014v2.pdf


If we use DDS it might make LCNC compatible with the industry of the 
future. Is everyone jumping onto the DDS bandwagon? Which messaging 
system will gives us the best chance at fitting into factory automation, 
CNC machines and robotics of the near future (next 20 years)? Will this 
best solve the issues of separating the controls from the GUI over the 
network as well as connect LCNC to factory controls and robot material 
handlers? Is this mission creep or killing two birds with one stone?


I am inclined to think the latter, based on we can either help set the 
standards, by doing it first and hopefully right or forever chasing the 
proprietary stuff.


I think we have the contributor talent to do it! But watch the licensing 
very carefully.


Take care and stay well everybody.

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] A vision for working now to LinuxCnc version 10

[Bari]

On 12/5/22 10:57, Steffen Möller wrote:



I guess any such industrial decision making is equally based on the "unknown" 
when it comes to interoperability. The EU funds (did fund?) COST actions for this purpose 
- bring industrial and academic partners together and squeeze something like a joint 
standard out of them. Since quite a number of CNC companies are located in Europe, it 
seems like worthwhile to write something up with them. Any such COST action pays for 
travel, not for people, except some smallish side projects when someone visits cross 
country. Opinions?

Good idea. Do you have any more info on COST. Unfortunately they chose 
an acronym that makes it difficult to search for.



Interesting to see some DDS performance testing. Looks like we might use 
what they call "local delivery" for latency <1mS .


https://www.rti.com/blog/latest-connext-dds-ros-2-performance-benchmarks



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

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Steffen Möller]

> Gesendet: Montag, 05. Dezember 2022 um 17:33 Uhr
> Von: "Johannes Fassotte" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] A vision for working now to LinuxCnc version 10
>
> DDS looks very interesting and I will plan to look into it more today. Thanks 
> for the link to DDS. Future compatibility with other industrial work is very 
> important and highly desirable.
> 
> Johannes - 
> Fairbanks, AK 99712
> 
> > On Dec 5, 2022, at 6:13 AM, Bari  wrote:
> > 
> > A pdf that explains where DDS fits in to industry 
> > https://www.dds-foundation.org/sites/default/files/RTILunchAddressOMG2014v2.pdf
> > 
> > If we use DDS it might make LCNC compatible with the industry of the 
> > future. Is everyone jumping onto the DDS bandwagon? Which messaging system 
> > will gives us the best chance at fitting into factory automation, CNC 
> > machines and robotics of the near future (next 20 years)? Will this best 
> > solve the issues of separating the controls from the GUI over the network 
> > as well as connect LCNC to factory controls and robot material handlers?

I guess any such industrial decision making is equally based on the "unknown" 
when it comes to interoperability. The EU funds (did fund?) COST actions for 
this purpose - bring industrial and academic partners together and squeeze 
something like a joint standard out of them. Since quite a number of CNC 
companies are located in Europe, it seems like worthwhile to write something up 
with them. Any such COST action pays for travel, not for people, except some 
smallish side projects when someone visits cross country. Opinions?

> Is this mission creep or killing two birds with one stone?
It is "Two flies with one clap."

Best,
Steffen


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

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Johannes Fassotte]

DDS looks very interesting and I will plan to look into it more today. Thanks 
for the link to DDS. Future compatibility with other industrial work is very 
important and highly desirable.

Johannes - 
Fairbanks, AK 99712

> On Dec 5, 2022, at 6:13 AM, Bari  wrote:
> 
> A pdf that explains where DDS fits in to industry 
> https://www.dds-foundation.org/sites/default/files/RTILunchAddressOMG2014v2.pdf
> 
> If we use DDS it might make LCNC compatible with the industry of the future. 
> Is everyone jumping onto the DDS bandwagon? Which messaging system will gives 
> us the best chance at fitting into factory automation, CNC machines and 
> robotics of the near future (next 20 years)? Will this best solve the issues 
> of separating the controls from the GUI over the network as well as connect 
> LCNC to factory controls and robot material handlers? Is this mission creep 
> or killing two birds with one stone?
> 
> 
> 
> ___
> 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] A vision for working now to LinuxCnc version 10

[Bari]

A pdf that explains where DDS fits in to industry 
https://www.dds-foundation.org/sites/default/files/RTILunchAddressOMG2014v2.pdf


If we use DDS it might make LCNC compatible with the industry of the 
future. Is everyone jumping onto the DDS bandwagon? Which messaging 
system will gives us the best chance at fitting into factory automation, 
CNC machines and robotics of the near future (next 20 years)? Will this 
best solve the issues of separating the controls from the GUI over the 
network as well as connect LCNC to factory controls and robot material 
handlers? Is this mission creep or killing two birds with one stone?




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

Re: [Emc-developers] feed hold ?

[gene heskett]

On 12/5/22 09:26, John Thornton wrote:

Wait till you get my age... I'm 69 now.

JT


Or mine, I'm 88 now. ;)>


On 12/4/2022 5:00 PM, Chris Morley wrote:

lol thanks Phil. I hit 50 and can only remember half of anything :)

Chris


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] feed hold ?

[Chris Morley]

Lots Spring left in that chicken. We have guys still coming to work at the 
plant full time at 72 and part time ..up to 79!


Chris



Sent from my Galaxy



 Original message 
From: John Thornton 
Date: 2022-12-05 6:29 a.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] feed hold ?

Wait till you get my age... I'm 69 now.

JT

On 12/4/2022 5:00 PM, Chris Morley wrote:
> lol thanks Phil. I hit 50 and can only remember half of anything :)
>
> Chris
> 
> From: Phill Carter 
> Sent: December 4, 2022 10:48 PM
> To: linuxcnc-developers 
> Subject: Re: [Emc-developers] feed hold ?
>
> There is a motion.jog-inhibit pin in 2.9 and later
>
>
>> On 5 Dec 2022, at 7:16 am, Chris Morley  wrote:
>>
>> Yes it was miss named but it was meant to stop all motion. Only a thread 
>> pass would finish. Which you could certainly argue was wrong too.
>>
>> After I realized the name was bad it was kinda too late.
>>
>> Chris
>>
>>
>>
>> Sent from my Galaxy
>>
>>
>>
>>  Original message 
>> From: andy pugh 
>> Date: 2022-12-04 11:32 a.m. (GMT-08:00)
>> To: EMC developers 
>> Subject: Re: [Emc-developers] feed hold ?
>>
>> On Sun, 4 Dec 2022 at 19:19, Jon Elson  wrote:
>>
>>> Yikes!  I can see arguments both ways, but feed hold or feed
>>> inhibit seems like it should stop all motion,
>>
>> I think it should stop feeds (or it would be called
>> "all-motion-inhibit" :-)
>>
>> --
>> 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
>>
>> ___
>> 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] Bug#1025433: Copyright issue

[andy pugh]

On Mon, 5 Dec 2022 at 14:14, Adam Ant  wrote:

> Source: linuxcnc
>
> src/rtapi/procfs_macros.h incorrectly attributes copyright.
>
> The original file can be found here:
>
> http://svn.savannah.gnu.org/viewvc/rtai/magma/base/include/rtai_proc_fs.h?view=markup


At what point does a file become a new file? The file in LinuxCNC appears
to be a sub-set of an original file contributed to RTAI by Erwin Roll.

So who would be the correct copyright holder?  It is possibly not Paulo
either,

-- 
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] feed hold ?

[John Thornton]

Wait till you get my age... I'm 69 now.

JT

On 12/4/2022 5:00 PM, Chris Morley wrote:

lol thanks Phil. I hit 50 and can only remember half of anything :)

Chris

From: Phill Carter 
Sent: December 4, 2022 10:48 PM
To: linuxcnc-developers 
Subject: Re: [Emc-developers] feed hold ?

There is a motion.jog-inhibit pin in 2.9 and later



On 5 Dec 2022, at 7:16 am, Chris Morley  wrote:

Yes it was miss named but it was meant to stop all motion. Only a thread pass 
would finish. Which you could certainly argue was wrong too.

After I realized the name was bad it was kinda too late.

Chris



Sent from my Galaxy



 Original message 
From: andy pugh 
Date: 2022-12-04 11:32 a.m. (GMT-08:00)
To: EMC developers 
Subject: Re: [Emc-developers] feed hold ?

On Sun, 4 Dec 2022 at 19:19, Jon Elson  wrote:


Yikes!  I can see arguments both ways, but feed hold or feed
inhibit seems like it should stop all motion,


I think it should stop feeds (or it would be called
"all-motion-inhibit" :-)

--
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

___
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] Bug#1025433: Copyright issue

[Adam Ant]

Source: linuxcnc

src/rtapi/procfs_macros.h incorrectly attributes copyright.

The original file can be found here:
http://svn.savannah.gnu.org/viewvc/rtai/magma/base/include/rtai_proc_fs.h?view=markup


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

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Steffen Möller]

> Gesendet: Montag, 05. Dezember 2022 um 03:16 Uhr
> Von: "Bari" 
> An: emc-developers@lists.sourceforge.net
> Betreff: Re: [Emc-developers] A vision for working now to LinuxCnc version 10
>
> On 12/4/22 19:08, Steffen Möller wrote:
> 
> >
> >> Gesendet: Sonntag, 04. Dezember 2022 um 23:39 Uhr
> >> Von: "Chris Morley" 
> >> An: "EMC developers" 
> >> Betreff: Re: [Emc-developers] A vision for working now to LinuxCnc version 
> >> 10
> >>
> >>
> >>
> >>> My work on this will  continue, initially getting the required network
> >>> code in place for both TCP and UDP connections and also the Redis base
> >>> to handle the distribution of Cmd, Status and Error data to where ever
> >>> it is needed. Once that is done change my routing commands away from the
> >>> NML remote TCP ports into the newly created TCP server ports for further
> >>> testing and evaluation and development of any additional code
> >>> requirements. The same for status and errors.
> >>
> >> Do you mean linuxcnc would NML into a redis database and then network out 
> >> of redis?
> >>
> >> A couple of things come to mind that I run into as a UI builder:
> >>
> >> How does HAL fall into this? Many things the uis currently interact with 
> >> are HAL related.
> >>
> >> Error handling is terribly difficult. The 'consumed' error messages make 
> >> it very difficult to detect errors and act accordingly, particularly if 
> >> you have multiple ui sources.
> >>
> >> The fact that linuxcnc doesn't have an internal memory of say jog rate, 
> >> means every ui has one, yet unless you use HAL you can not communicate 
> >> between uis. This is what I think you mean by 'python based addons' we 
> >> worked around this in qtvcp and gladevcp by adding jograte to python's 
> >> status module. Mostly because linuxcnc and NML are too big of a black box 
> >> with no docs/examples.
> >>
> >> Can your proposal help with the 'no docs blackbox' problem too? Redis is 
> >> certainly mainstream.
> > I think we all somewhat agree that eventually we want to have a system with 
> > which we can somehow control multiple machines (as in a larger production 
> > facility) and those machines may be in different rooms or (as for 
> > telescopes) on another hill or wherever. But mostly we are after local 
> > synchronisation to load or unload or change the position of some piece or 
> > .. whatever.
> >
> > Would you think it would be a reasonable assumption that there may be 
> > scenarios in which two different GUIs want to control the same machine? A 
> > complicated workflow to finish a machine could have different GUIs that 
> > control different parts of the production. Or two colleagues (one on each 
> > hill) with different expertises and different expert software are 
> > interested in the same machine but look at it differently - one from 
> > support and tool maintenance, the other the with an interest in the part 
> > maybe. Should that be something to aim for then those local variables in 
> > the GUI likely need to somehow move towards something that works like HAL.
> >
> > I have no idea if there is a word for that in real time computing, but I 
> > see that variables are likely used in layers. The threads with shorter 
> > periods (base thread) I see less likely to read from variables (with 
> > well-defined exceptions) that are controlled by threads with a longer 
> > periods (server thread). And all human activities that a GUI represents are 
> > so damn slow, that this is just another layer that it does not feel natural 
> > to occupy HAL with them, so those became part of the GUI. Maybe we also 
> > need a Human Abstraction Layer (which would unfortunately have the same 
> > abbreviation) and have different GUIs communicate with that? And to prepare 
> > or some AI steering our CNC, maybe a better word would be "Intent 
> > Abstraction Layer"?
> >
> > That was not too wild, was it?
> > Steffen
> >
> What I actually run into is having to synchronize multiple CNC machines 
> with each other and with robots. For example I was asked to build a 
> large machine with four 5-axis machines on each quadrant of a large work 
> volume~2x3x0.5m. Each machine could operate independently from each 
> other yet would have a small overlap of their workspace with each other 
> for 100% coverage of the work volume. Having one instance of LCNC to 
> control all would have been nice but I had to run four different 
> controllers and do some fancy CAM plus collision detection (in case I 
> made a mistake in CAM).
> 
> I am currently working on a CNC multi-axis lathe for glassworking. The 
> head and tailstock are both powered and most of the time they are 
> synchronized in rotation to each other. It has the equivalent of 
> multiple independent live tool turrets with tooling and torches that are 
> synchronized to the head and tailstock rotation as well. It also has to 
> automatically load and unload glass tubes. I can make this work with 
> LCNC as-is but it would be