On 9/19/2012 6:30 PM, Michael Haberler wrote: > Am 19.09.2012 um 23:54 schrieb John Kasunich: > >>> The example case (reporting HAL groups as compound messages of several >>> HAL signals) is directed at a messaging model, though not request/reply; >>> I would think publish/subscribe is the more suitable pattern for status >>> reporting. I'm exploring a model where a 'HAL group name' becomes a >>> 'topic name' on the publish/subscribe level automatically, and >>> serialisation of HAL objects is derived from the group member list, with >>> the idea of having status messages generated by HAL-only configuration >>> and nothing else. I would think retrieving the names and types from HAL >>> <...> >> I still haven't wrapped my mind around your idea of messages in HAL and >> signal groups. My server/client thought was strictly thinking about > I know this is pending explanation. I'm writing on it (text, not code); > <...> > Right. > > The HAL groups/status reporting idea could be viewed at two levels: > > At the halcmd level, there are two new objects, groups and members. Groups > are named and have parameters which HAL does not interpret per se, just > convey them. Same for members: they refer to a signal, and have a parameter. > Defining a group and adding member signals does not cause any action at all, > or change for existing components. All it does is provide an abstraction for > a using entity, which would be a HAL component. > > At the using HAL component level, this provides an interface to search for > groups, and their members. Now assume that HAL component understands how to > do messaging between linuxcnc enitities, like task, gladevcp and others (in > other words, it can talk zeromq patterns, like publish/subscribe). > > <...> > > I've left out lots of detail, like meaning of parameters, and how HAL names > are conveyed so the receiving end can make sense of the values - I'm just > trying to get the idea across > > - Michael >
Michael, John, Ebo: As my first, flip reply should indicate, this discussion turns me on. When I was using the pub/sub pattern for loosely-coupled communications between "smart" buildings and emergency-response services, I struggled with the problem of the dog-that-didn't-bark-in-the-night. By this I mean, I had to deal with the possibility that the absence of a fault message could mean there was no fault or could mean the building system and/or communications path was down at that moment. To get my experiment going, I implemented an in-band heartbeat message (think the Mercury astronauts constantly droning A-OK), but I never had the time to explore alternatives. "Are you there?" query/response seemed inappropriate for my approach. Since buildings potentially could throw dozens of types of status and fault messages at irregular intervals, the heartbeat was used to make sure the building was still capable of communicating even if no message had been received recently. I had a watchdog client whose normal purpose was to monitor the heartbeats for all the buildings within an emergency-response district and sound an administrative alarm if one or more went down, even if there were no emergency. Once a building started publishing emergency messages, the heartbeat was used more critically. I was designing my building-communication protocol to allow repeating the pattern at bigger and bigger scales across single buildings, multiple buildings, an emergency-response district, a town, a region, possibly becoming more synoptic at each layer, ultimately wrapping it within the national emergency messaging system that was being proposed at the time, so I was using very weak technology like xmpp. Obviously I was working with a different problem on a a different timescale. In any case, my knowledge is now close to 10 years out of date. Sorry for being long-winded but watchdogs are useful for more than motor drives. Just my 2-cents worth. Regards, Kent PS - Another problem I dealt with was that a particular service might not become engaged until an emergency was already underway. Here in the USA, it's common, for example, to have mutual-aid agreements between services where the first service to respond may call in backup from other. (Example, NIST is a federal agency with its own fire and rescue service. It has a mutual-aid agreement with the surrounding Montgomery County fire and rescue service such that each can support the other.) I provided a subscriber that, when triggered* by an initial fault message from a building, would begin logging all messages from the building. Any other client could ask it to play back the log so the new client could catch up to the current status. (This was necessary to support new simulation-driven predictive methods that were being developed by others---such as how big is this fire? how fast is it developing? what's at risk next?---as well as to enable after-action analysis.) Would there ever a need in LinuxCNC to be able to log and replay the messages generated in a session? *I also nursed the notion of the analogy of a cockpit recorder, where the buildings control system would keep a rolling log of events so the pre-trigger events could be examined on demand or after the fact. All this was predicated on what the marketers were calling "smart buildings". Another group in my division was working on the BACnet protocol that made this possible with arbitrary collections of vendor products. ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
