Specifies the maximum interval for which controller waits before trying again for the subsequent attempt. After trying for the specified count, controller starts again with the loopback IP, resulting into the same initial behavior. It tries to find the IP address for the number of retries that are specified in the parameter. In the case of loopback IP address, if robot_ip is not configured in robot.cfg, then controller tries to get the system IP. Specifies the maximum number of retries that controller can use to find the system IP address. To resolve this issue, two configurable parameters have been added to robot.cfg:
This issue has been resolved in this release. Please refer to to robot (controller) release notes:įixed an issue in which when a robot was unable to find a valid IP address in the robot.cfg or DNS, it was taking the loopback address. If the server or UIM is restarted, then on startup it seems to be fairly likely that the controller will bind to the 169.x.x.x DHCP failure address in this case. It is also common to leave the adapter disconnected from a virtual switch until configured which will prevent it from reaching a DHCP server.
Loopback ip address upgrade#
So it may also still be worth setting the Nimsoft Robot Watcher service to 'Automatic (Delayed Start),' on Windows if the upgrade and parameters listed below do not avoid the issue of the robot taking the loopback or APIPA address.Īdditionally, it is common when adding a virtual adapter in VMware running Windows in that the adapter will initially go live with a default IP configuration which includes DHCP. In some cases, this seems to be caused by a 'race condition' between UIM starting and the network going active.
Rebooting of servers would sometimes bring up the robot using the loopback address (127.0.0.1) on the server.
0 kommentar(er)
