#linuxcnc-devel Logs

Feb 27 2018

09:14 PM jepler: rene-dev: that test takes each header file that is copied to include/ and, with a few hard-coded exceptions, makes sure that it "works properly" as a header file.
09:16 PM jepler: rene-dev: if it detects a problem, then show us the changes and the specific errors and we may be able to provide guidance.
09:16 PM rene-dev: thanks, I figured that out, and found it in the makefile :)
09:16 PM jepler: okay
09:16 PM rene-dev: my changes pass almost all tests now...
09:16 PM rene-dev: whats your opinion to where the tooltable should go?
09:16 PM rene-dev: currently its in iocontrol, and I moved it all in the interpreter.
09:17 PM jepler: oh you mean in which process or component? I don't have a well-formed opinion about that.
09:17 PM rene-dev: I think the interpreter is a much better place, as that is the stuff that accesses it
09:17 PM jepler: I appreciate you asking though
09:17 PM rene-dev: ok :D
09:18 PM rene-dev: I see the tooltable similar to the parameter file, and thats in the interpreter
09:18 PM jepler: so you would add a call like GET_EXTERNAL_TOOL_TABLE_FILE_NAME?
09:18 PM jepler: and remove calls like GET_EXTERNAL_TOOL_LENGTH_XOFFSET ?
09:18 PM rene-dev: its in the rs274 dir, but actually used by iocontrol...
09:20 PM rene-dev: currenlty I just get it from the ini. the interpreter parses the ini to get the parameter file...
09:20 PM jepler: that's going to cause problems
09:21 PM rene-dev: why?
09:21 PM jepler: at least, I fear that it would cause problems
09:21 PM jepler: have you encountered how UIs with preview have to provide an alternate var file for the preview?
09:21 PM jepler: becaues the act of previewing a part program need to *NOT* affect the "real parameter file"
09:21 PM jepler: so they need to provide a copy of the parameter file, use it to generate the preview, and then throw away any changes
09:22 PM rene-dev: I see, probably the same goes for the tooltable, as that can be edited from gcode
09:22 PM jepler: exactly
09:23 PM rene-dev: good point
09:23 PM jepler: with SET_TOOL_TABLE_ENTRY I think
09:24 PM jepler: so in the alternate world, where interp modifies the tool table directly, I think it needs to get the tool table *name* in a way that it's easy for the previewing UIs to point at a throaway copy of the table
09:24 PM rene-dev: yes, that sends a message to iocontrol
09:24 PM jepler: now, of course, this could be done by the previewing UI creating a whole alternate inifile...
09:24 PM jepler: within the previewing UI, SET_TOOL_TABLE_ENTRY calls different code, it doesn't call into task (and from there to iocontrol)...
09:24 PM rene-dev: I dont have a copy anymore, I read from the file/database every time. I only need to throw away the writes.
09:25 PM rene-dev: preview is done all in python, with a different interpreter as far as I see
09:25 PM jepler: the interpreter is the same, but the implementation of all the canon functions like SET_TOOL_TABLE_ENTRY is different
09:26 PM rene-dev: yes, thats what I meant
09:26 PM jepler: OK then we're on the same page
09:27 PM jepler: and yes the previewing UIs in the tree all do it in Python, but in theory there's no reason a previewing UI couldn't do it in C++ instead; making sure that's not totally broken for an out-of-tree C++ previewing UI is what tests/interp/compile is for
09:28 PM rene-dev: yep
09:28 PM jepler: (it's too bad they are plain functions and not (virtual) methods on a class which would have different implementations, but that's part of the original NIST interpreter design that we inherited; I don't know if it was originally plain C code, where such a decision made more sense...)
09:29 PM jepler: it's late here, so I'll be going AFK soon, but I hope that the perspective and feedback are useful.
09:29 PM rene-dev: I also had to remove the tooltable array export thing to python, it didnt seem to be used by anything. Im sure it can be added, but I dont know how to do that properly with the python bindings.
09:29 PM rene-dev: sure it is :) its even later here^^
09:31 PM jepler: you mean this thing?
09:31 PM jepler: interp_array_types.hh:typedef pp::array_1_t< CANON_TOOL_TABLE, CANON_POCKETS_MAX> tool_table_array, (*tool_table_w)( Interp & );
09:31 PM rene-dev: yes, that array, and its limits are all removed
09:31 PM jepler: configs/sim/axis/orphans/pysubs/remap.py: print "tool number:", self.tool_table[n].toolno
09:32 PM rene-dev: the length was hardcoded everywhere
09:32 PM jepler: I think that this might be accessing it
09:32 PM jepler: yes I see that an assumption about the max # of items is written right there
09:33 PM rene-dev: yes, there were a few things, but they only ever accessed the current or prepped tool, not any tool. so there are seperate variables for that.
09:33 PM jepler: I see.
09:33 PM rene-dev: but im sure it can be made in a way that the function to access any tool can be called from python
09:34 PM jepler: I am trying to imagine the use case
09:34 PM jepler: someone wants to write a remap which says "load me the biggest tool with diameter under 5mm"
09:34 PM jepler: goodnight
09:34 PM rene-dev: same goes for iocontrol. iocontrol doesnt need any tool, only current and prepped. so I added all it needs to the nml messages, so you dont need 2 copies of the tooltable, like it is now