How to use this library?

[Kyle Goodwin]

I've had my eye on this library for many years now but never had a need for it. I finally have an application for it but unfortunately; it's not as easy to use as I was hoping.

I am able to compile executable, archive, shared objects, and build the docs. The executable bin/posix/src/ports/POSIX/OpENer runs with seemingly no issues but I do not have a PLC with me to test.

I was hoping the archive bin/posix/src/ports/POSIX/libPOSIXPLATFORM.a could just be dropped in along with opener_api.h to my application and it would work. This does not seem to be the case though. After manually adding all the header files and the define it complained about I still gets errors like:

Saying this is invalid syntax. Which as far as I can tell it is, but seems to compile fine in the library itself.

CipInstance *GetCipInstance(const CipClass *RESTRICT const cip_object,
const CipInstanceNum instance_number);

I've never seen const CipClass *RESTRICT const cip_object pattern before. I understand the idea of a constant pointer to constant data but I don't know what the RESTRICT is there for.

Or saying that OpenConnectionFunction is not defined, which as far as I can tell, is not. Yet compiled fine in the library as well.

Is there documentation, guide or tutorial on how to actually use this? What is the intended method of using this? Fork the repo and start modifying sample_application?

Also seems like maintenance has stopped and it is out of date with the ODVA spec. Is this safe to use in production? 

Thanks

[vivek.ha...@gmail.com]

Hi Ken

Others will need to respond regarding the technical questions, but I can provide some background information with respect to the OpENer project in general.

Unfortunately, the TU Vienna - who were looking after the maintenance and development of OpENer - chose not to continue working on industrial communications. As a consequence of this, the funding for the project was also lost. Options for continuing the project are being evaluated at present.

Regarding the question on the use of OpENer in production: the position I take (as part of my technology promotion role at Rockwell Automation) is that OpENer is an excellent tool for learning and prototyping. I have generally recommended the use of a commercial provider for anything that is used in production. That said, I am aware of EtherNet/IP conformant products that have been brought to the market using OpENer (and in some cases have also passed PlugFest) - so it can be done. The decision on which path to follow typically comes down to the level of effort that the developer wishes to put in to align an OpENer based solution with the latest version of the CIP Specification, getting the product through the Conformance Test and expectations on support and backup. 

Regards

Vivek

[Richard Wu]

This is the ChatGPT answer on RESTRICT syntax,

The declaration:

const CipClass *RESTRICT const cip_object;

contains multiple qualifiers, and understanding its intent requires breaking it down:

Components:

1. const CipClass *:

• A pointer to a CipClass object.

• The pointer points to a const instance of CipClass, meaning the object it points to cannot be modified through this pointer.

2. RESTRICT:

• This is a compiler-specific keyword (e.g., from C99 standard). It indicates that this pointer is the only means by which the object it points to is accessed in the scope. This allows the compiler to make optimizations under the assumption of no aliasing.

3. const cip_object:

• The pointer itself is const. You cannot modify cip_object to point to another CipClass instance after its initialization.

Interpretation:

• The pointer cip_object:

• Points to a constant CipClass object.

• Cannot be reassigned to another CipClass after initialization.

• Has restricted aliasing due to the RESTRICT keyword, allowing optimization.

Practical Use:

The declaration ensures a read-only CipClass object and optimizes pointer usage due to aliasing restrictions. If your code doesn’t modify the object via the pointer or require pointer reassignment, this declaration enforces these constraints at compile-time.

--
You received this message because you are subscribed to the Google Groups "EIP Stack Group OpENer users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eip-stack-group-open...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/eip-stack-group-opener-users/cc97da66-c80b-423c-b516-9c47a114b29cn%40googlegroups.com.

[Richard Wu]

