A few beginner questions

[JEff Noll]

First let me apologize for me ignorance, industrial controls isn't our business so I'm pretty new to CIP.

We have a new project that is running on an arm with linux that needs to communicate with a CompactLogix. The current implementation has an xcp server running on it for data exchange. It seems opener would be a pretty good drop in replacement of sorts.

For another project we're using libplc to push and pull data from a plc. So my initial thinking is I should be able to push/pull data from an opener server using libplc as a simple test.

However, looking at the sample I'm a bit lost on the concept of a plc tag. sampleapplication.c seems to what to use int values to specify data requests. I'm only familiar with string tag names for data lookup.

Am I missing something obvious? Or totally missing the boat?

Thanks!

[Martin Melik-Merkumians]

Hi,

no need to apologize. The group is exactly here to answer such questions.

To be honest I don't know scp or libplc, so I cannot really make comparisons here.

OpENer is first an EtherNet/IP adapter - so it is a fieldbus server device, and although it is possible to read and write PLC tags via EtherNet/IP, it is not part of the ENIP specification, as far as I know it. This is more a vendor- and version-specific feature.

But before we talk about accessing data on an PLC, I want to mention, that OpENer is a pure server device. So it is passive, waiting for a PLC to connect to it, and specifying which data shall be exchanged. So no single sided push via OpENer without modifications.

The standard way for accessing data in EtherNet/IP is via the Assembly object, which is an array of bytes, where you can put arbitrary data. If you create an input and an output assembly, you can establish some sort of bidirectional communication, where the input assembly receives data and the output assembly sends the data, but also unidirectional connections are possible.

So based on your question I am not sure if OpENer is the right tool for you. If you want to be able to read PLC tags directly, then OpENer is probably not the right thing to use. If your goal is to establish some kind of I/O (sort of real-time'ish) communication, then OpENer can serve your case most likely, as described above with the assemblies.

If you only want to sporadically read and write tags without hassle, then there are more suited solutions out there.

Best regards,

Martin

[JEff Noll]

Ok, I think I'm starting to get this. I think this is still the solution i'm looking for once I understand it a bit more. The end goal is to have opener running on a linux box as a server with an external Allen Bradley PLC pushing and pulling data. We've done the same sort of thing with PLC -> controller comm for both profi and modbus tcp servers.

If I understand this correctly the simplest way is to expose 2 arrays in opener, one for input, the other output. Basically what the sample app does. On the PLC side I'll have to do the mapping to and from the array whatever local tags I want. But even at that simple level I'm at a bit of loss to how the PLC knows how to request data. For example in how does it know #define DEMO_APP_INPUT_ASSEMBLY_NUM 100 should be sent to get the inputs, 150 to write data, etc. For example how does it know send a 100 and 32 bytes of data, or 150 and read 32 bytes.

In fact is there a specific module type I have to add in studio 5000 in the Ethernet I/O configuration to even let the PLC project know how and where to get this data? Maybe that's where I'm missing it.

[Amin Ramazanifar]

Hi JEff

In the past I used the industrial Communication Library in Labview to communicate with Allen Bradley PLC using Eithernet/IP class I (implicit message) which is similar to OpenER. In the RSLogix you need to add a Generic module under your communication module:

 and specify the IP address and data type and assembly numbers and data sizes. They should match your setting in your C program:

Last, if you are still interested in reading and writing PLC tags (Ethernet/IP Class 3 or explicit messages) I know few libraries in Python programming language that are very easy to use. Please check

pycomm or pylogix 

in GitHub.

Thank you

[Bill McCormick]

... also, there's an EDS file in the data dir ... opener_sample_app.exs. Use the Logix5000 EDS import tool to import. You can change the ProdName through devicedata.h.in, to give it more custom look and feel.

You can also using the EZ-EDS tool to roll your own EDS file, and make a more fancy looking interface on the PLC side; something more than a generic array of SINT's.

I just finished adding support for shared libs, so you could make you're own executable that relies less on the given sampleapplication. I used it for a ROS application here if you want to see what I did.

The sample application also includes support for an EXPLICIT assembly, where a PLC MSG instruction would *request* data (that might be different from what you shove in the INPUT ASSEMBLY), but I've not been able to make it work.

-Bill

--
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 post to this group, send email to eip-stack-grou...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eip-stack-group-opener-users/e13705be-ef78-4979-b932-bdf166044f87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bill McCormick]

Sorry, opener_sample_app.eds

[JEff Noll]

Perfect. Now I get it. I had missed the eds file when I was looking through the git project. That's totally the missing piece to the puzzle.

thanks!

[JEff Noll]

Perfect. Now I get it. I had missed the eds file when I was looking through the git project. That's totally the missing piece to the puzzle.

thanks!

Along with the adding of the generic ethernet. For whatever reason I couldn't find that with any of the filters but unfiltered I found it in the big list. So we're good to go now.