Date / Time buttons
richardherman
Posts: 401
Hello,
I've got a client with two almost identical sytems. Each uses a NI-4100 and one NXD-1200V. On the TP I use the address setup port to display the date and time. This works fine, but after a while (days,weeks) it displays the wrong date /time. I assume the panel gets this info from the master. On the master the date and time are correct. If i reboot the panel, things are working fine, until the same thing happens again. And it keeps happening.
Recently I noticed that, while trying to correct the error, I could also not telnet into BOTH TP's (the connection is accepted but i don't see any commands, just a cursor) and the VNC connection also doesn't work (protocol error). Not sure if this has something to do with it, but i assume it has. Using telnet with both NI controllers works fine.
The client only notices the date/time error, the rest of the system works fine.
This happens on both of his systems. They use (limited) M2M comms, but apart from that are completely seperate systems.
The TP's use the latest firmware (V2.72.11); the masters a very recent one (V3.30.371)
Idea's ?
Richard Herman
I've got a client with two almost identical sytems. Each uses a NI-4100 and one NXD-1200V. On the TP I use the address setup port to display the date and time. This works fine, but after a while (days,weeks) it displays the wrong date /time. I assume the panel gets this info from the master. On the master the date and time are correct. If i reboot the panel, things are working fine, until the same thing happens again. And it keeps happening.
Recently I noticed that, while trying to correct the error, I could also not telnet into BOTH TP's (the connection is accepted but i don't see any commands, just a cursor) and the VNC connection also doesn't work (protocol error). Not sure if this has something to do with it, but i assume it has. Using telnet with both NI controllers works fine.
The client only notices the date/time error, the rest of the system works fine.
This happens on both of his systems. They use (limited) M2M comms, but apart from that are completely seperate systems.
The TP's use the latest firmware (V2.72.11); the masters a very recent one (V3.30.371)
Idea's ?
Richard Herman
0
Comments
The other issues do seem a bit weird. May want to call tech support on that one (well, on all of it really.)
Right now the date/time display says 'may 17' on one system and 'may 10' on the other. So it's way off. Like I wrote, the masters date and time setting are correct. If i reboot the panel it takes the time info from the master and is fine again. just not for very long. The master is not setup to get the network time for a simple reason: it is not connected to an 'outside' network. Both systems are on their own networkswitch and I remote connect to it through an ISDN modem.
I assume that displaying the date/time on the panel with the address setup port (port 0) is the way 'everybody' does it?
I agree the Telnet / VNC thing is a bit weird. Although i have had several times before when i could not telnet directly into a TP. Rebooting through the master always solved it.
Richard Herman
Really dumb question; there aren't any elements in the panel file that have been copied from the system page template are there (ie. there's no chance that elements in the panel's user pages inadvertently have setup port / channel combinations that correspond to time/date manipulation functions)?
Hmm, that smacks of an invalid gateway specified on the panels or other network issue (duplicate IP address?). Doesn't explain the system clock issue though. The logs on the panel may help to shed some light.
It would be much better in a way if the panels weren't working for the client when they fault as this would help to narrow down the list of potential issues quicker.
If the network and settings are peachy, the obvious things to try are:
(a) Ensuring the master and panel firmware are up to date
(b) Maybe issuing a reboot(<touchpanel dev>) from the master's code once a week at a convenient time is the easiest fix?
(c) A couple of interesting quotes from the user manual are:
"Modero touch panels do not have an on-board clock. This [setup] page both receives and
sets the time/date of the NetLinx Master."
"The only way to modify a panel?s time, without altering the Master, is to use NetLinx
Code."
It doesn't indicate how often the panel requests the time/date from the master after coming online, so it's possible that the the panel time isn't actively maintained. In that case you may need to add this functionality in the master's code to ensure that the time stays in sync.
Richard, what do you have in the URL lists for each master?
Are you able to test the 2 systems by removing the M2M elements and testing them as seperate systems - you could assign a different IP range for 1 Master and 1 TP to prevent any comms between the 2.
Are the panels set to Auto to search for a master?
It sounds like something is messing with the IP queues
in the URL list of the first master is the IP address of the second. The URL list of the second is empty.
This would be very difficult to test for any length of time (> couple of hours). An important part of the way the systems function depents on it.
They are set to URL
I'm not exactly sure what this means or how I could test this. Could you explain this a little more?
Anyway, thanks for the help,
Richard
Anything is possible, so I would be dumb not to check this. So i did...: there are no (unwanted) duplicate address codes for port 0.
The gateway seems to be the right one (The router/modem I use to connect to the systems). There are no duplicate IP adresses (scanned the network with an IP scanner to make sure; everything looks normal). I can't get the log files: i usally do this with telnet (doesn't work now) and if i go through the webinterface it tells me: "no log data for this device". don't know if that should work, never used it before. The log file of the master contains nothing (well, actually, it does: the usual IP connection stuff that just fills the log)
They are
Mhhh, you are probably right, but i hesitate: I've had a couple of panels that would get stuck during a reboot and needed a power cycle to get working again. With this client that would mean a 3 hour car ride for me... no way he would do that himself.
Ok, thanks for the quote. In case i would go that way: Would anyone have some code available for setting the date/time on a panel? (I probably could figure it out.. but I'm lazy...)
Thanks for the help,
Richard
I've often pondered the idea of just setting the upd bc rate to the longest possible time interval instead of 0 to keep the broadcast in place for what ever reason it may be beneficial and still minimize the network chatter.
Could be strictly for discovery though. Any smart people out there?
Through telnet 'SET UDP BC RATE' it tells me it's currently 5 seconds, which is default.
No, just me...
Richard
It's been posted many times that this can (should?) be set to 0 to reduce network chatter. This is used for auto discovery for TPs (when set to auto) but since it's recommended for most installations to use "URL" there's no need for this to be on and every 5 seconds doing .255 (depending on the net mask) broadcast to all devices on the networks which in turn all need to respond w/ their mac's and other pertinent info.
Thought there might be a chance the the master pooled this info for an update table but apparently not.
A definite possibility. I wouldn't recommend it as being the best practice "solution".
I wondered the same last night, but I'm lasy too and didn't pursue it...
One thing I thought of was setting the master's time to the current time occasionally thinking that the update would force the master to resend the current time to connected devices. I only have an R4 remote to test with at the moment, but nonetheless this does not seem to work (unless it can take a long time for the change to propagate, I only waited about 5 - 10 minutes). The time doesn't appear to update until the remote next goes offline and subsequently comes back online. So this poses the question, how can we force an online event for the panel occasionally? From memory a device has to fail to respond to 3 ICSP blink messages (at 5 second intervals) to be considered offline, so blocking Ethernet comms to the device on TCP port 1319 for 16 seconds should do the trick. I can't think of a way to do that easily though. If it was a wireless panel that supports "standby" you'd be sorted.
The manual doesn't list Telnet commands for the panel and I don't have an Ethernet panel around. Not sure if there're any commands in the list that would allow you to update the time manually or trigger an online event. If this is the case I can probably point you in the right direction to getting the master to Telnet into the panel to update the time.
Anyway, I suspect that you're seeing two different issues which aren't directly related:
1) Given that the master doesn't seem to actively maintain the time on panels; the panel is not maintaining it's internal clock accurately. I note that in AMX's past there have been very minor issues with the system clock of devices. Not sure how far out the clock is slipping and how quickly, but there's a real possibility that this is an issue with the panels in this install.
2) There's an issue with Ethernet communications to the panel for one reason or another. Hard for me to make suggestions as I don't know the network topology and configuration on the site.
@Vining
The AMX doco on the subject is fairly limited.
You should have a look at the following if you're not already familiar with them:
http://www.amx.com/techsupport/techNote.asp?id=544
http://www.amx.com/techsupport/techNote.asp?id=250
"Setting the 'udp BC rate' to zero should not have had an effect on connectivity to the master. However, there may be some network settings on this customer's network that makes the UDP broadcast a problem.
The average system does not need UDP. It is used only if 'Auto Connect' is used. Setting this to zero does not affect any other networking process. The only thing that you lose is the Auto Connect on G4 panels."
"Regarding ICSP, the NetLinx master generates a UDP broadcast message of 60 bytes every five seconds. [...] For every Ethernet ICSP device (including other NetLinx masters) that?s connected TCP, there are two outbound messages and one response every five seconds. The outbound messages are 29 bytes and 60 bytes, while the inbound response is 40 bytes. "
There's another source of information on AMX interdevice communications of a more low level nature, but it's more of an academic nature and is not generally useful. PM me if you're interested.
Hey, hey, hey that's not vary nice. i can program control systems me
Are your 2 panels referenced in a single master or is it 1 panel to 1 master? Are both Masters clocks set to the exact same time? ie via NTP or one off local PC sync. If 1 to 1 can you change the code to set both to the same system number... It is possible that they are receiving conflicting time messages from each master
What make and model network switch are you using? Several manufacturers switches have caused IP traffic issues in the past. Have you tried swapping out the switch?
Can you also post your set queue size and set threshold settings from both masters?
1 panel to 1 master
They do not use time sync. Each master only uses their own internal clock. (which are correct!)
I'm not sure what you mean by this. The panels are connected with the 'URL' method, each to it's own master. How could the panels get conflicting time messages? And if so, I'm using the panels setup port to display the time; how do i set that to use a different master as the one it is conncted to ??
3Com Baseline switch 2916-SFP Plus. (manageable 16 port gigabit switch). haven't tried another switch, we use this one a lot; also on sites where there are no date/time problems
If it will make you happy...... :-), but they are all default; both masters are identical.
>set queue size
-- This will set the maximum message queue sizes for several threads. --
-- Use caution when adjusting these values. --
Set Queue Size Menu
1. Interpreter (factory default=2000,currently=2000)
2. Notification Manager (factory default=2000,currently=2000)
3. Connection Manager (factory default=2000,currently=2000)
4. Route Manager (factory default=400,currently=400)
5. Device Manager (factory default=1500,currently=1500)
6. Diagnostic Manager (factory default=500,currently=500)
7. TCP Transmit Threads (factory default=600,currently=600)
8. IP Connection Manager (factory default=800,currently=800)
9. Message Dispatcher (factory default=1000,currently=1000)
10. Axlink Transmit (factory default=800,currently=800)
11. PhastLink Transmit (factory default=500,currently=500)
12. ICSNet Transmit (factory default=500,currently=500)
13. ICSP 232 Transmit (factory default=500,currently=500)
14. UDP Transmit (factory default=500,currently=500)
15. NI Device (factory default=500,currently=500)
Enter choice or press ESC:
>
>set threshold
-- This will set the thresholds of when particular tasks are pended. The --
-- threshold is the number of messages queued before a task is pended. --
-- Use extreme caution when adjusting these values. --
Current Interpreter Threshold = 1500
Enter new Interpreter Threshold (Between 1 and 2000) (Default=1500): 1500
Current Lontalk Threshold = 50
Enter new Lontalk Threshold (Between 1 and 2000) (Default=50): 50
Current IP Threshold = 1500
Enter new IP Threshold (Between 1 and 2000) (Default=1500): 1500
New Threshold values specified are identical to current values.
Thresholds are: Interpreter 1500
Lontalk 50
IP 1500
No changes are being made.
>
Richard
The first thing i asked myself was: Why? I'm sure we all like to write code, but AMX has made an internal TP function available to us which does this all 'automagically'. Did you have problems using this?
If I would write code to handle this, it seems easy enough, but i haven't given it much thought. Do you have some tip's available? Do you use a timeline or define_program? Do you just use the system var's TIME and DATE or do you use formatting ? (i live in Europe; DD/MM/YYYY).
Anyway, it's friday 4:15 pm, i'm switching my brain to the weekend mode: AMX? huhh??
See you all next week!
Richard
Several of our clients work in multiple time zones and they like to be able to change their TP clocks to match with whomever they are working. (Seems silly to me but who am I to judge.) I wrote a routine to deal with this and it just became part of the canon of our systems. It doens't hurt anything It's already written and allows for some pretty silly automation if need be. The time messages get sent either way.
Sorry for the delay Richard, I've been away on a job... strangely it also had weird things going on with the network - proved to be a faulty AP that was in effect killing the local segment by flooding the network with random crap packets. Master & panels stayed up 95% of the time but messages just didn't arrive...
What I meant was place both TP's in System #1 and then reference the panel used for System#2 as a device defined in system#1. Change your URL to System#1 for both panels. If both panels are referenced to a single master do you still get weird time changes.
The fact that you loose Telnet to the panels suggests to be a network issue, I've also seen systems fall over in time after a firmware update corrupted the values for queues and thresholds...