Home AMX User Forum AMX Resource Management Suite Software

Touch Panel Device status issues

I was reading through another thread (http://www.amxforums.com/showthread.php?7265-Touch-Panel-Control-System-Errors) that was similar but not totally related to what we have going on at two different locations.

All of our issues seem to be revolving around touch panels, both wired and wireless. Both locations we are on the building networks. One location we are on their wireless (managed enterprise cisco WAPs) and the other we are primarily using AMX WAPs.

The biggest issue we are getting is that the wireless panels (and some wired) are swinging on and off line about 400 to 500 times a day. The other panel we have primarily seen this with is a NXV-300. When I called tech support I was just given a line that it is a network issue.

I am trying to setup and see if the issue is similar to the one in the other thread and large amounts of data are just over flowing the NIC but I'm just not sure. We use the same modules all over the place and don't see issues with the touch panels having connectivity issues, but then again we don't have those systems on RMS either. But you never have a issue picking up a touch panel somewhere else and using it.

I have attached a current output of one of the logs from one of the RMS systems. Any help anyone could think of as a starting point would be greatly appreciated. This was thrown at me to solve as our clients are getting very unhappy with the solution they have purchased as it throws them a few thousand emails a day.


  • pdabrowskipdabrowski Posts: 184
    Is TP log is also available? without the TP log there really isn't much info that can be gleamed from that RMS log to ascertain what is happening to cause these online/offline events.
  • Dave_UKDave_UK Posts: 54
    You can monitor the traffic between the TP and the Master in Netlinx Studio. If you are seeing a lot of traffic there with the same timestamp, then you have a programming problem and may have endless loop conditions like I found. (You can also monitor this in the Netlinx web console but I've found that to be a less reliable tool than Netlinx Studio.) This showed up on the local network monitoring system as a large amount of traffic between the two switch ports.

    This problem should be obvious to a Netlinx programmer, however some will just walk away from the problem and blame the hardware / network.

    Another cause can be the NIC speed. I have found a small number of 5" TP's (NXD-500i / NXD-CV5) and one Netlinx master (NI-3100) which have problems when left on auto speed detect and I have had to manually set them to 10Mbps to avoid the problems, even though the lines check out ok with a Fluke at higher speeds. This showed up on the local network monitoring system as high number of link drops.

  • John NagyJohn Nagy Posts: 1,733
    We have seen many locations where a wifi panel at the edge of coverage will flap 3 times a minute or faster. This continues until the Netlinx has had enough and shuts down all TCPIP communications, including telnet and Studio monitoring. Only a reboot will make it recover, and sometimes that happens spontaneously.

    We know this to be a network issue. You can see the wifi signal at threshold. It continues even if no program communication to the panels occurs at all.

    I suggest you intercept a panel in this mode, and change its AMX address to one your program does not communication with. See if the flapping resumes. If so, your program clearly is NOT affecting it. If it cleans up when you aren't talking to it, change the equation some other way, and try again.

    We log every on and offline event on panels, and if they are away less than a minute, we let them back in but do not reinitialize any data, so we are not in any way prodding it into another offline. It's not been away long enough to be seriously out of synch anyway, and if it stays online, we'll get it refreshed as it is used.

    If we get too many offlines in a few minutes, we sever communications with the panel and ignore it, and send it to a warning page that says there's a comm problem, to resolve it or call the dealer, and a single button to request to start over clean. Lots of work in all that, but it preserves the operation of the rest of the system for a while. If the panel flaps for a couple days, we usually see a NetLinx shutdown of all IP. This is better than trying to reinitialize it several times a minute which for us causes system-wide lags and even apparent lockups as it can never finish coming online. It also notifies the customer of where the problem is while there is time for them to correct it. It's usually just out of range.

    Your problems include wired panels, so only some of this is of use to you... I'd still bet on network issues. But the test above should prove it. If they flap with the program code not involved, it's hardware or network.
  • pdavis41pdavis41 Posts: 16
    I totally forgot that I posted this.

    It is definitely a network issue. I loaded the same code into a processor at our office and not a single email from our RMS server.

    As a workaround right now we just added a bit of code to timeout the events. If the panel drops offline it starts a timeline. If it comes back online it kills the timeline. If the timeline completes it activates a channel on a virtual that we monitor as the touch panel.

    That has solved our issues for now. I'm down from 500 emails a day to only a few (if the panel is offline for more than 300 seconds).

    I will look into the other things mentioned though.
  • Touch Panel Device status issues

    the new RMS Enterprise supports time delayed parameter thresholds for devices like this that may not maintain fulltime cocnnectivity. Delay time may be set in one minute increments.
  • Dave_UKDave_UK Posts: 54
    Doug Hall wrote: »
    the new RMS Enterprise supports time delayed parameter thresholds for devices like this that may not maintain fulltime cocnnectivity. Delay time may be set in one minute increments.

    Doesn't really help us until you actually release it... ;)
    I needed that feature back in 2009, but it's now looking like 2012.

    Any preliminary documentation yet so as we can start getting up to speed ?

  • Hi Dave,

    The programmer's guide for the new RMS Enterprise is now available on the AMX website:

    Please see page 40 for information on "Registering Asset Parameters Thresholds". There is an optional "Delay Interval" argument that you can provide that specifies the number of seconds to delay the threshold tripped state. If not specified, the value is assumed to be 0 and no delay is applied.
Sign In or Register to comment.