R4 Feedback Constraints

John Paul

I have an iport which keeps sending song details like time remaining to the R4. Since i don't want to show the time remaining on the R4, i have not assigned this address code on the R4 but the iport module still will send to the R4.

My doubt is if the address codes are not assigned in R4, will the R4 be still be affected by the feedback send by the controller or is it just ignored.

vining

John Paul wrote: »

I have an iport which keeps sending song details like time remaining to the R4. Since i don't want to show the time remaining on the R4, i have not assigned this address code on the R4 but the iport module still will send to the R4.

My doubt is if the address codes are not assigned in R4, will the R4 be still be affected by the feedback send by the controller or is it just ignored.

That's a good question. I think I reacall hearing that the UIs pass to the masters the ports and channel codes used in their design when coming online so maybe the masters, if this is the case, know and ignore ports/channels not part of the UI. I would look at notifications and see if these string/commands are being sent to the R4. If they are then they have to pass through the gateways and be processed to the point where the R4 decides it can't use them.

Grey areas like this is why I prefer to handle these things in code. When any UI comes online I call DEVICE_ID determine what it is and assign it a value based on what it is. When it goes offline I set that valuye to 0. NOw it my various feedback routines I never send to the dev_UI_array but run feedback through a for loop that checks the device type and whether the UI is on that particular device page. If it is on page I run the feedback though a SWITCH CASE based on the UI type that regulates what can pass to it or whether to send ^TXT or ^UNI to that index of the UI array.

Here's an example of that function. This example doesn't regulate based on address channels but could if I needed to. When I call this function I pass it either the particular UI index I want the VT sent to or I pass it 0 which I have a constant UI_UPDATE_ACTIVE = 0. With 0 or the particular index number it first checks to see if that UI is active of the dev page, 0 for no and the dev's instance index if on page and then filters based on UI type. I do the same for channel feedback, levels and commands if for nothing else than to prove their online since if not the UI type array for that index is 0 and that they're on the dev's page and need to be updated.

DEFINE_FUNCTION fnFB_DoSend_VT(INTEGER iUI_Indx,INTEGER iCHAN,CHAR iStrMSG[]) 
     
     {
     STACK_VAR INTEGER n ;
     STACK_VAR INTEGER nTPCount ; 
     STACK_VAR INTEGER nLoopStart ; 
     STACK_VAR CHAR cUNI_STR_2[MAX_4096];
     STACK_VAR WIDECHAR cUNI_STR_1[MAX_4096] ;
     
     if(iUI_Indx)
	  {
	  nTPCount = iUI_Indx ;
	  nLoopStart = iUI_Indx ;
	  }
     else
	  {
	  nTPCount = sSBS.sPlayer.nNum_UIs ;
	  nLoopStart = 1 ;
	  }
     //fnDevMod_DeBug("'SEND_VT: ',iStrMSG,' :DEBUG<',itoa(__LINE__),'>'") ;
     if(length_string(iStrMSG))
	  {
	  cUNI_STR_1 = WC_DECODE(iStrMSG,WC_FORMAT_UTF8,1) ; 
	  cUNI_STR_2 = WC_ENCODE(cUNI_STR_1,WC_FORMAT_TP,1) ;
	  }
     for(n = nLoopStart ; n <= nTPCount ; n++)
	  {
	  if(nUI_ActiveArry[n] == sSBS.sPlayer.nDev_Instance)//means it on this SB & ACTIVE on page
	       {
	       SWITCH(nUI_TypeArry[n])
		    {
		    CASE UI_TYPE_G4:
		    CASE UI_TYPE_R4:
		    CASE UI_TYPE_MIO_DMS:
			 {
			 if(length_string(cUNI_STR_2))
			      {
			      STACK_VAR CHAR cUniSend[MAX_4096];
			      STACK_VAR INTEGER nAppend;
			 
			      cUniSend = cUNI_STR_2;
			 
			      WHILE(LENGTH_STRING(cUniSend))
				   {
				   STACK_VAR CHAR cTMP[UNI_STR_SIZE];
			 
				   if(LENGTH_STRING(cUniSend) > UNI_STR_SIZE)
					{
					cTMP = GET_BUFFER_STRING(cUniSend,UNI_STR_SIZE);
					}
				   else
					{
					cTMP = GET_BUFFER_STRING(cUniSend,LENGTH_STRING(cUniSend));
					}
				   if(nAppend)
					{
					SEND_COMMAND dvUI_SBSArry[n],"'^BAU-',ITOA(iCHAN),',0,',cTMP";   //Append Unicode to Modero Panels
					}
				   else
					{
					SEND_COMMAND dvUI_SBSArry[n],"'^UNI-',ITOA(iCHAN),',0,',cTMP";   //Unicode to Modero Panels
					}
				   //fnDevMod_DeBug("'SEND_COMMAND UNI, APPEND-[ ',itoa(nAppend),' ], CHNL-[ ',itoa(iCHAN),' ], STR-[ ',cTMP,' ] :DEBUG<',ITOA(__LINE__),'>'");
				   nAppend++;
				   }
			      }
			 else//we need to clear text fields too, duh!
			      {
			      SEND_COMMAND dvUI_SBSArry[n], "'^TXT-',itoa(iCHAN),',0,',cUNI_STR_2" ; 
			      }
			 }
		    CASE UI_TYPE_G3:
		    CASE UI_TYPE_iPHONE:
		    CASE UI_TYPE_iTOUCH:
		    CASE UI_TYPE_iPAD:
			 {
			 //////fnDevMod_DeBug("'^TXT- TP INDX: ',itoa(n),', CHNL: ',itoa(iCHAN),' :DEBUG<',ITOA(__LINE__),'>'") ;
			 SEND_COMMAND dvUI_SBSArry[n], "'^TXT-',itoa(iCHAN),',0,',iStrMSG" ; 
			 }
		    CASE UI_TYPE_METKP:
		    CASE UI_TYPE_UNKNOWN:
		    CASE UI_TYPE_VIRTUAL:
			 {
			 //DO NOTHING
			 }
		    }
	       }
	  }
	  
     RETURN ;
     }

