Realistically the "we can accomodate *this* much" is more of a design limit. It is good to know for practical purposes, but not so important from day to day. That said if I were working on it I would also make sure that the tool table could be read out-of-core -- meaning that there is some mode where you can read in just the portion you need to process without reading in the entire thing. That is the one place where having a relational database might give this to us for nearly free (assuming that we wrote the use case in the appropriate way).
I would like to hear what you find/think about the CAD/CAM problem. I have a situation where we need to worry about these things, and the question is if we do it outside of LCNC and only have that worry about the g-code, or if LCNC supports some of that as well. On Oct 27 2016 9:24 AM, dragon wrote: > Good point... I didn't even think of storing a mesh, wireframe, or > SVG > of the tool profile in the DB. > > I started playing with the path feature of the latest FreeCAD last > night. This morning I started to wonder what all of the different CAM > programs expect for reading in tool tables and if LinunCNC should > even > care about that? > > > > On 10/27/2016 08:14 AM, EBo wrote: >> On Oct 26 2016 9:40 AM, andy pugh wrote: >>> On 26 October 2016 at 16:07, EBo <e...@sandien.com> wrote: >>>>> This is NOT 1980. Memory (at this level) is free. >>> >>> Indeed. It is hard to imagine needing more than 5kB per tool. >> >> The 1980 quote was not mine (the clip makes it appeare to attribute >> that to me, but no offence taken). As mentioned in my reply, I have >> been doing a lot of massively parallel work of late (actually >> uniquely >> identifying every tree and shrub with a canopy size greater than 2 >> square meters across the entire sub-Saharan Sahel -- roughly 9 >> million >> square kilometres), and my mind just went to efficient packing of >> information. Sorry about that... >> >> That said lets do a simple budget analysis. if we us a 16-bit tool >> number. That gives us 65,536 choices (I would probably remove two >> of >> those to mark MIN_INT and MAX_INT as special cases or internal >> flags, >> but that is trivial) So assuming that it is 5,120 bytes we end up >> with >> a max table size of 336MB, but in reality, it would be a few MB in >> size. >> Those are reasonable numbers in modern machines. It is even >> realistic >> with small dedicated SOC embedded machines, but there it would >> probably >> be pushing what can be dedicated to the functionality. Now let us >> test >> our assumptions. What all is in the 5kB allocated per tool? Is >> that >> realistic? I can think of one application that might break that >> assumption -- where I digitize a high resolution profile of the tool >> so >> that I can model the actual shape cut by that tool. Very >> specialized >> work, and only really useful when you are custom grinding >> specialized >> tool bits with weird shapes and want to try feed that into a >> CAD/CAM. I >> would expect that to take up more than the 5kB, but lets start >> discussing what is already defined, and what people want to add, and >> make sure that we are not talking MB per tool instead of kB per >> tool. >> >> EBo -- >> >> >> >> ------------------------------------------------------------------------------ >> The Command Line: Reinvented for Modern Developers >> Did the resurgence of CLI tooling catch you by surprise? >> Reconnect with the command line and become more productive. >> Learn the new .NET and ASP.NET CLI. Get your free copy! >> http://sdm.link/telerik >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> > > > > ------------------------------------------------------------------------------ > The Command Line: Reinvented for Modern Developers > Did the resurgence of CLI tooling catch you by surprise? > Reconnect with the command line and become more productive. > Learn the new .NET and ASP.NET CLI. Get your free copy! > http://sdm.link/telerik > > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
