No announcement yet.

RX over network P2000

  • Filter
  • Time
  • Show
Clear All
new posts

  • RX over network P2000

    having trouble with tags , i have 2 p2000 on a network and can see and talk with both , need to get a 4 -20 analog signal reading from on to the other using RX , any ideas or examples would be great thanks

  • #2
    I'm a big fan of the Network Read (RX) instruction. It's proprietary to PxK, but it works AWESOME.

    Get the program done on the P2K that has the analog card on it (lets call it the slave). On the master P2K, use the RX instruction to read the slave PLC. Slap in the IP, read the slave's program file, map the tags, done. By far the easiest way to get PxK's to talk to each other, IMO.


    • #3
      Have you looked at ProNet option?
      Publisher side ( PLC with analog module)

      1) create publisher and use "CPU In Run" for Enable and enter tag for duplicate
      2) Create an array tag that is same datatype and as many columns as you have channels on the analog module (or however many you wish to transfer)
      3) Use CPD instruction in ladder to copy Analog channels to array tags

      Subscriber side ( PLC without analog module)

      1) Create subscriber listening for global ID of the publisher you created in the other plc and use "CPU In Run" for enable add tags for activity and datatype mismatch
      2) Create an array tag same data type and size as subscriber

      Make sure both plcs are on same IP subnet and run the data should update every 10th of a second. You can use the Activity tag in the slave to see if the communications has been lost if you need it.


      • #4
        Something like this?
        Click image for larger version

Name:	image_3419.png
Views:	33
Size:	63.4 KB
ID:	116947

        Make sure the TCP port matches what is set up in the P2k's hardware config for the Ethernet port.


        • #5
          The way I would do it is if the error tag turns on then either display a message or having it go into a counter and if the counter gets enough error counts then display an error. Depends how critical this instruction is to your program.
          Industrial environments are usually noisy, so you will probably get an occasional error. That is why a counter is usually used. Error timeouts are usually around 250-1000ms so 1 dropped message can be disregarded. But if communication is actually lost it will generate an error each time the instruction is processed so it will quickly generate 3-5 errors and then you can use that to display that there is an error. Also run a timer that if an additional error tag does not get generated within 1-5 seconds then reset the error counter.

          You will probably also want to have something check how full the network buffer is. If you are filling the buffer fast from sending data too quickly over the network you will want to know that so that instructions dont get skipped due to buffer full or suppressed by network equipment as it may look like a DOS attack.
          Last edited by MikeN; 08-09-2018, 11:39 AM.


          • #6
            thank you this is very helpfull