subject:"\[Emc\-developers\] A vision for working now to LinuxCnc version 10"

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

2022-12-19 Thread Johannes Fassotte

I had made some changes in my note file names to add .txt file
extension. Its liklye best the use the main link to navigate to my notes
and other info when posted.

https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work

After running the 6 tests it completed so far makes me confident enough
that OpenDDS is installed and able to function. I will be working on
trying to get it linked into my LinuxCnc master clone and Initially to
the tasks related to the IO control for some of the simple on/off
commands and their status replies. Not at all sure on how to do that
yet. Will need to do more research on how to integrate it into a
application.

On 12/18/2022 5:23 PM, Bari wrote:

On 12/18/22 18:24, Johannes Fassotte wrote:

I had a chance to do some work on OpenDDS while waiting for parts for
another project. I installed OpenDDS with its depends on my Linux
Mint 20 development computer and made some notes on how I installed
it and all the depends. I have not checked out the built in tests yet
described in the OpenDDS Developers Guide which need to run under Perl.

I have put my current install "first.dds.install" note on github.

https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work/install-notes/first.dds.install

Main folder at:

https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work

I did not note how long configure ran, but "make" took about 2
hours, sudo "make install" about 2 minutes.

Hope the info there will be helpful and will add to these as the
project continues.

Johannes,

Thank you for kicking this off.

Looks like a typo in your first link. This works for me:

https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work/blob/main/install-notes/first.dds.install

___
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

2022-12-18 Thread Bari


On 12/18/22 18:24, Johannes Fassotte wrote:

I had a chance to do some work on OpenDDS while waiting for parts for 
another project. I installed OpenDDS with its depends on my Linux Mint 
20 development computer and made some notes on how I installed it and 
all the depends. I have not checked out the built in tests yet 
described in the OpenDDS Developers Guide  which need to run under Perl.


I have put my current install  "first.dds.install" note on github.

https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work/install-notes/first.dds.install 



Main folder at:

https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work

I did not note how long configure ran, but  "make" took about 2 
hours,  sudo "make install" about 2 minutes.


Hope the info there will be helpful and will add to these as the 
project continues.




Johannes,

Thank you for kicking this off.

Looks like a typo in your first link. This works for me:

https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work/blob/main/install-notes/first.dds.install



___
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

2022-12-18 Thread Johannes Fassotte

I had a chance to do some work on OpenDDS while waiting for parts for
another project. I installed OpenDDS with its depends on my Linux Mint
20 development computer and made some notes on how I installed it and
all the depends. I have not checked out the built in tests yet described
in the OpenDDS Developers Guide which need to run under Perl.

I have put my current install "first.dds.install" note on github.

https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work/install-notes/first.dds.install

Main folder at:

https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work

I did not note how long configure ran, but "make" took about 2 hours,
sudo "make install" about 2 minutes.

Hope the info there will be helpful and will add to these as the project
continues.

On 12/6/2022 10:55 AM, Bari wrote:

On 12/5/22 15:21, Johannes P Fassotte wrote:

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.

Sounds great. Let us know when you have a public repo so that we can
follow your deep dive into this.

___
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

2022-12-16 Thread Jérémie Tarot

Le ven. 16 déc. 2022 à 16:09, Steffen Moeller  a écrit :
>
> I sense that there is an agreement that everyone would like such a
> distribute CNC meta-layer to emerge.  Should this thread not somehow be
> transferred into some wiki page or so such that we can operationalize a
> bit on what needs to be done and to find volunteers to address the
> identified tasks?

Agreed. Converting it to some kind of RFC in a GH wiki page would be
nice, coupled with a dedicated GH discussion to elaborate a plan,
identify tasks, set up a project, and call for participation.

--
Jérémie Tarot


___
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

2022-12-16 Thread Steffen Moeller


I sense that there is an agreement that everyone would like such a
distribute CNC meta-layer to emerge.  Should this thread not somehow be
transferred into some wiki page or so such that we can operationalize a
bit on what needs to be done and to find volunteers to address the
identified tasks?

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

2022-12-06 Thread Bari


Let us know if anyone find any negatives to openDDS besides some complexity.

On 12/6/22 15:41, Nicklas SB Karlsson wrote:

Read that DDS include application programming interfaces (APIs) and
libraries of implementations in among others ADA and that's great.






___
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

2022-12-06 Thread Nicklas SB Karlsson

Read that DDS include application programming interfaces (APIs) and
libraries of implementations in among others ADA and that's great.


tis 2022-12-06 klockan 13:55 -0600 skrev Bari:
> On 12/5/22 15:21, Johannes P Fassotte wrote:
> 
> > 
> > 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.
> > 
> > 
> Sounds great. Let us know when you have a public repo so that we can 
> follow your deep dive into this.
> 
> 
> ___
> 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

2022-12-06 Thread Bari


On 12/5/22 15:21, Johannes P Fassotte wrote:



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.



Sounds great. Let us know when you have a public repo so that we can 
follow your deep dive into this.



___
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

2022-12-05 Thread 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

2022-12-05 Thread 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

2022-12-05 Thread 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

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

