Skip to Content
avatar image
Former Member

synchronize MII transaction - only one running instance at a time

Hello,

I have a scenario where I use an MII transaction triggered by PCO, and it may be the case that the same PCO notification triggers this transaction twice within a very short time, i.e., the second transaction instance starts its execution before the first instance has finished. But I really need to make sure that those calls are done one after the other and that they do not overlap.

What is the best way to achieve this? Which MII technologies can I use? I do not want to use message services and schedule a job that handels the requests one after the other - I need real time action and in this case I would need to schedule the Job every second. Im really looking for a kind of semaphore/mutex solution to make sure that the MII transaction call can be fired by PCO and in case the previous transaction call is still running, the current one should wait until the previous one has finished.

Thank you for your input and ideas!

Best Regards,

Matthias

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

1 Answer

  • Aug 24, 2012 at 07:27 PM

    Hi Matthias,

    Couple of questions:

    1. What triggers the PCo notification that calls the transaction, and what is the update rate of the notification event?

    2. What is the expected duration of the MII Transaction?

    3. Which version of PCo and MII are you using?

    Regards,

    Steve

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Steve Stubbs

      Hi Steve,

      I'm still in the concept phase for realizing the szenario above, so I can easily build in any additional things if required and feasible.

      Yes, I have planned to pass the line identifier and the plant id in the XML massage from PCO to MII. For persisting the last counter, I was thinking about a database table.

      The steps would be the following:

      • PCO triggers message containing the line number and the current counter of the line (this line counter is actually the trigger for the PCO message)
      • if there is no persistent entry for the previous counter of this line in the db table, assume it is the first message for this line - just record 1 produced piece in the system.
      • if there is a persistent entry for the previous counter do the following:
        • calculate the difference between the previous counter and the current counter
        • if the difference is 1 (should be most of the time), record 1 produced piece in the system
        • if the difference is greater 1 (say n), record n produced pieces in the system (this may cover a PCO outage - the PLC continues counting although PCO does not trigger messages during its outage)
        • if the difference is less than one, do not record anything in the system (this would indicate a wrong order in message delivery from PCO, could be the case when messages are buffered in PCO, but as far as I know there will be a feature in PCO 2.2. that can ensure a proper order in message delivery)
        • update the persistent counter in the db to the value in the currently processed message

      Do you see any better possibilities for storing the persistent counter? maybe use shared memory variables?

      Thank you for your input.

      Regards,

      Matthias