AMX not receiving data string event from TCP connection
aldous
Posts: 35
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
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
0
Comments
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.
Here the generic IP error function with an example of how to call it:
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.
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.
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.
How on earth did I get that round the wrong way?!
With that behaviour I would personally put a line with 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...
The #warn 'xxxx' is a good idea for problems like this that seem to make no sense.
Thanks for the advise. Just tested with the warning code. Unfortunately, I got the warning.
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.
As a test you can try talking to yourself with this loopback code:
When you push button 1 you should get the following printout:
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.
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.
Thanks again to everyone.
It’s a constant defined in Netlinx.axi
Aldous
So, I assume that AMX is not monitoring this forum. Would you tell me where to submit this issue to AMX, please
Thanks
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