On May 17 2013 11:15 PM, Michael Haberler wrote:
> Am 18.05.2013 um 00:55 schrieb Dave <e...@dc9.tzo.com>:
> ...
>>>> I don't know if you would need more than two offsets. I suspect
>>>> that
>>>> three would be plenty.
>>
>> Certainly tool and wear offsets are a must, but it isn't hard to
>> imagine
>> more than two being required in some situations.
>> Perhaps the number of offsets should be configurable?? Offsets
>> could
>> come from a number of sources..
>
> Let's look at a simple example how you would model offsets in a
> relational schema, since it's a good example to start thinking about
> this:
>
> you'd have the following tables (the first attribute is the primary
> key and unique - no duplicates):
>
> tools(toolid, length, diameter, other-non-offset parameters)
> offsets(offsetid, xoffset,yoffset..., purpose) (purpose could be:
> coordinate system offset, wear, tool holder..)
if we redefined [xoffset,yoffset...] to be an n-tuple of offsets, then
we can simply the API to offsets(offsetid, [offsets list], purpose).
From a programming perspective I would rather see the ordering changed
to
offsets(offsetid, purpose/decription, xoffset,yoffset...)
I can make that easily work in code, but this is a niggly bit. I would
like one of the always defined fields to be a descriptor. In can be
empty, but I think it is reasonable to always have a human readable
"what the hell is this" field. Hmmm... maybe I am getting caught by the
"jumping to quick to implementation details, but...
On a more theoretical level, does it make any sense to have more than
6-D offsets for a tool? If a tool has some length, then row/pitch/yaw
can come into play, but I am having trouble conceptualizing a 7-D+
offset (unless other dimensions include info on force feedback or tool
friction). That being said, I agree that there is no real reason to
limit the table size and just keep it an n-tuple.
> then you have a relation describing the active offsets, which is 1:N
> in nature (a tool can have an arbitrary number of offsets or none at
> all):
>
> tooloffsets(toolid, offsetid) (only toolid is a primary key)
Getting back to the abstraction of tool number (which is a CNC
programming abstraction, ie. T01), tool UID, and the offsets which I
think only make sense attached to a given unique tool id. So, I would
conceptually explore something like this:
set_tool(toolnum, toolid) (where toolnum equates to something like
T1)
set_tooloffsets(toolnum, offsetid)
I can also see tooloffsets(toolid, offsetid) in the relations table.
Hmmm... maybe that is what you meant whereas I was thinking in
programming model instead of relations model... So, we should be clear
when we talk about relations/program models to make sure we are talking
the same thing, but to further the discussion I would like to keep the
idea of abstracting the tooluid from the toolnum.
> the actual offset of a tool is a view of these relations, say defined
> as activeoffset(tool) which does the following:
> - select all tooloffsets where tool == toolid, and add the columns of
> matches to determine the compound offset
>
> (there is no point and no simplification gained in limiting the size
> of the tooloffsets table)
agreed.
> the following operations would become toolstore API calls (among
> others) *):
>
> - activating an offset(o) for tool(t) : this becomes an insert
> operation on table tooloffsets(t,o)
> - deactivating an offset(o) of tool(t): becomes a delete operation on
> tooloffsets(t,o)
> - changing an offset(o) whether active or not: becomes an update
> operation on table offsets where offsetid == o
> - retrieving the current offset becomes a select on the
> abovementioned view
>
> Note that database object (tables, rows, views) do not cross the API
> - those are internal to the toolstore, which means the interpreter,
> gui, motion etc remain agnostic wrt the storage mechanism
I mostly agree, however there is the issue of connecting the unique
tool id to the tool number. Other than that I agree that the model
seems workable.
> a loosely related example, which expresses some of the above in a
> sqlite3 schema: http://pastebin.com/sAqJW6TV
> (this was an attempt to formulate the idea of tool holders which came
> up a long time ago on the list; conceptually holders are a form of
> offsets and probably could be subsumed under offsets)
> the 'actual offset' view is called 'total_offsets' there and the view
> is defined in line 108
I will have to look at this in detail later. I need to get back to
work and then repare a machine, and then think about spending a little
time on my thesis...
> *) to become useful in the linuxcnc context, API calls would need an
> extra 'perspective' parameter, which could be either 'interpreter' or
> 'machine' as the interpreter might be far ahead of the machine
The last time I took a graduate level course in computer graphics the
instructor suggested separating the world view from the perspective,
object, and other views. In this way we could easily run the objects
through multiple transformations (which are additive and cam be
precalculated in transformation space and the world transformed once
instead of running each transformation separately). I would have to
wrap my head around what this would mean in terms of geometric
abstractions for offset-surfaces/tool-paths, but the point here is this
is a way to accommodate the idea that tool holders are basically offsets
themselves to the machine head reference point.
> plus there would be operations to synchronize perspectives: 'apply
> offset' means to commit the interpreter perspective to the machine
> perspective at an appropriate point during execution; whereas
> 'synchronize interpreter' would mean to commit the machine view to
> the
> interpreter view (e.g. on startup)
I think in principle I agree, and it may be a different way of saying
what I did above. There be dragons in the depths of this path, but I
think it may be a fruitful one to consider.
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