I have been using OpENer for the past 2 years,  customized it for PLC data collections,  I noticed it in handling high throughput data from PLC in IO messaging . it is well designed with event driven  in a single threaded process and easy to extend with new EIP specification features. but it has pretty stiff learning curve due to lack of documentations:(

its sample application shows how to use the stack. overall I think the community together should keep this only open source EIP Adapter Stack alive!

Best,

Richard   

[Kyle Goodwin]

The lack of documentation is a problem, that once fixed might solve everything. But I think there are some larger underlying problems preventing this from wider adoption.

The other libraries I am using compile easily (despite having their own documentation issues) and spit out .so or .a files that I can use right out of the box and compile fine in my project with gcc. Initial testing is complete same hour as cloning the repo. Not this library though, it is a whole project unto itself just understanding the (perhaps necessarily so) complicated build process. I am by no means a C expert but I have been able to get the job done over the years. From my point of view it's clear this library's target audience is research by computer science masters and doctors, not industrial monkeys like me, which I think Vivek was alluding to as well.

There is an awful lot of potential here but the difficulty of use is the roadblock. For someone in my position the commercial alternates are faster, safer, and will end up cheaper than trying to decipher this. It was a painful realization to come to because I've wanted an reason to use this for many years.

[Alois Zoitl]

As one of the original developers I think I have to step up and put a
few things into perspective.

First of all as any open source project OpENer was always understaffed
and under financed. For that we managed to come up with a very good
library that allows a lot.

I also don't understand the documentation complaint. OpENer API is very
well documented:
https://github.com/EIPStackGroup/OpENer/blob/master/source/src/opener_api.h

With the sample application you even get examples how to use it.
However it requires a certain C knowledge. Our goal was always that you
can download it compile it and get it running for tests.

Regarding the question of the future of OpENer you have to ask yourself
the question what you want? Do you want an open source library that can
be easily used. Then people have to step up and invest either money or
people to support us.

Or do you just want to pay some commercial vendor some license fees?

Unfortunately there is no free lunch!

If anyone wants to help us in improving OpENer I'm happy to help.

Cheers,
Alois

> --
> You received this message because you are subscribed to the Google
> Groups "EIP Stack Group OpENer users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to
> eip-stack-group-open...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/eip-stack-group-opener-users/37932b37-323f-4867-ae96-37a3679212adn%40googlegroups.com
> .

[Kyle Goodwin]

It's not so much the API documentation is lacking, it's the getting to the point of actually being able to use the API that is the issue. The other libraries I am using also do not hold your hard and are missing important steps from the readme, but once you figure out the missing parts they compile, install, and work. A specific example for OpENer is the currently open github issue complaining the doxygen instructions aren't right. They are running the commands incorrectly because I got it to work but they're also not wrong, the readme does not provide the correct instructions.

Anyways, after messing around with it a bit more I did figure out how to get shared objects to install (again, the readme does not fully describe how to do this). Unfortunately I am right back where I started with errors on the RESTRICT keyword and the lack of a OpenConnectionFunction type (which I just realized is also due to the RESTRICT keyword).

For my immediate commercial purposes, my competency level with C is such that, this library is simply not viable. Especially when the commercially licensed options are actually not unreasonably priced. If someone want's to help me with my keyword woes I would be happy to continue slogging through this and update or write some new documentation for people like me.

[Alois Zoitl]

As said I'm happy to support. It would be amazing if you could provide
us your improvements as pull request.

Regarding your RESTRICT problem. I think the best would be if you could
open an issue in the github project and provide us with the exact
compiler error message or even better the full compiler output. If that
is not possible (confidentiality issues) you can also just put the
error message and send me the full output privately. I'll try my best
to dig into finding out what is going on here.

> https://groups.google.com/d/msgid/eip-stack-group-opener-users/46c28b82-bd35-4248-8b3f-3fb6a35e945en%40googlegroups.com
> .

[martin...@gmail.com]

Hi,

regarding the RESTRICT part:

as several compilers are using different variants of the restrict keyword, I added restrict as a define to the code, which is also why it's all capitals.

Without seeing your compiler errors, there are two most likely sources of an error

1. the define via compiler flag in the corresponding platform specific cmake file does not fit your compiler

2. the used compiler has general issues with the restrict keyword.

However, both issues can be "solved" by adding the compiler flag -DRESTRICT="" to set the define of RESTRICT to an empty sting, effectively eliminating the use of keyword.

This will not change any of the functionality, as restrict, as mentioned by Richard, is used to give the compiler the possibility for more aggressive optimizations, which is why I added RESTRICT to certain parts of the library.

For your issue with the OpenConnectionFunction type, I would need your compiler log output, as the Github build does not have any issues.

May I ask you how your build process works in general? Did you do any modifications on the usual CMake process?

For the issues regarding documentation I am happy for any help.

To disclose the current situation with OpENer from my side, as the main developer for the past 10 years:

As Vivek already disclosed, my former employee, the TU Wien, decided to stop this project and with that the funding and access to the ENIP specification, and I switched to a new job in a different field, so my time is very limited since then, effectively only a part of my spare time.

There has been a bit of community development now and then, but mainly this project was a one-man show.

If people are interested to keep this project running and developing again, then a common community effort is needed on the one hand supporting development via Issues and the willingness to go to several rounds of refinement in describing the issue (more than once I got an issue with "X is not working" and no reaction whatsoever after I tried to get more information), and on the other hand to make the project relevant for the ODVA, so we can get somehow access to the specifications. I think it goes without saying that nobody here wants to spend 3000 USD+ per year to get access to the ODVA CT Tool and the necessary specifications on their own to even be able to meaningfully contribute to the code base and functionality.

I think there should be enough parties interested out there, as OpENer is deemed relevant enough by the US government to give it a proper security audit by external parties, but unfortunately most of those parties never delivered back code, nor supported the project in any other way, with the notable exception of Rockwell Automation.

So to sum that up in a TL;DR way

If the community makes an effort the keep this project alive, I am also willing to bring my expertise and spare time to the table for future development and also for support of the community to use the stack and build products, but it is not possible that I run and develop this project as a one-man show.

Best regards,

Martin

[Kyle Goodwin]

I was wondering about the all caps nature of that. Based on what I read about the restrict keyword I tried a number of define flags and none of them worked. I had basically given up and assumed there was something in the CMake process did that defined it that I could not decipher. The one flag I did not try was "-DRESTRICT=restrict" which seems to the the one that actually does the trick.

It's shameful to admit but I don't actually know how to use CMake. I can make other people's setups work but I don't use it myself. Developing C is such a small part of what I do that I've never had the time to learn it. I need to keep things pretty basic with either a lib folder full of .a files or install .so and a simple Makefile. This is my quick test script just to get gcc to actually make something without complaining, which is now does. The text.c file is just a basic hello world with a #include "opener_api.h" line.

INC=-I/usr/local/include/ports \

-I/usr/local/include/ports/POSIX \

-I/usr/local/include/cip \

-I/usr/local/include/utils \

-Iinc/OpENer

DEF=-DPC_OPENER_ETHERNET_BUFFER_SIZE=100 \

-DRESTRICT=restrict

LIB=-lPOSIXPLATFORM \

-lCIP \

-lENET_ENCAP \

-lNVDATA \

-lPLATFORM_GENERIC

all:

gcc $(INC) $(DEF) -o test $(LIB) src/test.c

[Richard Wu]

Hi,

just clone the latest repo,  and cd  ./bin/posix/    and   setup_posix.sh, you will get the sample application built.

Best,

Richard

[Kyle Goodwin]

That does work and produces a functioning example but it doesn't do me any good because I am not going to build my application inside the library repo. I want to install the library and use it in my own project like every other library I use.

[martin...@gmail.com]

No worries, I am happy to help.

CMake was the only viable way for me to provide working build setups for Windows and Linux(-variants) and the different compilers (gcc, clang, MSVC, mingw - you name it) to be used, without spending almost my complete available time into that.

Parts of the build configuration is therefore in the corresponding cmake files for the platforms.

If you have ideas for improving the CMake build to make your external lib approach better, please go ahead, I will try to either support you, or if you have a bit of time, I can try to change it myself.

The original shared lib config war provided gratefully by the community, but during my daily work of implementing and fixing ENIP stack functionality I rarely used it myself.

If thats even easier, I can think about making a github action to create a prebuilt library.

cheers,

Martin

[Alois Zoitl]

To add here also my 5 cents. I'm a big fan of CMake Gui. As this
provides people like me who do not know CMake in deep a graphical
interface to setup the libraries for compilation.

> --
> You received this message because you are subscribed to the Google
> Groups "EIP Stack Group OpENer users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to
> eip-stack-group-open...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/eip-stack-group-opener-users/7a08beeb-99d5-42b6-899e-4687476ca194n%40googlegroups.com
> .

[Kyle Goodwin]

CMake makes a lot of sense for an agnostic library like this with many tagets. Not being a CMake user myself, I would be unable to improve it at all. Knowing what I know now I think I could probably update the build documentation so that others in my shoes could get to where I am without issue. Otherwise I think the build system itself works fine.

Having pre-built shared objects, archives, and include folders for a given release would go a long way to community usability. But given the number of targets I get why it's not already being done. Also how many people want to go about using it as an external library vs just modifying the sample application and calling it a day, I do not know. Perhaps hosting the specific binaries elsewhere and not in the tagged releases along with an application specific blog/tutorial type thing is a more conventional approach. I'll have to think about if I have time to work on something like that.

CMake GUI sounds interesting. Yet another thing to add to the list.