I got to the point with the tool database where I either wanted to push it for discussion, or tear it up and start again. I chose to push it _then_ tear it up and start again.
The impetus for the change partly came from the request for tool wear offsets to be added. The current arrangement is that the entire tool table is passed around between the modules in an NML message, which are a limited size, and so any increase in tool-table complexity results in a reduction in the number of tools available. The "drogge patch" that some people are using makes this explicit, in that "dummy" tools need to be used to hold the wear offsets. If you are going to make the tool table into a database, then it makes sense to try to get the database right. I think we have that, or at least something pretty close. Once the tools are in a database it is relatively easy to add new data fields, and as long as the API stays the same, it should not require any code changes. One aim of the new structure is to allow the database to potentially reside on a separate system. It seems logical for the tool database to be factory-wide. The initial push I made yesterday doesn't actually do any of this. It simply copies the existing tool table to a local SQLite database. The point of this branch was to figure out where the tool table gets used, and what needs to change to make it all work. Everyone seems to be in agreement that there should be a "tool API" rather than the raw tool-array access that is currently the norm. I started out writing this API in Python (lib/toolstore.py). In a move I think I now regret I also decided to allow for configurable queries into a configurable tool database, so there is an XML-like file of SQL code that is used to import tool files, and access the tool database. (share/sql/classic.sql). This arrangement does work, but I don't really like the sqxml file, and this structure is only needed if there is a requirement to support radically different versions of the database structure. It also turns out to be far from elegant to call Python classes from C++. Any file that wants to access the tool database API needs to #include boost::python and the access to the classes is by curious incantations, and the return values need to be parsed out into C-types. A typical example is src/emc/iotask/iocontrol.cc lines 607 to 644. I can see a number of ways to make this "nicer". One way, which I suspect won't work, would be to leave the code almost unchanged, but to add tool database access methods to the NML class. If you look at src/emc/nml_intf/emc_nml.hh lines 1562 to 1573, that is where the data lives that everything else uses. That's a C++ Class. So in principle that data could be handled by getter and setter methods into the tool API. My suspicion, though, is that the "message" passes through so many layers (and may find itself on a remote system) that this approach won't work. It also seems likely that the sucessor to NML won't be posting C++ classes around the network at all. On balance, I think all that belongs in that data field (which is what it really is being used as) is the URL of the active tool database. The boilerplate for sql->python->C++ is untidy, so the obvious answer seems to be to wrap it up in some functions. I can't decide whether to do that as #defines (doesn't seem right) or a set of new C++ functions. Then the question is whether the C++ functions call Python functions, or the Python class imports the C++ class. (There may be a third way, can Python export classes to C++ in a way that is simpler than Boost, at the expense of more complex Python code) I will point out that it makes no difference to me whether I code in Python or C++. I will be learning both languages almost from scratch anyway.... [QUESTION] How best to organise a tool database API in terms of where the code is held, and which language it exists in. I think that it would be better to only have one tool database structure. We did spend months trying to get it right, after all, so I think we should trust ourselves there and always use the "big" structure. Tooledit is probably the place to conceal that complexity when it is irrelevant. [QUESTION] Is the "one structure to hold them all, one structure to find them" approach to the database layout the way to go? There is another big issue that worries me. Some things keep a private version of the tool data. Some things _need_ to do this. For example the GUI preview needs to keep track of tool offset changes. It must _not_ commit those changes to the database, or things will go wrong at runtime. I need to be very careful about this. A less straightforward but similar situation exists with read-ahead. What happens if the g-code has a G10 in it, which changes an offset in the tool table? This might cause problems if not-yet-executed moves access the tool database directly at all times. This seems to indicate that there needs to be a local set of offsets kept in the motion planner that is "true" for the current segment. What happens if read-ahead goes through a G10 but execution is halted before executiuon gets there? I think it is probably not a problem, as it if was, it would also be one with the existing tool handling. But it is something to worry about. (Incidentally, G10 in the recently pushed branch still operates on the tool array, not the tool database.). [QUESTION] Does the code in src/emc/rs274ngc/interp_convert.cc:3509 (Interp::convert_setup_tool) only get executed at block execution time, rather than read-ahead time? [QUESTION] What worries you about all this tinkering? -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
