Store PLCnext CommunityPLCnext on LinkedInPLCnext on Instagram  PLCnext on YouTube Github PLCnext CommunityStore PLCnext Community

  1. julie
  2. PLCnext Technology & PLCnext Controls
  3. Saturday, 28 November 2020

I am new to the PLCnext technology so please forgive me if I use incorrect terminology.

I want to write a real-time PLM program that can read the input "Arp.Io.AxclC/0.DI01" without manually configuring an association between the digital input and a PLM program's input variable in PLCnext Engineer.

I know I can do it from outside the real-time environment by writing an ACF project but I need to do it within the real-time environment.

Is there a way to dynamically create an association between a digital input and a PLM program variable from within an executing PLM program? Or is there some other way to use the path "Arp.Io.AxclC/0.DI01" to get the input state without additional manual configuration using PLCnext Engineer?

Accepted Answer
Martin PLCnext Team Accepted Answer Pending Moderation


That is a very good question that shows a very good insight into PLCnext Technology, so there is no need to apologise.  :-)

If you are writing a real-time PLM program in C++, then the "simplest" way to get access to I/O variables like "Arp.Io.AxclC/0.DI01" is to declare GDS port variables in your C++ program, and then connect these to corresponding I/O variables using a .gds.config file. When you configure port connections in PLCnext Engineer, it actually creates new entries in the file /opt/plcnext/projects/PCWE/Plc/Gds/PCWE.gds.config, which you can see on the PLC. But, there is no need to use PLCnext Engineer to make these port connections, you can "simply" create your own .gds.config file with the required port connections, and bypass PLCnext Engineer altogether.

So, that removes PLCnext Engineer from the equation. However these port connections must still be made at design-time - it is not possible to make new port connections "dynamically", at run-time.

One way to configure dynamic access to I/O variables is using the ANSI-C interface. This interface was provided so that other runtime systems - like Codesys - can access Axioline I/O. This is not normally used in PLM programs, but I guess this could be possible. The ANSI-C interface is demonstrated in the Sample Runtime example in Github.

Finally, it is also possible to configure your project with a "generic" I/O configuration, which effectively makes the address space look like an array of 512 input bytes and 512 output bytes. You can connect these two arrays to Port variables in your PLM program, and each Axioline I/O point will appear somewhere in that "generic" address space. This is a very flexible option, but you need to figure out where each I/O point is in the address space for any given physical hardware configuration, and you lose the benefits of having an individual GDS port for each I/O point. If you want to try this option, there is an example in the BusConductor example in Github.

Please let us know if you have any more questions.

~ Martin.

Phoenix Contact Electronics Headquarters - PLCnext Runtime Product Management and Support

julie Accepted Answer Pending Moderation

Thank you for the suggestion to use the ANSI-C interface inside a PLM project. That arrangement seems to work.

If anyone else attempts to do the same, just make sure you also have the following line in your CMakeLists.txt file:

target_link_libraries(YourProgramName PRIVATE ArpDevice ArpProgramming Arp.System.ModuleLib Arp.System.Module Arp.Plc.AnsiC)

  • Page :
  • 1

There are no replies made for this post yet.
However, you are not allowed to reply to this post.