1

Topic: RATC controlList

I remember working with RATC a while ago and the controlList command returned not only the control alias names, but also their type(gain, mute, etc). Where did that go?

2

Re: RATC controlList

It's right were it use to be...  in MWare.

Sorry Jason - I couldn't resist!

Thanks,

Joe

3

Re: RATC controlList

Aww, you're right!! That's where I remember it. I really wish that information was available in the current version of RATC on the Nion platform....

4

Re: RATC controlList

Try a "Find; Control Alias" and leave it blank, and then see if the find results is what you are looking for.  It may take awhile if you have lots of controls/aliases.

Now we just need a way to copy the find results into a spreadsheet.

Make it intuitive, never leave them guessing.

5

Re: RATC controlList

I don't need this to be available in Nware, but rather via the remote control interface(RATC). What I'm working on is a control client that adapts dynamically to whatever control aliases it is presented with. For example, the usual method is to assign control alises as needed, give that list to the control system programmer who must now implement the protocol in such a way to associate these aliases to specific events/states in his control system.

Now consider a different method. The Nion programmer and control system programmer agree on the set of devices that need to be controlled. The control system programmer gives the Nion programmer a list of each control and the 'address' to which that control is to be associated. The concept of 'address' is of course more specific based on the exact controller platform I am working on, but isn't important beyond that. The Nion programmer then embeds this address into the control alias. Say for example a control called 'knob' needs to be assigned to address 10. The resulting control alias would be something like "knob [10]". My application running on the control system gets the list of control aliases and picks out the ones with a delimited address, in this case addresses enclosed in square brackets. It then makes the required addressing associations and uses a general purpose implementation of the RATC protocol that isn't tied to a specific set of control aliases. This removes task of the protocol implementation from the control system programmer and allows him to concentrate on the higher level logic.

The reason I was interested in the device type information in a 'controlList' command is that it makes it very easy for the application to determine if the control is an analog or binary type, requiring a word or bit address respectively. Also comes in handy for limiting the values that can be sent to a particular type of control.

6

Re: RATC controlList

Does RATC RAW have the required features?  You need the Device ID, but the RUIDs are known, and a table could be created with every expected device already listed.  Remember that doing a "Find;Control Alias" will find every control in a project, and will take some time in a large project.

If you have more than one NioNode in a project, one could be set to RATC2, and the other to RATC RAW.

Make it intuitive, never leave them guessing.

7

Re: RATC controlList

RATC RAW has a little more, but the user does not have the capability of modifying the control aliases. My program looks for the special address sequence in an alias to determine how it should be controlled, if at all.

The old RATC protocol gave me the 'class', like PAPrmGainKnee, which I then knew must be a control with an analog value. It also gave me the valid ranges for that control, like -100dB to +12dB.