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 >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
