AnsweredAssumed Answered

rawqos function built off the rawalarm function

Question asked by droark on Dec 3, 2013
Latest reply on Mar 6, 2014 by droark

Hello scripting community!

 

We're trying to come up with a script that posts null values to qos to keep those objects alive from deletion based on last timestamp.  I'm finding that the nimbus.qos method is rewriting the headers to reflect the hub rather than the originating robot, which forks the data and doesn't work for what we need to do.  We use a rawalarm function that was posted on these forums, and I'm wondering if we can repurpose this to post raw qos messages to the bus as well. 

 

Running a dr. nimbus scan, I get a list of pds handles that match most qos, some of which I'm pretty sure I could manipulate with a rawqos function, some of which I'm not sure if I need in order to keep the objects from getting forked.

 

nimid, nimts, tz_offset, source, md5sum, robot,domain,origin,pri,subject,prid,dev_id,met_id,qos,source,target,sampletype,samplevalue,samelstdev,samplerate
,hop,hop0,qsize

 

I'm curious which of these values I will need to set in order to fully replicate a qos object and qos message with only a null value as the difference.  Also, what are the different sampletypes?  I see that sampletype = 0 means float, but I'm just curious what the other values equal (e.g., 1 for string or 2 integer?)

 

I've attached the rawalarm function to this as well.

 

Thanks for any insights,

Devin

Attachments

Outcomes