Jump to content

linxchas

UniStream & UniLogic Beta
  • Posts

    70
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by linxchas

  1. You have 3 ways to get the remote access to PLC thru internet: 

    1. The easiest is remote access to the computer in same network as PLC - for example  TeamViewer. Just install Visilogic on this machine and you are ready to go. 
    2. Port Forwarding in the router which belongs to the remote network. Here you'll need IT assistance.
    3. Listen mode. (see topic 7780). The most complex, but the best way in case of enterprise application, when you'll need maintain connections to many PLC's (2500 in my case).
  2. In the case of Port forwarding, PLC works the same way as any other PC.

    If you set correctly PFW in the router, and you can connect to PLC locally but not externally, than the most common mistake is wrong Gateway address in PLC.

    Some networks may have multiple gateways (ex: Data & Voice). you have to set PLC to the one, you are using for port forwarding.

     

    P.S.

    Ping is useless to diagnose forwarded devices. The response comes from the router, not from the device.  

  3. I was assuming that the output message is all ASCII.

    If your string is ASCII with control characters in <>, and ASCII variables in [ ], then yes - you are right and your line should work.

    The only concern is a blank space before <STX>. But you can remove it with vector "Shift Left" under vector menu:

     

    shift.JPG

     

     

    For test you have 2 options:

     

    1.  PLC info mode:

    Go to Info Mode->Ethernet->Monitor. Select "Port 2" and you will see every incoming and outgoing packet in ASCII or binary.(In this case you will need to trigger transmission from visilogic debug mode since the display will be used as monitor)

     

    2. "Wireshark" on your PC.


    install your version and run the program

    set the filter as "udp.port == 20257"

    select network interface and click "Start"

     

    You will see all packet broadcasting by PLC to port 20257
  4. OK, here is how standard Modbus slave looks:

     

    Modbus.PNG

     

     

     

    And here how ModBus SCAN can be in your own code (Example for Modbus over TCP, but UDP would be very much the same):

     

    ModbusClone.PNG

     

    Subs 1.ProcessModbusRequest and 3.ComposeModbusResponce should be written based on Modbus protocol description.

    Modbus is a public protocol and description you can find on http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf

    In the sub 2.ValidateModbusRequest you should put your specific validation requirement.

     

    No doubts, this it is a piece of work. But it doable. So you should consider, if your project worth of it.

    You'll probably need a bit of Unitronics help in matter of exact modbus version implemented in the controllers (especially addressing).

    Reverse engineering (sniffer) will be helpful as well.

     

     

    • Upvote 1
  5. Danries,  

     

    On your snapshot i can see only packets from the server, there is no replies from PLC, so it hard to define who  terminated the connection, however from PLC side the only reason may be is a small value of SI105 (Socket 2 TCP/IP Keep Alive (units of 100 msec). Try to set it to SI105=50 (5sec).

    SI143=0 tells that socket configured correctly and SI149=6 - connection was established.

     

    The problem may be on the server side. Borth PLC's trying to connect to the same port (502), but again you can see it only on wireshark snapshot of bi-directional traffic .

×
×
  • Create New...