Home› AMX User Forum› NetLinx Studio

Weird TCP comms issue

regallionregallion Posts: 95
in NetLinx Studio
Hi guys,

Have any of you come across strange TCP/IP issues like this?

I have a very simple test app that sends pings to a media server (DFS Base). The player should receive these ping requests and respond.

My AMX controller, however, only picks up the responses rarely. If it receives the response, it will continue to receive the responses for the duration of the program run. If I re-run the app and it doesn't receive the response - it won't receive any for the duration of the program run.

I see the same issues with the company's own AMX driver as well.

I've run this test app (and their driver) on two separate AMX controllers to the same effect.

I've taken the AMX test code and converted it to Visual Basic and it runs 100% of the time.
I've taken this test code and converted it to run on a Cue controller and it runs 100% of the time.

I wrote an emulator in VB to respond to ping requests and the AMX test code works 100% of the time.

So what we have here is some bizarre issue between the media player and AMX controllers?! I've upgraded firmware to no avail.

I'm pulling my hair out here and grateful for any sources of inspiration!

For interest, here's the test AMX code:
PROGRAM_NAME='TestMain'


DEFINE_DEVICE
dvBaseIP1 = 00:03:00


DEFINE_VARIABLE
VOLATILE CHAR rxBuffer[4096]
VOLATILE INTEGER connected
VOLATILE INTEGER count

DEFINE_START

// I've tried this both with CREATE_BUFFER and using data.text - both have same issue
//CREATE_BUFFER dvBaseIP1, rxBuffer

WAIT 50
    IP_CLIENT_OPEN(dvBaseIP1.PORT, '192.168.67.33', 6002, IP_TCP)



DEFINE_EVENT

DATA_EVENT[dvBaseIP1]
{
    ONLINE:
    {
	SEND_STRING 0:1:0, "'DATA_EVENT[ONLINE]:'"
	connected = 1
    }


    OFFLINE:
    {
	SEND_STRING 0:1:0, "'DATA_EVENT[OFFLINE]:'"
	connected = 0
    }

    STRING:
    {
	STACK_VAR CHAR rx[4096]

	rx = data.text //rxBuffer
	SEND_STRING 0:1:0, "'DATA_EVENT[STRING]: (', ITOA(LENGTH_ARRAY(rxBuffer)),') ', rx"

	//CLEAR_BUFFER rxBuffer
    }

    ONERROR:
    {
	SEND_STRING 0:1:0, "'DATA_EVENT[ONERROR]: ', ITOA(data.number)"
    }
}


DEFINE_PROGRAM

if(connected)
    WAIT 50
    {
	count++
	if(count > 5)
	{
	    IP_CLIENT_CLOSE(dvBaseIP1.PORT)
	    SEND_STRING 0:1:0, "'Done'"
	}
	else
	{
	    SEND_STRING 0:1:0, "'Ping: ', ITOA(count)"
	    SEND_STRING dvBaseIP1, "'*[Ping][][][][][][][][][][][][]#', $0D,$0A"
	}
    }

