1 Topic by tucan

  • tucan
  • NWare Pioneer
  • Offline
  • From: London
  • Registered: 2007-09-07
  • Posts: 64

Topic: RATC2 Change Group Schedule Speed

The RATC2 changeGroupSchedule is a very useful command as it allows the Nion to transmit to a RATC client every time any of the controls in its change group have changed:-

    cgs  changeGroupSchedule [group] seconds : schedule recurring Change Group gets

HOWEVER the lowest value allowed in seconds is 1 second, meaning that it can take upto 1 second before a change is transmitted to the RATC client. If this value was reduced such that tenths of a second could be entered, then it would allow a usably fast response for many more things. This is probably an arbitrary minimum value, so if the quickest response settable would be maybe 0.2s then this would be a massive and useful improvement.

Hopefully this modification is trivial to make??????

2 Reply by cwa

  • cwa
  • cwa
  • Peavey Technical Director
  • Offline
  • From: Boulder, Colorado USA
  • Registered: 2007-08-13
  • Posts: 193

Re: RATC2 Change Group Schedule Speed

I am reluctant to make this change.  In general, it is a bad idea to implement non-polled communications.  This feature was actually implemented under duress, the engineer involved was not keen on the idea. 

If you want to display a meter, the display device should send a request for an update.  It should then wait for a reply, and then issue another request when it is ready.  This allows for fast updating, without causing extra load on either the display device, or the NION.  Meter values are created and sent at precisely the right rate.

If you were to set the NION to send a meter value every 200ms, it is doing the work and generating the network traffic regardless of if the display device can keep up, or is even displaying the meter(s) concerned.

3 Reply by tucan

  • tucan
  • NWare Pioneer
  • Offline
  • From: London
  • Registered: 2007-09-07
  • Posts: 64

Re: RATC2 Change Group Schedule Speed

In my situation I was planning to use this function to quickly send when a boolean changed state, and not repeatedly send the current value, just to simply send something when it changed state. Therefore most of the time there is no transmission.

This is how the changeGroupSchedule actually works, it only transmits when there is a change to the state of one of the controls within the control group.

in the case of a varying meter this would potentially generate lots of traffic, however.

The idea behind reducing the schedule time is that the transmission happens sooner after the control changes state, with the current 1 second minimum this is the maximum time before there is a tranmission after the change. If for instance this is for passing a state change to another system, (such as an AMX) the only other alternative is for the AMX to continually poll the Nion./Conman. Surely this would put a greater load on the Nion processor, and anyway would require that the AMX does much more work.

4 Reply by tucan

  • tucan
  • NWare Pioneer
  • Offline
  • From: London
  • Registered: 2007-09-07
  • Posts: 64

Re: RATC2 Change Group Schedule Speed

Another thought.....

Obvioulsly a nion has limited control resources, but if this  ChangeGroupSchedule minimum time was reduced on conman only then Conman should be better able to cope with any resulting processing overhead without any danger of audio implications.

It should also be relatively easy to increase the processing power of Conman by up specing the machine it is running on.

In my system Conman is where most of the control devices that I would be using woudl be located anyway.

5 Reply by cwa

  • cwa
  • cwa
  • Peavey Technical Director
  • Offline
  • From: Boulder, Colorado USA
  • Registered: 2007-08-13
  • Posts: 193

Re: RATC2 Change Group Schedule Speed

Ok, I can see how this would be useful.  I still contend that the polled system is better.  Without two way communications happening there is no way to handle dropped messages.  With a poll, eventually you are guaranteed to get it.

6 Reply by tucan

  • tucan
  • NWare Pioneer
  • Offline
  • From: London
  • Registered: 2007-09-07
  • Posts: 64

Re: RATC2 Change Group Schedule Speed

Maybe a more useful way to do this would be a whole new command:-

sgs  statusGroupSend [group] [on/off] seconds : schedule recurring status Group gets

...which would recurrently send the values of all the controls that had been added to that status group, using a statusGroupAdd command exactly like a changeGroupAdd command

As before the 'seconds' delay value should be settable to less than a second.

The on/off value is to easily start and stop the transmission, such as when the information is needed only when the AMX is in a certain mode say, without having to redefine the complete statusGroup

This would have the advantage over polling in that less network traffic is needed in total, and it would be easy to set different update speeds for different control types, and with all the advantages of polling, where if an individual change was missed it would be caught the next time.

7 Reply by Fergy

  • Fergy
  • MM Tech Support
  • Offline
  • From: The Home Office--Meridian
  • Registered: 2007-08-15
  • Posts: 334

Re: RATC2 Change Group Schedule Speed

The problem with a schedule of less than 2 seconds is this output of information frequently (perhaps “almost always†) overwhelms the AMX/Crestron/etc buffer.  But for some reason, the blame is always placed on the Nion.  For this reason, less than an 1 second polling should not be permitted.   And for this same “we always get the blame† reason, should the limit actually be raised to two seconds?

CWA polling suggestion is the better solution, but with a twist.  See a new topic in Hints/Tips Discussion called Third Party (Crestron/AMX) Control Updates.  I would like to see your feedback on this solution.

Make it intuitive, never leave them guessing.

8 Reply by Joe Kurta

  • Joe Kurta
  • Member
  • Offline
  • Registered: 2007-08-17
  • Posts: 1,179

Re: RATC2 Change Group Schedule Speed

For the record I am also a big fan of the 'true' client/server model (IE polling).  However we have also had situations where the scheduled change group is useful.

A few other things to consider: 1) experienced AMX and Crestron folks that can handle the coms no problem generally don't have to call Peavey tech support (so you might not be aware this is being used a lot), 2) most things that are asked for in these circles have already been implemented by someone else.  We've seen similar features implemented by other manufacturers successfully - not that it means anything.

What if we reach a compromise and have a new command like tucan suggests but set some limits? 
1) only one alias
2) automatic timeout (90 seconds)

statusSend "alias" [frequency:(.1) to (10)]

This way you could 'subscribe' to a single control, set a response speed and you would have to keep sending that every 90 seconds or so to continue receiving updates.  If you forget to re-subscribe to that alias, the updates stop arriving.  That way if the control system goes off line or gets overrun it eventually times out and stops coms.

Thanks,

Joe