IP Device Falling Offline

TurnipTruck

I have an IP controlled device that falls offline at random times. I am running known-good code, used in many other systems with no problems

I am noticing that it takes longer to come online than usual. Here are the internal messages at boot-up. The device in question is 0:5:14. I have no log of what happens when it goes offline at this point.

Any suggestions appreciated.

Line 1 (17:25:18):: UNKNOWN HOST: utcnist.colorado.edu
Line 2 (17:25:18):: ClientOpen mxInetAddr or hostGetNyName error 0x0
Line 3 (17:25:18):: CIpSocketMan::ProcessPLPacket - Socket Already Closed
Line 4 (17:25:18):: CIpSocketMan::ProcessPLPacket - Socket Already Closed
Line 5 (17:25:18):: CIpEvent::OnError 0:3:14
Line 6 (17:25:18):: CIpSocketMan::ProcessPLPacket - Socket Already Closed
Line 7 (17:25:18):: CIpEvent::OnError 0:5:14
Line 8 (17:25:18):: CIpEvent::OnLine 0:5:14
Line 9 (17:25:18):: CIpEvent::OnError 0:3:14
Line 10 (17:25:18):: CIpEvent::OnError 0:3:14

John Nagy

TurnipTruck wrote: »

I have an IP controlled device that falls offline at random times. I am running known-good code, used in many other systems with no problems

I am noticing that it takes longer to come online than usual. Here are the internal messages at boot-up. The device in question is 0:5:14. I have no log of what happens when it goes offline at this point.

Any suggestions appreciated.

Line 1 (17:25:18):: UNKNOWN HOST: utcnist.colorado.edu
Line 2 (17:25:18):: ClientOpen mxInetAddr or hostGetNyName error 0x0
Line 3 (17:25:18):: CIpSocketMan::ProcessPLPacket - Socket Already Closed
Line 4 (17:25:18):: CIpSocketMan::ProcessPLPacket - Socket Already Closed
Line 5 (17:25:18):: CIpEvent::OnError 0:3:14
Line 6 (17:25:18):: CIpSocketMan::ProcessPLPacket - Socket Already Closed
Line 7 (17:25:18):: CIpEvent::OnError 0:5:14
Line 8 (17:25:18):: CIpEvent::OnLine 0:5:14
Line 9 (17:25:18):: CIpEvent::OnError 0:3:14
Line 10 (17:25:18):: CIpEvent::OnError 0:3:14

Isn't IP port 5 dedicated internally for the time update? I know we avoid ports 0-8 as internal use, we start at 10 for things we attach. If I'm not way off here, the attempt to do the time update (every 2-4 hours) uses port 5 to do it. Note that your log starts with the failed time lookup. Try a port above 8.

John Gonzales

Since code is good and functioning on other systems, here are my guesses:
1) Could be DNS resolution error
2) Could be firewall rule at switch/router blocking WAN access.

-John

vining

Usually the unknown host means your not resolving DNS properly. I would check the master and set the DNS to your gateway routers IP.

Usually only ports 1 & 2(?) are reserved for use by the master. I start my usage at 3.

jjames

vining wrote: »

Usually only ports 1 & 2(?) are reserved for use by the master. I start my usage at 3.

Same here. I was told (or maybe read somewhere?) that 1 and 2 are reserved, and I typically start at 3 as well.

PhreaK

On a vanilla AMX box (ie not running and 'solutions' or third party software) port 1 is used by the master, port 2 is reserved for "future use" and port 3 and up are fair game (as far as I know). Sounds like a network config issue, either at the AMX box end with DNS / gateway settings, or within the network infrastructure (firewall etc).

shr00m-dew

PhreaK wrote: »

On a vanilla AMX box (ie not running and 'solutions' or third party software) port 1 is used by the master, port 2 is reserved for "future use" and port 3 and up are fair game (as far as I know). Sounds like a network config issue, either at the AMX box end with DNS / gateway settings, or within the network infrastructure (firewall etc).

If that's true, that's another reason to not use FIRST_LOCAL_PORT, as it's set to 2.

Kevin D.

vining

shr00m-dew wrote: »

If that's true, that's another reason to not use FIRST_LOCAL_PORT, as it's set to 2.

Kevin D.

I think the intent of FIRST_LOCAL_PORT was to act as a base for addition. Like FIRST_LOCAL_PORT + 1 to equal the first port used (port 3) or FIRST_LOCAL_PORT + 2 to equal the sencond port used (port 4), etc and not to be used all by itself. I'm sure when they created the Netlinx.axi it made sense to the creator but I think he's the only one that would find it useful. Not to knock on the creator since I tend to do stupid $hit like that too sometimes and never go back to remove it even after I realize how stupid it really is.

shr00m-dew

vining wrote: »

I think the intent of FIRST_LOCAL_PORT was to act as a base for addition. Like FIRST_LOCAL_PORT + 1 to equal the first port used (port 3)

No one told the help file guy:

To make sure that this IP device naming convention does not interfere with future naming schemes, a range of numbers are reserved for local port numbers. The program must only assign local port numbers at or above the value of the keyword, FIRST_LOCAL_PORT. For example,

DEFINE_CONSTANT
PORT_REMOTE_MASTER1 = FIRST_LOCAL_PORT
PORT_REMOTE_MASTER2 = FIRST_LOCAL_PORT + 1
PORT_REMOTE_MASTER3 = FIRST_LOCAL_PORT + 2

All port numbers below FIRST_LOCAL_PORT are reserved for future use.

I don't use it, but it's crazy how it exists being how bad it can be (when used in compiled modules). I suppose if they ever start using port 2 for something, a new version of NS will come out and change FIRST_LOCAL_PORT to 3.

Any one know if the master allocates ports up to the max like the touch panels do? IE, if I start at 0:10:0, does 2-9 get created automatically?

Kevin D.

TurnipTruck

Thanks guys.

I was taught that port 3 is the first usable port for our purposes as well. In the case of my problem system, port 3 is the iTime manager, and port 5 is my problem device. There are no other IP devices, hardware or virtual in the system.

I also avoid first_local_port. I beleive I was discouraged of using it in my PII class way back when.

Further, I never define devices (or ports) in modules. That completely defeats the purpose of making modules that are portable and reusable.

vining

Did you resolve the problem?

TurnipTruck

I replaced the network switch and cables that seperate the NI from the controlled device. I'm checking the obvious before going any deeper.

DHawthorne

There are a couple things going on here. First off, it's been my experience that any NIST server can vanish for a while and come back. I don't know if they are sharing the task on different servers, and the DNS is taking a while to catch up, or if they get overloaded and reject connections. I just know they often aren't available for a while, then will work just fine.

The other errors are just normal IP connections stuff. A connection will often break before fully recognized by the master, which is where that socket error comes from. That will settle down in a few seconds.

true

I've had NIs fail an immediate reconnection to a hostname that was just successfully connected to and disconnected from. They seem to be finicky about DNS and don't seem to cache queries.

AMXJeff

Only Port 1 is reserved, that is the master device port. The masters time manager does not use these Netlinx socket ports.

This constant is available for assignment.

INTEGER FIRST_LOCAL_PORT = 2;

// example
dvSocket1 = 0:FIRST_LOCAL_PORT:0
dvSocket2 = 0:FIRST_LOCAL_PORT+1:0