Ken,
Am 07.02.2013 um 15:39 schrieb Kenneth Lerman: >> Any future NML replacement should be late-binding capable. > YES. Although we should not ignore the fact that this will be inherently > slower and take more memory than the compiled (early binding) approach. > If this were an engineering requirements document, I would use LARGE > TYPE to remind the reader that the existing architecture is (I'm > guessing here) over thirty years old and that since that time, > processors have increased in memory by a factor of 1000 and in speed by > a factor of 1000. During that time, our control loop requirements have > increased in speed by perhaps a factor of ten. (Feel free to provide > more precise numbers -- I consider an order of magnitude to be a minor > error here.) I agree on the 'the platforms have improved a lot' point; still, the 'how fast is it' aspect is bound to come up in discussion at least, if not in reality. There are some decisions in what I laid out driven by performance aspects, for instance to use signals over pins; the reason is - an existing signal used in a member has a fixed memory location by the time it's defined, and it is protected against deleting if it is used in a member. That makes an update check running through a frozen, typed list of pointers, which is very fast. When using a pin, you need to guard against linking/unlinking as the object location changes underneath. Clearly any decision forward needs to be based on measured numbers, not musings & conjecture; it is paramount to do this with a structure as large as EMC_STAT, not just my demo example, to see the impact of scaling. I have pushed the demo code above several thousand/sec and seen a low-single digit CPU usage on a current PC, but that doesnt cover the bases (even if it includes the messaging overhead). An obvious way of grinding the problem would be to break up the huge EMC_STAT blob, keeping in mind any dependencies. For instance, there is limited value of reporting EMC_IO_STAT - which basically has rarely changing tool-related information - with the same frequency as motion updates, all in one go. So this is a key precondition, as well as doing protobufs versus JSON timing, which would be my #2 contender for serialisation. --- Note that the matching operation is very similar to what a kernel packet filter does, for instance IP tables, or bpf. Therfore: if needed, the route is open to use the same optimization techniques, all the way down to just-in-time compilation of filters. I'd rather cross that bridge once we get there, not before. I dont think anybody these days thinks about the performance impact of kernel packet filters, and rightfully so. I think the reporter idea is not significantly different in principle. >> (there are some minor exceptions like the gcode filename which are not >> relevant here). > Might not be relevant HERE, but should (IMHO) be supported. Yes, it should. The question is: how, where, and what is the semantics. For the messaging and serialisation code it is not an issue at all. It is also not difficult to add the basic support to HAL, if one sticks to fixed size objects with eternal lifetime, and that would be good enough for the current scenario. The question would be rather: "what does it mean to have a HAL string object", for instance 'linking to a string signal', and 'updating a string signal'. I think one cannot ascertain the atomic update property with strings as you can with scalar values. There are a few ways around the issue, none of which I really liked. For instance, you can define a named HAL object, but not have it subject to HAL pin/signal/linking semantics but subject to other getter/setter methods. Something similar does exist, for instance thread functions. Does it work? yes. Is it systematic from a type perspective? No. Another way is to have such a networked stringstore in a separate component altogether, with functions accessible to using code; a bit tricky, not nice, too. I'd be interested what John thinks on the issue here. See my note below. I'm not convinced the whole thing is needed at the _HAL Status reporting level_, it is clearly needed at the messaging level. >> A HAL member would have the following attributes: >> - any member is a part of a single given group. > I assume you mean, "at most one group at a time." Yes, but that restriction applies to the member, which is a first class object; it does not apply to the signal. A given signal can be referred to by several members. There is a delete consistency check for signals, to make sure there are no dangling members. >> >> > Some things I see missing: > > 1 -- I would still like to have arrays of characters (strings), and I'd > like them supported up to the gcode (interpreter) level. I should be > able to call a (gcode) function that engraves the value of a string > parameter (my name). Let me make sure the actual limitation I proposed is fully understood. I addressed the most complex part of status reporting _as it originates in HAL components_; this is where HAL data types go 99% of the way, if not all. I excluded explicitly any messages for instance between UI and task, which of course would have to carry strings. Any messaging scheme can do that. Those are more pedestrian, if you will; and there really isnt that much of a requirement of say, a UI-to-task message to fit into the HAL component reporting type scheme. The reason why I said 'not relevant here' is because I see no significant source of strings changed in/reported by _HAL components_. > 2 -- Can a group be a member of another group? If not, I think that is a > limitation. Today, we have structures that are contained within other > structures (although they must be compiled in). That is a very good point, let me think about it before answering that one. There you have it: let a compiler writer think about a problem, and dang! you wind up with a recursive data structure in no time flat;) Related: I think we need to introduce a 'HAL session' concept; after session commit, the HAL name binding would be complete and immutable until shutdown. I think it would simplify runtime consistency of such proposals significantly. Note the code is halfway there, it's mostly firming up definitions. > 3 -- To simplify, my primitive elements would be: characters, integers, > reals, bools. My compound elements would be groups (of primitives or > compounds) and arrays (of primitives or compounds). Arrays would have > variable (possibly with a maximum specified size -- although I prefer > not) length. Yes, introducing arrays or structs would cover it all. Note however current HAL live with arrays - indices rolled into HAL names - quite well. I'm open to an elegant solution how arrays could be done at the group object layer. I dont think there is any point in introducing arrays at the basic HAL level. I'm not sure an array concept of the HAL status reporting level will gain us much. > Personally, I would take this opportunity to change to a more standard > external data representation. JSON comes to mind for an external (human > readable) representation. See <http://www.json.org/> for a definition > of the representation (in a single page) and links to a flock of > libraries in many programming languages. It's going to be on the shortlist. - Michael ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
