Options
Default IP adress of NI ?
wilsoncarter
Posts: 15
i have a really dumb question that, what is the default IP adress of the NIs?
since i am using vista and bafo usb to com cable which can't work with the cross cable, if i know thw default IP of the NIs, i can simply just connect my lan cable for intial set up.
any expert please help me.
since i am using vista and bafo usb to com cable which can't work with the cross cable, if i know thw default IP of the NIs, i can simply just connect my lan cable for intial set up.
any expert please help me.
0
Comments
They come out of the box set to DHCP. So, if it's new, you might try looking at the table on the router.
You can always plug into the program port with an rs232 cable and connect that way to get the IP address.
Now playing: Death In Vegas - So You Say You Lost Your Baby
via FoxyTunes
You should also be able to use Bonjour to get the IP.
Hope this helps,
Jeff
P.S.
Another option would be to go into the router or whatever is serving the DHCP server and check the client list to see what IP was assigned to the processor.
Most new laptops will detect if you connect directly to a device, and will handle the cross over automatically. Older laptops would not do this and you would need a cross over cable.
Thx for the replies, Jeff's method is basically what i need =.=v since i will go into site for the program loading and the system configuring, all i need to do is bring a DHCP router plug in the switched hub then there i go.
but i am just wondering, y not havn't a fixed default IP? it will make things simpler, when even using DHCP, u need to connect master one by one anyway since u will not know the DHCP will assign what IP to who, right?
rs232 connection is always a problem for new laptops, usb to com cable is always not a trustable connection, for example i use bafo BF-810, even they have driver for vista, and the cable worked for hyper terminon, but they are not working with AMX's comunactaion. SIF, however XP is working perfectly.
I think one of the main reasons is that if you have a fixed IP and plug it into an already established network that is running the same IP address range you risk creating an address conflict, which for some reason tends to make most network admins quite angry.
New masters such as the 3101 have done away with the rs-232 program port and instead have a usb port which connects to an internal rs-232 adapter. I think this is a nice step however I would love to see an internal bluetooth to rs-232 adapter for initial configuration, the hardware that you need for this is incredibly cheap and just about every new laptop has a bluetooth interface which supports a standard bluetooth serial profile now days.
This of course would be if the router allows it.
Potential security risk I suspect. I wouldn't want to leave a bluetooth connection discoverable on a master, whether it was secured or not... I'm sure something like that will be the norm one day, but I don't think we're ready for it yet.
That would definately be the one major disadvantage of it. Nothing that couldn't be fixed by a dip switch on the master though.
Studio3 has this feature if Bonjour is installed.
Agreed. We do a fair amount of work in secure environments, and the security officers in such places generally *never* allow such things in their facilities. Ditto wireless touchpanels, wireless mics, etc.
On IP addresses, you can't always count on any given network having a DHCP server (although most do nowadays). Further, some DHCP servers are configured to only give out IPs to MAC addresses that they already know; so without prior arrangements, Joe Random Netlinx will not get an IP even if a DHCP server is running.
Using Static DHCP is an option like I had posted earlier, especially when you are setting up the router, or can get the network administrator to make those changes for you.
I'm using it on an upcoming job, and think it'll work nicely. Simple steps really:
1) Put MAC address in router & designate an IP.
2) Give master to technician and install.
Right, and it's actually a rather good option. But it's not always feasible. My corporate clients tend not to want me mucking around with their server configurations, and rightly so (and who wants to be "the last guy that touched it", anyway?) If there's a router between my AMX stuff and the client's LAN, then we've just offset this problem to my router rather than the NI itself.
At least I don't hear "get that sh!t off my network" much anymore :^P
True, I didn't think about the commercial aspect. I wonder if you could set the IP address via code (through a telnet connection.)
Hmmm . . .
Yes, you can. If you mean through Netlinx code itself, it's possible to do through a telnet connection (although I've never tested programming a master to telnet to its loopback address, which you'd have to do before it had a known IP). There is also a SET_IP_ADDRESS() function that allows you to set the IP on the master, just use that and reboot. I've used that in a sort of homebrew redundancy solution that I had to work up once.
On another note, I really wish that if the controllers are to be set for DHCP out of the box that they would support link-local addresses (the 169.254.x.x address that your computer shows when it doesn't receive an address from a DHCP server). Basically, it exists to help in just this type of situation. Also known in the Microsoft world as Automatic Private IP Addressing, it allows for two or more hosts that are on the same network segment and set to DHCP to communicate with one another after their DHCP requests time out. I don't see any real reason for AMX not to support this, and it is certainly a helpful feature in certain circumstances, but perhaps they do have a reason why they have stayed away from it. Just for fun, you can read more about it at RFC 3927 if you wish.
I've done this and it works fine. Early on before AMX came up with Remote Manager I worked at a University where we rolled our own RM system. One of the problems we had was the M2M URL would change.
I had written a routine on the remote masters to seek out the lost mothership and , when found, rewrite it's URL ip address to it. It worked pretty well until an NI firmware upgrade ditched the Set_URL command set. My code quit working and old working project would no longer compile.
I wrote a worksround that would make the master telnet into itself and change it's url that way. All my anger at Amx was dispelled by the joy of getting that clunky thing working.
The set_URL commands were back with the next firmware and build of NS. So, I put it all back.
1) If there is any kind of router or DHCP glitch, the components can still find each other (I have seen this a lot)
2) Many devices won't let you connect to a namespace, it has to be an IP number. If it's not static, it may not work next reboot.
I have no difficulty temporarily re-assigning my computer IP to match the subnet of my devices if they aren't talking; the only real problem is when you don't know what the subnet is.
When working in the field a useful way to cope with DHCP is to set up tftpd32.exe as a DHCP server on your laptop. It's freeware from http://tftpd32.jounin.net/ Then plug the AMX directly into your laptop (with crossover if required), reboot it, and the laptop will server IP addresses to DHCP clients like the AMX. You even see what the IP address is in tftpd32.exe. This makes it easy to work with a DHCP AMX, provided that it doesn't require other IP services. (If an IP TouchPanel is involved, make a temporary isolated network with a dumb hub/switch.) If the hardware doesn't pick up an IP on reboot, it gives you a good clue that it is set to static IP, in which case I would then try the "Listen" option in NLS.
Failing that, the Keyspan USB->RS232 dongle is sufficient for sorting out the static/DHCP config of the master.
Once it is all configured, I plug it all back into the main network, reboot & test. Remember that if there is no DHCP service running on the network, a DHCP AMX will "pause" for and extra 40-80(?) seconds on bootup while waiting for an address.
Roger McLean
Swinburne University
I'm not sure about doing this with the TPs though and often match them static instead just to minimize the time they take to come back onlne after a nap or reboot. Even during regular use if they drop the connection they just seem to hang in limbo wasy to long, waitng for DHCP? Or just plain flaky, I don't know.
All our wired TPs (CV7/700vi) use sticky DHCP. Current firmware seems to be quite okay with DHCP.