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 lights up a
light bulb that points to the potential to add a flexible data base that
can distribute information between sub processes to user and real time
levels. So that brings it back to the potential question adding a Redis
data base handler which is extremely fast.
7 Chris: "Oh you are auto-mation-assist on the forum - guy that did
labview work."
Answer: Yes that is me. I have been working on this for years, loosing
interest every now then due to other work such as electronic design work
for my new metal detector for locating extremely small pieces of gold
for summer time enjoyment of being outdoors. And of coarse other things
at always seem to need attention.
A few moths back I configured my milling machine control computer to run
on Debian instead of Mint and installed Labview 2021 and 2022, which
takes a a few changes in the install procedure since Labview install is
not set up to run on Debian. Several files need to be modified to allow
it to install on Debian.
I also ran into a problem with the install of the Labview VI package
manager install which is not actually part of Labview but helpful in
installing optional packages build by other developers. This went fine
for Laview 2021 but would not connect to Labview 2022. Which makes it
more difficult to make Labview 2022 friendly to use since adding
packages for 2022 without the package manager require manually adding
folders and files to Labview 2022 for adding additional functionality.
I stopped working on my development on LinuxCnc two or three months back
since It seemed like there were continues changes being made to LinuxCnc
Master and I needed to develop new circuit boards from my metal detector
project.
At that time I was developing my LinuxCnc remote UI code with stripped
down version of LinuxCnc this became a problem. My plan now is when I
continue is not to strip down LinuxCnc and just add the code required to
continue working on remote UI control interface.
NML Cmds to LinuxCnc are not a problem, what is a problem are those
things that run separate like Python related code and perhaps some
others that I have not looked into that generate internal cmds and
status data that does not get routed to NML and thus is not processed by
the remote NML TCP channels. To attempt to overcome that it seem
reasonable to add the Redis data base to handle distribution of all
movement of flowing cmd, status and error data.
Requirements for adding the Redis data base can be researched by looking
at the old LinuxCnc code that has Redis added as part of LinuxCnc. As
believe Tormach installs Redis external to LinuxCnc which possibly makes
updating Redis somewhat simpler.
Machinekit in my view is using methods are complicated and thus likely
not way to get the job done to run remote UI's. Workable yes, best way ?
Only time will tell as other development for LinuxCnc code progresses.
My remote UI interface project continues but much more slowly than I had
anticipated.
My project goal is to provide a standard way for LinuxCnc to interface
with UI's that have built in ability to run locally or remotely via TCP
connections to fully control LinuxCnc and also provide access to all
status data and error messages. In short any new generated code is
intended to serve as universal interface for any UI that has built in
TCP network connectivity and allow such a UI to run either on the same
computer as LinuxCnc, or remote computers including windows based with
high reliability and security.
Ok, sounds great does it not, so lets get excited and get it done. I
expect that most of the code to be generated will be C.
I have been making a bit of noise about some of the shortcomings in
developing a improved UI remote user interface for LinuxCnc for a number
of years and feel that the response back as been somewhat disappointing.
My pushing this is not meant to upset anyone it is meant to feel out
what the support or opposition. In looking at the responses it is easy
to see who is on what side but one ever says that is technically not
feasible or not beneficial. I fully understand that not everyone has
the same interest as myself and also that each and everyone of us has a
limited amount of time available to allow deviating from our own
individuals goals. But that makes it possible for an individual to
develop things that they themselves see beneficial and as that slowly
gets incorporated others also start to see the value in those newly
developed things and start using the them. That is how progress works,
one person with an idea leads to its development and something new and
great is created that everyone loves. That is until the next great idea
comes around. In other words what we worked on last years can easily
become obsolete in no time at all.
UI remote interface for use within LinuxCnc is a future requirement
simply because the use of networking is continuously expanding every
year. In addition to providing remote ability it also allows for simple
ways to route data to where it is needed.
In view of the above I would truly like to receive some basic input for
interested individuals on what is sought to be best way to implement my
proposed remote UI interface for use within LinuxCnc. Example code for
various sub-functions, block diagrams, anything that can help me to
develop the code required to implement this. Without input from others
it is easy to overlook something that may later require a lot of rework.
Thus the goal is to come up with something that is easy to implement,
highly reliable and with methods efficient. The final goal of coarse is
to get this incorporated it into LinuxCnc or at minimum as an optional
install able module.
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.
If anyone is interested it this work and to share information feel free
to contact me via email. I can set up one of my github account folders
for sharing development data.
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
