Options
Panel dropped offline
Thomas Hayes
Posts: 1,164
in AMX Hardware
Hi everyone
I'm hoping it was a power glitch that sent one of my panels into lock up but I was wondering if anyone has had a Modero (CV7) panel drop offline for no real reason? I have both the controller and the panel plugged to the same switch so even if the network goes down they should still be able to talk to each other.
I'm hoping it was a power glitch that sent one of my panels into lock up but I was wondering if anyone has had a Modero (CV7) panel drop offline for no real reason? I have both the controller and the panel plugged to the same switch so even if the network goes down they should still be able to talk to each other.
0
Comments
How long is the Network run from your CV7 to the Switch? Have you re-terminated the Cat-5? Is it Kinked?
Overall, I've had excellent results with the wired Ethernet panels. cant think of any that dropped off the network without being Broken or a cableing issue.
Make sure your Power supply is adequet. I had one system that was at the virge of the Power Supplies and did have a couple CV7's exibit some strange behavior. Once I added some more PS, the system becamse rock Solid.
Something also, check that your program (if it uses IP sockets for control or whatever) is not exhausting all IP sockets of your master, preventing than the Modero to connect through IP to the master !
Vinc
If you put the panel in the URL list of the master you should have the panel in listen mode. In this configuration the panel is listening for the master to initiate the IP connection.
I recommend removing the panel from the URL list and putting the panel in URL mode. Several advantages here. When the NetLinx system is on a DHCP network only the master needs a static IP. When configured this way the master is the server and the panels are clients. It does not matter what the IP address of the panel is. It simply look for the masters IP you have listed in the master IP adress of the panels system setup page.
Rex
I have not had this difficulty on that particular project since I assigned all my panels static IP addresses, as well as the masters. There seems to be some sort of issue with lease renewals with some DHCP servers. Taking that out of the chain resolved the difficulty. It's a bit more of a pest to maintain the network, but it works much better for me.
I've always either used "URL" on the panel with static IP addressing, or in my shop when I feel brave about having all the gear on DHCP, I've used "Auto" and just put the master's system number in.
- Chip
I don't know that any is inherently better all the time, but the more chances you give something to go wrong, the more likely it will.
TKN
Hi everyone
Happy New Year (seems like ages ago!)
I last posted here back on 10th October while I was still working for the UK distributor (I'm now freelance again).
I've been seeing something like this happen (mostly with wireless panels but also much less frequently with wired panels) for over 12 months now. While I was still working for RGB Communications, I had the head of the firmware development team visit a couple of sites with me here in London (November).
Though it's difficult to induce 'on demand' I was able to demonstrate a situation whereby the master would refuse a connection from a panel (we managed to do this by wandering in and out of range of a WAP with three MVP7500s - it took us only around 10 minutes to get a result). What I was not able to demonstrate during the visit, but WAS able to remotely about a week later, was a similar situation whereby a panel loses connection with the master somehow and will then NEVER reconnect until that master has been rebooted. I've had clients report that their panels have stopped working for days at a time.
The problem appears to be at the master end of things (it may turn out to have something to do with panel firmware as well, but it DEFINITELY implicates the master). If a device goes offline without actually sending a message to the master to confirm this (e.g. it loses power or is unplugged) then the master SHOULD automatically generate an OFFLINE event after a short period of time (and run any associated code). However, this does not always seem to occur and on a number of occasions I have found that opening a telnet session to the master and enabling messaging ('MSG ON'), I will then see either or both of the following messages?
?Socket transmit timed out on broadcast msg, socket closed (19)?
followed by?
?Ignoring/closing connection from IP 192.168.1.101 (Duplicate of Device=10001:1:0)?
Note - When both occur together they alternate every few seconds and repeat continuously.The socket number, IP address and device number obviously depends on which panel is failing to reconnect.
Rebooting the panel causes these messages to cease only until the panel has finished initialising after which they resume. Only rebooting the master resolves the issue.
If you see this, try temporarily changing the device number of the panel and rebooting it WITHOUT rebooting the master - you should find it connects ok proving your cabling, wireless LAN, etc. Restoring the original settings, again without restarting the master, should cause the error to resume.
I'm not sure why a panel would go offline in the first place but when it happens and it doesn't come back, this is something to look for.
Unfortunately, this situation has continued with a beta firmware revision left with me at the end of November. Since then I?ve given the development guys remote access to three separate sites so as they could monitor the situation. I understand that they were able to get some useful data as a result and so I guess we're just going to have to wait and see if the next official firmware release fixes the problem. Fingers crossed.
I thought fluke and let it be. It went out a few days later again. I checked the log this time and found that it was going out at least once an hour, anywhere from 15 minutes to 3-4 days. It would always eventually come back.
Even though my access points don't make it outside of the house, I checked for other networks. There was some form of 'uber' network on the same channel as mine. The next closest house is like 200 feet away! I was getting better signal on it rather then sitting right next to my access point.
Anyway, I changed channels and the problem hasn't returned.
Kevin D.
Are you refering to the Master? I set the mode to 10 half on the master a long time ago and still have issues, can you change the panel setting? I thought that I had read somewhere that you shouldn't change the panel setting.
I hate to say it, but it sounds to me like this particular problem is code based. Open up Diagnostics and turn on all the event notifications for one of these panels, then monitor for traffic. Wireless communications is inherently slower than wired, so excess notifications are more likely to be an issue than with wired panels. Any duplicate event that is generated more than once a second is too much, but not likely to casue trouble; but I have seen events fire 50+ times a second and bring a system to its knees.
i how now proven that AMX controllers have a flaw in their network services.
my report on this has been passed along to my suppliers, who have verified this finding. i expect it is being passed along the chain to AMX as i write. it needs paramont attention.
i strongly recommend that we all stop chasing our tail until AMX addresses the issue.
hmm... I've seen this post before...
Can you describe this flaw and what kinds of projects it might effect, so as to be more helpful to us?
but, the symptom i can recreate is related to DNS lookups.
my example is.. one network service is Max, and the comms module polls Max something like every 30 seconds. that's fine.
now, create an IPCLIENT, and get it to try to open a connection, with a URL that requires a DNS lookup. get it to try every minute or so to connect. prove it can connect if you like, but it doesn't need to.
now, if you disable access to the DNS server (which can happen when internet connections fail) or provide an invalid DNS server address in the controller, you can create the following condition...
while the controller is waiting for the DNS reply (which will timeout as it can't find it) other network services begin to log-jam. when the timeout finally occurs for this DNS request, it will report to the controller that it had an error, that's fine. but then the error impacts on the other network service, which is on a different port number and didn't require a DNS response. the other network service then may get corrupted (in my case is does corrupt the comms module) and so any future requests to the comms module will be unreliable.
i think that this is just a symptom, not the actual fault, of intermittent network errors. a more thorough check of other services are probably needed. but this error i am reporting can be regenerated time and time again.
i tend to wonder if the problem is also in panels, where a DNS request for a dynamic image may be returning an error.
(i setup a local live dynamic image (IP address) at 5 second updates, then setup another dynamic image that required a DNS lookup. i then disabled access to the DNS server from the panel. the image that required DNS didn't impact the image that was fed from the local ip number).
I then tried to connect to different master with still no luck. As a last resort the firmware was reloaded (via USB since it couldn?t connect to a master) and abracadabra, the MVP connected. Go figure?