DELAY BOOT? HELP!
jsnyder
Posts: 23
in AMX Hardware
Greetings,
my new "business class" switches (Cisco SG200-08P) boot slower than my NI-3100s so the NI gives up trying for its static ip. then it just sits there.....
any clue how I can delay start-up?
Thanks,
John
my new "business class" switches (Cisco SG200-08P) boot slower than my NI-3100s so the NI gives up trying for its static ip. then it just sits there.....
any clue how I can delay start-up?
Thanks,
John
0
Comments
If you want to keep the NI's dhcp but static bound in the switch for whatever reason you could then write code to telnet into the master to get it's ip address and if it's in the auto private range then try to ping the switch. When you can ping the switch then issue a reboot of the NI. When in come back test for a proper IP again.
I also use SG300 switches but I keep it on another ethernet controlled outlet and never reboot all outlets at the same time, usually even if I do thet'd be sequenced.
and a serial terminal "get ip" returns correct info. along with a msg about timeout on a try for the master in it's url list. over and over again.
rebooting the master (via terminal) restores it.
the switch is default config with no vlan specified.
Thanks.
Alas, no joy...
I tried setting a reboot in code so if TP1 goes offline it should reboot the master.
sadly, since the master boots before the switch can hand out an ip TP1 never makes it "online" in the masters eyes
so it never goes "offline".
(bash cranium against wall here)
After master boot, attempt a code interaction with the slave. If you get through, continue.
If you don't, wait 1 minute and reboot.
(Put a telnet message up saying it looks like the M2M isn't ready, and maybe allow a manual abort (via telnet) of the reboot for test purposes.)
Creeping featurisms:
You can add a counter in non-volatile variable that is zeroed on slave communication being established, and increment it on each reboot. And stop the rebooting if the count goes to 5 or so... which would mean it isn't happening. Keep the master running and reset the counter to 0 for the eventual next session.
You could increase the wait time for each reboot, based on the variable, such that you have time to recover if there is transient network trouble. Say, boot 4 waits 5 minutes instead of 1, and boot 5 waits 15. So 5 boots gives you 23 minutes to get the network happy.
You could periodically verify M2M after that, if needed, say check once an hour or maybe once a day.
And DOCUMENT, DOCUMENT, DOCUMENT. The above behavior would make any tech crazy if they didn't know it was happening or why.
I'd just make a integer flag that gets set at the TP online event to one. Also put the flag back to zero in the offline event.
Then on startup create a wait that will give the to enough time to connect f the switch is up and running. Then after the want check for the flag value. If the TP is still offline you can reboot the Netlinx master then.
I will go on record as saying I'm not a fan of this method as it puts another device in the mx that may or may not be the cause of the problem.
The way I'd approach this is to turn on SNMP on the network switch and just try to hit the switch for a response. If no response, reboot.
Hi all,
thanks for the attempts!
John: since the master boots before the switch, TP1 never makes it "online" in the masters eyes
so it never goes "offline". no slave to play with either .
and like you pointed out: making it rely on an external item is bad.
Eric: could you please give me a code example of a "wait on startup"? what I used is not working.
Thanks!
I am assuming the max time to reboot the switch is under 4 minutes (Wait 2400 ).
So, what happens here is the flag variable will boot up zero until the panel comes online and then get set to 1. In the mean time at the 4 minute mark the program will check the value if the flag. If the network switch was up and working correctly AND the TP was connected to the master, the flag will be 1 and no reboot.
But if 4 minutes goes by and the network switch still hasn't cone up yet the master will reboot and try again.
Here again, I wouldn't do it this way myself. But to at least answer your question here is some code.
We have a winner!!!
Thanks Eric!
I've never used a volatile integer before, awesome sauce!
Back to soldering stuff, Have a swell week!
Sincerely,
John