Producer/Consumer design pattern with twincat

Hi,

I am trying to develop a producer/consumer software architecture to use in my automation projects.
The idea is to have two tasks, the first one (let's call it task A) reads and write the OpcUA interface, and the second (let's call it task B) performs the automation.
The two tasks communicate asynchronously through "WorkUnits" which are produced by Task A and consumed by Task B.

Now, I have some problems realizing this with Twincat 3. I have a strong background of Object Oriented development, and I would like to develop this way.
So I modeled the "WorkUnits" using Function Blocks (which I understand to be the equivalent of Classes in OOP) and using the __NEW Operator I create them from Task A and pass them to Task B (using Global variables).
Of course I work with interfaces, this means all Input variables in my function blocks methods are of interface types.

I am not sure this is a good approach, because it seems this way of development causes massive problems with the memory management. I get page fault and access violation errors, which to me are very difficult to debug and understand. This leads me to ask your help to understand if I am doing right or not. Here some concrete questions:

• 
  Is it ok to pass function block as input of other function block methods?

• 
  How should I pass them? It seems I have multiple possibilities. I could use REFERENCE TO, or POINTER TO, or I coult just use input variables with the interface type (example: myInputVar : I_MyWorkUnit). What are the differences between them?

• 
  What does actually happen in my memory if I declare a variable using an interface type? Example: myInputVar : I_MyWorkUnit. Does it create a pointer? A Reference? I guess no memory is allocated, since I don't specify any implementation.

• 
  Is there an alternative to the horrible bechkoff documentation?

Thank you, kind regards.
Enrico

Check this.

I don't think many in here are fan of pc styled programming in automation world. I see some advantages, but what you seem to be trying to do, is way too complicated with pretty much no gain in my opinion.

TC3 Oop extensions are pretty nice in many places doing some previously hard things doable, but they must be only used when there is gain from them.

Thank you for the hint.
I think you're right, I had the feeling I was doing it too abstract and complex.

I refactored my code, now I use a much easier architecture with one single loop and no dynamic memory allocation.