Re: [Emc-developers] A vision for working now to LinuxCnc version 10
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
[Emc-developers] A vision for working now to LinuxCnc version 10
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
[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
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] LinuxCnc growing with to much none essential code
I have noticed that over the years LinuxCnc is taking up more and more space and that this is mostly related to supporting the QT related work. When looking at the amount of Pythom code that is now contained in LinuxCnc it appears to equal more than 90% of all the code present based on my prior searches and charting. I'm not in love with QT and in my personnal LinuxCnc installs QT related items are one of the first things that gets removed from LinuxCnc. To me it is just a tool to allow building QT based sluggish user interfaces that I dont use. It would be better if it was a optional install for users that which to use it. I do understand that it has taken a lot of work to develop the QT things but I would like to see LinuxCnc trimmed down to just containing the essential things. As far as tools for building user interfaces It would also not surprise me if the next fad for building those is just around the corner and that QT will hopefully be just part of the old LinuxCnc history. I there will always be newer and better ways to get things done without getting trapped into a current fad. It was not to may years ago that LinuxCnc was just over 120Mb in extracted size. Now V 2.9 master is takes up 252Mb so its getting bloaded with a lot of none essential things. I think it needs a good cleaning to get it back on track. I feel that there are to many personnal projects being added that are better suited to be developer supported addtions and not part of LinuxCnc itself. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
