On Thu, 5 Nov 2020 at 04:34, Johannes Fassotte <[email protected]> wrote:
> It seems to me that a regular file or small database is more than > sufficient for a tool table with a choice depending on if pictures are > wanted or not. I see absolutely no valid reason for messing around with > NML buffer sizes to handle the tool table. The reason that the tool table is present in the NML file is that the data is potentially required by the realtime layers. This often runs in kernel space, and kernel space has no file system access. It does seem that a low-effort fix might be to only load the NML file with tools actually used in the loaded G-code file. (Though this might be impossible in some circumstances, for example tools or offsets being selected by analogue inputs or computed from probe results) A better solution in my opinion is simply to accept that any tool change or change in tool data "busts the queue". Maybe I lack imagination but I can't see any need to blend paths through a tool change. This would allow a call back to Userspace for the new tool data, and then a database query. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
