|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||
|
|||
|
Re: LabVIEW Update, Utilities Update, Driver Station Update...which to install and wh
A new (optional) driver station update is available that will ease proper configuration of the driver station laptop's IP configuration (making you more likely to successfully connect to the field). You can find it here: http://joule.ni.com/nidu/cds/view/p/id/2263/lang/en
-Joe |
|
#2
|
||||
|
||||
|
Quote:
Trying to decide if we should consider updating or not... |
|
#3
|
|||
|
|||
|
Re: LabVIEW Update, Utilities Update, Driver Station Update...which to install and wh
Quote:
Joe |
|
#4
|
||||
|
||||
|
Re: LabVIEW Update, Utilities Update, Driver Station Update...which to install and wh
Here's another fun scenario we ran into during testing this past week.
We plugged our netbook into a network this week that had another computer at the same IP address (both static). Windows 7 assigned a new IP address in the 169.XXXXXX range. Going in and changing that back to the correct static address in the tcp/ip properties did nothing. An ipconfig /release /renew did nothing as well. Only changing it to dynamic ip address assignment, then back to static, then adding the correct address would fix it. Windows 7 seems to be a bit dyslexic in this situation. Of course, we couldn't figure it out solely from the driver station window - the driver station couldn't set the IP properly either once this occured but was also not setting any error message. Is there a way to modify the driver station IP assignment code so that it checks that it's successfully been changed? Having it appear to change but not actually change caused us a good 30 minutes of headaches until we logged into the developer account and did an ipconfig to check. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|