Skip to content

PLCNext Technology environment and CoDeSys on same CPU

Hello,

 

I have CoDeSys running on an F2152, to utilize the E/IP Master and Ethercat Master.  Works well and no questions there.  I was hoping to use OPC UA to pass data to PLCNext Technology and log to cloud.  I have been told that's possible.

 

I see that PLCNext tech environment is on the CPU, I can connect to it and download to it, but it doesn't appear to be "running" - it seems "paused".  I'm not accessing I/O modules right at the moment, just using local variables with the hopes of connecting to Proficloud.

Is there any procedure to follow to get PLCNext active?

 

Best Regards,

 

Ted

Comments

  • Hi Ted,

    That's a very interesting question.

    I am assuming that by "cloud", you mean the "Proficloud Time Series Data (TSD) service" (please correct me if I'm wrong).

    It's difficult for us in Phoenix Contact Runtime Support to offer advice on working with third-party applications like Codesys, and the first port of call should be Codesys themselves. They should be able to say if or how they support Proficloud on PLCnext Control devices.

    If you get no joy from Codesys, then some facts about the Codesys installation could help us see what is and is not possible.

    Here is what I have seen after installing Codesys on an AXC F 2152 with firmware version 2020.6.1:

    • As you have found, the Codesys installation prevents the PLCnext Engineer project on the PLC from even being loaded by the PLCnext Runtime. It does this by re-directing the symbolic link /opt/plcnext/projects/current so that it no longer points to the PCWE directory. There is probably a way to work around this, but it will not be simple and is probably not a good idea.
    • The good news is that the PLCnext Runtime itself is still running, which means that all the services offered by the PLCnext Runtime are potentially available, including the Proficloud TSD service.
    • The not so good news is that the Codesys installation disables the following PLCnext Runtime services:
      • Profinet (both Controller and Device)
      • Ethernet/IP
      • eHMI
      • OPC UA server

    It makes sense that Codesys would disable these PLCnext Runtime services, because Codesys offers similar services in its own runtime.

    So, given these facts, the question is: How best to get data from the Codesys runtime, to Proficloud?

    You mentioned that you wanted to use "OPC UA" to pass data to the PLCnext Runtime. What did you have in mind here? Would this require the PLCnext OPC UA server to be running? If so, how would you use this to get data from the Codesys runtime?

    The best solution I can think of involves writing a custom ACF component in C++, and instantiating this in the PLCnext Runtime. This component can define OUT ports with the "Proficloud" attribute, which will automatically send the values of those port variables to Proficloud. Then, that component would need to read data from the Codesys runtime. It could do that via OPC UA, or perhaps using the Codesys "PLCHandler", or perhaps there is another API on the Codesys runtime that you could use. In any case, one big disadvantage of this solution is that the names of the Proficloud variables must be hard-coded into the ACF component, and so the C++ program must be re-compiled every time you want to change the Proficloud TSD variable list. But this might not be a big deal for your application.

    I hope this has given you some ideas on how to achieve what you want.

    ~ Martin.

     

  • Thank you for the quick response!

    My main thought in regards to OPC UA was that we use it to pass data between PLCNext engineer and Node-red, Ignition and other softwares.  It is my understanding that 2 OPC UA servers can exchange data, so OPC UA was my first thought for passing data from CoDeSys to PLCNext, and then up to the Proficloud.  If that is not going to work, then I am thankful for the suggestion.

    There is a customer in the USA (not in my area of responsibility) that has this working (CoDeSys and PLCNecxt Engineer) but we have been reluctant to ask them how they did it!  I am hoping we can figure it out on our own.  If PxC gets E/IP master working in PLCNext Engineer, I imagine most of the demand for this dual runtime system will go away

    Best Regards,

     

    Ted Thayer

  • Hi Ted,

    That's very interesting - that someone is using Codesys and PLCnext Engineer on the same PLC. The details of how they did that would be even more interesting.

    I can think of a few ways that this might be possible, but these involve either tinkering with the Codesys installation, which I wouldn't be comfortable with, or tinkering with the PLCnext Engineer project location.

    Even if you got this working, if your aim is to transfer data between Codesys and PLCnext Engineer, then that is a separate challenge.

    It is my understanding that 2 OPC UA servers can exchange data

    I don't think that's true, but I am happy to be proven wrong. Two OPC UA servers can only exchange data via an OPC UA client, AFAIK.

    we use it to pass data between PLCNext engineer and Node-red, Ignition and other softwares

    Right, but Node-Red and Ignition include OPC UA clients. You could install an OPC UA client to exchange data between the servers - either one you write yourself, or (for example) Node-Red. The OPC UA client could even be running on a different machine.

    If PxC gets E/IP master working in PLCNext Engineer, I imagine most of the demand for this dual runtime system will go away

    If, in this case, all you are missing from Codesys is the ability to send data to Proficloud, then it seems like a complicated solution to do this via a PLCnext Engineer project. We could talk to Codesys and our Proficloud colleagues about the best way of extending the Codesys runtime to include Proficloud support. That might be another way to make the demand for a dual-runtime system go away. Let us know if you'd like to explore this option.

    ~ Martin.

Sign In or Register to comment.