John Paul

Thanks so much for this information. I am still understanding the function that you have send across. How do you understand if the TP is on a certain page, is it by page name or by code?

John Nagy

It's not a grey area- commands sent to the R4 take up the precious bandwidth to the device whether the R4 does anything with it or not.

If you send too many too fast, the gateway backs up and disconnects the R4. You can view the buffer high water marks and current statuses in the Gateway web server.

vining

John Nagy wrote: »

It's not a grey area- commands sent to the R4 take up the precious bandwidth to the device whether the R4 does anything with it or not.

If you send too many too fast, the gateway backs up and disconnects the R4. You can view the buffer high water marks and current statuses in the Gateway web server.

I wasn't suggesting that unecassary or excessive traffic to an R4 was a grey area but if the masters has a built in map and is smart enough to know that there's not a channel or an address mapped to a specific UI. I would think it doesn't know but i've never tested or thought of testing to see if it did or not. As i mentioned earlier i recall hearing that the UIs send some sort of map or list of assigned port/channels when they come online so if this is the case then maybe the master is does know that a UI doesn't have a channel or address assigned so it doesn't bother sending.

John Nagy

When a panel or R4 comes online, you can see each port that is actually represented in the TP4 file come on individually. Well actually, the range used all come on. IF you have put buttons in it that use port 1, 3 5, and 6, you will see an online event for ports 1, 2, 3, 4, 5, and 6. Even though you didn't use 2 and 4.

If you used just port 1 and 100, all ports from 1 to 100 will report for duty in an online event.
Similarly, the highest channel actually on a button is tracked in the panel (you can see it on the INFO PAGE) but I don't know if it is reported in any way to the NetLinx. I've never seen it in the detailed traffic logs we studied to try to eliminate excess panel traffic. But I wasn't looking for it. I know it has no visible effect.

I do know that I see commands sent to panels when I know the panel doesn't have the actual destinations in it. So you are correct to advise smarter code that knows the UI type in play and manages commands accordingly when it is one that reacts poorly to higher traffic.... like the R4.

AS mentioned in some of the many places R4 commands are discussed, we found what AMX didn't know, that the R4 behaved much happier if you alternate clumps of commands with even a 10'th of a second "rest". The Gateway is poor at managing outputting commands to the R4 while receiving commands from the NetLinx. 100 commands broken in 2 or 3 chunks are dispatched noticeably quicker from the Gateway buffer than 100 sent at once or with evenly spaced timing. That's why purely slowing command queues doesn't help as much as you expect.

DHawthorne

If you have access to the UI module source, trap out the commands you don't want sent to the R4 in the first place. My habit is to create a STRUCT with all my panel data, including an entry on the panel type. THen simple test in the feedback routine can limit what goes out to a specific panel type.

a_riot42

I can't see how sending a few characters of text once a second to an R4 would have any deleterious effect. I send elapsed time to R4s all the time and haven't noticed any ill effects at all.
Paul

John Nagy

a_riot42 wrote: »

I can't see how sending a few characters of text once a second to an R4 would have any deleterious effect. I send elapsed time to R4s all the time and haven't noticed any ill effects at all.
Paul

You are right, but a few characters a second are not what we're discussing. If that's all you are doing, you don't need to worry. If you are doing metadata, dynamic text, and code-driven page manipulation, you can have dropouts if you don't manage traffic.

TurnipTruck

A real simple way to exclude feedback from the R4 is to grab the device ID of all UIs when they come online. Do your global feedback with a loop and exclude R4s by checking device IDs.