Newbie code help
prfitton
Posts: 1
I am trying to write some code to the 25 favorite channels that appear on the touch panel. The device is an IR device. Any suggestions on how to handle the that task without writing 25 lines of executable code?
0
Comments
BUTTON_EVENT[vdvFavorites,0] { PUSH: { SEND_COMMAND vdvCable[GET_LAST(vdvFavorites)],"'XCH ',ITOA(BUTTON.INPUT.CHANNEL)" } }Where vdvFavorites is a TP array and vdvCable is a cable device array.
You will also need to configure the XCH command in the cable box Data_Event.
That button event will get called for every button press from any of the touch panels regardless of whether its a fav or not. Any non-fav channel will get sent to the cable device as well. Is that really what you want?
I tend to do something like this:
button_event[dvAllUIs, iFavs[1]] { push: { stack_var integer iChan, ui stack_var char sChan[3] ui = get_last(dvAllUIs) iChan = get_last(iFavs[1]) sChan = itoa(iFavs[2][iChan]) send_command dvUISources[ui], "'XCH ',sChan" } }Where iFavs is a 2 dimensional mapping of channel numbers to stations favs.
I put the favs on their own TP port and assign the TP button to the fav number. The only buttons that are on this port are favorite buttons. You only assign buttons to the favorites you want. You want to change the favorites you only have to change the TP file not the code. I don't see any downside.
You didn't mention the different port in your original post. In my set up you only have to change the numbers in the array once not in every TP file, which I prefer since I find changing numbers in an array quicker than doing it through TPD, Keypadbuilder, etc, and I can use power assign since they are arbitrary channel numbers rather than station numbers, but that's just my preference. Plus since the station numbers aren't hard coded to the channel numbers like with your method, I can have stations past 4000 for moderos, or 255 on some other devices.
The channel number and station number have nothing to do with each other so I don't like the fact that they are used like that as if they were related somehow. No offense intended but it reminds me of when I saw a colleagues code and he had a constant for the number of outputs on a switch (64). 64 was also the conversion factor used to transform the volume from its native format to a 0-100% format. So in his volume code, rather than create another constant called conversion factor as 64 he just used the one he created as the number of outputs. Needless to say, when we used his file for a switch with only 32 outputs, the volume feedback broke and it took the programmer some time to figure out why. The 20 seconds my colleague saved himself by not creating another constant cost hours during a project with a tight deadline. This is why I don't like making unrelated things seem related in code.
Paul
http://www.amxforums.com/showthread.php?p=21068#post21068
What have you found that is broken? I haven't any problems with it yet. Was it a problem with IR in general or the XCH command in particular? I remember seeing something in the notes a while ago about it being fixed but don't recall what the problem with it was.
Paul
I have always used SP and CTON/CTOF so maybe I never came across this particular issue. I will take your word for the fact that your function works, it just seems to me to be doing alot of very expensive division and modulo for just a cable preset though.
Paul
Considering how expensive modulo is I think I would do something like this if I didn't use the XCH command:
(untested)
define_function sendFav (dev device, integer fav) { stack_var integer i, j stack_var char station[4] station = format('%04d', fav) for (i = 1;i <= 4;i++) { send_command device, "'SP', atoi(station[i]) + 10" } send_command device,"'SP', 49" }Yes, CTON and CTOF affect XCH as well.
Some choose to write the favorites to disc so that you don?t have to modify the code, recompile, and load a new program every time a channel lineup change occurs.
Not if you are using code similar to what you posted using the XCH command. Unless a change has occurred that I?m not aware of XCH only allows 0-999 which is why I also choose to roll my own. If XCH gets updated to allow more than 3 digits I would probably go back to it.
I can see the advantage of doing it this way, although I have never actually changed someone's favs believe it or not. I think the next time I delve into this I will make it user configurable from master files although the amount of work may not be worth it since it isn't something I get a request for very often.
So far 999 has been good enough. There are already too many channels. I am hoping they switch from quantity to quality sometime soon (yeah right).
I dumped XCH the first time I did a job that used Dish Network. Dish has a bunch of 4 digit channels going up into the 9,000s.
When pigs fly. The Boob Tube is such a powerful yet (aside from a few rare exceptions) shamefully underachieving medium when it comes to content. As long as we keep eating it, we?ll continue to get fed garbage. But who I am to talk? One of my favorite channels is GSN. I really get a kick out of watching contestants drop through a trap door on Russian Roulette; I can?t help but smile every time. Goes to show where my intellect level is at.
I think AMX should launch a new TV station called the Netlinx channel, 24/7 non stop programming about programming. I know I?d tune in. :cool:
Well, considering that I haven't a clue how "expensive" modulo is in terms of slowing down the processor, I would venture to guess that performing a FOR-loop with the FIND_STRING command on top of a defined string variable (which now takes up memory), that just may lose the efficiency battle against modulo.
Modulo tends to be the most expensive mathematical operation you can do since it requires division. I have read that with VXWorks a mod function can actually take up to 30 ms as its emulated in software. Not sure if that's the case with AMX controllers, but I tend to avoid that kind of thing unless absolutely necessary.
My point with the function above is to trade some memory for cycles, since the memory required is so small, but the cycles needed to perform division is large. Obviously it would need to be analyzed to see which is actually faster, but in general floating point operations on an RTOS are expensive.
Paul
Ok, I had a couple minutes to kill, so I threw a little test together. I used the functions provided (did not test actual functionality) as such:
define_function fnSendFav (dev device, integer fav) { stack_var integer i, j stack_var char station[4] station = format('%04d', fav) for (i = 1;i <= 4;i++) { send_command device, "'SP', atoi(station[i]) + 10" } // send_command device,"'SP', 49" } DEFINE_FUNCTION fnGET_TV_STATION(DEV dvSOURCE,INTEGER PRESET) { LOCAL_VAR INTEGER CHAN1[4] CHAN1[1] = (PRESET/1000+10) CHAN1[2] = (PRESET/100+10) CHAN1[3] = ((PRESET%100)/10+10) CHAN1[4] = ((PRESET%100)%10+10) IF(PRESET>=1000) SEND_COMMAND dvSOURCE,"'SP',CHAN1[1]" SEND_COMMAND dvSOURCE,"'SP',CHAN1[2]" SEND_COMMAND dvSOURCE,"'SP',CHAN1[3]" SEND_COMMAND dvSOURCE,"'SP',CHAN1[4]" }I then used a button event to run each function 1000 times and get the approximate execution time. I ran each 1000 execution test 10 times in a row for each function. I used the same channel code of 1234 for all tests. The results are as follows:
First run of 1000 for Modulo: 3110ms
First run of 1000 for Format: 4700ms
Second thru tenth run of 1000 for modulo: ~1061ms
Second thru tenth run of 1000 for Format: ~2676ms
Do what you will with the results
Jeff
define_function sendFav(dev device, integer fav) { local_var char station[4] station = format('%04d', fav) send_command device, "'SP', station[1] - 38" send_command device, "'SP', station[2] - 38" send_command device, "'SP', station[3] - 38" send_command device, "'SP', station[4] - 38" }First Run of the unfurled for loop: 4703ms
Second thru tenth run of unfurled: ~2620ms
Just for fun, I modified the test so that I ran the timed test only once (instead of 1000 times). This produced a very interesting result in which the Modulo version took less than 1ms to run and both of the Format versions took between 2 and 3ms to run. I bumped up the number of tests performed and averaged the results and it seems that the Modulo runs consistently in the 1ms range and the Format versions run in the 2-3ms range.
The for loop didn't seem to change the results very much.
Just made it so that the tests ran 10 times and the first tests seemed to be that same amount of time as the 2nd thru 10th (I'm thinking the extra overhead is due to optimization possibly). Anyway, running the tests 10 times seemed to show the corresponding results to running the code once. The increased resolution puts a single run through the Modulo function at ~1.0ms and a single run through the Format function at ~2.6ms.
Jeff
P.S.
These tests are being run on an NI-3100 with no other code really being run. (Ideal conditions if you will
P.P.S.
The thing I think I found most interesting was how the processor some how optimized things after the first run through when I had the iterations set to 1000. It was fairly close to double the speed on the strings and almost triple the speed on the Modulo function. I wonder if any AMX employees could shed any light on how the processor might optimize things to make this happen.... then we might be able to exploit this feature in our code.
P.P.P.S.
I think I have beaten this horse to death and maybe a bit beyond
Hey Jeff,
I?m not sure how you performed your tests but I see nothing close to your results on my test NI-700 running DUET with the latest version of firmware. If I?m reading you correctly you?re claiming that FORMAT runs almost 3 times slower than the math version?
I?ve got two button events and I?m doing a SEND_STRING 0 with a GET_TIMER before and after a FOR loop that calls one of the functions 1000 times. The difference I see is completely negligible, about 1 ms total difference for sending out 1000 presets. So we?re no where near the same ballpark, I?d say not even the same sport.
I also found that using a FOR loop in the preset function does make a difference (at least more of a difference than the two methods), the FOR loop is slower by a couple of ms. But we all know the FOR loop isn?t the fastest beast in the jungle.
Were you by chance sending the SP commands to a real device? If you were I think that may have tainted your results. I can only guess what happens when you try to stack up 1000s of PULSE commands to a device at one time. I know when I tried it memory took a nose dive and never even recovered 1 byte. I may have stumbled into a memory leak. The max buffer count shot up also (the Con Manager maxed out.) My system seemed to bog down and the SEND_STRING 0s didn?t print out as quickly as the timer indicated.
Instead of using a real device I sent the SP commands to a virtual since the test has nothing to do with pulsing IR. Memory remained stable along with the buffer count and the SEND_STRING 0s reported in a timely fashion.
I think the moral of the story is if Jay and others want to divide and use Mod they should feel free to do so, same for those who like FORMAT. And for that matter I see nothing wrong with what Tony posted early on when he related the button channel number to the station channel number. There is no one right way.
And you thought you obliterated the horse.
" An argument can only exist in an environment where two or more people agree to play the game..." ~ unknown...
Here is the code I wrote for the test:
define_function fnSendFav (dev device, integer fav) { stack_var integer i, j stack_var char station[4] station = format('%04d', fav) for (i = 1;i <= 4;i++) { send_command device, "'SP', atoi(station[i]) + 10" } // send_command device,"'SP', 49" } define_function sendFav(dev device, integer fav) { local_var char station[4] station = format('%04d', fav) send_command device, "'SP', station[1] - 38" send_command device, "'SP', station[2] - 38" send_command device, "'SP', station[3] - 38" send_command device, "'SP', station[4] - 38" } DEFINE_FUNCTION fnGET_TV_STATION(DEV dvSOURCE,INTEGER PRESET) { LOCAL_VAR INTEGER CHAN1[4] CHAN1[1] = (PRESET/1000+10) CHAN1[2] = (PRESET/100+10) CHAN1[3] = ((PRESET%100)/10+10) CHAN1[4] = ((PRESET%100)%10+10) IF(PRESET>=1000) SEND_COMMAND dvSOURCE,"'SP',CHAN1[1]" SEND_COMMAND dvSOURCE,"'SP',CHAN1[2]" SEND_COMMAND dvSOURCE,"'SP',CHAN1[3]" SEND_COMMAND dvSOURCE,"'SP',CHAN1[4]" } DEFINE_FUNCTION fnModuloTest() { INTEGER x INTEGER y INTEGER tempID nWORK_IN_PROGRESS = 1 TIMELINE_CREATE(lTL_ID,lTL_Times,5,TIMELINE_RELATIVE,TIMELINE_REPEAT) for(x=1;x<=nLoops;x++){ fnGET_TV_STATION(vdvVIRT_IR,1234) } TIMELINE_PAUSE(lTL_ID) lMOD_TIME[nCNTR_MOD] = TIMELINE_GET(lTL_ID) TIMELINE_KILL(lTL_ID) lMOD_TIME[6] = ((lMOD_TIME[6]*lMOD_AVG_CNTR) + lMOD_TIME[nCNTR_MOD])/(lMOD_AVG_CNTR + 1) lMOD_AVG_CNTR++ IF(nCNTR_MOD == 5) nCNTR_MOD = 1 ELSE nCNTR_MOD++ nWORK_IN_PROGRESS = 0 } DEFINE_FUNCTION fnCharFavTest() { INTEGER x INTEGER y INTEGER tempID nWORK_IN_PROGRESS = 1 TIMELINE_CREATE(lTL_ID,lTL_Times,5,TIMELINE_RELATIVE,TIMELINE_REPEAT) for(x=1;x<=nLoops;x++){ fnSendFav(vdvVIRT_IR,1234) } TIMELINE_PAUSE(lTL_ID) lCHAR_TIME[nCNTR_CHAR] = TIMELINE_GET(lTL_ID) TIMELINE_KILL(lTL_ID) lCHAR_TIME[6] = ((lCHAR_TIME[6]*lCHAR_AVG_CNTR) + lCHAR_TIME[nCNTR_CHAR])/(lCHAR_AVG_CNTR + 1) lCHAR_AVG_CNTR++ IF(nCNTR_CHAR == 5) nCNTR_CHAR = 1 ELSE nCNTR_CHAR++ nWORK_IN_PROGRESS = 0 } DEFINE_FUNCTION fnCharFavTest2() { INTEGER x INTEGER y INTEGER tempID nWORK_IN_PROGRESS = 1 TIMELINE_CREATE(lTL_ID,lTL_Times,5,TIMELINE_RELATIVE,TIMELINE_REPEAT) for(x=1;x<=nLoops;x++){ sendFav(vdvVIRT_IR,1234) } TIMELINE_PAUSE(lTL_ID) lCHAR_TIME[nCNTR_CHAR] = TIMELINE_GET(lTL_ID) TIMELINE_KILL(lTL_ID) lCHAR_TIME[6] = ((lCHAR_TIME[6]*lCHAR_AVG_CNTR) + lCHAR_TIME[nCNTR_CHAR])/(lCHAR_AVG_CNTR + 1) lCHAR_AVG_CNTR++ IF(nCNTR_CHAR == 5) nCNTR_CHAR = 1 ELSE nCNTR_CHAR++ nWORK_IN_PROGRESS = 0 } . . . BUTTON_EVENT[dvTP,8] { //fnGET_TV_STATION PUSH: { STACK_VAR INTEGER x; FOR(x=1;x<=nNumTests;x++) { fnModuloTest(); } } } BUTTON_EVENT[dvTP,9] { //fnSendFav PUSH: { STACK_VAR INTEGER x; FOR(x=1;x<=nNumTests;x++) { fnCharFavTest(); } } } BUTTON_EVENT[dvTP,10] { //fnSendFav PUSH: { STACK_VAR INTEGER x; FOR(x=1;x<=nNumTests;x++) { fnCharFavTest(); } } }I modified nLoops and nNumTests via the debugger. Everything was being sent to a virtual device. There is a good chance that I have some flawed logic in my benchmark test, let me know when you find my obvious mistake.
Jeff
P.S.
There is more code, but these are the important parts.
Ugh, that's a bad leak. If the remote gets inbetween cushions on the couch so that a button is held indefinitely, I wonder if there would be an issue with memory leakage. I would have thought that as soon as the IR command is finished pulsing then the memory would be returned to the system.
Paul
Besides, was there even a horse to begin with? What's a couple of milliseconds when tuning to a channel? Don't get me wrong, a very fun exercise, and I appreciate all the work Jeff has put in, I just wonder . . . does it make a difference on the end result?
Thank you for the appreciation, for starters. As for the couple of milliseconds....you add up ms and you get M$.... need I say more?
I do think that it is a bad habit to ignore the impact of code on the processor. As some have surely found out, coding that works when there is a single processor with only a handful of devices and a single touch panel, is not guaranteed to work when more devices are added and the number of touch panels multiplies.
Next thing you know, you're coding in a 3d simulator to display the names of the programmer(s), but only if they push all of the correct buttons in the correct order..... hmm, sounds like an interesting idea tho... if the customer turns on the correct lighting scene, followed by the hot tub, then the fireplace, then the Barry White play list, the touch panels displays a big thumbs up! ... or maybe a pair of dice roll across the screen and then land with a total of 7!
Jeff
P.S.
I may have inhaled a bit of carbon monoxide today while working next to a generator.... does it show?
And about the fumes . . . nope, couldn't tell. Not one bit. Seriously. I thought you just ate some fish from Lake St. Clair.