On 9 November 2012 08:10, Michael Haberler wrote:
> what we need to break the NML size limit is the following change:
I am still reading the code and trying to see at which point the tool
table is passed in an NML message.
(I am not well practiced at teasing apart code, especially complex
code,
Am 06.11.2012 um 18:15 schrieb Michael Haberler:
>
> Am 06.11.2012 um 17:34 schrieb Michael Haberler:
>>
>> The mechanism I would choose for this API is to reuse the embedded Python
>> code which is already in place, robust and quite simple to use. The API
>> calls I listed above would just m
Am 09.11.2012 um 01:14 schrieb andy pugh:
> On 6 November 2012 16:34, Michael Haberler wrote:
>
>> the notion of a 'table' might suggest that this is a tabular arrangement of
>> data which code consults and gets a unique answer every time. This is not
>> the case, and it has to do with interp
On 6 November 2012 16:34, Michael Haberler wrote:
> the notion of a 'table' might suggest that this is a tabular arrangement of
> data which code consults and gets a unique answer every time. This is not the
> case, and it has to do with interpreter readahead. What you have in reality
> is an
Am 06.11.2012 um 21:54 schrieb andy pugh:
> On 6 November 2012 19:55, Jan Van Gilsen wrote:
>
>> Maybe you could use this geometry:
>> http://ars.els-cdn.com/content/image/1-s2.0-S0890695501000451-gr1.jpg
>
> I suppose that is one way to be very general. But excludes ogee router
> cutters and
On 6 November 2012 19:55, Jan Van Gilsen wrote:
> Maybe you could use this geometry:
> http://ars.els-cdn.com/content/image/1-s2.0-S0890695501000451-gr1.jpg
I suppose that is one way to be very general. But excludes ogee router
cutters and panel-raising bits.
Then the question becomes how genera
Andy,
Maybe you could use this geometry:
http://ars.els-cdn.com/content/image/1-s2.0-S0890695501000451-gr1.jpg
This results in different possible tool shapes:
http://ars.els-cdn.com/content/image/1-s2.0-S0890695501000451-gr2.gif
from: http://www.sciencedirect.com/science/article/pii/S08906955010
Am 06.11.2012 um 17:34 schrieb Michael Haberler:
>
> The mechanism I would choose for this API is to reuse the embedded Python
> code which is already in place, robust and quite simple to use. The API calls
> I listed above would just map to Python methods of the same name. There is
> just no
Hi Andy,
great to see the tooltable issue gets attention.
having thought about it in the past, and decided I leave this for LinuxCNC3 ;)
anyway let me note some observations and suggestions how to go about it.
first, views.
the notion of a 'table' might suggest that this is a tabular arrangeme
On Tue, 2012-11-06 at 12:33 +, andy pugh wrote:
> (Originally posted to the dev list, but there appear to be no opinions
> on the matter there)
>
> So, having started to think about how a database-based tool table might work
> (As background, the currently tool table only supports 56 tools,
>
On 6 November 2012 13:42, Dave Caroline wrote:
> The sliding head in the garage has two tools on a rocker
> so there is an inversion in direction for cutting too :)
That can be accomodated in the existing structure in at least two ways.
1) You can use negative diameters when using the other-side
> I suspect that it would be difficult for the code which transmits the
> tool table in the current structure to know which tools the requesting
> code wanted.
> Another inelegant feature of the current method is that it enforces a
> one-tool-per-pocket limit. I can conceive of a few scenarios wher
On 6 November 2012 13:08, Dave Caroline wrote:
> That NML message restriction is just silly, just send a few tools per message,
> those that are about to be used
There is a further complication with the current scheme (and with your
proposal) that means that several different "opinions" of the
On Tue, Nov 6, 2012 at 12:33 PM, andy pugh wrote:
> (Originally posted to the dev list, but there appear to be no opinions
> on the matter there)
>
> So, having started to think about how a database-based tool table might work
> (As background, the currently tool table only supports 56 tools,
> be
(Originally posted to the dev list, but there appear to be no opinions
on the matter there)
So, having started to think about how a database-based tool table might work
(As background, the currently tool table only supports 56 tools,
because that is what will fit in an NML message. Any module that
15 matches
Mail list logo