Andy, Jon - Am 15.06.2013 um 03:52 schrieb Jon Elson <el...@pico-systems.com>:
> andy pugh wrote: >> On 14 June 2013 15:03, Matt Shaver <m...@mattshaver.com> wrote: >> >>> Should, for >>> example, the HAL be installable as a stand alone system (without the >>> CNC part of linuxcnc)? That was John Kasunich's original idea. IIRC >>> he was going to call it 'BLOCS'. I'm sorry that, at the time, I didn't >>> push him in that direction. >>> >> >> To a large extent it is. I do nearly all my testing in what amounts to >> a HAL-only environment. I have even set up machine controls in that >> way. (ie, halrun + stepgen + PyVCP + custom components) >> > And, I agree that we should keep this option to run hal standalone. This is what will happen automatically if we follow the machinekit idea through. But I dont think that will find much outside use if kept buried inside LinuxCNC. I'm relatively intimate with LinuxCNC intestines but it took me a while to figure that HAL standalone use is in fact possible. In theory that is, even the linuxcnc script as it stands today insists on starting task, emcio and whatnot if you like it or not. reiterating the MachineKit sales job with a minimal status report tacked on ;): - separate out HAL/RTAPI/components plus HAL-only gui tools into a standalone project, tentatively called MachineKit - introduce a documented remote-capable API based on zeromq, protobuf (with optional json/websockets hooks on top) to replace NML - mutate the rest of linuxcnc to talk the new API (this will affect primarily task, plus some gui supporting modules like the Python linuxcnc module) - mutate the command/acknowledgement input to motion to use same API - mutate the status reporting interface of motion (aka emcstat) to be based on observing HAL changes exclusively (i.e. no more dual path: HAL plus some funny ad-hack messages specific to a module) NML: history; HAL: usable standalone by definition (and more likely by other automation projects). Good license boundary. The LinuxCNC package would have MachineKit as a package dependency and be in effect using code. --- All the HAL extension work plus protobuf infrastructure and JSON autoconversion support is done. I'm now starting with the using layer - HAL status reporting, and motion command/status I/O I have already experimentally ripped the current motion command/status interface and replaced it by HAL messages and ringbuffer, and linuxCNC continues to run fine meaning I caught all sidechannels ;); however as it currently stands, the shared memory design assumption makes for a inelegant solution with 1:1 transliteration; the interaction model needs a bit finer granularity, namely a split between command/command acknowlegdement (really an RPC pattern on the motion upperlevel command handler) and separate status reporting based on a halcmd-defined set of status messages (which will come out as a Publish/Subscribe based interaction pattern). - Michael ps: kudos to Pavel for two of the more hairy parts of the plumbing addons: the lock-free ringbuffer code, and the JSON/protobuf autoconversion! > > Jon > > ------------------------------------------------------------------------------ > 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
