Announcement

Collapse
No announcement yet.

Disconnect after comm loss is painful

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


  • Disconnect after comm loss is painful

    If my link to the Do-more PLC gets disconnected somehow, it can take minutes for DMD to notice, go through retries, and allow me to disconnect. Any attempts to hasten the process cause DMD to crash and often crash the comm server as well. If the comm server crashes, I have to reboot my computer to reconnect. Are there settings I can adjust to make this easier/faster?


  • #2
    What are your timeouts and retry counts? If they are large, that's a double edged sword. It will help in some ways, but will hinder in others.

    1. Turn status OFF. If you have unstable comm, hit the All Status Off button. Status assumes your connection is just a little flakey, not lost. Hence, it will keep trying, and trying, and trying, and hinder other things from cycling through and eventually "timing out".
    2. Try minimizing the timeout and retry. That will help Designer get through the pending requests quicker.
    There are 10 kinds of people in this world, those who know binary, and those who do not.

    Comment



    • #3
      Defaults shouldn't be anything like that, a few seconds at most. What port are you connected on? What is the scantime of your PLC?

      Comment



      • #4
        Originally posted by franji1 View Post
        What are your timeouts and retry counts? If they are large, that's a double edged sword. It will help in some ways, but will hinder in others.

        1. Turn status OFF. If you have unstable comm, hit the All Status Off button. Status assumes your connection is just a little flakey, not lost. Hence, it will keep trying, and trying, and trying, and hinder other things from cycling through and eventually "timing out".
        2. Try minimizing the timeout and retry. That will help Designer get through the pending requests quicker.
        I will try the status off next time, I always have it on when I'm online.

        Originally posted by BobO View Post
        Defaults shouldn't be anything like that, a few seconds at most. What port are you connected on? What is the scantime of your PLC?
        5000 ms Timeout and Application Timeout, 3 retries, port 28784 UDP. Average scan time is ~6 ms

        Comment



        • #5
          Originally posted by TheGreatMarklar View Post
          If my link to the Do-more PLC gets disconnected somehow, it can take minutes for DMD to notice, go through retries, and allow me to disconnect. Any attempts to hasten the process cause DMD to crash and often crash the comm server as well. If the comm server crashes, I have to reboot my computer to reconnect. Are there settings I can adjust to make this easier/faster?
          If the comms server crashes, can you terminate CSMainDM.exe task in task manager, and then give it a go, without rebooting?

          Comment



          • #6
            Originally posted by TheGreatMarklar View Post
            5000 ms Timeout and Application Timeout, 3 retries, port 28784 UDP. Average scan time is ~6 ms
            That means that 1 comm request will take 20 seconds to timeout (5000ms for the first try, then 5000ms * 3 retries). Default is 100ms and 1 retry. Not sure why it's configured that way, but that is the reason the software appears "slow" when shutting down with a "disconnected" PLC. I'm going to guess that your communications is set up that way for a reason, and so changing it to 100ms/1rety is not an acceptable answer.

            Is there anything you can do to create a higher quality communications link between your PC and the PLC? If not, try cutting back to 1000ms and 1 retry. Bad READs are "tolerable" (flat Trend Views or non-changing Data Views or static Ladder status). But unstable WRITEs are much more of an issue (Data, Project, Firmware).

            If communication quality is more binary than analog (i.e. the link either works like a hose, or it doesn't work at all), definitely cut back on the timeout and retries. It will log more "errors" at a faster rate when the connection is broken, but the software will be much more responsive.
            There are 10 kinds of people in this world, those who know binary, and those who do not.

            Comment



            • #7
              Link quality is generally good, these settings are carried over from the last programmer who worked on our equipment (and was fired before I started). I'll turn the numbers down and test it out. (Most of my comm interruptions are because someone is working on the hardware and turns it off).

              Comment



              • #8
                Originally posted by TheGreatMarklar View Post
                Link quality is generally good, these settings are carried over from the last programmer who worked on our equipment (and was fired before I started). I'll turn the numbers down and test it out. (Most of my comm interruptions are because someone is working on the hardware and turns it off).
                If you set it back to the default of 100ms timeout with 1 retry, I think you will like the result.
                There are 10 kinds of people in this world, those who know binary, and those who do not.

                Comment



                • #9
                  Originally posted by franji1 View Post

                  If you set it back to the default of 100ms timeout with 1 retry, I think you will like the result.
                  Reduced to 500ms with 3 retries, a HUGE improvement! Turning All Status off also helps a lot. Thanks for the advice!

                  Comment

                  Working...
                  X