Ok, I finally received my cradles so I could charge the batteries. That was nice. Now I've spent some time with the gateway and the R4. It sure would be nice to have some sort of document, besides both reference guides, that walks you through all of the steps necessary to get this up and running. The Quick start was on the right track but lacking in essential detail.
I have had to disable security on my Netlinx master because I am not given an opportunity within the gateway configuration to add the user and password. The fields are greyed out. Anyone get around this?
What's the status on this thing falling offline when it goes to sleep? I was wondering why whenever it'd time out things were weird when I tried to hit stuff when it woke up. Once it took over 5 seconds to finally get online - how many button presses do you think a client would have hit during that time?
And does it not have a "smart transfer" option? I made changes to 6 buttons, and it was only removing their addresses codes. And it decides to transfer the entire file - not to mention the USB transfer seems rather slow.
i have a question concerning R2: i get a Hold_event, but BUTTON.INPUT.CHANNEL is 0 always. is this because BUTTON_EVENT is done on channel 0? in the push-hanlder BUTTON.INPUT.CHANNEL works perfectly
i have a question concerning R2: i get a Hold_event, but BUTTON.INPUT.CHANNEL is 0 always. is this because BUTTON_EVENT is done on channel 0? in the push-hanlder BUTTON.INPUT.CHANNEL works perfectly
i have a question concerning R2: i get a Hold_event, but BUTTON.INPUT.CHANNEL is 0 always. is this because BUTTON_EVENT is done on channel 0? in the push-hanlder BUTTON.INPUT.CHANNEL works perfectly
Easy enough to test: change your button channel 0 to an array that spans all the buttons on the remote. Then see if it works.
I get the same no HOLD response. I made a simple button that should toggle on/off every second in the below code for the purpose of testing the ZigBee wireless range. The idea was to hold a button, walk about and watch the feed back button turn on/off.
I figured why not try the [dvArray,0] as I never have before and sure enough no hold when holding a button but down below if you look at the diagnostic print out I get a HOLD 0 every [HOLD,repeat] time when nothing is held. The system apparently always sees 0 as being a hold_event.
So I guess if you need to HOLDS in a button_event you can't use [dvArray,0].
i have a question concerning R2: i get a Hold_event, but BUTTON.INPUT.CHANNEL is 0 always. is this because BUTTON_EVENT is done on channel 0? in the push-hanlder BUTTON.INPUT.CHANNEL works perfectly
Never use button event objects in a HOLD. Those objects are really only available in the PUSH or RELEASE. Use a global variable to make an assignment and then reference the varialbe in the HOLD.
Think of a HOLD as much as you would a WAIT. And never use a HOLD with a panel array in a button event, only a single panel.
You could almost argue the need for a seperate cDevRef or nChanRef var
for every panel in the dvArray so that the potential of another panel changing the value before the hold executes is eliminated. Rare but possible!
You could almost argue the need for a seperate cDevRef or nChanRef var
for every panel in the dvArray so that the potential of another panel changing the value before the hold executes is eliminated. Rare but possible!
Does this refer to the R4 or all Netlinx Programming?
I have chosen to use a HOLD only if my button event references a single panel because of the rare but potential conflict of two panels needing to use button objects. Again, button objects are only valid during the PUSH or RELEASE. Any other time the objects are subject to being either nul or subject to change by other events.
It is very important to make sure the variables in a HOLD are not unintentionally altered when the code in the HOLD executes. A HOLD is more a stealth WAIT or stealth TIMELINE than a button event.
I have chosen to use a HOLD only if my button event references a single panel
BUTTON_EVENT[dvPNL,0]
I missed that part!
Now it's even worse, requiring a seperate button_event for each TP if HOLDS are to be used to avoid the remote possibility of another panel changing a value prior to the HOLD executing. Before I thought we were just going to reference a single panel in the HOLD (which isn't really possible). Yuk! The alternative is to take your chance and hope some one on a different TP doesn't use the same device during the period that the HOLD is in a wait to execute. Again, yuk!
And you can't even use local variables. Which brings up another questions, why can't we declare local variables just after the opening brace of the button_event prior to the PUSH so they can be used for all handlers under the button_event?
Is there a reason, that on the R4 the Channels for Cursor up/down/left/right/ok are between 32 and 36 instead of the SNAPI channels 45-48. This does'nt make any sense at all to me and is annoying like hell.
Is there a reason, that on the R4 the Channels for Cursor up/down/left/right/ok are between 32 and 36 instead of the SNAPI channels 45-48. This does'nt make any sense at all to me and is annoying like hell.
Doesn't make much sense to me either, but you can change this in TPDesign4. Open the R4 file and open up "External Controls" and change the cursor channels to whatever you want; just make sure there's no 45-48 anywhere else on that remote.
You can change the global channel assignment or just the channel assignment while a particular page is displayed or both which is a very nice.
a hint for those wishing to change the global assignment:
- make sure the workspace viewer is on (view => workspace)
- the first entry in the workspace after the name of the workspace is named "external controls"
- double-click on that entry, change buttons as you like, they will be changed everywhere.
I tried to like the R4's but I found that the lack of important hard buttons renders this remote to be more like a touch panel then a handheld.
Maybe to switch sources or other contorl functions I dont mind using the touchpanel, but most people use tivo's or other dvr's and without those buttons, the remote is a bad design IMO.
My workaround was to use the number buttons for left/play/right pause. BUt man for the price of this remote, I dont want workarounds.
I tried to like the R4's but I found that the lack of important hard buttons renders this remote to be more like a touch panel then a handheld.
AMX should have realize that play, stop, pause, rec... buttons are a must, anyone buying this remote will have a video DVR connected to their system. When trying to use the circle control for these functions people really get confused when they try to control the DVD - is the circle control for the play/stop/ect or for the menu up/down/ect????
But I do like the R4 much more than a touchpanel when watching TV.
For the price of this thing, I was hoping it was going to do tricks for me - you know, jump up and down, do backflips, and even do my laundry. I was dissapointed to hear it only recieves feedback from the processor.
I think you pretty much have to put transport controls on the screen. Using the direction pad for anything other than cursor control could get confusing.
Of all buttons that should be hard buttons, it makes the most sense to leave out the transport buttons since they are most often associated with feedback, so that when they're put on the screen their state can also be used to indicate the current process. Of course this is not relevant for IR devices.
<-- Insert advertisement for a similar remote that can be used with AMX's RF reciever here -->
AMX is so close to having such a great remote, they just need to replace the Zigbee junk with Ethernet and add some valuable hard buttons. I just hope they release an R-5 remote that addresses these issues.
<-- Insert advertisement for a similar remote that can be used with AMX's RF reciever here -->
AMX is so close to having such a great remote, they just need to replace the Zigbee junk with Ethernet and add some valuable hard buttons. I just hope they release an R-5 remote that addresses these issues.
Let's think about this from an engineering standpoint for a sec. If we were to add transport controls to the R-4, where would they go? Would the remote be longer? Or would we remove buttons currently on the remote?
Maybe remove the number pad, but how would we enter channels, passwords, etc? Having to type on a keyboard on this screen would be a pain.
Maybe remove the direction pad, put a trigger on the underside of the remote, and detect direction based on the movement of the remote a la Wii. How much would this add to the cost? Would we need to install one of those little strips in every room?
I like that other remote too, but it has no feedback and it's slow. The remote is the most accepted paradigm for controlling media, so I am glad to see AMX is improving its remote line. Like many others have said, there is still room for improvement.
Yup - exactly what I was thinking. I've never compared the two side by side, but have worked with both of them. I know the T2-C is a bit bulkier, but . . . I would prefer one of those over an R-4 any day in my home. The touch on the R-4 just seems awkward compared the T2-C; I dunno what it is, it just "feels" weird hitting the R-4 screen.
We actually load up the T2C with AMX RF codes. Work great too.
i agree completely with with jjames, ethernet for connectivity and especially downloads is a must. I just installed 3 of these and switching between usb and mesh is not fun in the field.
i agree completely with with jjames, ethernet for connectivity and especially downloads is a must. I just installed 3 of these and switching between usb and mesh is not fun in the field.
Imagine having 90% of your jobs 3 hours away. Not a quick fix.
That is a nice remote but I like this design: http://www.universalremote.com/product_detail.php?model=128
It has all of the most used buttons as hard buttons and I know its not a touch screen but there is no reason why AMX could not make it with a touch screen.
Let's think about this from an engineering standpoint for a sec. If we were to add transport controls to the R-4, where would they go? Would the remote be longer? Or would we remove buttons currently on the remote?
There are many remotes on the market that have a better design. I think AMX needs to have a beta group that can give feedback before the product goes to market. I used to test for DigiDesgn (digital audio work stations) and our group made countless changes to the product that Digi would have never thought of... Something about not seeing the trees in the forest or is it the research lab? And most important the group gets to keep the product!
There are many remotes on the market that have a better design. I think AMX needs to have a beta group that can give feedback before the product goes to market. I used to test for DigiDesgn (digital audio work stations) and our group made countless changes to the product that Digi would have never thought of... Something about not seeing the trees in the forest or is it the research lab? And most important the group gets to keep the product!
We recently commissioned a couple of R2s - which I appreciate are a little off topic, but, I ponder the following...
Do we really need to have the majority of our buttons labeled. Fixed. Unchangeable?
Do we really only need 6 sources to choose from and another 3 that can be sort of used as sources?
Traditionally the software designer determines what the remotes should do (the old TXC xx platform as an example) No limitations, no pre-determined ideas of what we should do with this remote. Blank out the unused buttons etc.
I feel like these fixed design remotes are sort of telling US what we can do a bit.
Steven,
I could not aggree more with you. The R2 should spit out 45 channel numbers and that is it. It creates more programming headaches to use it in its current form. All buttons engravable would also be awesome.
I am also confused as to why the website says the AXB-RF is in LTD supply, if this is true, then does that mean the R2s are also in limited supply. I hope not it is a great remote and a great solution to axcess programming. I would also love to see more frequencies become available. The R2 in many ways is such a better remote than the R3, so it should be expanded upon.
Comments
I have had to disable security on my Netlinx master because I am not given an opportunity within the gateway configuration to add the user and password. The fields are greyed out. Anyone get around this?
And does it not have a "smart transfer" option? I made changes to 6 buttons, and it was only removing their addresses codes. And it decides to transfer the entire file - not to mention the USB transfer seems rather slow.
Can you show us the hunk of code? Thanx..
ejm
Easy enough to test: change your button channel 0 to an array that spans all the buttons on the remote. Then see if it works.
I figured why not try the [dvArray,0] as I never have before and sure enough no hold when holding a button but down below if you look at the diagnostic print out I get a HOLD 0 every [HOLD,repeat] time when nothing is held. The system apparently always sees 0 as being a hold_event.
So I guess if you need to HOLDS in a button_event you can't use [dvArray,0].
BUTTON_EVENT [dvR4_Array,0]//nR4BtnArray *******************************button event { PUSH: { LOCAL_VAR INTEGER nBTN STACK_VAR CHAR cDevice[11] ; nBTN = BUTTON.INPUT.CHANNEL//GET_LAST(nR4BtnArray) cDevice = fnDEV_TO_STRING(BUTTON.INPUT.DEVICE) ; If (nR4_DeBug) { SEND_STRING 0,"'R4 ',cDevice,'-CHANNEL ',itoa(nBTN),' Line-<',ITOA(__LINE__),'>',CRLF" ; } SELECT { ACTIVE (nBTN > 0 && nBTN < 50): { SWITCH(nBTN)HOLD [20,repeat]: { STACK_VAR INTEGER nBTN STACK_VAR CHAR cDevice[11] ; nBTN = BUTTON.INPUT.CHANNEL//GET_LAST(nR4BtnArray) If (nR4_DeBug) { SEND_STRING 0,"'R4 ',cDevice,'-CHANNEL ',itoa(nBTN), ' Line-<',ITOA(__LINE__),'>',CRLF" ; } SELECT { ACTIVE (nBTN > 0 && nBTN < 50): { SWITCH(nBTN) { CASE 22: // { ON [dvR4_Array,10] ; wait 10 OFF[dvR4_Array,10] ; break ; }diagnostics:
Never use button event objects in a HOLD. Those objects are really only available in the PUSH or RELEASE. Use a global variable to make an assignment and then reference the varialbe in the HOLD.
Think of a HOLD as much as you would a WAIT. And never use a HOLD with a panel array in a button event, only a single panel.
DEFINE_VARIABLE Volatile cDevRef[11] Volatile nChanRef BUTTON_EVENT[dvPNL,0] { PUSH: { cDevRef = fnDEV_TO_STRING(Button.Input.Device) nChanRef = Button.Input.Channel } HOLD[20,Repeat]: { If (nR4_DeBug) { SEND_STRING 0,"'R4 ',cDevRef,'-CHANNEL ',itoa(nChanRef), ' Line-<',ITOA(__LINE__)" } } }You could almost argue the need for a seperate cDevRef or nChanRef var
for every panel in the dvArray so that the potential of another panel changing the value before the hold executes is eliminated. Rare but possible!
I have chosen to use a HOLD only if my button event references a single panel because of the rare but potential conflict of two panels needing to use button objects. Again, button objects are only valid during the PUSH or RELEASE. Any other time the objects are subject to being either nul or subject to change by other events.
It is very important to make sure the variables in a HOLD are not unintentionally altered when the code in the HOLD executes. A HOLD is more a stealth WAIT or stealth TIMELINE than a button event.
Now it's even worse, requiring a seperate button_event for each TP if HOLDS are to be used to avoid the remote possibility of another panel changing a value prior to the HOLD executing. Before I thought we were just going to reference a single panel in the HOLD (which isn't really possible). Yuk! The alternative is to take your chance and hope some one on a different TP doesn't use the same device during the period that the HOLD is in a wait to execute. Again, yuk!
And you can't even use local variables. Which brings up another questions, why can't we declare local variables just after the opening brace of the button_event prior to the PUSH so they can be used for all handlers under the button_event?
a hint for those wishing to change the global assignment:
- make sure the workspace viewer is on (view => workspace)
- the first entry in the workspace after the name of the workspace is named "external controls"
- double-click on that entry, change buttons as you like, they will be changed everywhere.
In case anyone is interested, new R4/ZigBee firmware has been released.
Please review the release notes before upgrading.
http://www.amx.com/techcenter/firmware.asp?Category=Mio%20Remote%20Controls#Mio%20Modero%20R-4%20Firmware
Maybe to switch sources or other contorl functions I dont mind using the touchpanel, but most people use tivo's or other dvr's and without those buttons, the remote is a bad design IMO.
My workaround was to use the number buttons for left/play/right pause. BUt man for the price of this remote, I dont want workarounds.
But I do like the R4 much more than a touchpanel when watching TV.
I used the circle buttons as directional buttons.
Of all buttons that should be hard buttons, it makes the most sense to leave out the transport buttons since they are most often associated with feedback, so that when they're put on the screen their state can also be used to indicate the current process. Of course this is not relevant for IR devices.
AMX is so close to having such a great remote, they just need to replace the Zigbee junk with Ethernet and add some valuable hard buttons. I just hope they release an R-5 remote that addresses these issues.
Maybe remove the number pad, but how would we enter channels, passwords, etc? Having to type on a keyboard on this screen would be a pain.
Maybe remove the direction pad, put a trigger on the underside of the remote, and detect direction based on the movement of the remote a la Wii. How much would this add to the cost? Would we need to install one of those little strips in every room?
I like that other remote too, but it has no feedback and it's slow. The remote is the most accepted paradigm for controlling media, so I am glad to see AMX is improving its remote line. Like many others have said, there is still room for improvement.
http://www.rticorp.com/products/t2c.html
Curt
We actually load up the T2C with AMX RF codes. Work great too.
That is a nice remote but I like this design:
http://www.universalremote.com/product_detail.php?model=128
It has all of the most used buttons as hard buttons and I know its not a touch screen but there is no reason why AMX could not make it with a touch screen.
Do we really need to have the majority of our buttons labeled. Fixed. Unchangeable?
Do we really only need 6 sources to choose from and another 3 that can be sort of used as sources?
Traditionally the software designer determines what the remotes should do (the old TXC xx platform as an example) No limitations, no pre-determined ideas of what we should do with this remote. Blank out the unused buttons etc.
I feel like these fixed design remotes are sort of telling US what we can do a bit.
I could not aggree more with you. The R2 should spit out 45 channel numbers and that is it. It creates more programming headaches to use it in its current form. All buttons engravable would also be awesome.
I am also confused as to why the website says the AXB-RF is in LTD supply, if this is true, then does that mean the R2s are also in limited supply. I hope not it is a great remote and a great solution to axcess programming. I would also love to see more frequencies become available. The R2 in many ways is such a better remote than the R3, so it should be expanded upon.