Am 09.11.2012 um 01:14 schrieb andy pugh:
On 6 November 2012 16:34, Michael Haberler mai...@mah.priv.at 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
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 map to
On 9 November 2012 08:10, Michael Haberler mai...@mah.priv.at 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,
On 6 November 2012 16:34, Michael Haberler mai...@mah.priv.at 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
Am 06.11.2012 um 21:54 schrieb andy pugh:
On 6 November 2012 19:55, Jan Van Gilsen janvangil...@gmail.com 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
(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
On Tue, Nov 6, 2012 at 12:33 PM, andy pugh bodge...@gmail.com 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
On 6 November 2012 13:08, Dave Caroline dave.thearchiv...@gmail.com 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
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 where
On 6 November 2012 13:42, Dave Caroline dave.thearchiv...@gmail.com 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
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,
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
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
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:
On 6 November 2012 19:55, Jan Van Gilsen janvangil...@gmail.com 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
15 matches
Mail list logo