2022-12-05 Thread 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

2022-12-05 Thread 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

2022-12-05 Thread 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

2022-12-05 Thread 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

2022-12-05 Thread 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

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

2022-12-05 Thread 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

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

2022-12-04 Thread Bari


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 nice to have CNC machines synchronize with 
robot arms that use ROS2 for control.


ROS2 decided to use DDS for their real time messaging vs 0mq. I have 
been looking at OpenDDS https://github.com/objectcomputing/OpenDDS


More on DDS  https://design.ros2.org/articles/ros_on_dds.html

https://en.wikipedia.org/wiki/Data_Distribution_Service

DDS middleware is architecturally based on the publish-subscribe design 
pattern. The publish-subscribe architecture ensures that the application 
providing the data and the application accessing

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

2022-12-04 Thread Steffen Möller




> 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



___
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

2022-12-04 Thread Chris Morley




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

Chris



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

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

2022-12-04 Thread Johannes P Fassotte


Some answers In reply to one of Chris Morley's message by number.

And near the end past 7 some general comments about my goals for this 
project:



1 Chris : "ok You must realize almost no one uses the networking 
capability of linuxcnc."



Answer:  Yes that is true. But that is only because the remote NML 
interface has not been updated to include all required information that 
is handled by separate Python or other code that is not part of NML, and 
of coarse NML a lot harder to deal with. The second reason is that it 
has not been promoted at all as a option for interfacing UI user 
generated code. And the the third reason is that UI developers utilize 
methods that have been made available to them. In other words no 
standard network interface means no UI development for networks by UI 
developers.



2 Chris : "It seems to be the case that most machines have the controls 
on the machine so over network is not that important. Certainly its a 
limitation in some cases. I guess I don't see why its 
the-most-important-thing that you seem to?"



Answer:  The migration of technology is to interconnect various sub 
functions using network technology. Thus not including a user interface 
to provide that technology is not progress and instead is suppression of 
flexibility. Networking within LinuxCnc is already present in areas such 
as connection to a Machine using the Mesa networking FPGA cards and 
control of spindle drives.  Why then would such a user interfaces be 
excluded? It is not used now because it does not exists. If it was 
present it would be used because of natural progression of code development.



3 Chris : "I am not sure why you are hostile. I am really trying to 
understand exactly what you want. Machinekit did work on networking, 
though I think it was just HAL. It's why I mentioned it."



Answer:  I'm not being hostile.  I'm at a loss as to why there is so 
little interest and constructive support on how to develop the code to 
allow make it easy to interface UI's using network technology and thus 
my frustration shows. Spin offs like Machinekit and those of Tormach all 
come from LinuxCnc and LinuxCnc is thus the common point and thus 
LinuxCnc users and developers should likely do the development work for 
such a user interface. Tormach's version being a closer match because of 
its use of the Redis data base to handle shuffling of all kinds of 
variable data where needed. Redis was of coarse proposed many years ago 
to be encluded in LinuxCnc and was actually being worked on and 
implemented in some versions. Redis allows for a direct interface for 
network data distribution.


To me making LinuxCnc more flexible is more important that adding it to 
Debian since compiling from source is not difficult and has worked well 
for users of LinuxCnc for many years. I will always build from source.  
Source is controlled by the assigned developers and thus I hope that the 
developers can provide some guidance with either suggested code or block 
diagrams to help my self and others who desire to aid in working on such 
a user interface.


4 Chris : "I'll tell you I know almost nothing about networking. I'm a 
self taught programmer that uses hack-till-it-works more then 
engineering a solution. I have done tons of work in linuxcnc, but not so 
much on NML."



Answer:  I think that NML is a real pain to understand fully for 
everyone but it does work well. To replace it would be quite difficult 
and very time consuming.  It is better to work on other code 
improvements and enhancements. There are many option to replace NML but 
all would likely require LinuxCnc to be torn completely apart and then 
glued back to together with the replacement for NML included. I think 
that the updated versions of Redis may well be able to do that job.


5 Chris A:  " I'll tell you I know almost nothing about networking. I'm 
a self taught programmer that uses hack-till-it-works more then 
engineering a solution. I have done tons of work in linuxcnc, but not so 
much on NML.


And

5 Chris B:  "I'd be happy if NML was replaced to something mainstream so 
there was examples to go by. Machinekit wanted to use ZMQ but never got 
all the way there as I understand it. But it is beyond my skill."



Answer:  I think that most of us are doing exactly the same thing. It is 
nice that NML fuctions can be added fairly easily by modification of 
some tasks. Since that is possible it makes replacing NML a lot less 
important. I usually use the play until it works as expected technique 
and includes remote assess to HAL.



6 Chris: "I certainly agree that inter-ui communication is not good in 
linuxcnc and often a real pain to work around. Some hardware paradigm 
don't lend themselves to multiple 'blind' ui control."


Answer:  I agree with you fully. I think that this is mainly due to 
additions that have been made to LinuxCnc that are not able to talk to 
each other and run separately. When you think about that it

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

2022-12-04 Thread Sebastian Kuzminsky


On 12/4/22 08:16, Dewey Garrett wrote:


