Am 31.10.2012 um 07:30 schrieb Chris Morley: >> Yes - the tool table entry for the geometry offset is in (Tool Number) + >> 10,000. I agree that it's odd, but it's the way Fanuc designed it. Because >> I was trying to make the interpreter behave the way a Fanuc lathe >> interpreter behaves, I figured I'd duplicate the whole enchilada. It >> doesn't play too well with tooledit.tcl - a revision to tooledit.tcl that >> supported this patch would make this patch easier to use - perhaps with your >> GUI expertise this is something you could easily handle. > > I would suggest we drop the +10000 - it's not needed and doesn't add anything. > I know nothing of TCL which tooedit.tcl is programmed in so sorry can't help > you - though I would upgrade tooledit_gtk if needed. > > Yes I see that adding two wear entries is necessary. I think Michael was the > last one to change the tool table so maybe he could chime in.
looks like I'm married to the keywords 'tool table', and I'm responsible for Xmas lighting now, too;) sorry, but I would'nt know what to do in that case. The tt data model (haha) is basically inextensible as it stands, so kludging is IMO the only option right now. -- A while ago I suggested a DB approach to the tooltable - which would have allowed for a tool being retrieved through a view, like including holder and wear offsets. The reaction basically was 'oh my god, he's taking the grandiose flat text file format from me, we will all have to run Oracle to start with, yada yada etc etc', so that is where we are - kludging around. Maybe it helps if folks think around the corner next time before shooting down an idea if "being used to how it always was" is viewed as unconditionally preferable to solving a fundamental problem. And probably I should stop listening in such cases. - Michael as for the amount of design: I understand the reason for the latest design round of the TT file format was 'it looks like gcode so the interpreter can read it in theory' - which I cant discern as desirable to start with, plus: that 'reading by the interpreter' never happened. > >> >> >> I wasn't sure about the INI file setting versus the features mask - the >> features mask is already in use for enabling/disabling other interpreter >> behavior changes. I think that an INI setting is easier for the integrator, >> but that features mask seemed to be there for a reason. Comments from >> others would be appreciated. >> >> Rogge >> > > The feature mask for for remapping code. > Again Michael could chime in to let us know why he chose a mask rather then > switch but I'm sure it makes remap code easier. > > Thanks for answering the questions. > > Chris M > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
