Re: [Emc-developers] A vision for working now to LinuxCnc version 10
On Fri, 2 Dec 2022 at 18:43, Johannes P Fassotte < johan...@automationassist.com> wrote: > 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. 1) This is the first time that I have heard this requirement articulated. 2) Do you have a definition for this interface? 3) Who do you expect to do the considerable amount of work? And what would their motivation be? Maybe the GUI authors can chime in with an opinion on how much of an obstacle the current interfaces are? -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Fwd: A vision for working now to LinuxCnc version 10
Sory should have gone to list... Forwarded Message Subject: Re: [Emc-developers] A vision for working now to LinuxCnc version 10 Date: Fri, 2 Dec 2022 12:53:31 -0800 From: chris morley To: Johannes P Fassotte On 2022-12-02 10:38, Johannes P Fassotte wrote: 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. Are you talking distributed as in across network or distributed as in individual distributed packages? 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. I guess in my mind this is already true -Qtpyvcp is a separate project that is added to linuxcnc is it not? 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. Probably because its a actually a lot of work on code that require specialized knowledge. I also don't see the 'big mess' part. i think it's somewhat of an advantage to have everything needed to use linuxcnc under one project. For instance i as a mostly ui guy, needs to know almost nothing about packaging and make files. This lowers the bar to being a developer on the project. There is surely some disadvantages too - you are not completely free to do whatever you want or even whats best. 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. I'm not sue it simplifies it - just distributes it among more projects. Again advantages and disadvantages . 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. So one obvious way to help is to become a part of the linuxcnc group instead of staying on the 'outside'. Now this can be a frustrating experience sometimes and you will have to compromise - a lot. We are currently way too short on developers to do much big changes. Another way is to develop on the side and work on getting it accepted. But if your work massively overlaps on going work already in the project, expect resistance - that is just human nature. In this case Kurt probably could have avoided this by not disappearing from qtvcp project. I don't remember any big fights with him. i very much enjoyed working with him at the time. looking back at it though, it does seem clear he always wanted to do his own thing - fair enough. 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. It is disappointing what happened with machinekit - In truth I think it should have happened earlier before feeling were hurt and walls were built up - so that we could come back together with the best of both. Linuxcnc has always been a slow moving project. It's often frustrating. But it seems to have something that keeps it popular. I mean Qtpyvcp isn't using machinekit's network distributed ui system. Chris ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] A vision for working now to LinuxCnc version 10
Johannes, Thank you for your thoughts and time to put this in writing. I mostly agree with a few exceptions. NML should be changed to DDS for easier compatibility with ROS2 https://www.ros.org/ LCNC development is all voluntary and the current devs are already capacity with their time, energy and desire for LCNC development. I only expect big changes like this to happen if the project is forked for a few years while this is developed by funded developers. After these changes including folding some of machinekits https://www.machinekit.io/ features back into LCNC the new and improved LCNC. The tricky part is getting funding for an open source machine controller. -Bari On 12/2/22 12:38, Johannes P Fassotte wrote: 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 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
Re: [Emc-developers] pncconf discrepancy between 2.8 and 2.9
Am 30.11.22 um 11:24 schrieb andy pugh: pins.c, hostmot2.h, hostmot2.c, release_notes.txt, hostmot2.9, hm2_eth.9 changelog and VERSION should all be resolved by --ours. For release_notes.txt please accept both changes but in reverse order, so that it look like this - fixed sensitizing of user tab button on toggling "edit offsets" (#2111) - fix error on creating new G-code file when RS274NGC_STARTUP_CODE is not set (#2057) ver 3.4.0 New features: ... -- Am 02.12.22 um 11:23 schrieb andy pugh: On Fri, 2 Dec 2022 at 04:38, Sebastian Kuzminsky wrote: I'm merging 2.8 into 2.9, and I came across a spot where it looks like a feature was added independently to both 2.8 and 2.9 (7i96s support in pncconf), and a bunch of bugfixes were applied in 2.9 but not 2.8. I was going to do that merge too, as I am responsible for the somewhat unusual process. In fact I planned it for yesterday but got engrossed in trying to get LinuxCNC-rt debs building. Basically 7i96s support in hm2 and pncconf was in 2.9 but not 2.8. Then the chip shortage meant that the 7i96s was just about the only board readily available, so I cherry-picked just enough to support the board from 2.9 to 2.8 for the 2.8.4 release. To solve the conflicts there I believe that the best strategy is to leave the 2.9 version as-is (ie checkout --ours) for hm2 and pncconf. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Eye candy is important - Titan got a new German friend - want that reaction for a LinuxCNC controller
Le ven. 2 déc. 2022 à 03:01, Kurt Jacobson a écrit : > > I have been busy starting a family so have been completely out of the > LinuxCNC loop lately,glad to see most of the old familiar names still > active, as well as the new ones! > "Starting a family" ? Good one ! This never, ever ends LOL Very glad to have you back on the field Kurt :) I have not thoroughly read this thread, but I have read enough to be > discouraged by some of the things said. > Don't, please. We are, for once, discussing big matters in a handful of threads, and that is good ! We may have diverging visions, contradictory opinions and incompatible plans, but at least we are putting them on the table. And we all know what a traitor e-mail communication can be... at least I, as a hot-headed, irreverent, chatty Mediterranean, have paid that price often enough :-/ Lets good willingly receive fears and (fair, well-argued) criticisms, and welcome ideas be they old reborn, new or even "disruptive" as they say ;-) As far as I know, we are all here for the fun of a good mental > challenge and to enjoy some time away for the usual stress of work > and life. I don't think anybody is trying to compete in any but a > constructive > manner or "steal market share" from any other GUI project. > To the fun and mental challenge, I'd add the great will of Open Source: making the world a better place. This is an important point as its consideration may heavily impact the project vision from a garage tinkerer software, to a world class project FOSS project for users, developers, education and professionals. > IIUC, @hazzy had a "control agnostic UI" vision in the beginning. That > > could explain why the project was created outside LinuxCNC. > > But others may have better knowledge of the whys and hows... > > > > You are 100% correct. I'm not sure where the rather obvious bitterness > over > the QtPyVCP project originated, but I can explain why I chose to start a > seperate Qt based VCP toolkit. > Let me try an explanation... the developers' loneliness and frustration to see someone start something new instead of joining forces whereas they already painfully lack of it ? Push that into communication traps... And here we are Here is a quick history of the origins of QtPyVCP which may prove helpful. Thank you so much for writing this down ! This part _must_ be copy-pasted in the "About" section of QtPyVCP's doc, as this gives the missing contextual understanding of the project that is the bond with LinuxCNC While QtPyVCP has remained much closer tied to LinuxCNC-only than I > originally hoped, I believe it has been successful at lowering the > barrier to > creating and sharing custom user interfaces. > True, and I believe QtVCP, the nice UIs built with it, and its extensive (learned it to my expense ) documentation does the same. Anyway, they are the modern toolkits rocking the stage nowadays, with people behind them, ideas to develop and will to go forward... Let's focus on that and walk along ! Important question is, does QtPyVCP vision still holds that control agnostic strategy, how deep, and to what end ? From that essentially may depend the soundness of the project joining LinuxCNC's. > Indeed, considering the success of QtPyVCP, as an outsider, it doesn't > seem > > to impede its development and progress ! > > I think the very fact that it is a seperate project is what has made it so > successful. It is much less intimidating for a new user to contribute to > a small > focussed project, than a massive sprawling code base like LinucCNC has > become, and this is why I believe QtPyVCP should remain at least in a > separate repo. > Can't agree more ! I'm surely not advocating main repository split to invite QtPyVCP to an additional big merge This is also exactly the point I was making some time ago: subprojects buried into main repo get their lifecycle slowed by the necessarily long one of the core, as well as their overly tight (vs intimate, which is good) link with the code base, tests, docs and build system is holding back their evolution (or withdrawal !). > > > I'm sure neither project wants their years of work trampled on. > > As I said before, I believe most if not all of us are here for fun and to > enjoy > > working together. > If I Was under the impression somebody thought I was trampling on their > work, I'd move on to a group that encouraged constructive turning up of > the > ground! > In such case, you wouldn't go anywhere alone... TY J ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] pncconf discrepancy between 2.8 and 2.9
On Fri, 2 Dec 2022 at 04:38, Sebastian Kuzminsky wrote: > I'm merging 2.8 into 2.9, and I came across a spot where it looks like a > feature was added independently to both 2.8 and 2.9 (7i96s support in > pncconf), and a bunch of bugfixes were applied in 2.9 but not 2.8. I was going to do that merge too, as I am responsible for the somewhat unusual process. In fact I planned it for yesterday but got engrossed in trying to get LinuxCNC-rt debs building. Basically 7i96s support in hm2 and pncconf was in 2.9 but not 2.8. Then the chip shortage meant that the 7i96s was just about the only board readily available, so I cherry-picked just enough to support the board from 2.9 to 2.8 for the 2.8.4 release. To solve the conflicts there I believe that the best strategy is to leave the 2.9 version as-is (ie checkout --ours) for hm2 and pncconf. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
