Announcement

Collapse
No announcement yet.

C-More Discrete Bit Update Timing

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


  • C-More Discrete Bit Update Timing

    I have a 3-stage process that goes from off to dim to bright [to dim] to off.
    The transitions between stages are triggered by inputs (Xs) and control bits (Cs).
    These transitions are implemented with JMP instructions which simultaneously turn off the JMP ing stage and turn on the JMP ed to stage.

    I've added the C-More to the mix and have tried several things that don't work.

    (1) I've tried slamming the Stage Bits with a radio button control. That appears to work like break-before-make relays as the C-More shows none on before it shows the new stage being on. That works except I get to the bright stage on the way from off to dim!

    (2) I've tried setting C bits with regular C-More push buttons to trigger the JMPs. That works sometimes. It should always work or never work!

    I have been assuming that the C-More updates discrete variables between scans the same as for Inputs and Outputs and Clocks and ... If this is so, the first way should always work and the second way should give consistent results.

    I can't find any documentation that explains exactly when the C-More can poke on PLC memory.
    It looks like it can change memory during a scan of the ladder logic. Is this so?
    And if it is so can it change during the execution of one rung? How asynchronous are the updates?
    Is it like Data View with multiple updates?

    There a almost 100 of these 3 stage setups. I'd like to get a method that works before I start propagating changes to the Ladder Logic and the HMI.

    Any thoughts? Thanks. Roger


  • #2
    The C-more scan is asynchronous. There is no way to make communications as fast as a PLC scan, at least with current technology.

    PLC scans work like this (simplified version, for more detail check out Chapter 3 of any of the PLC hardware manuals):

    Start of scan
    Communications
    Read/Write PLC module status
    Update Input table
    Process Logic
    Update Output table
    End of Scan

    As you can see, communications is one of the first things that happens. This is why you can't easily override physical inputs with an HMI. It is also why if you use a register that is written by the HMI as an output in the PLC, what is written by the PLC is what will always win.

    When C-more scans a screen for memory locations to read/write to/from the PLC, it tries to group sequential or even partially sequential PLC registers to make the communications faster. If the PLC registers are too far apart for grouping then it has to make a separate read/write to the PLC. This means that it can take multiple PLC scans to get a screen fully populated with data. The farther apart the PLC registers are, the more communication requests that C-more has to make to get all of the data that it needs. So it is possible that you might have to make a request to the PLC for every single active object that has a PLC register on the C-more screen. Obviously this takes some amount of time. In some cases it can take dozens of PLC scans to get a full round of data into the C-more so that it can start over from the beginning on a new round of updates.

    So lets try to put some real bounds on how fast C-more can actually do something. Assuming that you set it for 9,600 baud, C-more can transmit around 1,200 characters to the PLC or 600 words of PLC data. But that is not completely true. Some of that bandwidth must be used to tell the PLC what registers that the C-more wants to do something with, right?

    So out of those 600 words, you knock off about 4 to 12 words for each PLC register request that C-more makes. Then the PLC uses a word to Acknowledge that it got the request. But, that is not all. You also have about that same number of words, plus the actual data in the response for the PLC. So if you ask for 5 word registers you actually have about 10 words on the wire with the PLC telling C-more what it is really sending back as well as the data. Then you lose a word for C-more Acknowledging the packet. So for each request of 5 consecutive PLC registers the C-more and PLC knock back around 18 words of traffic. Then you get to add on the scan time of the PLC to the responses, because remember, Communications only happens once at the beginning of every scan. So the more requests, the more scans it takes to populate the C-more screen.

    Whew. That's a lot of writing. Maybe this does a reasonably decent job of explaining how communications works and why it isn't always super speedy. This is of course a greatly simplified version of what actually takes place, but hopefully it helps you out.
    Last edited by Do-more PE; 07-26-2014, 09:49 PM.
    If you have an urgent issue, please contact AutomationDirect's Technical Support team.

    AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

    Comment



    • #3
      Your problem is a bit outside of my range of "expertise" , but I do know that what PLC you are using is probably a very important (more so than the C-More) part of the situation as far as when actual registers will be updated. For the benefit of people who might be able to help, you might let them know what you are using.

      I'm quite sure the communication between the C-More and PLC is generally asynchronous with respect the PLC scan, but it is conservable that some PLCs have a buffer for communications, and update the working registers synchronously with the scan, while it is also conceivable that other PLCs do write to the working registers asynchronously.

      (EDIT) well, Do-more PE posted while I was typing, and made my comments sound like nonsense, in my defense, I was thinking at both too low of level and too high of level. At the too low of level I was thinking of the UART, which I think nowadays is virtually always subsystem that is relatively independent of the main CPU. The days of a microcontroller bit banging the serial port are likely long gone, but the UART would also be a dumb subsystem and would be dependent on the main CPU to read or write to registers, thus that operation could, and almost certainly would, be synchronous with the scan (As Do-more PE said) On the too high of level, rather smart subsystems and multi threaded processes are pretty common these days, and a system could be built that could read/write registers asynchronously, however, in a PLC that probably would not be entirely desirable (predictability probably being more important than raw speed), so I imagine isn't done in practice.
      Still, knowing what PLC you are using couldn't hurt.

      Also the communication protocol and physical layer (e.g.. RS242, 485, Ethernet, etc.) is probably relevant too.
      Last edited by Tinker; 07-26-2014, 10:21 PM. Reason: I'm an idiot

      Comment



      • #4
        In general yes, HMI writes can occur asynchronously with the scan (as Tinker noted, we don't know which PLC you're using so that's a general observation). If your program won't work if that occurs, then point your HMI writes to one range, say C0-C77, then at the top (or bottom) of scan, copy that to a different range, say C100-C177 and use those in the ladder. That way the writes are forced to effectively occur once per scan.

        Comment



        • #5
          Thank you all.

          OK for starters: I'm using a D2-260 with H2-ECOM100 and an EA9-T8CL connected via Ethernet with Giga-Bit switches operating at 10/100 for this link.

          Thanks Do-More PE for explaining the process and interactions. Especially interesting was the knowledge that the C-More will optimize the order of transmission of data to/from the controls on the screen.

          For my application - and probably most applications - the HMI is mostly reading from the PLC so the protocol overhead is telling the PLC what it wants to see and then having the PLC wrap the result in a package that tells the HMI what it's sending. Plus confirmations, etc. I think there's also an even smaller limit than the 600 you mentioned that limits how many bytes/words that can go through the D2 backplane on each scan. The data from the PLC will arrive when it arrives

          Thanks Tinker for bringing up the obvious point that I should have included more details about my system. I'm sure the H2-ECOM100 operates asynchronously and with lots of hand shaking control bits. This is really obvious with the email function - where you need to assign addresses for the ECOM to use for each message. I've used a BASIC co-processor and I needed to put handshaking in that logic to let the co-pro know it had work to do and to let the co-pro tell the ladder logic it was done.

          And Thanks ControlsGuy. It seems clear now that I need to do proper handshaking between the HMI and Ladder logic. And there need to be places that only the HMI writes to for signals and parameters for the ladder logic. I can do that except for ...

          OK. Now this comes back to Do-more PE's I/O optimization comment. Assume there are several controls on the C-More putting values in the PLC that the Ladder needs to see. Also assume there's a separate button on the C-more that says Process. Is there a sure way to know that the values have made it to the PLC before the Process bit shows up? Or is it just timing? Is that what the button delay setting is for?

          Thanks again for all the helpful comments.

          Comment



          • #6
            No problem. I think most people that move into advanced communications end up struggling with this a bit at first. I know I did.

            Originally posted by AZRoger View Post
            OK for starters: I'm using a D2-260 with H2-ECOM100 and an EA9-T8CL connected via Ethernet with Giga-Bit switches operating at 10/100 for this link.

            I think there's also an even smaller limit than the 600 you mentioned that limits how many bytes/words that can go through the D2 backplane on each scan. The data from the PLC will arrive when it arrives
            As far as backplane traffic, you are correct. The DL205 backplane is limited to 256 bytes per module per scan, so at most you can get about 120 words or so each scan out of a single ECOM100. The Do-more CPU has no such limitation other than the TCP packet size which is limited by MTU (Maximum Transmission Unit) which is 1492 bytes although it could be less. BobO can correct me if I am not thinking properly here.

            OK. Now this comes back to Do-more PE's I/O optimization comment. Assume there are several controls on the C-More putting values in the PLC that the Ladder needs to see. Also assume there's a separate button on the C-more that says Process. Is there a sure way to know that the values have made it to the PLC before the Process bit shows up? Or is it just timing? Is that what the button delay setting is for?
            That is what the button delay is for. I have never actually used it, but it should be explained in the help. If not, let me know and I'll see if I can get the C-more PE to step in and explain it in better detail.
            If you have an urgent issue, please contact AutomationDirect's Technical Support team.

            AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

            Comment



            • #7
              Thanks.

              OK. I'll check the help file just to see what's there and how it's explained. Thanks.

              Comment



              • #8
                Asynchronous at the physical layer, Synchronous to the PLC scan

                At the physical layer (signals on a wire coming into a UART or Ethernet PHY chip), communication occurs asynchronously.

                However, in DirectLOGIC and Do-more PLCs (I do not know Click or P3K architectures), at the APPLICATION LAYER they are handled SYNCHRONOUS to the PLC scan. That means that if you write a C-bit, it is done at during the "comm slice" portion of the PLC scan. So there is some buffering between the physical layer and the application layer.

                That means that the C bit will NOT change state DUE TO COMMUNICATIONS in the MIDDLE of the LOGIC scan portion of the PLC scan.

                In Do-more, communication time slice is done towards the bottom of the PLC scan. See the attached picture.
                Attached Files
                Last edited by franji1; 07-28-2014, 08:07 AM.
                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
                  At the physical layer ... communication occurs asynchronously.

                  However, in DirectLOGIC and Do-more PLCs ... at the APPLICATION LAYER they are handled SYNCHRONOUS to the PLC scan. ...

                  That means that the C bit will NOT change state DUE TO COMMUNICATIONS in the MIDDLE of the LOGIC scan portion of the PLC scan.
                  Excellent! Changes mid-scan would be hard to deal with! Thanks for the clarification.

                  Comment

                  Working...
                  X