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