Home› AMX User Forum› AMXForums Archive Threads› AMX Hardware
Options

R4 No Feedback on Channels 401+

TurnipTruckTurnipTruck Posts: 1,485
in AMX Hardware
Greetings,

I am working on a system with R4s. I have some functions on buttons in the 401-440 range. The pushes occur and trigger the appropriate events, but no feedback is dislplayed on the buttons. I have tried manually turning the buttons on from "Control a Device" in studio. Lower button numbers can be illuminated, not these.

FWIW, The system is offsite, the R4 and gateway are in my office connected remotely. I don't see how that would make any difference though.

Any ideas? Thanks.

Comments

  • Options
    ericmedleyericmedley Posts: 4,177
    You might try putting a set_virtual_channel_count(dv_device,1024) or whatever your device is at the data_event[]>Online: for the R4s.

    hope that helps.
    e

    PS: Oh, and happy 1K posts (belatedly)
  • Options
    TurnipTruckTurnipTruck Posts: 1,485
    ericmedley wrote: »
    You might try putting a set_virtual_channel_count(dv_device,1024) or whatever your device is at the data_event[]>Online: for the R4s.
    Did that and solved it. I thought that was only for channel counts of virtual devices. Thanks for the tip.
    ericmedley wrote: »
    PS: Oh, and happy 1K posts (belatedly)
    Thanks! you were the first to send those wishes! Hopefully the signal to noise ratio of my first 1K posts was found to be quite high.
  • Options
    viningvining Posts: 4,368
    TurnipTruck wrote:
    I thought that was only for channel counts of virtual devices.
    It is just for virtual devices but there's been a few occassion where a firmware release has messed up the default channel counts for real diveces. A year or so ago we had this problem caused by frimware where FB for regular TP ports wouldn't work on channels over 255?(maybe 400 or 500). After the next frimware release fixed the problem another frimware release made it work sporadically and of course you don't notice unless you're dealing with a device which uses a lot of buttons and most of our devices don't. Looks like the R4 has the problem now.
  • Options
    DHawthorneDHawthorne Posts: 4,584
    I've come to the conclusion long ago that there is little difference, if any, internal to the master between a real device and a virtual. If a real device exists, it is mapped to the same memory object, and device-specific characteristics transferred over. For a virtual, there is no mapping, just a default set of channels, levels, etc. This would be a case of an error in that mapping function, where all possible hardware device channels aren't automatically mapped to the object used by the master. Using the SET_VIRTUAL_CHANNEL_COUNT function simply does it manually.
  • Options
    HARMAN_shane-a-rooHARMAN_shane-a-roo Posts: 39
    When a device comes online, one of its parametric messages that it sends to the master is the max number of channels on a particular port (if it is greater than 255). This is determined by the highest channel number as defined in the TP pages. When the master receives this, it will expand its database for that port to allow for that many channels. If for some reason the device does not send this information OR the message got lost, the master will not know to set the database size appropriately and feedback attempts will be no-ops. One reason that a message could get lost is if there are queue overflows along the processing path. In the case of the R4 this could be in the Gateway or the master itself. Overflows in the master are usually due to too many messages as all of the devices come online at the same time. Some of the newer panel FW versions have made some efficiencies to reduce the number of messages that get pushed to the master at startup. I believe the latest R4 Firmware does this but most of the bigger panels do not yet support it. By calling SET_VIRTUAL_CHANNEL_COUNT, you are telling the master via a back door how many channels a particular Device:Port has, the same as if it had come from the device itself.
  • Options
    TurnipTruckTurnipTruck Posts: 1,485
    shane-a-roo wrote: »
    When a device comes online, one of its parametric messages that it sends to the master is the max number of channels on a particular port (if it is greater than 255). This is determined by the highest channel number as defined in the TP pages. When the master receives this, it will expand its database for that port to allow for that many channels. If for some reason the device does not send this information OR the message got lost, the master will not know to set the database size appropriately and feedback attempts will be no-ops. One reason that a message could get lost is if there are queue overflows along the processing path. In the case of the R4 this could be in the Gateway or the master itself. Overflows in the master are usually due to too many messages as all of the devices come online at the same time. Some of the newer panel FW versions have made some efficiencies to reduce the number of messages that get pushed to the master at startup. I believe the latest R4 Firmware does this but most of the bigger panels do not yet support it. By calling SET_VIRTUAL_CHANNEL_COUNT, you are telling the master via a back door how many channels a particular Device:Port has, the same as if it had come from the device itself.

    Great insight! Thanks! Well worth the price of admission.
  • Options
    viningvining Posts: 4,368
    shane-a-roo wrote:
    This is determined by the highest channel number as defined in the TP pages. When the master receives this, it will expand its database for that port to allow for that many channels.
    What if you're using channels for internal flagging higher than the highest TP channel used?

    My understanding was that virtuals defaults were 255 channels and 8 levels while non virtual devices were 4000 channels and xx levels (I forgot).

    Now what you're saying is that if a panel is offline we're screwed but that doesn't seem to be the case. I think the defaults are the defaults and aren't dependant on the UI informing the master of the number of channels or ports that need to be tracked. Of course I've been wrong many, many times but this is the first of heard of such a procedure.
  • Options
    HARMAN_shane-a-rooHARMAN_shane-a-roo Posts: 39
    vining wrote: »
    shane-a-roo wrote:
    My understanding was that virtuals defaults were 255 channels and 8 levels while non virtual devices were 4000 channels and xx levels (I forgot).

    The default for any NetLinx device (real or virtual) is 255 channels, 8 levels. Anything beyond these values should be set by the device itself (based on the pages that are loaded) or programmatically via the set_virtual_channel_count and set_virtual_level_count APIs. Beyond that, it gets a little complicated. For example, if a master receives an input channel state change from a device beyond the number of channels it thinks the device has, it will automatically increase the number of input channel database entries for that device whether it had received the ONLINE parametric information or not. The logic there is...the device must know how many channels it has or it wouldn't have turned that input channel on...so go ahead an increase the database. But output and feedback channel states don't work this way. You can't just ad-hoc try to turn on an output or feedback channel state for a channel number that hasn't been reported by the device or overridden via the set_virtual_channel_count API.
  • Options
    [Deleted User][Deleted User] Posts: 0
    shane-a-roo wrote: »
    When a device comes online, one of its parametric messages that it sends to the master is the max number of channels on a particular port (if it is greater than 255). This is determined by the highest channel number as defined in the TP pages. When the master receives this, it will expand its database for that port to allow for that many channels. If for some reason the device does not send this information OR the message got lost, the master will not know to set the database size appropriately and feedback attempts will be no-ops. One reason that a message could get lost is if there are queue overflows along the processing path. In the case of the R4 this could be in the Gateway or the master itself. Overflows in the master are usually due to too many messages as all of the devices come online at the same time. Some of the newer panel FW versions have made some efficiencies to reduce the number of messages that get pushed to the master at startup. I believe the latest R4 Firmware does this but most of the bigger panels do not yet support it. By calling SET_VIRTUAL_CHANNEL_COUNT, you are telling the master via a back door how many channels a particular Device:Port has, the same as if it had come from the device itself.

    As an small addition, this optimization Shane is talking about is to allow devices to come online quickly. We found that some devices were sending so many message that it was taking 10-20 second just to come online. That was with a 100-base-T wired ethernet connection, on ZigBee it was much, much worse.

    I'll take a look to make sure we are not being too aggressive in removing unecessary messages.
  • Options
    viningvining Posts: 4,368
    shane-a-roo wrote:
    The default for any NetLinx device (real or virtual) is 255 channels, 8 levels. Anything beyond these values should be set by the device itself (based on the pages that are loaded) or programmatically via the set_virtual_channel_count and set_virtual_level_count APIs.........
    .....You can't just ad-hoc try to turn on an output or feedback channel state for a channel number that hasn't been reported by the device or overridden via the set_virtual_channel_count API.

    I was wondering where you were getting this info from since I've never heard it before but the new avatar explains it. I also see that everyone from AMX engineering is using it now which is a good idea, let's us know who's who and the added participiation from your department is much appreciated.

    Unforetunately I now have to re-think every thing I thought I knew again. I hate when that happens. :)
  • Options
    ericmedleyericmedley Posts: 4,177
    none of this explains the fact that I had an older TV control box where the I/O sensor feedback wouldn't work on channel 255 until I put in Set_vitural_ etc.. (dv_box, 512) It wouldn't work with 255. It was another thread. If 255 is included, why didn't it work until i bumped the set_virt value to the next bit-depth?
  • Options
    viningvining Posts: 4,368
    ericmedley wrote:
    none of this explains the fact that I had an older TV control box where the I/O sensor feedback wouldn't work on channel 255 until I put in Set_vitural_ etc.. (dv_box, 512) It wouldn't work with 255. It was another thread. If 255 is included, why didn't it work until i bumped the set_virt value to the next bit-depth?
    There definitely were issues in previous firmware releases that broke the way this supposedly operates. Maybe it used to be real devices had 4000 channels when defined and then a firmware release optimized to this method so that it now only creates what's needed, maybe it's always been the way shane-a-roo describes, it's just bizarre that I/we've never heard this on the forums before. Maybe I missed it?

    I seem to remember posting a question to the forum a long time ago asking "that since real devices were created with 4000 channels (my belief at the time) wouldn't it make sense to set_virtual_ch_count to what was actually needed to reduce overhead" and if I recall the answer I recieved was that the extra overhead wasn't that big of a deal. I didn't get "don't worry mate" that's not how it works, you only get the amount used on the TP.

    I'm sure there are many things we'll never understand and all we can do is keep trying.
  • Options
    [Deleted User][Deleted User] Posts: 0
    vining wrote: »
    ericmedley wrote:

    There definitely were issues in previous firmware releases that broke the way this supposedly operates. Maybe it used to be real devices had 4000 channels when defined and then a firmware release optimized to this method so that it now only creates what's needed, maybe it's always been the way shane-a-roo describes, it's just bizarre that I/we've never heard this on the forums before. Maybe I missed it?

    I seem to remember posting a question to the forum a long time ago asking "that since real devices were created with 4000 channels (my belief at the time) wouldn't it make sense to set_virtual_ch_count to what was actually needed to reduce overhead" and if I recall the answer I recieved was that the extra overhead wasn't that big of a deal. I didn't get "don't worry mate" that's not how it works, you only get the amount used on the TP.

    I'm sure there are many things we'll never understand and all we can do is keep trying.

    The 255 channel limit is a default that goes back to the original Netlinx Master releases. It limit is actually part of the Axcess stuff, but in Axcess 255 is a hard limit, if you want more than 255 channels on an Axcess device, you have to have use multiple device numbers.

    The optimization of startup messages to try and prevent unecessary traffic is a fairly new thing.
  • Options
    viningvining Posts: 4,368
    rhargrave wrote:
    The optimization of startup messages to try and prevent unecessary traffic is a fairly new thing.
    Thanks, knowing these sorts of nuances in the system operation is really helpful. Maybe not at this minute but eventually I'm sure they will be.
Sign In or Register to comment.