Touch Panel Device status issues
pdavis41
Posts: 16
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.
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.
0
Comments
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.
Dave
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.
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.
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 ?
Dave
The programmer's guide for the new RMS Enterprise is now available on the AMX website:
http://amx.com//techdocs/RMSEnterprise.NetLinxProgrammersGuide.pdf
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.