Home AMX User Forum NetLinx Studio

AMX not receiving data string event from TCP connection

Hi,
I'm trying to build a Telnet client from AMX to telnet server running on a mac. I created buffer variable instead of using data.text. In debug, I saw the negotiating data received to the buffer variable. However, there was no data event triggered (I added "send_string 0" in every data event but not seeing it in diagnostics messages). Therefore, AMX won't send any respond to negotiate. Am I missing something?


I have the following codes (note: I created a button push to call the IP_Client_open) :

define_device
myTelnet_device = 0:6:0
myTP = 12001:1:0

define_variable
char telnet_server='10.10.10.1'
char telnet_buffers[50]
integer negotiated=false

define_start
create_buffer myTelnet_device, telnet_buffers

define_event

button_event[myTP, 100]
{
push:
{
ip_client_open(myTelnet_device.port, telnet_server, 23, 1)
}
}

data_event[myTelnet_device]
{
string:
{
// I didn't see following message in diagnostic but I saw data received in telnet_buffers variable from debug.
send_string 0, "'received string: ', telnet_buffers"

if (!negotiated)
{
..... // send_string to tenet_server with negotiation characters
}
}
}

Thanks,
Aldous

Comments

  • ericmedleyericmedley Posts: 4,177
    What firmware are you running on the Netlinx master? I've found the older firmware when used with newer Netlinx Studio produces some odd behavior when it comes to TCP and strings.
  • aldousaldous Posts: 35
    I have an old NXI with ME processor. The firmware is build 117. I didn't upgrade to any later firmware because it requires additional 1.5 MB disk space and I have only 1.1 MB disk space available. If this is firmware issue and I am not able to upgrade to later firmware, anyway to work around?

    Thanks very much
  • ericmedleyericmedley Posts: 4,177
    aldous wrote: »
    I have an old NXI with ME processor. The firmware is build 117. I didn't upgrade to any later firmware because it requires additional 1.5 MB disk space and I have only 1.1 MB disk space available. If this is firmware issue and I am not able to upgrade to later firmware, anyway to work around?

    Thanks very much

    Yeah, you might want to try and install Netlinx Studio before version 3 on another machine and try it then and see what happens. You'll need to do a clean disk command on the master before loading all the files. See if that helps you. I've had to do this on a couple projects on the older masters. I copy/pasted the code into the older NS, compiles, uploaded and it worked just fine.
  • viningvining Posts: 4,368
    Put an "Online & Onerror" handler in you data_event with send_string 0's to see if you're actually making the connection or throwing errors.

    Here the generic IP error function with an example of how to call it:
    DEFINE_FUNCTION CHAR[100] fnGET_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'";
    	  }
         }
    ONERROR:
    	  {
    	 SEND_STRING 0,"'IP CONNECT ERROR: [ ',fnGET_IP_ERROR(TYPE_CAST(DATA.NUMBER)),' ]'" ;
    	  }
    
  • ericmedleyericmedley Posts: 4,177
    vining wrote: »
    Put an "Online & Onerror" handler in you data_event with send_string 0's to see if you're actually making the connection or throwing errors.

    Here the generic IP error function with an example of how to call it:
    DEFINE_FUNCTION CHAR[100] fnGET_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'";
    	  }
         }
    ONERROR:
    	  {
    	 SEND_STRING 0,"'IP CONNECT ERROR: [ ',fnGET_IP_ERROR(TYPE_CAST(DATA.NUMBER)),' ]'" ;
    	  }
    

    You can see this kind of stuff without code by telneting into the master and typing the command 'msg on all'

    Vinning's suggestion is a good one.
  • aldousaldous Posts: 35
    I've put send_string 0 to every data event (online, offline, on error, string). but none of them return anything. However, from diagnostics, I saw "CIPEvent: : Online 0:6:0" which is the telnet server device. Also, I watched the TCP packets between AMX controller and the telnet server. I saw there was open connection and keep-alive packets sending. As soon as the connection opened, I saw "keep-alive" packets sending between AMX and telnet server every minutes or so. So, I'm positive that the connection was made. I'll see if I can find the old version of NS for testing.

    Thanks everyone.

    Aldous
  • ericmedleyericmedley Posts: 4,177
    aldous wrote: »
    I've put send_string 0 to every data event (online, offline, on error, string). but none of them return anything. However, from diagnostics, I saw "CIPEvent: : Online 0:6:0" which is the telnet server device. Also, I watched the TCP packets between AMX controller and the telnet server. I saw there was open connection and keep-alive packets sending. As soon as the connection opened, I saw "keep-alive" packets sending between AMX and telnet server every minutes or so. So, I'm positive that the connection was made. I'll see if I can find the old version of NS for testing.

    Thanks everyone.

    Aldous

    Keep Alive packets do not mean a string is being sent. Does the device send any string to you when you connect to it using a Windows telnet session? (PuttY or Hyperterminal)

    The device might be waiting for you to send a string to it before sending anything.
  • regallionregallion Posts: 95
    Perhaps there's a clash with the Netlinx's own telnet port 23?

    Try another port perhaps?
  • ericmedleyericmedley Posts: 4,177
    regallion wrote: »
    Perhaps there's a clash with the Netlinx's own telnet port 23?

    Try another port perhaps?

    nah... the command says he's going to port 23. But, the NI is probably sending from some port way up high.
  • aldousaldous Posts: 35
    I have done more than just seeing the packets. I captured all the required negotiation string by using computer to computer and created different button events in AMX to send the negotiation string to the telnet server. Then, I pressed the buttons (one by one) to tell the AMX to send the strings. While I was doing this, I saw the string was sent to telnet server and the telnet server was actually responding. By doing this, I was able to reach the Telnet's login prompt. Unfortunately, all the responds from Telnet server didn't trigger any event on AMX. Thanks.
  • regallionregallion Posts: 95
    ericmedley wrote: »
    nah... the command says he's going to port 23. But, the NI is probably sending from some port way up high.

    How on earth did I get that round the wrong way?!
  • AuserAuser Posts: 506
    aldous wrote: »
    I've put send_string 0 to every data event (online, offline, on error, string). but none of them return anything. However, from diagnostics, I saw "CIPEvent: : Online 0:6:0" which is the telnet server device.

    With that behaviour I would personally put a line with
    #WARN 'Socket code being compiled (this is a good thing)'
    
    in and then recompile just to make sure the section of code with your socket handling events is being compiled in.

    It's not impossible that your code is in an .axi that you've inadvertently forgotten to include or that you've got other compiler directives (such as #IF_DEFINED with no corresponding #END_IF) causing that code to be omitted from the compilation.

    Unlikely to be the case, but worth testing...
  • viningvining Posts: 4,368
    Auser wrote: »
    It's not impossible that your code is in an .axi that you've inadvertently forgotten to include or that you've got other compiler directives (such as #IF_DEFINED with no corresponding #END_IF) causing that code to be omitted from the compilation.

    Unlikely to be the case, but worth testing...
    You don't know how many times stupid crap like this has made me bang my head agaisnt a wall. I think a semi-colon directly after a function definition has bit me like this as well. The function never runs and there's no compiler error either.

    The #warn 'xxxx' is a good idea for problems like this that seem to make no sense.
  • aldousaldous Posts: 35
    Auser wrote: »
    With that behaviour I would personally put a line with
    #WARN 'Socket code being compiled (this is a good thing)'
    
    in and then recompile just to make sure the section of code with your socket handling events is being compiled in.

    It's not impossible that your code is in an .axi that you've inadvertently forgotten to include or that you've got other compiler directives (such as #IF_DEFINED with no corresponding #END_IF) causing that code to be omitted from the compilation.

    Unlikely to be the case, but worth testing...

    Thanks for the advise. Just tested with the warning code. Unfortunately, I got the warning.
  • AuserAuser Posts: 506
    aldous wrote: »
    I have an old NXI with ME processor. The firmware is build 117. I didn't upgrade to any later firmware because it requires additional 1.5 MB disk space and I have only 1.1 MB disk space available. If this is firmware issue and I am not able to upgrade to later firmware, anyway to work around?

    Unfortunate, I've got to suspect it is indeed an issue with the older firmware on the NXI-ME based off the information you've given. The easiest resolution that I can think of is to lay your hands on an NI-700 and use that to do the processing, using the NXI as a slave cardframe via master-to-master communications.

    The benefit is that you get a controller with a bunch more memory, more speed and a bigger flash drive. The only change to the code that you **should** need to make is to change the system number of all physical device definitions to point at the NXI.

    I've not dealt with NXI-ME's before, but if they store the OS image and file system on a compact flash card, it would also be possible to clone the existing compact flash onto a larger one and then use a partition manager application to resize the partition(s) to fill the card. You should then be able to install the later firmware.
  • Joe HebertJoe Hebert Posts: 2,159
    aldous wrote: »
    I'm trying to build a Telnet client from AMX to telnet server running on a mac. I created buffer variable instead of using data.text. In debug, I saw the negotiating data received to the buffer variable. However, there was no data event triggered (I added "send_string 0" in every data event but not seeing it in diagnostics messages). Therefore, AMX won't send any respond to negotiate. Am I missing something?

    As a test you can try talking to yourself with this loopback code:
    (***************************************)
    DEFINE_DEVICE
    
    dvServer = 0:3:0
    dvClient = 0:4:0
    
    dvTP = 10001:1:0
    
    (***************************************)
    DEFINE_CONSTANT
    
    INTEGER nTCPPort = 2001
    
    (***************************************)
    DEFINE_VARIABLE
    
    CHAR cServerBuffer[1024]
    CHAR cClientBuffer[1024]
    
    IP_ADDRESS_STRUCT sNetlinx
    
    (***************************************)
    DEFINE_START
    
    CREATE_BUFFER dvServer, cServerBuffer
    CREATE_BUFFER dvClient, cClientBuffer
    
    GET_IP_ADDRESS(0:0:0,sNetlinx)
    
    IP_SERVER_OPEN(dvServer.Port,nTCPPort,IP_TCP)
    IP_CLIENT_OPEN(dvClient.Port,sNetlinx.IPAddress,nTCPPort,IP_TCP)
    
    (***************************************)
    DEFINE_EVENT
    
    BUTTON_EVENT[dvTP,1] {
    
       PUSH: {
          SEND_STRING dvClient,'Hello Server '
       }
    }
    
    DATA_EVENT[dvServer] {
    
       STRING: {
          SEND_STRING 0,"'Data from Client: ',DATA.TEXT"
          SEND_STRING dvServer,'Hello Client '
       }
       
    }
    
    DATA_EVENT[dvClient] {
    
       STRING: {
          SEND_STRING 0,"'Data from Server: ',DATA.TEXT"
       }
       
    }
    

    When you push button 1 you should get the following printout:
    Line      1 (02:30:12)::  Data from Client: Hello Server 
    Line      2 (02:30:12)::  Data from Server: Hello Client
    

    If this test doesn’t work then I agree that it’s most likely a firmware issue.

    If this test does work then I would I would point to your data_event not getting in the event table for one reason or another but we would need to see the actual code you’re using to try and spot the problem.
  • AuserAuser Posts: 506
    Joe Hebert wrote: »
    If this test does work then I would I would point to your data_event not getting in the event table for one reason or another but we would need to see the actual code you’re using to try and spot the problem.

    Good call; a call to rebuild_event() may resolve the issue if the socket device is a variable which is assigned at run time (although that doesn't appear to be the case looking at the code snippet you originally posted).

    As Joe says, if you attach the actual code you're working with we're in the best place to be able to spot any potential issues. More importantly, if you give us complete code we can try it on a master with later firmware to see if the problem is inherent to the firmware build on your NXI-ME.
  • aldousaldous Posts: 35
    Thank you all. unfortunately, I won't be able to go on site until next week. I'll try the test code and post the result when I get there.

    Thanks again to everyone.
  • jimmywjimmyw Posts: 112
    Also, I dont remember what the value actually is, but its something like FIRST_LOCAL_PORT returns somethings around 8 + or so iirc (I just start at 21) so, everything before 0:FIRST_LOCAL_PORT:0 is going to toss errors
  • Joe HebertJoe Hebert Posts: 2,159
    jimmyw wrote: »
    Also, I dont remember what the value actually is, but its something like FIRST_LOCAL_PORT returns somethings around 8 + or so iirc (I just start at 21) so, everything before 0:FIRST_LOCAL_PORT:0 is going to toss errors
    FIRST_LOCAL_PORT = 2
    It’s a constant defined in Netlinx.axi
  • aldousaldous Posts: 35
    Just tested with NS v 2.1 and I saw all the IP client feedback but still not seeing feedback with NS v3.1 and v3.2. So, I think that it is firmware issue. Too bad, I like the new editor in v3 but I have to stay with v2.1. Anyway, thank you everyone here trying to help.

    Aldous
  • AuserAuser Posts: 506
    Wow, bummer. Are you planning on reporting this to AMX? It would be good to let them know so they're aware and they may even decide to implement a fix in a future version of NS3.
  • aldousaldous Posts: 35
    Auser wrote: »
    Wow, bummer. Are you planning on reporting this to AMX? It would be good to let them know so they're aware and they may even decide to implement a fix in a future version of NS3.


    So, I assume that AMX is not monitoring this forum. Would you tell me where to submit this issue to AMX, please

    Thanks
  • jjamesjjames Posts: 2,908
    aldous wrote: »
    So, I assume that AMX is not monitoring this forum. Would you tell me where to submit this issue to AMX, please

    Thanks
    This is not an official tech support forum.

    When you log into your dealer account at www.amx.com - up at the top there is "Tech Center" - click on that, and on the left hand side you'll see a "Tech Support" link; click on it and you'll be able to report your problem that way - or simply call them, but be sure to have your dealer ID ready.
  • aldousaldous Posts: 35
    jjames wrote: »
    This is not an official tech support forum.

    When you log into your dealer account at www.amx.com - up at the top there is "Tech Center" - click on that, and on the left hand side you'll see a "Tech Support" link; click on it and you'll be able to report your problem that way - or simply call them, but be sure to have your dealer ID ready.

    I've sent the email to support. Thank you
Sign In or Register to comment.