A correction:


NML is used between the GUI(s) and Task, and between Task and IO.


The commit 2dbb2f640f changed the interface between
EMCIO and TASK to use a memory mapped interface.

This facility has been in use in the master branch
since its incorporation in January 2021 and is
currently included in the 2.9 branch.


Thanks for correcting my outdated information!


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

2022-12-04 Thread Dewey Garrett



A correction:

> NML is used between the GUI(s) and Task, and between Task and IO.

The commit 2dbb2f640f changed the interface between
EMCIO and TASK to use a memory mapped interface.

This facility has been in use in the master branch
since its incorporation in January 2021 and is
currently included in the 2.9 branch.

The prior NML tool interface remains available as
a configuration option (--enable-toolnml) and enables
use of the TOOL_NML directive in the code [1].

This option is not routinely built nor tested.
As no known person seems to use, maintain, or test the
former TOOL_NML methods, the facility should probably
be considered as a deprecated provision subject to
removal.

Ref:
https://github.com/LinuxCNC/linuxcnc/commit/2dbb2f640f
https://github.com/LinuxCNC/linuxcnc/blob/2.9/src/configure.ac#L177

Note:
[1] The TOOL_NML directive is found in 15 places in the code:

$ find src -iname '*.*[ch]' -exec grep -Hc "TOOL_NML" {} \;|grep -v :0$|wc -l
15

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

2022-12-04 Thread Sebastian Kuzminsky


On 12/3/22 19:20, Jon Elson wrote:
Underneath HAL there is NML that links major sections of LinuxCNC 
together and makes the state of major components available.  NML exports 
the ENTIRE state of everything to all clients.  This is doable on a 
single computer system, but causes issues on multiple networked nodes.  


Note, HAL does not use NML.  This diagram shows the places where NML is 
used:


http://linuxcnc.org/docs/devel/html/code/code-notes.html#_architecture_overview

NML is used between the GUI(s) and Task, and between Task and IO.  The 
connection between Task and Motion uses an NML-like message-passing 
system, but not the actual NML code.


That diagram predates HAL.  HAL is a fine-grained shared-memory system 
acting as a kind of backplane connecting IO, Motion, and the "Realtime 
Hardware Devices" and "Non-Realtime Hardware Devices" in that diagram. 
HAL does not use message-passing.


One challenge with making LinuxCNC distributed across multiple physical 
computers is that HAL is shm-based, not message-based.  So we'd need a 
tool to periodically inspect the state of (some?) HAL objects, serialize 
the information into a message, and send that message to recipient(s) on 
the network.  I believe Machinekit made some progress in this area, but 
I don't know how far they got and I never saw a PR that I could understand.



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

2022-12-04 Thread Sebastian Kuzminsky

On Dec 3, 2022, at 10:58 AM, Chris Morley
 wrote:

Have you looked at machinekit code? Is that similar to what you
want?

On 12/3/22 17:06, Johannes Fassotte wrote:
> I think that this will get done individuals like me that get together
> and see the advantages that this offers. I usually get  referred to
> machinekit liked you did which is really like saying go away, we
> don’t want to hear this because it is not compatible with existing
> plans and therefore rejected.

I have two comments to make here.

1:

Last time i looked at machinekit's "machinetalk" feature, it was 
basically a special UI that got its "user input" from 0mq instead of 
from mouse clicks and keyboard presses, and reported its info into 0mq 
instead of into a GUI window.  Machinetalk still interfaced to LinuxCNC 
using the same old NML system we've been using since the beginning.

