Home AMX User Forum NetLinx Studio

Terminal connection

I shoud use IP comunication to control cameras connected to "other control system".

I can control it from Putty , just by sending
$1001

when i pres RETURN camera goes to Preset 1.

HOW to send string to 'it' to control that camera ????

Comments

  • Spire_JeffSpire_Jeff Posts: 1,917
    I think you want to look at the IP_CLIENT_OPEN command. You can create an IP connection to the device and then use SEND_STRING.

    Jeff
  • VladaPUBVladaPUB Posts: 138
    I have IP_CLIENT_OPEN, but seems that problem is with connection.

    Have you any idea ?
  • Spire_JeffSpire_Jeff Posts: 1,917
    Instead of using putty, try using telnet. If telnet does not work, I don't think IP_CLIENT_OPEN will work.

    Also, verify that the connection is using the correct port.

    Jeff
  • VladaPUBVladaPUB Posts: 138
    I have try, telnet work !
  • Spire_JeffSpire_Jeff Posts: 1,917
    Can you post the code you are trying to use to talk to the device? If telnet works, IP_CLIENT_OPEN should work.

    Jeff
  • AuserAuser Posts: 506
    VladaPUB wrote:
    I can control it from Putty , just by sending
    VladaPUB wrote: »
    I have try, telnet work !

    That may be the problem. A telnet connection is NOT the same as a raw socket connection. Try connecting with Putty with the connection type set to "Raw". If this does not work, it implies that the remote device is expecting telnet negotiation.

    If this proves to be the issue, it is reasonably easy to implement telnet negotiation by answering the device with "I won't" when it requests that you turn on a telnet feature. There should be some good references to the telnet protocol out there on the web.
  • VladaPUBVladaPUB Posts: 138
    Auser wrote: »
    That may be the problem. A telnet connection is NOT the same as a raw socket connection. Try connecting with Putty with the connection type set to "Raw". If this does not work, it implies that the remote device is expecting telnet negotiation.

    If this proves to be the issue, it is reasonably easy to implement telnet negotiation by answering the device with "I won't" when it requests that you turn on a telnet feature. There should be some good references to the telnet protocol out there on the web.


    How to solve that ???
  • VladaPUBVladaPUB Posts: 138
    I am opening connection like this :
    DATA_EVENT[0:1:0]
    {
      ONLINE :
      {
       IP_CLIENT_OPEN(dvCameraControl.PORT,'192.168.16.120',4001,IP_TCP)
      }
    }
    
    and trying to send string like :
    DATA_EVENT[dvCameraControl]
    {
        ONLINE:
                {
                WAIT 100
                SEND_STRING dvCameraControl,"'$1001',13,10"
                }
    
    }
    
    
  • viningvining Posts: 4,368
    Put the IP_CLIENT OPEN behind a button push for now so you can watch what happens in diagnostics. Connecting when the mast comes online you likely won't see anything unless you're really, really, really fast.

    Try eliminating the wait in th eonline event cuz it's possible the connection is timing out before you send. Not likely but possible. Tthe device may also maintain the connections so an initial connection when in define_start behind a long wait may be the way to go when this actually starts working.

    Port 4001? What port were you using in PuTTy? Telnet is 23 so what's 4001, how about a link to the protocol. Also create a buffer for the port so you can see what strings are coming in. You may be receiving a challenge that you need to respond to.

    Put some send_string 0's in so you can see when you send the IP_CLIENT OPEN and when (if) you get an ON_LINE event.
  • VladaPUBVladaPUB Posts: 138
    vining wrote: »
    Port 4001? What port were you using in PuTTy?

    Also 4001 !! Putty is set to TELNET connection.
    vining wrote: »
    how about a link to the protocol.

    I dont have protocol, I only have commands to send, like :
    $1001
    
    or
    $1029
    
  • VladaPUBVladaPUB Posts: 138
    Is there posibility that is a UDP port ???
  • jweatherjweather Posts: 320
    No, it's not UDP. Set PuTTY to raw mode and see if it still connects. If not, then the problem is telnet negotiations. Use Wireshark or a similar product to see the actual traffic between PuTTY and the device. Replay the same responses when you get those messages (generally starting with $FF if I remember correctly), and you should be good. You may also be able to simplify the responses by sending negative responses, but that may be too much trouble and requires understanding the telnet protocol.
Sign In or Register to comment.