User Event Tasks

PLCnext Engineer
1

Dear,

Recently I have started with developing C++ application for PLCNext control that makes use of user event tasks, while doing so I have raised some questions regarding the User Events.

                                               1. Is it possible to receive events in the C++ code beside only triggering them?
                                               2. When are you planning to implement the EVENT_TASK function block for the PLCNext?
                                               3. Have you already created the example code for the GitHub repo? I have found a mention of it in an other [thread ](index.php?option=com_easydiscuss&view=post&id=1943&Itemid=221&lang=en)If so, where can I find it?
                                               4. Is there any way to have the PLCNext task running constantly after receiving an User event? So far I have discovered that the task will perform a single cycle (in respect to the cycle time of the task setting the event) and then going back to idle again. Of course I can make use of the output ports that would signal the start of the task, but I would strongly prefer to apply User event tasks in my project.

Looking forward to hearing from you!

Kind regards,
Michael Czorniej

2

Hi Michael,

                                               1. Yes. You can create two C++ programs - an instance of the first program runs in a Cyclic task and triggers the event, and an instance of the second program runs in the User Event Task, and so will "receive" the event (i.e. it will be executed once each time the user event is triggered).
                                               2. I am afraid that we still do not have any information on when this FB will be available in PLCnext Engineer.
                                               3. We have not created this example yet ... it is still in our list of things to do. The code snippet that Frank provided previously should work OK - if not, please let us know what problem you're having.
                                               4. As you have discovered, User Event Tasks don't do what you want - each Task (including User Event tasks) will always execute all its program instances in order, precisely once, every time the task is triggered. And each task must complete execution within the Watchdog period.

Regarding the last point - are you looking for a cyclic task that starts cyclic execution based on an event, and continues cyclic execution forever? In this case - if you really want to use User Events - then I think the only solution is:
* C++ program 1 (P1) detects the event conditions. After the event condition is detected, P1 sets the User Event on every scan cycle. An instance of P1 runs in a cyclic task, with the same cycle time that you want the “constant” task to be performed after the event is detected.
* C++ program 2 (P2) performs the “constant” cyclic processing that you want to perform after the event is detected. An instance of P2 runs in the User Event Task.
In this way, P2 will be executed cyclically after the event is detected, at the same frequency as P1. Will this do what you want? Martin.

3

Dear Martin,

Thanks for the detailed reply. Luckily the code snippet proved to be a good starting point. To clarify my current idea. I wanted to have two programs running in separate tasks.

                                               * Task 1 (Cyclic Task) running a C++ code that detects the condition to set an event "StartMixing" over to Task 2. 
                                               * Task 2 (User Event Task) is running an IEC 61131 program that is getting triggered by the "StartMixing" event and performing n cycles until the program communicates via an OUT port that it has done its job.

Due to a scope of my research project, in my C++ application I am making use of generated code from a Dezyne modelling software, which is aimed for creation of RT event-based software systems. I do not think that this might cause any issues with the program itself - I have tested already some code with it while using ports instead of events. The issue is that due to nature of Dezyne generated systems, which you can see as event-driven state machines, I am able to set the event only once (program cy. Looping in the state to create multiple events for the task have been making some adverse effects, like unpredictability in the User Event task behavior or inability to exit the loop. I am aware that you might be unable to help me with Dezyne created code, but I am only looking for the help related to PLCNext technology. Now the two solutions that I have been thinking of are:
* Switching back from events to port based triggering of tasks.
* Finding a workaround inside Dezyne to find a reliable way to continuously trigger the events.
I decided to go back to port based “eventing”, since this came to be easier to implement in my scenario. It is still possible that I will use events only in C++ code, so your help is still highly appreciated.

Once again, thanks a lot for support!

Kind regards,
Michael

4

Hi Michael, It sounds like port-based triggering of events is probably the better solution in your case. Perhaps the terminology has been somewhat misleading … I don’t know what the topic of your research is, but if someone wanted to implement “event-driven programming” (which is a thing, according to IEC 61499, I believe), then they may be attracted by “user-event tasks” in PLCnext Control, because it has the word “event” in the name. But the intention of this name is not to suggest that it is the most suitable solution for even-driven programming - and in fact I think a port-based approach may be a better solution for event-driven programming in PLCnext Engineer. In any case, if event-driven programming is of interest, the FourZero runtime app in the PLCnext Store might be worth looking at, as would Eclipse 4diac (which has not been ported to PLCnext Control yet, as far as I know). PLCnext Engineer on its own has not been designed to be compliant with the IEC 61499 standard. Martin.

5

Hi Martin,

Thanks a lot for the further details. I will take a look at the proposed alternatives, they all seem quite interesting.

Michael