On Thursday 27 October 2016 09:01:00 James Waples wrote: > EBo, > > You're right, in hindsight that wasn't a very well thought out > statement. What I meant was to discuss what a minimal reimplementation > would look like and doing that relatively quickly, as opposed to > nailing down the entire desired feature set with a much longer > discussion period. > > This is a common pain point for Rust generally at the moment; nobody > knows it! Unfortunately I can't commit to maintaining an LCNC > component written in Rust, so a more commonly known language like C or > Python does make sense. > > James > > On Thu, 27 Oct 2016 at 13:45 EBo <[email protected]> wrote: > > 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 <[email protected]> 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.
First for someone like me, contemplating the making of a tool changer for my G0704, is a better, more foolproof method of identifying the tool, a method that doesn't cost $50 a toolholder to implement so that one could have a scan button to make LCNC scan the current contents of the chain and build its own in memory tool table from that. Then, on loading the code for this operation, LCNC could make an internal comparison to determine if it has the tools it needs to do the job, advising the operator what tools it still needs, and gives a list of those, and a list of chain pockets that contain tools not needed for this job so that those pockets could be emptied and refilled with tools it does need for the loaded job. The operator reloads the chain accordingly and rescans it to re-build its own tool table. But I do not know of a ready made tool ID method that is both non-destructable in normal usage, and could be done for $1.00 a tool holder, AND readily editable to reflect that the worn tool has been replaced, possibly by something entirely different. RFID stuff is pretty cheap, and the chip might be cemented into the open shank of a TTS holder, but is there such a space in the CAT holders? I've never had a CAT holder of any series in my hand. It would need to be applicable to all the tool holders such that LCNC would see a common data port, preferably with full read and write capability. As for the choice of languages for tool table implementation, I'm not overly impressed by the language of the month approach, for all of the reasons mentioned above. Format of the list, I'm in favor of anything that can be edited by nano, in CSV format in a pinch. But parsing that means a rigid data structure which is quite limited and matches what we have now. Limits. My $0.02. > > >> And > > >> who begins with a lathe list? IMHO the tool storage could be > > >> different. I think that is a given. I've tried to make a tool table for TLM, but when the QC tool holder's own base location on the cross feed may need adjusting (which totally blows away ALL the data in the tool table, no difference, see next paragraph, there from changing the compounds angle and position, but its 50x more rigid now) so the current tool can reach what it needs to reach, and I don't see that problem going away as I bring this 11x36 Sheldon back to life. Neither now has a compound feed, but the relatively massive blob of cast replacing it is carved off center on both machines to allow it to be rotated on the cross slider so that the tools cutting tip can be placed, both in or out and left to right, usually with the intention of putting the cutting tip at least within the left-right confines of the saddles very narrow footprint on the bed for TLM, and likely within the width of the cross slider's ways on the Sheldon. That may not be possible on the Sheldon as that Phase-II post sure has a large offset between its holdown bolt and the tip of any mounted tool. So cutting forces will unavoidably have some leverage on the cross-sliders ways. The at least 150 year old lantern post tool holder is far better in that regard. As a side note, the top and bottom of both globs of cast were machined with about a thousandth of concavity, this to put the bolt pressure on the outside. I have not had the post slip/rotate on TLM since, but when it was mounted on the compound, there was no way to stop that and I stripped the threads out of one compound top slider trying. Just one of the headaches that made that 7x12 earn its TLM moniker. But with the compound gone, and tapered gibs, its actually working pretty good now. The last drive rebuild changed the geardown in the belt drive so that it spends more time in low gear. With fresh tools it carved the toolpost base, starting at 5.5" in diameter, for the Sheldon. Took it a while, made about a quart of cast iron sand, but it did it. > > >> 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 Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
