> On 7. Apr 2020, at 18:15, Gene Heskett <[email protected]> wrote: > > On Tuesday 07 April 2020 11:34:22 Reinhard wrote: > >> Hi, >> >> On Dienstag, 7. April 2020, 16:13:07 CEST Rene Hopf via Emc-developers > wrote: >>> 1. Fix pocket numbers >> >> I'm no developer, but please allow me to bubble a few thoughts about >> tooltable, atc, pockets, slots, ... >> >> I'm quite unlucky to work on a machine, where I have to struggle with >> atc- slots. But I'm convinced absolutely, that's because of the >> deficits of the tooltable (my machine has nothing that can be called >> tooltable seriously :( - tool properties are just entries in >> onedimensional parameter list) My colleague at work that work on a >> recent mazak don't have that problem, as mazak machines have a >> marvelous tooltable. With big comment field, where you can enter >> meaningful descriptions and a picture, that shows the tool ... cnc-UI >> shows the tool picture of the current active tool - so cute ;) >> >> My colleagues don't bother with slots. Everything works by toolnumber, >> even the backdoor of the atc (with about 150 slots), where you can >> load or unload tools from atc, works with tool numbers and >> tool-description. Yes, you can search commentfield for substrings :) >> >> So I believe, that an atc should be like a blackbox for linuxcnc (on >> many machines the atc comes from a different vendor, than the machine) >> and tit for that - the atc should not be allowed to touch tooltable >> from linuxcnc. The atc-interface is pretty clear and simple: machine >> and/or operator ask for toolnumber and the atc should manage its >> own/private reference-table, where the toolnumber is associated to a >> slot. >> The atc does not need to know more about a tool, than its number. >> But for internal purpose, it will probably need more properties about >> the slots than just a number. But linuxcnc should not care about >> internal properties of the atc. >> There are many flavours of atc, but if the atc is an exchangeable >> module, only the toolnumber interface is of interest. >> >> So the tooltable in linuxcnc should be extended/changed. Slot field >> should be removed. Current file format already supports a comment >> field, axis and some other guis (like mine) read the file that way, >> but backend of linuxcnc does not support comment in status, which is >> pretty poor. >> >> I believe, that its a big overshoot to put the tooltable in the >> nml-status- area. Tooltable-properties are quite seldom requested by >> ui, so it would be sufficient, if the table or parts of it would be >> served at request only. >> >> Such a tooltable as described would improve decoupling of modules and >> would be good deed for users too :) >> >> >> cheers Reinhard >> > I'm with Reinhard but it sounds like a major rewrite perhaps belonging in > 3.0?.
I have more plans, but they will not be ready for 2.8. My commit already does part of that, cleaning up the internal handling of numbers. > > In any event I'm opposed t0 the automatic reload of the last tool. I home > to a safe position, and I sure don't want the last tool used loaded > leading to a crash and broken tool when I fire up linuxcnc the next day. But that is what your machine hardware does. When you restart, it will still have the last tool in the spindle. And that is how it was handled for random changers. What I don’t understand is, why nonrandom changers should behave different on startup. Not having a tool, but the machine thinking it has a tool is a safe condition, as it will store no tool to its pocket. The current implementation is dangerous, when the machine thinks it has no tool, and picks one up without storing the old one. > > 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) > If we desire respect for the law, we must first make the law respectable. > - Louis D. Brandeis > Genes Web page <http://geneslinuxbox.net:6309/gene > <http://geneslinuxbox.net:6309/gene>> > > > _______________________________________________ > Emc-developers mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/emc-developers > <https://lists.sourceforge.net/lists/listinfo/emc-developers> _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