Machinekit may have evolved since then, or I may me misremembering (as 
it's been years since I looked at it), so please fact-check me and 
correct me if i'm wrong.

I would welcome a new network-transparent interface for UIs to talk to 
the LinuxCNC machine control core, but I am not at all interested in 
adding a new layer of pretty networking on top of the existing 
interfaces.  If you're going to do this, do it right, by replacing the 
old cruft with new, more useful stuff.

2:

There is no cabal of evil villains preventing innovation and improvement 
in LinuxCNC.  There's not even a "board of directors" that makes their 
own plans and rejects everyone else's good ideas.

There is only a loose association of well-meaning, interested 
individuals, all contributing what we can, when we can, as it fits 
around the other things going on in our lives.

If you have a good idea, please, bring it up and discuss it on the 
mailing list as you did.  If anyone is moved to add anything to the 
discussion, they will.  Don't take silence as rejection, it's often just 
folks being distracted by other things and not paying attention to the 
mailing list.  Ideas that are presented clearly (and politely) will get 
the most interaction.  Your idea may get criticism and/or encouragement, 
but remember that in the end, no one is obligated to act on your ideas. 
If you want something, you generally have to do it yourself, with the 
guidance and whatever collaboration individuals in the community choose 
to offer you.

Code talks, especially well implemented, well documented, well tested 
code grounded in community discussion and rough consensus.

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

2022-12-04 Thread Nicklas SB Karlsson

lör 2022-12-03 klockan 21:22 +0100 skrev Steffen Möller:
> Hello,
> 
> > My goal for LinuxCnc is to provide a way for any user to interface
> > any
> > UI to LinuxCnc with a secure TCP network connection.
> 
> There are remote shells to HAL but I agree - would also like to see a
> bit more of remote control. My motivation is less about the distance
> than it is about controlling multiple machines from the same host -
> cooperating robots anyone?

Hopefully soon. with robot feeding a machine I guess use same user
interface for both might be convenient.



___
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

2022-12-04 Thread Nicklas SB Karlsson

lör 2022-12-03 klockan 16:57 -0800 skrev chris morley:
> 
> On 2022-12-03 16:06, Johannes Fassotte wrote:
> > I’m fairly familiar with machine kit and it has nothing to do with
> > that. It has strictly to do with modernizing the built in remote
> > interface that Linuxcnc was born with..
> 
> ok You must realize almost no one uses the networking capability of 
> linuxcnc.

Tried it but id did not get it to work.

> 
> It seems to be the case that most machines have the controls on the 
> machine so over network is not that important. Certainly its a 
> limitation in some cases. I guess I don't see why its 
> the-most-important-thing that you seem to?

Not many years ago it made sense with a real time computer without
displays an ordinary computer for user interface. It make less sense
now since ordinary computer seems to work well as real time computer.

Nicklas Karlsson




___
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

2022-12-03 Thread Jon Elson


On 12/3/22 18:57, chris morley wrote:
I am not sure why you are hostile. I am really trying to 
understand exactly what you want. Machinekit did work on 
networking, though I think it was just HAL. It's why I 
mentioned it. 


Underneath HAL there is NML that links major sections of 
LinuxCNC together and makes the state of major components 
available.  NML exports the ENTIRE state of everything to 
all clients.  This is doable on a single computer system, 
but causes issues on multiple networked nodes.  Machinekit 
was trying to replace ALL NML with ZeroMQ, which was 
designed to do this in a networked way.  Clients tell it 
what structures they want to subscribe to, and ONLY those 
structures are transmitted to that client.  My understanding 
is that this replacement was never finished.  Machinekit was 
aimed at work cell/robot systems and multiple instances of 
LinuxCNC working together in shared 3D spaces.


Jon



___
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

2022-12-03 Thread Small Shop Concepts

I could see this being implemented in lights out machining facilities which
would be fantastic!   Even low end 3d printers are utilizing this type of
remote interface which is great for letting machines run on there own and
keeping users updated as to issues or completion of prints so that the next
can be started without having to babysit.

Haas and many other commercial controls use this also for the lights out
machining capabilites where robots or loaders  or pallet systems
continuously run parts.   If tool breakage occurs it is detected during a
change and the user gets informed of the incident so that a tech can be
dispatched to correct and get the machine back to producing.   There are of
course also ways to overcome those issues with redundancies, but it's very
state of the art tech and would really elevate linuxcnc in my opinion,  I
love the idea of it!

On Sat, Dec 3, 2022, 2:48 PM Johannes P Fassotte <
johan...@automationassist.com> wrote:

> In order to help clarify what I would like to see in not only version 10
> of LinuxCnc but also in the current version 9 future work. I will start
> working on this as soon as my new circuits board for my metal detectors
> are populated with all the SMD components. The circuit blank circuit
> boards arrived yesterday. This requires placing 235 SMD componets on
> each of the boards and likely take about seven days.
>
> My goal for LinuxCnc is to provide a way for any user to interface any
> UI to LinuxCnc with a secure TCP network connection. LinuxCnc has had
> such an interface from its inception via the NML network servers however
> these are absolutely insecure and anyone with a bit of knowledge of
> remote NML commands can take control of LinuxCnc if those network ports
> are left open. Thus LinuxCnc needs modern secure network interfaces to
> replace the ones that were designed in from the very start government
> development and just ignored. Not many use this interface because it
> does not provide complete information due to developers add-ons such as
> Python that seem to just live in their own world within LinuxCnc and do
> not provide  any info into the NML network links. NML is likely the
> hardest thing to deal with and very difficult to replace but in general
> works just fine.
>
> About 12 years ago I developed code to allow remote control of a lot of
> time sensitive  industrial and electronic equipment that was  over 500
> miles from the actual normal user interface. The equipment being
> remotely controlled was located in a isolated area and without
> communication links and thus those also had to be designed and
> implemented. The overall bandwidth of the communication link was divided
> into remote receive data, multiple command channels,  status and error
> channels. The system was designed for very high reliability and met all
> design goals and is still in operation with some equipment updates
> having been made.
>
> The goal of me mentioning this is that I know that having a distributed
> data system with equipment to be controlled in one location and the user
> interface in an other more convenient location doe not have to suffer
> from reliability issues when properly executed. What it does provide is
> flexibility. In case of LinuxCnc which runs on Linux user interfaces and
> there support requirements can be offloaded from the Linux system and
> run on Windows based system instead or even on another Linux Based
> computer. Which as I mentioned before reduces the need to load up the
> machine control computer with support code that is not directly related
> to its main function which if of course to control a machine and output
> status info back to the user and process commands from the UI that may
> be located some distance away and not in a noisy environment. There are
> of coarse other ways to snoop into a Machine controller and some have
> implemented one or more o those methods strictly because LinuxCnc does
> not have a proper way of handing remote UI's.
>
> I thing that even version 9 master has a good deal of the required code
> to fix that problem by just adding some code to do some data routing and
> adding some secure TCP channels. I have drawn a basic block diagram of
> what would be required and attached it.
>
>
> ___
> 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

2022-12-03 Thread chris morley



On 2022-12-03 16:06, Johannes Fassotte wrote:

I’m fairly familiar with machine kit and it has nothing to do with that. It has 
strictly to do with modernizing the built in remote interface that Linuxcnc was 
born with..


ok You must realize almost no one uses the networking capability of 
linuxcnc.


It seems to be the case that most machines have the controls on the 
machine so over network is not that important. Certainly its a 
limitation in some cases. I guess I don't see why its 
the-most-important-thing that you seem to?



I think that this will get done individuals like me that get together and see 
the advantages that this offers. I usually get  referred to machinekit liked 
you did which is really like saying go away, we don’t want to hear this because 
it is not compatible with existing plans and therefore rejected.
I am not sure why you are hostile. I am really trying to understand 
exactly what you want. Machinekit did work on networking, though I think 
it was just HAL. It's why I mentioned it.


Using this method can allow any Ui including your efforts to function with 
minimum changes and with mostly the addition of a built in secure TCP 
interface.  It would be nice if you could help with development of the Python 
version of the proposed interface.


I'll tell you I know almost nothing about networking. I'm a self taught 
programmer that uses hack-till-it-works more then engineering a 
solution. I have done tons of work in linuxcnc, but not so much on NML.


I'd be happy if NML was replaced to something mainstream so there was 
examples to go by. Machinekit wanted to use ZMQ but never got all the 
way there as I understand it. But it is beyond my skill.


I certainly agree that inter-ui communication is not good in linuxcnc 
and often a real pain to work around. Some hardware paradigm don't lend 
themselves to multiple 'blind' ui control.


Oh you are  auto-mation-assist on the forum - guy that did labview work.

Chris



Johannes -
Fairbanks, AK 99712


On Dec 3, 2022, at 10:58 AM, Chris Morley  wrote:

Have you looked at machinekit code? Is that similar to what you want?

Chris



Sent from my Galaxy



 Original message 
From: Johannes P Fassotte 
Date: 2022-12-03 11:48 a.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: [Emc-developers] A vision for working now to LinuxCnc version 10

In order to help clarify what I would like to see in not only version 10
of LinuxCnc but also in the current version 9 future work. I will start
working on this as soon as my new circuits board for my metal detectors
are populated with all the SMD components. The circuit blank circuit
boards arrived yesterday. This requires placing 235 SMD componets on
each of the boards and likely take about seven days.

My goal for LinuxCnc is to provide a way for any user to interface any
UI to LinuxCnc with a secure TCP network connection. LinuxCnc has had
such an interface from its inception via the NML network servers however
these are absolutely insecure and anyone with a bit of knowledge of
remote NML commands can take control of LinuxCnc if those network ports
are left open. Thus LinuxCnc needs modern secure network interfaces to
replace the ones that were designed in from the very start government
development and just ignored. Not many use this interface because it
does not provide complete information due to developers add-ons such as
Python that seem to just live in their own world within LinuxCnc and do
not provide  any info into the NML network links. NML is likely the
hardest thing to deal with and very difficult to replace but in general
works just fine.

About 12 years ago I developed code to allow remote control of a lot of
time sensitive  industrial and electronic equipment that was  over 500
miles from the actual normal user interface. The equipment being
remotely controlled was located in a isolated area and without
communication links and thus those also had to be designed and
implemented. The overall bandwidth of the communication link was divided
into remote receive data, multiple command channels,  status and error
channels. The system was designed for very high reliability and met all
design goals and is still in operation with some equipment updates
having been made.

The goal of me mentioning this is that I know that having a distributed
data system with equipment to be controlled in one location and the user
interface in an other more convenient location doe not have to suffer
from reliability issues when properly executed. What it does provide is
flexibility. In case of LinuxCnc which runs on Linux user interfaces and
there support requirements can be offloaded from the Linux system and
run on Windows based system instead or even on another Linux Based
computer. Which as I mentioned before reduces the need to load up the
machine control computer with support code that is not directly related
to its main function which if of course to control a machine and

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

2022-12-03 Thread Johannes Fassotte

I’m fairly familiar with machine kit and it has nothing to do with that. It has 
strictly to do with modernizing the built in remote interface that Linuxcnc was 
born with..

I think that this will get done individuals like me that get together and see 
the advantages that this offers. I usually get  referred to machinekit liked 
you did which is really like saying go away, we don’t want to hear this because 
it is not compatible with existing plans and therefore rejected.

Using this method can allow any Ui including your efforts to function with 
minimum changes and with mostly the addition of a built in secure TCP 
interface.  It would be nice if you could help with development of the Python 
version of the proposed interface.


Johannes - 
Fairbanks, AK 99712

> On Dec 3, 2022, at 10:58 AM, Chris Morley  wrote:
> 
> Have you looked at machinekit code? Is that similar to what you want?
> 
> Chris
> 
> 
> 
> Sent from my Galaxy
> 
> 
> 
>  Original message 
> From: Johannes P Fassotte 
> Date: 2022-12-03 11:48 a.m. (GMT-08:00)
> To: emc-developers@lists.sourceforge.net
> Subject: [Emc-developers] A vision for working now to LinuxCnc version 10
> 
> In order to help clarify what I would like to see in not only version 10
> of LinuxCnc but also in the current version 9 future work. I will start
> working on this as soon as my new circuits board for my metal detectors
> are populated with all the SMD components. The circuit blank circuit
> boards arrived yesterday. This requires placing 235 SMD componets on
> each of the boards and likely take about seven days.
> 
> My goal for LinuxCnc is to provide a way for any user to interface any
> UI to LinuxCnc with a secure TCP network connection. LinuxCnc has had
> such an interface from its inception via the NML network servers however
> these are absolutely insecure and anyone with a bit of knowledge of
> remote NML commands can take control of LinuxCnc if those network ports
> are left open. Thus LinuxCnc needs modern secure network interfaces to
> replace the ones that were designed in from the very start government
> development and just ignored. Not many use this interface because it
> does not provide complete information due to developers add-ons such as
> Python that seem to just live in their own world within LinuxCnc and do
> not provide  any info into the NML network links. NML is likely the
> hardest thing to deal with and very difficult to replace but in general
> works just fine.
> 
> About 12 years ago I developed code to allow remote control of a lot of
> time sensitive  industrial and electronic equipment that was  over 500
> miles from the actual normal user interface. The equipment being
> remotely controlled was located in a isolated area and without
> communication links and thus those also had to be designed and
> implemented. The overall bandwidth of the communication link was divided
> into remote receive data, multiple command channels,  status and error
> channels. The system was designed for very high reliability and met all
> design goals and is still in operation with some equipment updates
> having been made.
> 
> The goal of me mentioning this is that I know that having a distributed
> data system with equipment to be controlled in one location and the user
> interface in an other more convenient location doe not have to suffer
> from reliability issues when properly executed. What it does provide is
> flexibility. In case of LinuxCnc which runs on Linux user interfaces and
> there support requirements can be offloaded from the Linux system and
> run on Windows based system instead or even on another Linux Based
> computer. Which as I mentioned before reduces the need to load up the
> machine control computer with support code that is not directly related
> to its main function which if of course to control a machine and output
> status info back to the user and process commands from the UI that may
> be located some distance away and not in a noisy environment. There are
> of coarse other ways to snoop into a Machine controller and some have
> implemented one or more o those methods strictly because LinuxCnc does
> not have a proper way of handing remote UI's.
> 
> I thing that even version 9 master has a good deal of the required code
> to fix that problem by just adding some code to do some data routing and
> adding some secure TCP channels. I have drawn a basic block diagram of
> what would be required and attached it.
> 
> 
> 
> ___
> 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

2022-12-03 Thread Steffen Möller

Hello,

> My goal for LinuxCnc is to provide a way for any user to interface any
> UI to LinuxCnc with a secure TCP network connection.

There are remote shells to HAL but I agree - would also like to see a bit more 
of remote control. My motivation is less about the distance than it is about 
controlling multiple machines from the same host - cooperating robots anyone?

I do not exactly know how ROS would come into play, but I presume, that would 
be another very close candidate as a controlling agent. I have no idea about 
how difficult this would all be to implement.

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

2022-12-03 Thread Chris Morley

Have you looked at machinekit code? Is that similar to what you want?

Chris



Sent from my Galaxy



 Original message 
From: Johannes P Fassotte 
Date: 2022-12-03 11:48 a.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: [Emc-developers] A vision for working now to LinuxCnc version 10

In order to help clarify what I would like to see in not only version 10
of LinuxCnc but also in the current version 9 future work. I will start
working on this as soon as my new circuits board for my metal detectors
are populated with all the SMD components. The circuit blank circuit
boards arrived yesterday. This requires placing 235 SMD componets on
each of the boards and likely take about seven days.

My goal for LinuxCnc is to provide a way for any user to interface any
UI to LinuxCnc with a secure TCP network connection. LinuxCnc has had
such an interface from its inception via the NML network servers however
these are absolutely insecure and anyone with a bit of knowledge of
remote NML commands can take control of LinuxCnc if those network ports
are left open. Thus LinuxCnc needs modern secure network interfaces to
replace the ones that were designed in from the very start government
development and just ignored. Not many use this interface because it
does not provide complete information due to developers add-ons such as
Python that seem to just live in their own world within LinuxCnc and do
not provide  any info into the NML network links. NML is likely the
hardest thing to deal with and very difficult to replace but in general
works just fine.

About 12 years ago I developed code to allow remote control of a lot of
time sensitive  industrial and electronic equipment that was  over 500
miles from the actual normal user interface. The equipment being
remotely controlled was located in a isolated area and without
communication links and thus those also had to be designed and
implemented. The overall bandwidth of the communication link was divided
into remote receive data, multiple command channels,  status and error
channels. The system was designed for very high reliability and met all
design goals and is still in operation with some equipment updates
having been made.

The goal of me mentioning this is that I know that having a distributed
data system with equipment to be controlled in one location and the user
interface in an other more convenient location doe not have to suffer
from reliability issues when properly executed. What it does provide is
flexibility. In case of LinuxCnc which runs on Linux user interfaces and
there support requirements can be offloaded from the Linux system and
run on Windows based system instead or even on another Linux Based
computer. Which as I mentioned before reduces the need to load up the
machine control computer with support code that is not directly related
to its main function which if of course to control a machine and output
status info back to the user and process commands from the UI that may
be located some distance away and not in a noisy environment. There are
of coarse other ways to snoop into a Machine controller and some have
implemented one or more o those methods strictly because LinuxCnc does
not have a proper way of handing remote UI's.

I thing that even version 9 master has a good deal of the required code
to fix that problem by just adding some code to do some data routing and
adding some secure TCP channels. I have drawn a basic block diagram of
what would be required and attached it.



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

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

2022-12-03 Thread Johannes P Fassotte

In order to help clarify what I would like to see in not only version 10 
of LinuxCnc but also in the current version 9 future work. I will start 
working on this as soon as my new circuits board for my metal detectors 
are populated with all the SMD components. The circuit blank circuit 
boards arrived yesterday. This requires placing 235 SMD componets on 
each of the boards and likely take about seven days.


My goal for LinuxCnc is to provide a way for any user to interface any 
UI to LinuxCnc with a secure TCP network connection. LinuxCnc has had 
such an interface from its inception via the NML network servers however 
these are absolutely insecure and anyone with a bit of knowledge of 
remote NML commands can take control of LinuxCnc if those network ports 
are left open. Thus LinuxCnc needs modern secure network interfaces to 
replace the ones that were designed in from the very start government 
development and just ignored. Not many use this interface because it 
does not provide complete information due to developers add-ons such as 
Python that seem to just live in their own world within LinuxCnc and do 
not provide  any info into the NML network links. NML is likely the 
hardest thing to deal with and very difficult to replace but in general 
works just fine.


About 12 years ago I developed code to allow remote control of a lot of 
time sensitive  industrial and electronic equipment that was  over 500 
miles from the actual normal user interface. The equipment being 
remotely controlled was located in a isolated area and without 
communication links and thus those also had to be designed and 
implemented. The overall bandwidth of the communication link was divided 
into remote receive data, multiple command channels,  status and error 
channels. The system was designed for very high reliability and met all 
design goals and is still in operation with some equipment updates 
having been made.


The goal of me mentioning this is that I know that having a distributed 
data system with equipment to be controlled in one location and the user 
interface in an other more convenient location doe not have to suffer 
from reliability issues when properly executed. What it does provide is 
flexibility. In case of LinuxCnc which runs on Linux user interfaces and 
there support requirements can be offloaded from the Linux system and 
run on Windows based system instead or even on another Linux Based 
computer. Which as I mentioned before reduces the need to load up the 
machine control computer with support code that is not directly related 
to its main function which if of course to control a machine and output 
status info back to the user and process commands from the UI that may 
be located some distance away and not in a noisy environment. There are 
of coarse other ways to snoop into a Machine controller and some have 
implemented one or more o those methods strictly because LinuxCnc does 
not have a proper way of handing remote UI's.


I thing that even version 9 master has a good deal of the required code 
to fix that problem by just adding some code to do some data routing and 
adding some secure TCP channels. I have drawn a basic block diagram of 
what would be required and attached it.



___
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

2022-12-02 Thread andy pugh

On Fri, 2 Dec 2022 at 18:43, Johannes P Fassotte <
johan...@automationassist.com> wrote:

>  I also feel
> that there is way to much resistance by the LinuxCnc developers to
> implement what many of us may see as a absolute requirement.

1) This is the first time that I have heard this requirement articulated.
2) Do you have a definition for this interface?
3) Who do you expect to do the considerable amount of work? And what would
their motivation be?