Comments

  • jjamesjjames Posts: 2,908
    Try increasing your WAIT time in DEFINE_START to 10 seconds & see if that helps. Are you sure it is actually online and not receiving the data? Also, use length_string() rather than length_array().
  • regallionregallion Posts: 95
    Yeah I've tried that - up to a minute.

    If you look at the code closer, you'll see the LENGTH_ARRAY isn't actually doing anything.

    I know the comms is working (code wise) as it does work sometimes.

    I guess I'm asking if anyone has had similar issues before with firmware bugs or specific network cards in pcs or IP stack problems etc. There's a real odd niggly incompatibility with AMX controllers and this box and it's real pig tying it down.

    I've had the developer of the media server look into it and he's putting some low level debug code onto my server to help find the issue.

    I'll post if it's anything interesting!!
  • jjamesjjames Posts: 2,908
    regallion wrote: »
    Yeah I've tried that - up to a minute.

    If you look at the code closer, you'll see the LENGTH_ARRAY isn't actually doing anything.
    Ahh - right, quick saw length_array(rx....) and didn't read further.

    I've not actually seen issues like what you're describing, but a call into tech support probably wouldn't hurt.
  • viningvining Posts: 4,368
    regallion wrote: »
    Hi guys,

    Have any of you come across strange TCP/IP issues like this?

    I have a very simple test app that sends pings to a media server (DFS Base). The player should receive these ping requests and respond.

    My AMX controller, however, only picks up the responses rarely. If it receives the response, it will continue to receive the responses for the duration of the program run. If I re-run the app and it doesn't receive the response - it won't receive any for the duration of the program run.

    I see the same issues with the company's own AMX driver as well.

    I've run this test app (and their driver) on two separate AMX controllers to the same effect.

    I've taken the AMX test code and converted it to Visual Basic and it runs 100% of the time.
    I've taken this test code and converted it to run on a Cue controller and it runs 100% of the time.

    I wrote an emulator in VB to respond to ping requests and the AMX test code works 100% of the time.

    So what we have here is some bizarre issue between the media player and AMX controllers?! I've upgraded firmware to no avail.

    I'm pulling my hair out here and grateful for any sources of inspiration!

    For interest, here's the test AMX code:
    PROGRAM_NAME='TestMain'


DEFINE_DEVICE
dvBaseIP1 = 00:03:00


DEFINE_VARIABLE
VOLATILE CHAR rxBuffer[4096]
VOLATILE INTEGER connected
VOLATILE INTEGER count

DEFINE_START

// I've tried this both with CREATE_BUFFER and using data.text - both have same issue
//CREATE_BUFFER dvBaseIP1, rxBuffer

WAIT 50
    IP_CLIENT_OPEN(dvBaseIP1.PORT, '192.168.67.33', 6002, IP_TCP)



DEFINE_EVENT

DATA_EVENT[dvBaseIP1]
{
    ONLINE:
    {
	SEND_STRING 0:1:0, "'DATA_EVENT[ONLINE]:'"
	connected = 1
    }


    OFFLINE:
    {
	SEND_STRING 0:1:0, "'DATA_EVENT[OFFLINE]:'"
	connected = 0
    }

    STRING:
    {
	STACK_VAR CHAR rx[4096]

	rx = data.text //rxBuffer
	SEND_STRING 0:1:0, "'DATA_EVENT[STRING]: (', ITOA(LENGTH_ARRAY(rxBuffer)),') ', rx"

	//CLEAR_BUFFER rxBuffer
    }

    ONERROR:
    {
	SEND_STRING 0:1:0, "'DATA_EVENT[ONERROR]: ', ITOA(data.number)"
    }
}


DEFINE_PROGRAM

if(connected)
    WAIT 50
    {
	count++
	if(count > 5)
	{
	    IP_CLIENT_CLOSE(dvBaseIP1.PORT)
	    SEND_STRING 0:1:0, "'Done'"
	}
	else
	{
	    SEND_STRING 0:1:0, "'Ping: ', ITOA(count)"
	    SEND_STRING dvBaseIP1, "'*[Ping][][][][][][][][][][][][]#', $0D,$0A"
	}
    }

    Is this "Ping" a device specific command or are you actually trying to ping this IP device? Any time I've tried to ping a device I open a telnet session with the master via code and issue "ping URL".

    Regardless I don't think I'd do this through define_start at all but use a button event to trigger the IP_CLIENT_OPEN so I can push it as many times as I like, when I like. Mainly cuz I'm too slow to catch it as the system comes online, especially with a short wait. With a longer wait I might stand a chance but typically if I open a socket from define_start I usually wait a few minutes to give the system time to settle down.

    For testing I would just create a button_event and the use control device or emulate device to simulate a TP push.
  • regallionregallion Posts: 95
    Yes the "Ping" is device specific protocol - I have the same result with any of it's commands.

    And I've also tried putting the calling code behind a button event as well.

    And I've done it within a timeline!

    I distilled the test down to it's most simplest form here just to eliminate any other factors but believe me I've tried everything!!

    I maintain there's something "odd" with this particular device and AMX controllers because I've duplicated the client code in Visual Basic and a Cue controller and it works fine. I've also duplicated the device with an emulator I wrote and ran on the my PC and the AMX client works fine.

    It's infuriating!

    EDIT: By the way I appreciate your time guys - keep the ideas coming!!!
  • viningvining Posts: 4,368
    Try this and see what happens. In your code you have the wait 50 after the check to see if the socket is connected and by the time the wait executes the socket may have closed already so try just using the CTS flag like shown and maybe it's just an IP timing issue. Maybe you're sending when the sockets closed, of course if that were the case you should get that error in diagnostics too. I would also move your IP_CLIENT_OPEN back to a button event and try this after the system has settled down and everything else is quite so you can see the timing of the send_string 0's in diagnostics a little clearer.

    That's all I can think of but maybe if you post what prints we could help some more.
     PROGRAM_NAME='TestMain'


