EBo, dave, Michael, Andy... Thank you for the explanations...
>>Bang, trapped again. You simplify an implementation; you never simplify the >>model proper because that gives you the power to describe the complex_and_ >>the simple. >>Note: the mess we have now is the result of 'going simple and optimizing the >>common case' too early. I get it.. way to early to be discussing simplifications. I can understand how early simplifications can cause problems down the road. I have entered that trap before! ;-) Ebo, you make a good point regarding the future also.. regarding other possible offsets. >>I don't know if you would need more than two offsets. I suspect that >>three would be plenty. Certainly tool and wear offsets are a must, but it isn't hard to imagine more than two being required in some situations. Perhaps the number of offsets should be configurable?? Offsets could come from a number of sources.. Dave Cole On 5/17/2013 5:11 PM, EBo wrote: > Dave, > > Fortunately these emails are archived, so they will not be *lost* but > converting the current discussions into a proper design document (even > informal) is going to take a fair bit of work, and I would argue is > still half baked. > > regarding tool ware offsets and who is going to bother... you are > probably correct if the only interface is editing the tables by hand, > BUT if someone developed something like a vision system that was able to > analyze the wear from an image, and update the table from there, then it > is as easy and snapping some pictures and easy as "click" -- ONE the > code is written ;-) But regardless of that. People have express the > desire/need for wear tables... > > To your list I would also add -- an integrated regression suite for the > code, and .... I forgot the other couple of things on my own mind... > > EBo -- > > On May 17 2013 1:06 PM, Dave wrote: > >> Andy, >> >> I've been trying to follow this thread but it keeps wandering off >> into >> other directions. (I'm partially to blame for that..sorry) >> >> Sounds like you are thinking out loud (good) and that an informal >> design >> document is being formulated. >> >> Can this be put into an outline form of some type?? (Do you already >> have something ..??) I think there are a lot of good ideas being >> discussed here and I am afraid we are going to lose some of them. >> >> As an integrator (wanna-be developer), I think that the LinuxCNC >> software is fantastic. (Thank you Andy and the other developers - >> you >> know who you are.. :-) ) >> >> In my mind, I think the best that LinuxCNC developers can do is to >> create an underlying framework of software that is adaptable, and >> then >> provide a "standard implementation". >> >> I like the idea of a database. However, realistically, how many >> people/users are going to want to apply the wear offset from one tool >> to >> a different tool?? Is that a requirement/desire by someone?? >> It seems like an overkill and could result in user errors and >> consequently machining errors. The general question I am >> raising...is >> how flexible do we want the tool table/offset/wear offset >> table/database >> to be? >> If it is made too complex, we risk a lot of confusion regarding the >> proper implementation of the tool table. I'm thinking that if the >> manual section of configuring the tool table is 20+ pages long, that >> will be a problem and the common LinuxCNC user will avoid altering >> the >> tool table at all costs. >> >> My two cents.. >> >> Dave Cole >> >> >> >> >> On 5/17/2013 1:03 PM, andy pugh wrote: >> >>> On 17 May 2013 17:51, EBo<e...@sandien.com> wrote: >>> >>> >>> >>>> to maybe state it a different way, is a relational database >>>> approach >>>> the best design model? Are there other design (like object >>>> oriented) >>>> from which we can leverage utility? >>>> >>>> >>> The tool data needs to be presentable to users in an editor. That is >>> one constraint that might cause problems. >>> I also think it is important that there should be no hard-coded >>> keys, >>> that system integrators can add application-specific data. >>> >>> >>> >> >> >> ------------------------------------------------------------------------------ >> AlienVault Unified Security Management (USM) platform delivers >> complete >> security visibility with the essential security capabilities. Easily >> and >> efficiently configure, manage, and operate all of your security >> controls >> from a single console and one unified framework. Download a free >> trial. >> http://p.sf.net/sfu/alienvault_d2d >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > > ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