Maybe the GUI authors can chime in with an opinion on how much of an
obstacle the current interfaces are?

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

2022-12-02 Thread Bari


Johannes,


Thank you for your thoughts and time to put this in writing.

I mostly agree with a few exceptions.

NML should be changed to DDS for easier compatibility with ROS2 
https://www.ros.org/


LCNC development is all voluntary and the current devs are already 
capacity with their time, energy and desire for LCNC development.


I only expect big changes like this to happen if the project is forked 
for a few years while this is developed by funded developers. After 
these changes including folding some of machinekits 
https://www.machinekit.io/  features back into LCNC the new and improved 
LCNC. The tricky part is getting funding for an open source machine 
controller.



-Bari

On 12/2/22 12:38, Johannes P Fassotte wrote:
As you may know I have been desiring  a better way to interface user 
interfaces to LinuxCnc and strongly feel that there needs to be a big 
change in the way this is being done at the present time. I also feel 
that there is way to much resistance by the LinuxCnc developers to 
implement what many of us may see as a absolute requirement. That 
requirement is secure distributed networking interfaces for all user 
interfaces and implemented as plugins for LinuxCnc.


As such I would like to see plugin code developed to allow user 
interfaces to have full control of LinuxCnc, along with consolidated 
status and errors with plugin interfaces for Python, C/C++ and NML.  
This will allow all user interfaces to be developed as plugins and use 
the secure distributed network interface ability to link into 
LinnuxCnc via ether local or remote network connections. LinuxCnc 
provided plugin code would set all default commands that could be 
excepted along with a standard way of sending all available status 
info back to the user and also any errors that may have been encountered.


