Am 01.07.2013 um 16:13 schrieb TJoseph Powderly <tjt...@gmail.com>: > On 07/01/2013 01:11 AM, Michael Haberler wrote: >> >> Am 01.07.2013 um 07:25 schrieb David Bagby <d...@calypsoventures.com>: >> >>> Andy, Michael, >>> The network accessibility of the data store and the associated API is >>> key to both providing and understanding the functionality that this >>> approach could provide. >>> Is there a proposed design document that lays out the API? >> >> not yet, this is the time to contribute your thoughts on the issue >> >> the way I envisage it to be is to be rather pythonic than c-ish, namely >> using name/value pairs as arguments rather than say positional arguments, >> which seems to me more suitable to the case and more extensible that a C >> binding >> >> on the operative level what I'll as soon as I'm back do is spin out a branch >> which has protobuf support and zmq examples in place so work can start 'in >> tree' on the issue >> >> - Michael >> >> > will the toolstore be only for linuxcnc or also for machines running > just HAL?
I would see using entities to be: interpreter, UI's, RT comps which access or change tool information so the answer would be: yes, in principle, but I'd have to think hard which entity could make use of tool information if the interpreter isnt there > > the python binding key:value sounds to me like a dict for each tool, What I refer to is: API parameters are identified by name, not positional, which gives a nice mapping to several interpretive languages (not limited to Python btw) It does not suggest the API _is_ a Python API; it is a set of protobuf messages going back and forth over zmq sockets and as such is rather independent of any language > > a dict allows different key sets for different tools( the broach has > keys that the grinding wheel does not ) > > will tool related data like spindle rpm and coolant be in the toolstore? I'd see the toolstore as a persistent storage mechanism; so for volatile settings I dont see the upside however, I'm currently considering persistent HAL pin values (note the mechanism in GladeVCP is being used, but I'm not particularly happy how that panned out; a proper solution at the HAL level would be better IMO) I note 'toolstore' is a bit of a misnomer, but I dont have a better name yet; I envisage it to be the single place where persistent values (surviving shutdown/restart) would be held - Michael > > thx andy thx michael > > tomp > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
