Re: [Emc-developers] Ethercat Working Group
That sounds awesome Rod! I am interested in your Xenomai 4 test results. On Fri, Feb 10, 2023 at 3:53 AM Rod Webster wrote: > > I was lucky enough to attend an Ethercat working group seminar today in > Brisbane, Australia where German based Martin Rostan, Executive Director > from the EtherCAT Technology Group (ETG) was the main presenter. > > It was all very interesting and the detailed low level description of > ethercat packets and alternatives based on TCP makes Ethercat streets in > front of other alternatives because of the sheer efficiency of the > protocol. This let me understand the issues causing the error finishing > read error being experienced with hm2eth connected devices (ie mesa > ethernet cards) in later kernels (5.10 and above). > > I was also able to speak with Martin about the licensing issue > preventing us from including the Linuxcnc ethercat driver in our > distribution and have a greater understanding of the problem. Their > license requires users of an ethercat master (in this case the iGh Etherlab > master we use) to become members of the ETG (which is free). Anybody > selling machines would need to adhere to this. So technically, we can't put > that condition on to our terms because the existing GPL licence > from Linuxcnc propagates to the ethercat driver. He did go on to say that > they would never take action against somebody promoting use of ethercat > masters. > > So back to the error finishing read problem (that can't be solved by wide > scale adoption of ethercat), I recently purchased an Odroid N2+ Arm based > PC which arrived today. I was hoping the different platform may improve > network latency. I have been able to compile an Armbian bookworm image > which booted OK. A user on the Armbian forum is willing to help me with > building a PREEMPT_RT image following this prerequisite first step. but his > main interest is in Xenomai 4 and he is keen to help me subsequently build > Xenomai for the N2+. Xenomai seems to have a significant advantage over > PREEMPT_RT re latency. Given we already support Xenomai 3, I am hoping it > will be a fairly simple matter to support xenomai 4 and build a test for > network latency to look at differences between xenomai and preempt_rt. > > So I am sure progress will be slow, but I am hopeful we will come up with a > solution to error finishing read! > > I hope some of you are interested in this ChatGPT free update! > > Rod Webster > > VMN® > > www.vmn.com.au > > Ph: 1300 896 832 > > Mob: +61 435 765 611 > > ___ > 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
Re: [Emc-developers] Show used tools for loaded NC program?
If i do not have a tool in my carousel i get an error stating the tool not in the carousel and the program wont start. It runs through and checks i am guessing at cycle start. I used to have an issue where if i called a tool twice with a different tool between it would error because it was not accounting for returning the tool to the carousel. I do like the idea of having the tool list read at program load and displayed somewhere on the gui for those who do not have cam that prints the tool list in the gcode file. On Fri, Jan 13, 2023, 4:59 PM Nicklas SB Karlsson wrote: > Looking into file generated by post processor I used it does not print > a list of tools used. > > It is easy to miss one and then program in best case quit then row to > insert tool is reached, not a big problem but still annoying. In best > case it would also check if tool is in tool table, this check should > work if each tool get a unique number. > > Nicklas Karlsson > > > fre 2023-01-13 klockan 16:39 -0500 skrev Small Shop Concepts: > > That can be accomplished in the post processor of most cam softwares, > > it > > writes the tool lost at the top of the gcode file. > > > > On Fri, Jan 13, 2023, 4:32 PM Nicklas SB Karlsson wrote: > > > > > Anyone else think it would be useful with possibility to show which > > > tools a loaded NC file use? > > > > > > Then pressing a button list with tools needed is shown. So far I > > > have > > > manually read the g-code file to determine which tools must be > > > prepared. > > > > > > > > > Nicklas Karlsson > > > > > > > > > > > > ___ > > > 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 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
Re: [Emc-developers] Show used tools for loaded NC program?
That can be accomplished in the post processor of most cam softwares, it writes the tool lost at the top of the gcode file. On Fri, Jan 13, 2023, 4:32 PM Nicklas SB Karlsson wrote: > Anyone else think it would be useful with possibility to show which > tools a loaded NC file use? > > Then pressing a button list with tools needed is shown. So far I have > manually read the g-code file to determine which tools must be > prepared. > > > Nicklas Karlsson > > > > ___ > 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
Re: [Emc-developers] A vision for working now to LinuxCnc version 10
I could see this being implemented in lights out machining facilities which would be fantastic! Even low end 3d printers are utilizing this type of remote interface which is great for letting machines run on there own and keeping users updated as to issues or completion of prints so that the next can be started without having to babysit. Haas and many other commercial controls use this also for the lights out machining capabilites where robots or loaders or pallet systems continuously run parts. If tool breakage occurs it is detected during a change and the user gets informed of the incident so that a tech can be dispatched to correct and get the machine back to producing. There are of course also ways to overcome those issues with redundancies, but it's very state of the art tech and would really elevate linuxcnc in my opinion, I love the idea of it! On Sat, Dec 3, 2022, 2:48 PM Johannes P Fassotte < johan...@automationassist.com> wrote: > 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 mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Eye candy is important
Awesome! Thanks Steffan! On Sat, Dec 3, 2022, 2:09 PM Steffen Möller wrote: > This turned into quite a thread. > > @Kurt, you did everything just right. > > There should not be much of a difference between LinuxCNC-related work > that is part of the same git repository, within the LinuxCNC github > organisation or external to it. I'll do my best to keep packaging your > dependencies and while we will miss the upcoming Debian freeze for them, we > should manage for the next. > > Best, > Steffen > > > Gesendet: Freitag, 02. Dezember 2022 um 02:57 Uhr > > Von: "Kurt Jacobson" > > An: "EMC developers" > > Betreff: Re: [Emc-developers] Eye candy is important - Titan got a new > German friend - want that reaction for a LinuxCNC controller > > > > Good evening! > > > > 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! > > > > I have not thoroughly read this thread, but I have read enough to be > > discouraged > > by some of the things said. > > > > 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. > > > > > > > > > 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. > > > > > > Here is a quick history of the origins of QtPyVCP which may prove > helpful. > > > > When I first started playing with LinuxCNC (2013), I had absolutely no > > coding or Linux experience of any kind. > > I learn by doing, so I started reading the LinuxCNC source code, trying > to > > understand it and make my > > own UI based off of Gmoccapy. The result of this was the first "Hazzy" > > (haas-like) UI I made: > > https://github.com/KurtJacobson/hazzy/tree/legacy > > > > I posted screenshots of Hazzy on the forms and got some interest (TurBoss > > for one), > > so I tried to figure out how I could share it with others. I found this > > extremely difficult > > as I had no GIT experience and the files I had modified to get the > > functionality I wanted > > were spread all over through the LinuxCNC code base. > > > > There is no way I would have got a PR to the main LinuxCNC accepted, > > since my code style was non-existent and I was intimidated by the PR > > process. > > (The linuxcnc dev community can be a little intimidating at times ...) > > > > I wished there was an easy way for newbies like myself to create and > > share VCPs without them needing to be polished to the same level as the > > main code base. > > This is something that Mach3 had that made a huge range if UIs available. > > > > TurBoss and I started trying to make a Mach3 style screen designer with > > drag and drop pre-made widgets. > > We did this with GtK and it worked reasonable well, but then we started > > having Gtk compatibility issues > > https://www.youtube.com/watch?v=rh7IONE3Lsk > > > > TurBoss had been working with Qt for other projects, so I decided to play > > with Qt as an alternative to Gtk. > > I learned of the QtPy project, and thought it would be neat to have the > > same level of abstraction between the > > machine control (LinuxCNC, GRBL etc.) and the UI so you could develop UIs > > for multiple controls with the same toolkit, > > > > By this time Chris M. was starting QtVCP, so to learn Qt I started > > studying and helping him on various things, > > but I was intimidated and my creativity stifled by having to PR to the > main > > QtVCP branch. > > > > This led me to start a repo for my vision of an abstract, control > agnostic, > > plugin-based VCP toolkit using QtPy > > and PyDM as its inspiration, hence the name QtPyVCP (it was originally > > QtPyMD for QtPy Machine Display). > > > > 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. > > > > > > Again, use of similar technologies is a not an issue but an opportunity > to > > > find commonalities and join forces on shared libs or whatever, freeing > > > resources for what is done truly differently in each project > > > > > > 100% > > > > > > > > Nothing wrong with being independent, seems to work for both > projects. > > > > > > > > > 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
Re: [Emc-developers] Eye candy is important - Titan got a new German friend - want that reaction for a LinuxCNC controller
"How are integrators (ie, GUI / Panel designers) meant to pick between QtVCP and the very similarly named QtPyVCP? They do the same thing, fundamentally." Does that even matter at the user level for gui selection? I am not privy to why the two were divided and frankly could care less as a designer, I was looking for a different option than existing 2018 gui's that didn't exist and ran across the BrendaEM thread. I began contributing to it but it seemed stifled and uncertain if that designer would continue moving forward so I looked for the next way to achieve the goal of a new UI. When I saw a functioning control panel video in one of the posts I said ok there is a way forward to make an updated gui a reality. So for me it was the first one that I found with something actually functioning which was QtPyVCP. I spent the next 4 and half years working on that platform. The collaboration there is fantastic and the general positive can-do attitude helped to push things along. If something is dreamt up it is tried and tested and if it works it is implemented. It has been by far the most fast paced and innovative team mentality group I have had the pleasure of working with to date. It is driven by some extremely talented developers genuinely excited about the creative process. I think a designer would be able to choose which they would want to work in and at this point they are different enough that it is relevant. The fact that their exists several very well received usable gui's in both is also a strong reason. By excluding one it is essentially short changing user choices. So the bigger question is why would anyone want to do that? On Thu, Dec 1, 2022 at 3:12 PM andy pugh wrote: > On Wed, 30 Nov 2022 at 23:31, Steffen Moeller > wrote: > > I consider all our users to be somehow part of our project and am > > agnostic about the interface they are using. From how I see it, if > > PyQtVCP does something better than QtVCP then QtVCP gets some > > encouragement and ideas on how to improve and vice versa. Both GUIs > > should be as easy to install and use as possible. > > > We already see users getting confused about whether they are using PyVCP > (hand-coded XML input files) > https://linuxcnc.org/docs/stable/html/gui/pyvcp.html > Or GladeVCP (more capable, more widgets, has Python handlers. designed > using a GUI (which is horrible, unintiutive and crashes a lot) > https://linuxcnc.org/docs/stable/html/gui/gladevcp.html > > How are integrators (ie, GUI / Panel designers) meant to pick between QtVCP > and the very similarly named QtPyVCP? They do the same thing, > fundamentally. > > -- > 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 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
" I consider all our users to be somehow part of our project and am agnostic about the interface they are using. From how I see it, if PyQtVCP does something better than QtVCP then QtVCP gets some encouragement and ideas on how to improve and vice versa. Both GUIsshould be as easy to install and use as possible. Neither QtVCP nor QtPyVCP are GUIs, they are infrastructure for creating GUIS. I would think that most users will use neither, they will just use the GUIs that have been developed." 100% ^^^ On Wed, Nov 30, 2022 at 7:32 PM Phill Carter wrote: > > > > > On 1 Dec 2022, at 10:27 am, Steffen Moeller wrote: > > > > > > Am 30.11.2022 um 19:12 schrieb Chris Morley: > >> The difference is free cad doesn't compete with anything in linuxcnc. > >> Qtpycp does. If they wanted to be included in linuxcnc, then they would > >> have been part of the project. They made a choice. > >> Otherwise as I said you are undermining the hard work of the devs that are > >> active in our project. > > > > I consider all our users to be somehow part of our project and am > > agnostic about the interface they are using. From how I see it, if > > PyQtVCP does something better than QtVCP then QtVCP gets some > > encouragement and ideas on how to improve and vice versa. Both GUIs > > should be as easy to install and use as possible. > Neither QtVCP nor QtPyVCP are GUIs, they are infrastructure for creating GUIS. > I would think that most users will use neither, they will just use the GUIs > that have been developed. > > > > > Best, > > Steffen > > > >> > >> > >> Original message > >> From: Steffen Moeller > >> Date: 2022-11-30 9:35 a.m. (GMT-08:00) > >> To: emc-developers@lists.sourceforge.net > >> Subject: Re: [Emc-developers] Eye candy is important - Titan got a new > >> German friend - want that reaction for a LinuxCNC controller > >> > >> > >> Am 29.11.2022 um 19:06 schrieb Chris Morley: > >>> Are you discussing an official linuxcnc release of ISOs? > >> So I hope. > >>> Are you suggesting including qtpyvcp on the ISO? > >> There are four Python modules missing in Debian to do so, from what I > >> have yet understood. But I feel motivated to help out, just locally > >> packaged oyaml. > >>> In my mind that undermines qtvcp which is actually part of linuxcnc. > >>> Full disclosure, qtvcp is project I started so I am slightly biased. > >> My motivation is to bring the best of Open Source CNC on Linux together > >> to help myself and others. And from what I hear and see, this includes > >> PyQtVCP. You may have a point for the minimal version of that .iso, but > >> for the full featured one it should be in, also FreeCAD and inkscape. > >> > >> Steffen > >> > >>> Original message > >>> From: Steffen Möller > >>> Date: 2022-11-29 8:53 a.m. (GMT-08:00) > >>> To: LinuxCNC Dev Mailing List > >>> Subject: [Emc-developers] Eye candy is important - Titan got a new German > >>> friend - want that reaction for a LinuxCNC controller > >>> > >>> Hello, > >>> > >>> No need to watch this, really. Titan has a nice Heller machine and passes > >>> the Sinumeric control > >>> https://youtu.be/zToKZtqQMIo?t=354 > >>> with some excitement. I actually find LinuxCNC even nicer, especially for > >>> what I saw from https://www.qtpyvcp.com/ . > >>> > >>> When we yesterday had this OpenMike session again, we had felt like there > >>> should be four USB sticks prepared: > >>>a) for two distros - Bullseye (Debian stable) and Bookworm (Debian > >>> testing, soon stable) > >>>b) in two flavours - minimalistic and fully-featured (including > >>> FreeCAD and Inkscape to make a good impression on those who come from the > >>> other OS) > >>> > >>> Andy had some confidence (and I share that) that the generation of those > >>> .iso files per se is not difficult. It was not immediately clear where > >>> the generation of those .iso files should happen, but the builders > >>> maintained by Sebastian are a likely target IMO. > >>> > >>> Question: Is there anybody out there who would like to work with me on a > >>> description and implementation of what the fully-featured .ISO should > >>> like alike? This would be Intel-only as a start, leaving everything for > >>> the RPi to Raspbian for the time being. > >>> > >>> There are a couple of Python libraries still missing on Debian to get > >>> QtPyVCP installed. This would likely be something for me to address. > >>> > >>> Best, > >>> Steffem > >>> > >>> > >>> > >>> ___ > >>> 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 mailing list > >>
Re: [Emc-developers] Eye candy is important - Titan got a new German friend - want that reaction for a LinuxCNC controller
I am not sure how that would be perceived as trampling on Qtvcp and that sounds like a very personal reason for exclusion of QtPyVCP UI's. I think that mentality is crippling to Linuxcnc's future and growth. I was under the impression we were collaborators not competitors? On Thu, Dec 1, 2022 at 1:42 PM Chris Morley wrote: > > Because qtpyvcp and qtvcp do the same job using mostly the same tools (python > and qt) > > If qtpyvcp wanted to be under the linuxcnc unberella they could have > continued working in qtvcp instead of making a new independent, project. > Nothing wrong with being independent, seems to work for both projects. > It is too bad we divided the effort but what is done is done. > > I'm sure neither project wants their years of work trampled on. > > Chris > > > > > Sent from my Galaxy > > Original message > From: Jérémie Tarot > Date: 2022-12-01 8:06 a.m. (GMT-08:00) > To: EMC developers > Subject: Re: [Emc-developers] Eye candy is important - Titan got a new German > friend - want that reaction for a LinuxCNC controller > > Le jeu. 1 déc. 2022 à 16:47, Small Shop Concepts a > écrit : > > > I think it would be great if QtPyVCP were included in Linuxcnc. I'm not > > sure how you mean it would undermine qtvcp? Isn't Linuxcnc stronger with > > more options for users? > > > Further, IIRC @cmorley, you're our UI API uniformization champion, aren't > you ? And I support that 1000% ! > What could be better on this front than to bring the other modern VCP > toolkit to the table ? And another awesome chap like @TurBoss ! > > > > I know JT also has been working on a config builder that is > > working really nicely and has added some features making setting up Mesa > > very simple and streamlined. > > > > Absolutely ! I already told JT and said here that MesaCT repository surely > deserves to join the LinuxCNC organization > > ___ > 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 mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCnc growing with to much none essential code
I would agree that development tools in Linuxcnc is not ideal, I think also in many cases it can bring a level of confusion to new users. I also think that it should be weighed and a solution found to bring those UI's that users would want to use into an easy to install situation that did not require pages of installation instructions foreign to windows conversion users or that would make it overly complicated. I truly believe this will thwart the user growth of linuxcnc over time. Probe basic before the py2/3 conversion issues, had an easy to install user version that was for the user who just wanted to run their machines and did not intend to make changes to the UI. There was also the developer installation which would allow for the installation of the QT developer kit for those who wanted to customize the UI and tailor it to their needs. I think maybe a macro solution to this would be to have the UI’s made available to be installed as a choice, but from within linuxcnc without the requirement of having it integrated in the linuxcnc installation. It seems to make the most sense and not force users to install unneeded/unwanted components. Perhaps it uses a script call, or installer download or Package Manager Etc. Joco wrote a script for installing Linuxcnc 2.9, the required RT Kernel, QtPyVCP and Probe Basic to make life a little simpler during this transition period and it works well save for it is rather lengthy installation time and update time (not complaining as I am grateful for the work Joco did to make it). My vision from the new user’s perspective would have a drop down menu very much like already exists with a tree branch for the developer version and user version of the available to install UI's for Linuxcnc and when selected would trigger the install of the user's selection. This would help keep the bloat out of Linuxcnc. In the docs as has been could be screen shots of each UI to help users decide on their flavor of UI for their machine types. I think this would simplify installation from the user’s perspective and would resolve the bloat growth within Linuxcnc. This will help bridge user tastes as some will want a more minimal UI and some will want a more robust UI that may take up more space and take a few seconds longer to load. Thoughts? Chris On Thu, Dec 1, 2022 at 12:44 AM Johannes P Fassotte wrote: > > 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 ___ 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
I think it would be great if QtPyVCP were included in Linuxcnc. I'm not sure how you mean it would undermine qtvcp? Isn't Linuxcnc stronger with more options for users? As the developer of Probe Basic and speaking on behalf of the thousands of Probe Basic users out there I am sure they would also like to see an easier method of installation. I know JT has many UI's that are used and Joco and Rod have been working on a really awesome plasma ui and Turboss is constantly pushing the envelope with new functionality and features for non standard machine types. Making these more accessible for users would only increase the possibility of attracting new users and open up development pathways for future growth and additions of UI development. I know JT also has been working on a config builder that is working really nicely and has added some features making setting up Mesa very simple and streamlined. I think this would be a very good things for Linuxcnc, and i say that with out Bias as I think qtvcp is great also and also adds strength to Linuxcnc's future growth path. Those are my thoughts at elast! Chris On Tue, Nov 29, 2022 at 1:11 PM Chris Morley wrote: > Are you discussing an official linuxcnc release of ISOs? Are you > suggesting including qtpyvcp on the ISO? In my mind that undermines qtvcp > which is actually part of linuxcnc. > Full disclosure, qtvcp is project I started so I am slightly biased. > > Chris > > > > Sent from my Galaxy > > > > Original message > From: Steffen Möller > Date: 2022-11-29 8:53 a.m. (GMT-08:00) > To: LinuxCNC Dev Mailing List > Subject: [Emc-developers] Eye candy is important - Titan got a new German > friend - want that reaction for a LinuxCNC controller > > Hello, > > No need to watch this, really. Titan has a nice Heller machine and passes > the Sinumeric control > https://youtu.be/zToKZtqQMIo?t=354 > with some excitement. I actually find LinuxCNC even nicer, especially for > what I saw from https://www.qtpyvcp.com/ . > > When we yesterday had this OpenMike session again, we had felt like there > should be four USB sticks prepared: > a) for two distros - Bullseye (Debian stable) and Bookworm (Debian > testing, soon stable) > b) in two flavours - minimalistic and fully-featured (including FreeCAD > and Inkscape to make a good impression on those who come from the other OS) > > Andy had some confidence (and I share that) that the generation of those > .iso files per se is not difficult. It was not immediately clear where the > generation of those .iso files should happen, but the builders maintained > by Sebastian are a likely target IMO. > > Question: Is there anybody out there who would like to work with me on a > description and implementation of what the fully-featured .ISO should like > alike? This would be Intel-only as a start, leaving everything for the RPi > to Raspbian for the time being. > > There are a couple of Python libraries still missing on Debian to get > QtPyVCP installed. This would likely be something for me to address. > > Best, > Steffem > > > > ___ > 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 mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
That sounds awesome! Tuned in to hear what everyone else thinks! On Sat, Nov 19, 2022, 3:40 PM Steffen Möller wrote: > > > > Gesendet: Dienstag, 15. November 2022 um 11:58 Uhr > > Von: "Jérémie Tarot" > > An: "EMC developers" > > Betreff: Re: [Emc-developers] 2.9 Release Manager Required. > > > > Le mar. 15 nov. 2022 à 01:03, Rod Webster a > écrit : > > > > > > I'll just wait until you guys decide on a way forward and iff the > offer we > > > have is required. > > > Perhaps the Github actions could be extended to build the 2.9 branch? > > > > I don't see what would prevent us to build whatever branches we'd want > to !? > > > > > If that were possible, maybe the VM here does the RTAI build? > > > > That remains possible with the GitHub actions thanks to the > > self-hosted runners feature: > > https://github.com/actions/runner > > https://docs.github.com/en/actions/hosting-your-own-runners > > https://github.com/actions/runner/blob/main/docs/start/envlinux.md > > > > > I'm not sure git will host the resulting debs > > > > Sadly, the GitHub Packages feature only supports programming languages > > modules packages. > > This is why I looked for an hosting solution and found PackageCloud.io > > which does just that. > > > > > but it might be worth mentioning the Open build Service I linked to > earlier can be incorporated > > > right into sources.list with the appropriate security keys. > > > > It is indeed ! Can't believe I didn't remember it and even that it > > didn't pop up in the many searches I did :/ > > This could actually be the best option to keep all builds (RTAI > > included), as it looks like OBS supports custom-built containers and > > VMs, and package hosting all in the same place. It may well be able to > > build the live ISO too, but I'm still not sure about that... > > It also supports GitHub integration via webhooks and status reporting, > > as well as it is Open Source and self-hostable, and even available in > > Debian... what else ?! :) > > > https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.scm_ci_workflow_integration.html > > > > OBS repositories could at least be mirrored/synced to > > http://linuxcnc.org/dists/ if no more elegant solution is available > > > > WDYT ? > > > > PS: Brother projects like MesaCT, QtPyVCP, etc. packages could also be > > built under LinuxCNC umbrella there too > > I do not get all the details but I tend to think that an external build > service would free energy for us to concentrate on LinuxCNC itself, so I am > very much up for it. > > Best, > Steffen > > > > ___ > 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
Re: [Emc-developers] 2.9-pre1
Is there going to be an iso or other install method for 2.9? If so is there an estimated time line? On Fri, Nov 11, 2022, 5:43 AM andy pugh wrote: > On Thu, 10 Nov 2022 at 18:18, Chris Morley > wrote: > > Is there any complete documentation of the process of releasing, so others > > could try to understand? > > > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ReleaseCheckList > > It does assume that the release manager has access to the buildbot. > > -- > 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 mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Time to split 2.9 and master?
Time for a official 2.9 stanle... :o I second! :) On Tue, Sep 20, 2022, 6:43 PM Rod Webster wrote: > Yes please! > > Rod Webster > *1300 896 832* > +61 435 765 611 > Vehicle Modifications Network > www.vehiclemods.net.au > > > On Wed, 21 Sept 2022 at 07:00, andy pugh wrote: > > > Is it time to split 2.9 off as a stable-ish branch with a 2.9.0~pre0 tag? > > > > -- > > 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 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
Re: [Emc-developers] next release discussion: Why not make the branch new
on Gitkraken for QtPyvcp we use the GLO Boards which is basically just an item check list with some good formatting, this way it is recorded what has to be fixed and strikes through once it has been completed. you can have an overall running list and other lists so you could perhaps setup a DTG (distance to go) :) list to launching the new release and once completed and checked off pull the trigger! it was quite useful a ways back trying to sort through a myriad of items and was a great motivator for when yuou had some time to work on something, striking through list items is very rewarding for me at least..lol https://www.gitkraken.com/ https://www.gitkraken.com/blog/gitkraken-boards-column-automation On Sun, Aug 21, 2022 at 8:25 PM andy pugh wrote: > On Wed, 10 Aug 2022 at 20:21, Hans Unzner wrote: > > > Andy, should I assist you by creating such a project? > > Possibly? > > (I am working through an email backlog, and only just got to this) > > -- > 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 mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Bug find
I am not sure if it is reported yet, but I am experiencing a status bug in which some m and g codes are not updating in status. This seems to be affecting qtpyvcp's backplotter as well and is being reported by other users as well. I verified the problem exists in axis prior to submitting here to make sure it was in fact in linuxcnc and not qtpyvcp. It is effecting the 2.8 and 2.9 branches from my testing. Mdi entries appear to work and update in status, but program load/run and Action buttons do not update status. It appears to be different level of breakage from 2.8 and 2.9. 2.9 seems to not like M3 M4 and 2.8 the same but also the work offset in gcodes doesn't want to update. Thanks and let me know you have any questions! Chris Polanski Lcvette on the boards and forum ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