DEFINE_DEVICE

dvBaseIP1 = 00:03:00

DEFINE_CONSTANT

CHAR DEV_TX_CTS          	= 0 ;
CHAR DEV_TX_BUSY         	= $FF ;
CHAR DEV_CTS_TIMEOUT		= 30 ;  //delay  

DEFINE_VARIABLE

VOLATILE CHAR rxBuffer[4096]
VOLATILE INTEGER connected
VOLATILE INTEGER count
VOLATILE CHAR nCTS 		= 0 ;

DEFINE_FUNCTION fnDEV_CTS()

     {
     CANCEL_WAIT 'DEV_CTS_TIMEOUT' ;
     nCTS = DEV_TX_CTS ;
     }  

DEFINE_START

// I've tried this both with CREATE_BUFFER and using data.text - both have same issue
//CREATE_BUFFER dvBaseIP1, rxBuffer

WAIT 50
    IP_CLIENT_OPEN(dvBaseIP1.PORT, '192.168.67.33', 6002, IP_TCP)



DEFINE_EVENT

DATA_EVENT[dvBaseIP1]
{
    ONLINE:
    {
	SEND_STRING 0:1:0, "'DATA_EVENT[ONLINE]:'"
	connected = 1
    }


    OFFLINE:
    {
	SEND_STRING 0:1:0, "'DATA_EVENT[OFFLINE]:'"
	connected = 0
    }

     STRING:
	 {
	  STACK_VAR CHAR rx[4096]
     
	  rx = data.text //rxBuffer
	  SEND_STRING 0:1:0, "'DATA_EVENT[STRING]: (', ITOA(LENGTH_ARRAY(rxBuffer)),') ', rx"
	  fnDEV_CTS() ;//for now set CTS regardless of what comes in
	  //CLEAR_BUFFER rxBuffer
	  }

    ONERROR:
    {
	SEND_STRING 0:1:0, "'DATA_EVENT[ONERROR]: ', ITOA(data.number)"
    }
}


DEFINE_PROGRAM

if(connected && nCTS == DEV_TX_CTS)
     {
     count++
     if(count > 5)
	  {
	  IP_CLIENT_CLOSE(dvBaseIP1.PORT)
	  SEND_STRING 0:1:0, "'Done'"
	  connected = 0 ;// expidite this flag to prevent continued running until the offline actually occurs
	  }
     else
	  {
	  SEND_STRING 0:1:0, "'Ping: ', ITOA(count)"
	  SEND_STRING dvBaseIP1, "'*[Ping][][][][][][][][][][][][]#', $0D,$0A"
	  nCTS = DEV_TX_BUSY ;
	  WAIT DEV_CTS_TIMEOUT 'DEV_CTS_TIMEOUT'
	       {
	       fnDEV_CTS() ;
	       }
	  }
     }
  • DHawthorneDHawthorne Posts: 4,584
    I concur that it is likely a timing issue. AMX network ports seem to have a strange set of rules about connect and disconnect timing that is completely undocumented, and to make matters worse, they require you to manage things that other NICs do automatically.
  • regallionregallion Posts: 95
    Thing is I've not seen this issue with other devices.

    Anyway the developer of the kit upgraded my server to their latest beta version and the problem went away.

    You guys have given me food for thought though regarding the timing - for which I thank you all for your time!!
Sign In or Register to comment.