'To More Specific Class' Not Working on sbRIO 9636

[JAnthony]

The application that I am working on requires me to programmatically access arbitrary components of a nested cluster. Currently, I am trying to do this by recursively traversing the cluster by using its Controls[] property node. Right now, my accessor VI to accomplish this works fine on a normal PC but does not work on my real-time target, an sbRIO 9636.

After some investigation, I have determined that the 'To More Specific Class' function does not work on my real-time target. I have attached some basic code that demonstrates the core of the problem. It works fine on a PC but will return a 53 error when running on my real-time target.

Some questions:

1) Is 'To More Specific Class' supported on the sbRIO 9636 or not?
2) If it is supported, what am I doing incorrectly?

3) If it is not supported, what are some other methods to programmatically access arbitrary components of a nested cluster?
4) If it is not supported, why does LabVIEW allow me to place the function even when the sbRIO 9636 is explictly selected as my target in my LabVIEW project? It would seem prudent to restrict its use if its not supported. My workday has been effectively wasted because of this issue.

For reference, here are some previous discussions

http://forums.ni.com/t5/Real-Time-Measurement-and/Modifing-Cluster-component-properties-on-sbRIO-No-...

http://forums.ni.com/t5/Real-Time-Measurement-and/quot-Manager-Call-Not-Supported-quot-When-Typecast...

Thanks,
JAnthony

[Alex-D · Accepted solution]

The other posts are correct in that it is currently not possible to use the function on a Real-Time Target. It is a known problem and is being investigated for correction but currently there is no work around. It is available on the pallets as this behavior is not intentional and should work. 

You described that your application requires you to recursively go through an array and access specific data. Does this imply that the Data Structure could be different whenever the vi is ran and you need to adapt to a changing data type? If not then all you would need to do is to get the Value from the reference and then unbundle the cluster as needed then store the modified values back to the same reference. 

If you have to adapt you're going to run into difficulties pragmatically determining what you should do but I have a suggestion. Create a cluster with an enum and a variant. You can use the Enum to define the type of the variant in question. This will select the type to convert the variant to for use in the code. This is a similar structure as the Queued Message Handler and its messages it passes except that you will be passing a reference to this cluster which has both the message and the payload in one. The reference could be used to get the Value and then the code only has to be written to accept the Cluster of Enum and Variant you can then convert the variant to the proper type for further use. For optimizing efficiency you should also use In Place Element Structure's.

This is only one way to potentially accomplish what you wish. If you describe your program and its needs more in depth we may be able to suggest a more tailored solution for your application that accomplishes what you need. I hope you have a great day. 

[JAnthony]

Thanks for clarifying that it is a bug, Alex.

For my application, I will have to dynamically adapt to different data types during execution and there could be any number of cluster types so unfortunately I can't predefine all cluster types using an enum.

I was planning on using this functionality when communicating telemetry/commands between my sbRIO (running a web service) and a generic HTTP client so that I didn't have to constantly send all information at once. The HTTP client could request or command any value within the cluster using a string to indicate which value the client was interested in.

For the time being, it looks like there's enough bandwidth to just send the entire cluster at once so I will do that instead and hopefully update the application later on if and when 'To More Specific Class' is ever fixed.

Thanks,
JAnthony

[Alex-D]

Sending the entire cluster might also be the most efficient way from a coding perspective as well. If the cluster gets too large you could run into problems sending it but that should be a viable solution for the time being. 

[mgiambusso]

I was able to work around this by using the Type Cast function instead of the To More Specific Class function. I know this is an old thread, but I just ran into the same problem with a cRIO 9038. This specific example is meant to convert the names of a cluster into MDSplus node paths.

Matt Giambusso

Ad Astra Rocket Company