Eclipse Community Forums: 4DIAC - Framework for Distributed Industrial Automation and Control » Questions: readPin() implementation && OPC UA I/Os integration

Home » Eclipse Projects » 4DIAC - Framework for Distributed Industrial Automation and Control » Questions: readPin() implementation && OPC UA I/Os integration

Show: Today's Messages :: Show Polls :: Message Navigator

Questions: readPin() implementation && OPC UA I/Os integration [message #1846987]

Mon, 11 October 2021 11:51

Tuojian Lyu

Messages: 18
Registered: October 2020

Junior Member

Hello,

I have two questions:
1) I just checked the implementation of readPin() and writePin() in sysfsprocint.cpp and I found the readPin() just returned a True. How is the IX so different from the code of writePin()? Is checkInputData() the actual method to read data from pin but why readPin() is used in IX.cpp?

index.php/fa/41123/0/

2) Any practice/comments/examples to integrate OPC UA functionalities to IX/QX? Would it be a natural style that IO-accessing FBs can be compatible with OPC UA?

Br,
Tuojian

Attachment: code.PNG
(Size: 86.16KB, Downloaded 227 times)

Report message to a moderator

Re: Questions: readPin() implementation && OPC UA I/Os integration [message #1846988 is a reply to message #1846987]

Mon, 11 October 2021 12:39

Alois Zoitl

Messages: 1584
Registered: January 2014

Senior Member

Hi Tuojian,

the reason for this difference is that we have in sysfs as well as in other IO interfaces an handler which is scanning the inputs and if needed generates IND events on the IX blocks. In order to not interfere between the two threads the readPin, which is triggered by the REQ event is in general doing nothing just assuming that the handler has recently updated the pin and therefore just send a CNF event. While looking at the code I noticed that there is a hardoced 10ms scanning loop. I remember that I never liked it. But we never found time to improve it.

The best would be to move the whole code to the new configurable IO concept that Johannes Meßmer developed in his Bachelor thesis. You can already see it applied in the embrick and new wago pfc implementation. An overview can be found in this paper: https://ieeexplore.ieee.org/abstract/document/8247577

I think this could also be the starting point for an OPC UA based IO concept. Or am I wrong.

Cheers,
Alois

Report message to a moderator

Re: Questions: readPin() implementation && OPC UA I/Os integration [message #1847001 is a reply to message #1846988]

Mon, 11 October 2021 18:42

Tuojian Lyu

Messages: 18
Registered: October 2020

Junior Member

Hi Alois,

Thanks for your fast reply!

Finally, I understand the execution chain that is: CIOHandler::run() -> updateReadData() -> checkInputData().

This is as I expected that checkInputData() is the method to read and update pin value but not the readPin().

I suppose the 10ms hardcoded scanning loop is CThread::sleepThread(10). Hope it could be improved in the future version.

For the paper you mentioned, it is indeed a good idea and it helps me solve the RevPi IO-accessing problem. I prefer this separated IO configuration resource idea. The symbolic link style could improve the portability of control applications. However, I think it is not relevant to OPC UA-integrated IO FBs. But it is still a good starting point., and I will try to do some practices.

Thanks a lot for your sharing!

Cheers,
Tuojian

Report message to a moderator

Re: Questions: readPin() implementation && OPC UA I/Os integration [message #1847002 is a reply to message #1847001]

Mon, 11 October 2021 19:01

Alois Zoitl

Messages: 1584
Registered: January 2014

Senior Member

Happy to support.

For the revpi there is already a modular IO config implementation [1]. Don't remember if I told you. I had to sort out one legal thing therefore it will not be in 2.0.0 but definitly in 2.1.0.

[1] https://git.eclipse.org/r/c/4diac/org.eclipse.4diac.forte/+/153699

Report message to a moderator

Re: Questions: readPin() implementation && OPC UA I/Os integration [message #1847004 is a reply to message #1847002]

Mon, 11 October 2021 19:13

Tuojian Lyu

Messages: 18
Registered: October 2020

Junior Member

Yes, you shared this with me in my last post and it works with RevPi. Just found one bug in CMakeLists that is to change "if(FORTE_MODULE_RevPiModularIO)" to "if(FORTE_IO_RevPiModularIO)" or change "forte_add_io" to "forte_add_module".

Report message to a moderator