Hello,
I recently took a look at the Sample Runtime repository. (Which is a wonderful piece of information)
GitHub - PLCnext/SampleRuntime: Integration example for other runtime systems using the PLCnext ANSI C interface Integration example for other runtime systems using the PLCnext ANSI C interface - GitHub - PLCnext/SampleRuntime: Integration example for other runtime systems using the PLCnext ANSI C interface And I have a question regarding the cycle time. In my current project I would really benefit from a faster cycle time than 0.5ms. I know that the Axioline local bus and my own software is fast enough to get the cycle time down to at least 150-200 microseconds.
When looking at this Sample Runtime i was hoping that if I wrote my own runtime, I could get the cycle time down. However, when looking at the code and the markdown documents, I noticed the following:
and
There seems to be a restriction on the cycle time of 0.5ms.
However, from my understanding the Axioline Bus should be super-fast, capable of having an update speed a lot faster than 0.5ms:
I’m struggling to understand why this restriction on the cycle time is in place. Is there a way around this? It feels like a missed opportunity, because the Axioline bus is so fast.
Could I still get the cycle time down if I wrote my own runtime? Is there perhaps a knob i can turn to make this happen?
Best Regards,
Daan
PS:
I was also wondering when the process data on the local bus of a controller get’s updated with the normal PLCNext Runtime. In my project, I have a realtime task running at a cycle time of 0.5ms. Does the process data get updated right before and after the task has been executed? Or is it executed somewhere within the 0.5ms of a cycle?
So, if my task takes 0.1ms to execute, does the process data get updated right after the 0.1ms? Or does it wait for something else?
Best Regards,
Daan
the Axioline Bus should be super-fast, capable of having an update speed a lot faster than 0.5msYes, that’s correct. I will try to explain what you’re seeing:
The AXC F x152 hardware
* has Axioline master capability. This allows the devices to exchange data with Axioline I/O modules at the speeds shown in your screen shot above (i.e. very fast).
* The Linux operating system on the AXC F x152 devices includes a low-level Axioline device driver that allows applications running on the Linux operating system to access Axioline data at the „full“ speed of the bus (i.e. very fast).
* Phoenix Contact does not publish the interface to the Axioline device driver, and does not support its use for general applications.
* Instead, the PLCnext Runtime - which is an application running on PLCnext Control devices - includes an Axioline ACF Component , which is the exclusive user of the Axioline device driver on PLCnext Control devices.
* The Axioline ACF Component coordinates the exchange of data between the Axioline bus and the Global Data Space (GDS), which is used by lots of other PLCnext Runtime components, including the PLC component that manages cyclic ESM tasks. As part of this coordination, Axioline I/O data is only exchanged between the Global Data Space and the Axioline Master at the lower frequencies that you mentioned - e.g. 500 µs - partly because the fastest possible ESM task cycle is 500 µs.
* The only supported way of accessing Axioline process data on PLCnext Control devices is through Global Data Space variables. The ANSI-C interface used by the Sample Runtime exchanges data with the Global Data Space, not directly with the Axioline device driver. This still requires the Axioline Component in the PLCnext Runtime to exchange process data between GDS variables and the Axioline I/O modules. And, this Axioline component is still limited to the same minimum cycle time (500 µs), which cannot be changed.
I hope that explanation makes sense.
With this in mind, the answers to your final two questions:
Could I still get the cycle time down if I wrote my own runtime? Is there perhaps a knob i can turn to make this happen?
… are „no“ and „no“ (sorry).
To answer the second set of questions about when the Axioline process data is updated:
Process data is exchanged between GDS variables and the Axioline bus at precisely 500 µs intervals (or whatever the I/O update time is), regardless of how long the cyclic task(s) actually take to execute.
Hi Martin,
Thanks for your help, your answers are clear
Best Regards,
Daan
Hi Martin,
I recently found this: sdurbin-pxc/plcnext-io-drivers-cpp: C++ driver classes to read and write I/O data from PLCnext Axioline modules. (github.com). Is this repository supported by Phoenix?
Best Regards,
Daan
No, it’s not (sorry).
It might be supported by our US subsidiary, and if so then it might only be supported for specific customer(s) based in the USA.
Or, it might only be supported in a personal capacity by the developer. You will need to check with the author of the project.