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
>> at startup or on change is good enough; pounding the HAL locks and object
>> lists for every message would be a bit inefficient.
>>
>> For command input into a HAL instance, a request/reply type RPC would be
>> the better fit at the macroscopic level, I think. I'm still fiddling the
>> puzzle with respect to intra-HAL messaging to enable layering of
>> components at the command level (such that one component provides a
>> service, and another component can use it by sending a message; for
>> instance a homing component sending a 'feed move' or 'probe' command and
>> motion would execute it).
>
> 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);
> halcmd type commands: newsig, setp, show pin, and similar. In that
> same category (but a little more buried) are the cases where halscope
> is about to present a dialog to the user to let them select the thing
> they want to probe. It needs a list of things, and gets that list by
> traversing the internal metadata lists. In this new case, it would
> get that list by asking the server for it.
yes, let's call this the halcmd interface
> None of these commands actually relate to the operation of the machine
> control - they relate to configuring (and possibly troubleshooting) it.
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).
What that component, lets call it HAL reporter, now can do is:
- go through the list of groups at startup
- see whether the group should be, for instance, reported cyclicyally (eg one
of the group parameters could be interpreted as a timer value)
- for each reported group:
-- when the time has come to send a status update message, go through the
member list, pull current values, and create a status message (this would have
to call upon the serialisation method employed in the future, for instance
Google protocol buffers, or JSON, or whatever we decide on)
-- the group name becomes the zeromq publishing topic
let me make up an example (syntactically incorrect, just conveying the idea):
Assume you want to monitor a powersupply, and the status message is defined
like so as a HAL group:
----- halcmd ----
# declare a couple of signals
newsig volt float
newsig amps float
newsig mains bit
newsig fuse-ok bit
# now define a HAL group, which has a name, a number and two optional parameters
newg powersupply 1 1 200
# now we add members to this group
newm powersupply volt
newm powersupply amps
newm powersupply mains
newm powersupply fuse-ok
#... link those signals to actual pins ...
----------- end halcmd ------
HALreporter finds a group 'powersupply' with parameters meaning 'publish this
cyclically every 200mS'
import zmq
context = zmq.Context()
socket = context.socket(zmq.PUB)
socket.bind("tcp://1.2.3.4:5555") # publisher socket
< find HAL group 'powersupply' by calling a hal_lib function>
while True:
<sleep 200mS>
<go through signal member list of 'powersupply'>
<serialize the values into a list>
socket.send( 'powersupply', <serialized list of values> )
# ------------^^topic ------^^^actual status report
-----------
for a client interested in powersupply updates, a Python fragment could look
like so (again untested):
import zmq
context = zmq.Context()
socket = context.socket(zmq.SUB)
socket.connect("tcp://1.2.3.4:5555") # the HAL reporter ZMQ socket
socket.setsockopt(zmq.SUBSCRIBE, "powersupply") # HAL group name
while True:
msg = socket.recv()
print msg.deserialize() # depends on serialisation method
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
>
>
> --
> John Kasunich
> [email protected]
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Emc-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
