> Gesendet: Montag, 05. Dezember 2022 um 03:16 Uhr > Von: "Bari" <bari00...@gmail.com> > 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" <chrisinnana...@hotmail.com> > >> An: "EMC developers" <emc-developers@lists.sourceforge.net> > >> 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 the data become > independent from each other. The component that creates the data > publishes the data over the middleware. The component that publishes the > data does not need to know to whom it should transmit the data. The > middleware is responsible for transmitting data to other components that > subscribe to this data. > > There is no special broker or registry service in the DDS middleware. > Data is transmitted directly to all subscribed applications via a UDP > multicast based protocol. New components can be added to the system to > publish data, or new components that can subscribe to existing data and > process the data can be easily added. > > It would be a massive undertaking to get LCNC to use DDS for Real Time > Publish Subscribe and would end up being EMC3 or LCNCv3. Just throwing > this out there for comments.
This reads all very nice. I presume that team building is the very next thing. If any such transition could be laid out such that programmers could join in (also those without a mill) to fill the gaps, then I am very confident that this would happen. Best, Steffen _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