With  such a plugin system for user interfaces there is no need to 
include anything related to user interface development withing 
LinuxCnc code itself since those are all handled as completely 
separate projects by the various UI developers.  All such developers 
comply with the default LinuxCnc plugin requirements but also have the 
ability to do some customizing. Such a system is not to difficult to 
implement for LinuxCnc version 10 since all that has to be done is for 
LinuCnc developers to build the code for the UI plugin interfaces and 
do some cleanup work to remove the nonessential UI code that is 
presently contained in LinuxCnc.


I don't understand why I see so much resistance in getting such a 
relatively simple thing done by the experts in LinuxCnc development. 
Everyone knows that distributed networking is extremely viable so 
there should be no reason not to implement this concept for 
interfacing with UI's. You cannot keep on adding UI development things 
to LinuxCnc without it becoming a big big mess. I think to do so is 
just due to hardheadedness.


Lets develop the UI plugin interface concept for LinuxCnc version 10 
that allows UI interfaces to run as a distributed data system and 
which at the same time simplifies maintaining LinuxCnc a thousand fold 
and also reducing the size of its footprint.


Its up you, the LinuxCnc developers and also the UI developers to get 
started on implementing something like this for LinuxCnc version 10! 
You are all the experts and developing the standard code for this is 
likely not difficult.  For those of us who are somewhat on the outside 
the development group we will have to do less customizing  work by not 
having to customize LinuxCnc to suit our desires and which causes a 
great deal of  update difficulties.


