James, You state: "Everyone could talk about things forever without anything being implemented. As long as the right decisions are made..." What is happening now is hashing out what people care to see. Other than that, we are discussing what we foresee as potential issues with the approach put forward.
With regards to Rust... It may be a very natural and appropriate choice. I do not know because I know nothing about Rust. And that is my point. I think there might be two Rust developers on the whole list. If you implement this in Rust you will require that some portion of the developers all learn Rust so that it can be maintained and extended -- or are your volunteering to maintain this for the next 10 or 20 years? Personally I believe that adding a new language dependency for a critical piece of code is really a bad idea from a maintainability and stability standpoint. Other than that if you want to knock up a prototype and pitch it to the group, that would be a reasonable next step. Frankly I would probably take something written in Rust and reimplement it in C, or any language that already implements major portions of the LCNC code -- so that it plays well with the rest of the code base. Anyway those are my thoughts. On Oct 26 2016 11:26 AM, James Waples wrote: > The tool count should be limited by how much RAM your machine has ;). > > We should start with a well designed, minimal reimplementation of the > tool > table in it's current incarnation (minus warts) and add features as > they > are needed/wanted. Everyone could talk about things forever without > anything being implemented. As long as the right decisions are made > new > features can be added quite easily, both to LinuxCNC and this library > module. > > I'd like to suggest Rust as the language of choice for this. The tool > library is a somewhat standalone component and would be a good > experiment > for using Rust in a wider capacity in LCNC. It's also pretty good at > binding with C code so integration shouldn't be too difficult. That > said, > it's quite a new language and mindshare is somewhat limited currently > so > this might not be the most practical solution. > > On Wed, 26 Oct 2016 at 18:11 Niemand Sonst <nie...@web.de> wrote: > >> Hallo, >> >> I followed till now with big interest. Most opinions and wishes are >> clearly understandable, but shouldn't we begin with other questions? >> >> - How hard will it be to get the tool storage out of real-time? IMHO >> it >> does not belong there. >> - What information are needed for linuxCNC itself (iocontrol, >> interpreter, etc) >> - What informations are needed by the GUI or what are the >> requirements >> of the user? >> - etc. >> >> Without knowing all that, it is not possible to discuss about the >> storage way (text, Database or XML, etc.) >> >> If I am allowed to dream: >> >> Tool table is a graphical tool editor, with images to show the user >> a >> drawing with the information required. >> "No" Tool number limit (I have no company, but one of my machine has >> about 150 SK30 tool holders, I was lucky getting them for some boxes >> of >> beer ;-) >> It contains (for a mill) >> - Tool Number >> - Poket Number (actually not handled correct in remap) >> - Tool diameter >> - Tool wear in diameter >> - Tool length >> - Tool length wear >> - length of the cutting flute (and linuxCNC will look in future if >> the >> tool is suited ;-) >> - Form of the tool (V or ballnose or flat (Future preview will show >> that >> style, because it will cut from a solid) >> - How long has the tool been used >> - How many times has it been mounted >> - Number of teeth (Cam may need that) >> - what is the recommended cutdepth / teeth (Cam may need that) >> - What speed to use (Cam may need that) >> - Power limit (If the tool needs more power, the machine will go in >> stop >> to avoid damage on the machine, like a aluminum milling closing the >> flutes) >> >> I am sure there will be more wishes, so please add them to the list. >> And >> who begins with a lathe list? IMHO the tool storage could be >> different. >> >> I am a python fan, so that is my preferred language to code the Tool >> editor. I am willing to do that, but I am not able to change the >> iocontrol, interpreter code :-( Who help with that? >> >> Norbert >> >> >> >> >> ------------------------------------------------------------------------------ >> The Command Line: Reinvented for Modern Developers >> Did the resurgence of CLI tooling catch you by surprise? >> Reconnect with the command line and become more productive. >> Learn the new .NET and ASP.NET CLI. Get your free copy! >> http://sdm.link/telerik >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> > > ------------------------------------------------------------------------------ > The Command Line: Reinvented for Modern Developers > Did the resurgence of CLI tooling catch you by surprise? > Reconnect with the command line and become more productive. > Learn the new .NET and ASP.NET CLI. Get your free copy! > http://sdm.link/telerik > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
