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