When you look at history there have been a number of warnings that 
this needed to be done a long time ago. One such example was the split 
and development of Machinekit which I feel was the direct result of 
developers being to stubborn to explore other points of view and their 
potential long term benefits. Just think about how much was lost by 
these two teams not being able to work together to resolve issues.





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

2022-12-02 Thread Johannes P Fassotte

As you may know I have been desiring  a better way to interface user 
interfaces to LinuxCnc and strongly feel that there needs to be a big 
change in the way this is being done at the present time. I also feel 
that there is way to much resistance by the LinuxCnc developers to 
implement what many of us may see as a absolute requirement. That 
requirement is secure distributed networking interfaces for all user 
interfaces and implemented as plugins for LinuxCnc.


As such I would like to see plugin code developed to allow user 
interfaces to have full control of LinuxCnc, along with consolidated 
status and errors with plugin interfaces for Python, C/C++ and NML.  
This will allow all user interfaces to be developed as plugins and use 
the secure distributed network interface ability to link into LinnuxCnc 
via ether local or remote network connections. LinuxCnc provided plugin 
code would set all default commands that could be excepted along with a 
standard way of sending all available status info back to the user and 
also any errors that may have been encountered.


With  such a plugin system for user interfaces there is no need to 
include anything related to user interface development withing LinuxCnc 
code itself since those are all handled as completely separate projects 
by the various UI developers.  All such developers comply with the 
default LinuxCnc plugin requirements but also have the ability to do 
some customizing. Such a system is not to difficult to implement for 
LinuxCnc version 10 since all that has to be done is for LinuCnc 
developers to build the code for the UI plugin interfaces and do some 
cleanup work to remove the nonessential UI code that is presently 
contained in LinuxCnc.


I don't understand why I see so much resistance in getting such a 
relatively simple thing done by the experts in LinuxCnc development. 
Everyone knows that distributed networking is extremely viable so there 
should be no reason not to implement this concept for interfacing with 
UI's. You cannot keep on adding UI development things to LinuxCnc 
without it becoming a big big mess. I think to do so is just due to 
hardheadedness.


Lets develop the UI plugin interface concept for LinuxCnc version 10 
that allows UI interfaces to run as a distributed data system and which 
at the same time simplifies maintaining LinuxCnc a thousand fold and 
also reducing the size of its footprint.


Its up you, the LinuxCnc developers and also the UI developers to  get 
started on implementing something like this for LinuxCnc version 10! You 
are all the experts and developing the standard code for this is likely 
not difficult.  For those of us who are somewhat on the outside the 
development group we will have to do less customizing  work by not 
having to customize LinuxCnc to suit our desires and which causes a 
great deal of  update difficulties.


When you look at history there have been a number of warnings that this 
needed to be done a long time ago. One such example was the split and 
development of Machinekit which I feel was the direct result of 
developers being to stubborn to explore other points of view and their 
potential long term benefits. Just think about how much was lost by 
these two teams not being able to work together to resolve issues.





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

39 matches

Mail list logo