Announcement

Collapse
No announcement yet.

click ethernet comms monitoring

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts


  • click ethernet comms monitoring

    Hi there,

    Im new to the click plc. I need to monitor the Ethernet comms port for activity to another plc.

    I need to de-energiser a relay if the communication fails. Wondering if any one has any suggestions / knows of any internal register that would show a connection failure?

    Im trying to avoid using a heart-beat.


    Thanks


  • #2
    Hi jace,
    Take a look at the SC area of the PLC on Port 1.
    SC90 _Port_1_Ready_Flag ON when Port 1 is Ready, does not indicate Busy Status Read
    SC91 _Port_1_Error_Flag ON when Port 1 has an Error with at least one server Read
    SC92 _Port_1_Connection_Limit ON when all of Port 1 server connections are busy. Read
    SC93 _Port_1_IP_Resolved ON when Port 1 IP Address is assigned Read
    SC94 _Port_1_Link_Flag ON when Port 1 Link is good. Read
    SC95 _Port_1_100MBIT_Flag ON when Port 1 Link is 100 Mbps. Read
    Regards,
    Garry

    Comment



    • #3
      You could either de-energize a contact if "link good" goes off, meaning the physical connection is no longer connected, or you could make a timer that gets reset on each success transaction bit. If you have consistently timed communications then a timer is a good way to go since then you know if you have an actual communication problem between the PLCs even if the physical connection is good. If that timer ever gets "done" then de-energize the contact.

      Comment



      • #4
        @OP I would have to ask 'WHY' are you 'trying to avoid a heartbeat?'

        @Others. Does LinkGood mean that the ethernet port on the click has A connection, or a connection TO A SPECIFIC DEVICE?
        Would LinkGood be true if the click is plugged to ANY ethernet device - like router/switch - and the other device not connected?

        Comment



        • #5
          Link good just means its port is connected to something ok. Usually that is a switch, so yes it is just monitoring the connection between the PLC and the first switch it connects to. If the switch gets powered off the link will go down, or if the cable breaks or is unplugged the link will go down, or if a port breaks for some weird reason the link will go down. There are cases however where a power surge will break the port but the physical link will still come up, in this case it will tell you "link good" even if all comms actually fail to send or be received.

          It is still useful for knowing the PLC is connected to a network successfully, but it doesnt actually tell you that packets are moving properly.

          Comment



          • #6
            Originally posted by MikeN View Post
            Link good just means its port is connected to something ok. Usually that is a switch, so yes it is just monitoring the connection between the PLC and the first switch it connects to. If the switch gets powered off the link will go down, or if the cable breaks or is unplugged the link will go down, or if a port breaks for some weird reason the link will go down. There are cases however where a power surge will break the port but the physical link will still come up, in this case it will tell you "link good" even if all comms actually fail to send or be received.

            It is still useful for knowing the PLC is connected to a network successfully, but it doesnt actually tell you that packets are moving properly.
            Thanks
            I just didn't want OP to go away thinking that LinkGood would solve the problems.
            Last edited by kewakl; 01-08-2019, 10:30 AM.

            Comment



            • #7
              Thanks

              I was trying to avoid a heartbeat because I've never programed in ladder before but the heart beat looks to be the safest way.

              Most of the logic is done in the other PLC via block, I'm only really using the click as a cheap IO.

              Comment



              • #8
                I came up with this.

                YB816 is the Master PLC Heartbeat
                T001 is the Failure Relay
                T002 delays the reset so I can see the point change on the main PLC

                The master is sending a pulse every 15s.

                Thoughts?
                Attached Files

                Comment



                • #9
                  What we do for a heartbeat is a copy of the scan counter (SD9). Then the remote PLC compares that data to a copy of it stored locally, and if it doesn't change for a set amount of time, set an alarm. I have a system where the master PLC is a Micrologix talking to a bunch of Clicks and some 3rd party RTU boards. The heartbeat goes both ways, so the remote PLC receives a number from the master (Free running clock S:4 in a Micrologix)...

                  My alarm timer is set for 300 seconds because in my case, the master is a radio polling station reading and writing chunks of data to 14 nodes with delays between each message and can be expected to have some errors, as well as the fact that this system can run just fine for 10 or fifteen minutes with a comm loss.

                  This type of heartbeat proves that not only are the devices "talking" but they are both in run mode. If the PLC faults, it will stop copying the scan counter or free running clock value to the address that is being sent/received. Messages usually still work even to faulted PLCs that are still powered up with undamaged ports, but you normally want to take action if the remote PLC is no longer running.
                  Attached Files
                  Last edited by OkiePC; 01-09-2019, 02:45 PM.

                  Comment

                  Working...
                  X