Home AMX User Forum NetLinx Studio

Help With Error Messages

Greetings,

I am running into this every time a system running I Schedule tries to time-sync. I have I-Schedule let to the IP of the NIST-a server. Wha is this telling me?

9: 12-30-2006 SAT 17:14:29 Interpreter CIpEvent::OnError 0:3:7
10: 12-30-2006 SAT 17:14:29 Interpreter CIpEvent::OffLine 0:3:711: 12-30-2006 SAT 17:14:29 SocketManager CIpSocketMan::ProcessPLPacket - Socket Already Closed
12: 12-30-2006 SAT 17:14:29 Interpreter Exiting TCP Read thread - closing this socket for local port 3
13: 12-30-2006 SAT 17:14:28 Interpreter CIpEvent::OnLine 0:3:7
14: 12-30-2006 SAT 17:14:28 SocketManager Connected Successfully

Thank you.

Comments

  • viningvining Posts: 4,368
    Put the ONERROR event and the GET_IP_ERROR function in your code so you can see the error number in diagnostics and then determine what type of IP error it is. My guess is your sending an IP_CLIENT_CLOSE when the port is no longer open which is harmless except for the error message it generates. A lot of connections close automatically so sending the close isn't always necassary. So if your not sure just put a condition if front of the close so that it is only sent if you are still online.

    like:
     if (nIP_DeviceOnline)//put where ever it belongs
    	  {
    	  IP_CLIENT_CLOSE (dvIP_Device.port)
    	  }
    

    Put this in your ONERROR data event:
    DATA_EVENT   [dvIP_Device]
         {
         ONLINE:
    	  {
    	  nIP_DeviceOnline = 1 ;
    	  }
    	  OFFLINE:
    	  {
    	  nIP_DeviceOnline = 0 ;
    	  }
    	 ONERROR:
    	  {
    	  if (data.number <> 0) // data.number = 0 -> No error
    	       {
    	       SEND_STRING 0,"'Device ',DEV_TO_STRING(DATA.Device),':',GET_IP_ERROR(DATA.Number),' line-<',ITOA(__LINE__),'>',13,10"
    		   }
    	  }
         STRING:
    	  {
              // nothing
    	  }
         }
     
    

    Put this function some where:
     DEFINE_FUNCTION CHAR[100] GET_IP_ERROR (LONG lERR)
         {
         SWITCH (lERR)
    	  {
    	  CASE 0:
    	       RETURN "";
    	  CASE 2:
    	       RETURN "'IP ERROR (',ITOA(lERR),'): General Failure (IP_CLIENT_OPEN/IP_SERVER_OPEN)'";
    	  CASE 4:
    	       RETURN "'IP ERROR (',ITOA(lERR),'): unknown host (IP_CLIENT_OPEN)'";
    	  CASE 6:
    	       RETURN "'IP ERROR (',ITOA(lERR),'): connection refused (IP_CLIENT_OPEN)'";
    	  CASE 7:
    	       RETURN "'IP ERROR (',ITOA(lERR),'): connection timed out (IP_CLIENT_OPEN)'";
    	  CASE 8:
    	       RETURN "'IP ERROR (',ITOA(lERR),'): unknown connection error (IP_CLIENT_OPEN)'";
    	  CASE 9: // not used
    	       {
    	       RETURN "'IP ERROR (',ITOA(lERR),'): Already closed (IP_CLIENT_CLOSE/IP_SERVER_CLOSE)'";  
    	       }
    	  CASE 10:
    	       RETURN "'IP ERROR (',ITOA(lERR),'): Binding error (IP_SERVER_OPEN)'";
    	  CASE 11:
    	       RETURN "'IP ERROR (',ITOA(lERR),'): Listening error (IP_SERVER_OPEN)'";  
    	  CASE 14: // not used
    	       {
    	       RETURN "'IP ERROR (',ITOA(lERR),'): local port already used (IP_CLIENT_OPEN/IP_SERVER_OPEN)'";
    	       }
    	  CASE 15:
    	       RETURN "'IP ERROR (',ITOA(lERR),'): UDP socket already listening (IP_SERVER_OPEN)'";
    	  CASE 16:
    	       RETURN "'IP ERROR (',ITOA(lERR),'): too many open sockets (IP_CLIENT_OPEN/IP_SERVER_OPEN)'";
    	  CASE 17:
    	       RETURN "'IP ERROR (',ITOA(lERR),'): Local port not open'";
    	  DEFAULT:
    	       RETURN "'IP ERROR (',ITOA(lERR),'): Unknown'";
    	  }
         }
     
    

    Here's the other function:
    DEFINE_FUNCTION CHAR[17] DEV_TO_STRING (DEV dvDEV)
         {
         RETURN "FORMAT('%d',dvDEV.NUMBER),':',FORMAT('%d',dvDEV.PORT),':',FORMAT('%d',dvDEV.SYSTEM)"
         }
    

    I don't know who originated these two functions but they are essential when doing IP communications.
  • The both function were done by me. They create a simple Text message about the ONERROR code number.

    Seems that the error is code 9, which means that a IP_CLIENT_CLOSE() is done but the IP connection is still closed. This is non critical but "not style guide"..... Some older modules are just closing or opening IP connects even though the connection is still closed/opened.
  • DHawthorneDHawthorne Posts: 4,584
    This has been an issue since day one, I've seen it many times. The offline events for a device are not the same as the socket state. I've never quite been able to nail down exactly what the relationship is. One example is timeouts - if you try to make a connection, and it fails, you might get an offline event, but the socket manager hasn't given up and is still considering the connection pending. So subsequent attempts to pen it generate an error. You are seeing the opposite effect - the socket manger has given up and considers the connection closed, but there hasn't been an offline yet.
  • adysadys Posts: 395
    Hi all

    I have the same issue now

    I have Max module and Lutron P5 module on the same master (both IP)

    now I found that the max module generates the folowing messages:

    Line 226 (12:12:21):: CIpEvent::OffLine 0:4:7
    Line 227 (12:12:25):: Connected Successfully
    Line 228 (12:12:25):: CIpEvent::OnLine 0:4:7
    Line 229 (12:12:25):: Exiting TCP Read thread - closing this socket for local port 4
    Line 230 (12:12:25):: CIpEvent::OffLine 0:4:7
    Line 231 (12:12:29):: Connected Successfully
    Line 232 (12:12:29):: CIpEvent::OnLine 0:4:7
    Line 233 (12:12:29):: Exiting TCP Read thread - closing this socket for local port 4
    Line 234 (12:12:29):: CIpEvent::OffLine 0:4:7
    Line 235 (12:12:33):: Connected Successfully
    Line 236 (12:12:33):: CIpEvent::OnLine 0:4:7
    Line 237 (12:12:33):: Exiting TCP Read thread - closing this socket for local port 4
    Line 238 (12:12:33):: CIpEvent::OffLine 0:4:7
    Line 239 (12:12:37):: Connected Successfully
    Line 240 (12:12:37):: CIpEvent::OnLine 0:4:7
    Line 241 (12:12:37):: Exiting TCP Read thread - closing this socket for local port 4
    Line 242 (12:12:37):: CIpEvent::OffLine 0:4:7
    Line 243 (12:12:41):: Connected Successfully
    Line 244 (12:12:41):: CIpEvent::OnLine 0:4:7
    Line 245 (12:12:41):: Exiting TCP Read thread - closing this socket for local port 4
    Line 246 (12:12:41):: CIpEvent::OffLine 0:4:7
    Line 247 (12:12:45):: Connected Successfully
    Line 248 (12:12:45):: CIpEvent::OnLine 0:4:7

    This loop keep going on forever.

    the real problem is that after some time the lutron module stop function...

    I have 3 questions:

    1. Can this error can cause other IP module to lose its connection?
    2. Did someone seen this problem in Max module? its not my code..
    3. I am trying to use vininv solution but gets no "ONERROR" for the ip device....

    Thanks

    Ady.
  • Joe HebertJoe Hebert Posts: 2,159
    adys wrote:
    I have 3 questions:

    1. Can this error can cause other IP module to lose its connection?
    2. Did someone seen this problem in Max module? its not my code..
    3. I am trying to use vininv solution but gets no "ONERROR" for the ip device...
    These entries?
    Netlinx wrote:
    Line 227 (12:12:25):: Connected Successfully
    Line 228 (12:12:25):: CIpEvent::OnLine 0:4:7
    Line 229 (12:12:25):: Exiting TCP Read thread - closing this socket for local port 4
    Line 230 (12:12:25):: CIpEvent::OffLine 0:4:7
    Line 231 (12:12:29):: Connected Successfully
    Line 232 (12:12:29):: CIpEvent::OnLine 0:4:7
    Line 233 (12:12:29):: Exiting TCP Read thread - closing this socket for local port 4
    Line 234 (12:12:29):: CIpEvent::OffLine 0:4:7

    ?are not error messages. They are ONLINE/OFFILINE messages for an IP device that is connecting and disconnecting successfully on port 4 every 4 seconds.
  • adysadys Posts: 395
    Thanks

    So any idea why lutron module is loosing the connection after few hours (only lutron)?
  • Joe HebertJoe Hebert Posts: 2,159
    adys wrote: »
    Thanks

    So any idea why lutron module is loosing the connection after few hours (only lutron)?
    No idea, sorry.
  • viningvining Posts: 4,368
    Is it possible that on start up the module sends the proper login & pasword but if it falls offline and attemps to reconnect due to the offline event the login / password step is ommitted or not the same user name/password is sent. You would then genarate an online event the login would fail and you go offline and this repeats over and over again.
  • adysadys Posts: 395
    But I am doing login upon online event:


    ONLINE:
    {

    wait 50
    {
    SEND_COMMAND vdvLights, "'PROPERTY-IP_Address,192.168.10.151'"
    SEND_COMMAND vdvLights, "'PROPERTY-port,23'"
    SEND_COMMAND vdvLights, "'PROPERTY-Login,amx,control'"
    //SEND_COMMAND vdvLights, "'PROPERTY-Login,LutronGUI,jetski'"
    SEND_COMMAND vdvLights, "'reinit'"

    send_string 0, 'Netlinx Virtual Device ONLINE.'

    wait 50
    {
    wait 5 SEND_COMMAND vdvLights,"'LUTRONKEYPADADD-1,[1:8:7]'" // salon

    wait 10 SEND_COMMAND vdvLights,"'LUTRONKEYPADADD-2,[2:4:19]'" // virtual keypad of cinema

    wait 15 SEND_COMMAND vdvLights,"'LIGHTADD-3,[1:1:0:7:3]'" // virtual keypad of cinema

    wait 20 SEND_COMMAND vdvLights,"'LIGHTADD-4,[1:1:0:7:4]'" // virtual keypad of cinema

    wait 25 SEND_COMMAND vdvLights,"'LIGHTADD-5,[1:1:1:1:3]'" // virtual keypad of cinema


    // 1-5 preset, 10 off, 23,24 up down.

    }
    }
    }
  • viningvining Posts: 4,368
    The strings passed to the virtual device should be case sensitive and I noticed in your code reinit is lower case and in the word doc they are all upper case. That is if you're using the latest duet module.
    SEND_COMMAND vdvLights, "'REINIT'" 
    
    I would also take out the wait after the online event and send the the commands to the virtual right away although it shouldn't matter since it won't take affect until the REINIT is sent.

    I would add the the online event:
    SEND_COMMAND vdvLights, "'PASSBACK-1'" 
    
    and create a buffer for the device and see for yourself what the problem may be.
  • adysadys Posts: 395
    vining wrote: »
    The strings passed to the virtual device should be case sensitive and I noticed in your code reinit is lower case and in the word doc they are all upper case. That is if you're using the latest duet module.
    SEND_COMMAND vdvLights, "'REINIT'" 
    
    I would also take out the wait after the online event and send the the commands to the virtual right away although it shouldn't matter since it won't take affect until the REINIT is sent.

    I would add the the online event:
    SEND_COMMAND vdvLights, "'PASSBACK-1'" 
    
    and create a buffer for the device and see for yourself what the problem may be.


    Thanks Vav

    I got this code from the supprot! so I didn't suspect that something can be wrong...

    I will try "'PASSBACK-1'"
Sign In or Register to comment.