synchronize MII transaction - only one running instance at a time

[Former Member]

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

[former_member196557]

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

[Former Member]

Hi Steve,

1. The PCO notification will be triggered when a PLC counter increases (which is actually the trigger that another piece has been produced on one of our production lines) - this happens in average every 10 to 15 seconds, but due to some special setup it can be the case that 2 or 3 consecutive pieces come out at the end of the line immediately one after the other, followed by a larger pause.

2. The expected duration of the MII transactoin will be approx. 2 to 3 seconds.

3. The exact software versions we use are PCO 2.1.6.1 and MII 12.1.9.123.

to be precise, the serialization of the transactiona does not need to be for all instances, but only for instances of the same production line, i.e., transactions of different lines may run at the same time, but for a single production line the transaction calls must not overlap.

The reason is the following: We want to implement a "difference posting" of produced pieces: each PCO message holds the  PLC counter value, and in the MII transaction I want to refer to the counter of the previously produced piece. If the difference is one, everything was OK, one additional piece needs to be recorded in the system. If the difference is greater than one (for the sake of example, lets say 3) I will record 3 new pieces in the system, and if the difference is less than one (wrong order in message delivery, should normally not happen) I will simply ignore the message. This gives us the possibility to not lose data during a PCO outage: PCO is up until PLC counter value 10, is down from PLC counter value 11 to 15, and comes back at PLC counter value 16. When I process the message with counter value 16, I will see that the last processed piece was for counter value 10, therefore I need to create 6 pieces - the 5 I have "lost" plus the current one.

To be able to safely refer to the previously produced piece, there must not be any parallel transaction executions, since then maybe two instances read the same "previous counter" and therefore mess up the collected data.

I hope this gives you an idea what I want to achieve.

Best Regards,

Matthias

[former_member196557]

Matthias,

This is how I understand your design:

• Single MII transaction to record the piece(s)
• One PCo notification per Manufacturing Line Counter
• Only ONE instance of MII Transaction running per PCo Notificiaton at any time

Some additional questions:

• Do you pass the Manufacturing Line identifier with the PCo notification? (assume yes)
• Assuming your transaction does this sequence, where do you persist the last counter value?
  • Read last counter value for the mfg line
  • Record the piece(s) if (cur_value - last_value)>0
  • Update the persisted counter value for the mfg line

Regards,

Steve

[Former Member]

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