ControlLogix 3rd Party eds files

AutomationPrimer

Lifetime Supporting Member
Join Date
Oct 2011
Location
Nashville, Tennessee
Posts
4
I have been using A-B products for over 20 years and I know I have been able to import and use eds files before. I have added SMC valvebanks, Cognex cameras and even have a Parker-Hannafin device currently selectable on my v.19 software. The problem is I have imported 2 files using the Hardware Import Wizard in RSLinx and neither device appears in my list, even though Linx can see the .eds document number. Every topic I have found online says that v.20 makes it easier and suggests using the Generic Module; the thing is, the Numatics device I am trying to use has a date of 2008, meaning it has certainly been used by somebody by now. All topics also mention that the Add On Profile has to have been tested by the vendor; why would the vendor make eds files available for Ethernet/IP if you have to create a Generic Module? ;) I am super frustrated right now. I can't upgrade the customer system to v20+ because they don't have the software. My Generic Module files don't work. I also have a Phoenix I/O block with the same problem, I have the eds file but the vendor is now looking for instructions on how to set the Generic Module up. Why won't this work?
 
Welcome to the Forum !

Why would the vendor make EDS files available for EtherNet/IP if you have to create a Generic Module?

One of the requirements of ODVA conformance testing is that you provide an EDS file, even if it contains nothing but the basic File and Device sections that allow RSNetworx to identify it and show a graphical icon.

While EDS-based Add-On Profiles in Logix 5000 v20 and higher are clever in theory, I have not seen many done well in practice. Usually they appear in the I/O module selection list, but generate incorrect or incomplete Module-Defined Tags. There is no ODVA requirement for the EDS-based AOP to work, and no ODVA conformance test for it.

My Generic Module files don't work.... [T]he vendor is now looking for instructions on how to set the Generic Module up.

My recommendation is to keep troubleshooting the Generic Module. Every time I've had a Generic Module device that wouldn't work, the problem was solved by focusing on the error codes and the device configuration. It's not as easy as RA devices that pretty much plug-and-play with the configuration objects, but the software does give you tools and status codes.

The most common Generic Module problem is a data type mismatch, closely followed by a data size mismatch. Modular I/O and valve control devices are particularly tricky to get the I/O sizes correct upon.

Which exact Numatics device are you using ? What is the error code for the Generic Module connection ?
 
Thanks Ken!

The only error I get is Code 16#0005 Connection Request Error: Bad Class. The Numatics valve bank is a 501 series with 2 16 valve manifolds, controller is a G3EP100D0E40 (G3 with Ethernet/IP & auto-recovery module).

I have EDS files for both this and the Phoenix Axioline AXL E EIP DI16 module. I made my selections in the generic modules based on looking at the eds file; I'm sure of the Phoenix being SINT based but it's hard to tell with the Numatics. It looks like INT based but all numbers are in bytes. You would think it would be easy to simply read the eds for setting up the Generic module...

Even with the eds, Linx shows a yellow question mark rather than the icon.

Even if it is difficult, I would like to know the procedure for getting the eds to generate an AOP that ControlLogix will recognize. As I said, there is a Parker-Hannifin directory in my selection list and it got there somehow... I also remember using Cognex and SMC in v.16 applications, but I don't have that computer anymore and don't remember how I got the devices to appear for selection.

A-B has had years to work on this problem. GSD files and Siemens seem to play together much better, but comms. has never been Allen-Bradley's strong suit.
 
Even with the eds, Linx shows a yellow question mark rather than the icon.

This is worth pursuing. The yellow question mark is how RSLinx indicates that the device on the network does not match any registered EDS files.

First, let's check to be sure we're on the same platform. RA migrated to an SQL-based EDS registration method with Studio 5000 v21, but installing RSLinx Classic 3.x or RSNetworx v21 can cause that update to happen as well. If you have any of that software installed, the software that relied on the old Windows Registry based EDS management will not work.

Next, let's find out for certain what the identity of the devices on the network is. Right-click on them in RSLinx and select "Device Properties", and note the Vendor, Type, Code, and Major/Minor Rev.

Then open the EDS files you've registered in a text editor and be sure that the Vendor, Type, Code, and Major/Minor Rev match.

The 16#0005 "bad Class" error is common with Generic Modules when the device isn't set up with the correct Assembly numbers. It's absolutely unacceptable for a vendor to say "look at the EDS file" or "Ask Allen-Bradley" when you request the Assembly configuration details.
 
Latest software installed is v19.01. A couple of differences in the eds: ProdCode, ProdName. Everything else matches.

I also received settings from Phoenix, but they said the output size should be 0, which Logix won't allow.

I am still waiting for a response from the vendor, I may try editing the eds.

Thanks for the help!
 
AutomationPrimer said:
...All topics also mention that the Add On Profile has to have been tested by the vendor; why would the vendor make eds files available for Ethernet/IP if you have to create a Generic Module?...

I'll focus on the 501 Series here...

What specific EDS file are you trying to use from Numatics for the 501 Series?

Did you download something from from their website or did someone send you something stating that it's specifically for the 501 Series?

On their EDS download page, I filtered a search for your product...

File Category: EDS
Protocol: EtherNet/IP
Electronic Platform: G3
Valve Series: 501

Search results: 0

I then searched again with the Valve Series filtered out...

File Category: EDS
Protocol: EtherNet/IP
Electronic Platform: G3
Valve Series: Show All

Search results: 10

At the bottom of the list is the nearest EDS match to the 501, but it's for the 503 Series. So it appears there is no specific EDS file for the 501 Series?

Are you trying to use the 503 Series EDS file for the 501 Series?

AutomationPrimer said:
...it's hard to tell with the Numatics. It looks like INT based but all numbers are in bytes...

Looking at the EDS file for the 503 Series, it indicates...

Code:
[Params]
   Param1 =
      0,                            $ first field shall equal 0
      ,,                            $ path size,path
      0x0000,                       $ descriptor
      0xC7,                         $ [B]data type : 16-bit Unsigned Integer[/B]
      2,                            $ data size in bytes
      "Output Size",                $ name
      "",                           $ units
      "",                           $ help string
      0, 504, [B]16[/B],                   $ min, max, [B]default data values[/B]
      0,   0,  0, 0,                $ mult, dev, base, offset scaling not used
      0,   0,  0, 0,                $ mult, dev, base, offset link not used
      0;                            $ decimal places not used

   Param2 =
      0,                            $ first field shall equal 0
      ,,                            $ path size,path
      0x0000,                       $ descriptor
      0xC7,                         $ [B]data type : 16-bit Unsigned Integer[/B]
      2,                            $ data size in bytes
      "Input Size",                 $ name
      "",                           $ units
      "",                           $ help string
      0, 504, [B]16[/B],                   $ min, max, [B]default data values[/B]
      0,   0,  0, 0,                $ mult, dev, base, offset scaling not used
      0,   0,  0, 0,                $ mult, dev, base, offset link not used
      0;                            $ decimal places not used

So, the data type appears to be Integer, which would be Comm Format: "Data - INT".

However, note the default of "16". This is set for 16 integers, or 32 bytes of data for both the Input and Output parameters for this device. This "might" be too high for the lesser 501 Series Manifold? Again, this is only if you are using this specific EDS file. Also, the 501 might not be data type integer, but probably is? I don't think it really matters when all you are dealing with is Discrete I/O. Whether you read/write individual bits in the controller in a SINT, INT, or DINT should not matter so much. The data type can be more for efficient data transfer with Discrete I/O, than anything else, by packing them into larger blocks of transferred data.

Over on the Rockwell Knowledgebase I found this...

459291 - Numatics G3 Series EtherNet/IP module generic profile configuration
Access Level: TechConnect
Date Created: 10/11/2011 11:06 AM
Last Updated: 01/14/2015 03:36 PM

So, as of January this year, it also appears as though they've still not gotten around to creating any specific Add-on Profiles for the Numatics G3 Series manifolds, and advise you to use a Generic Module configuration. Whether they ever intend to do so is debatable?

I would not be "too" concerned with the EDS file route, but more with getting the Generic Module configured correctly for your specific valve setup. You could, without the specific info for the 501 Series, be playing around with EDS file settings for a while before getting it to work, if at all. However, have you tried right-clicking the device in RSLinx Classic to see if you can download the EDS file directly from the device? If you want to continue down the EDS file route, then by all means, work away.

If you use the manual linked in the KB technote...

http://www.numatics.com/common/deliverables/fieldbus/TDG3EPTM1-3EN.pdf

...which I'm sure you already have, then you should be able to deduce the correct I/O sizes to enter into the Generic Module's "Connection Parameters".

Page 83, outlines some data sizes for the different Comm Formats, but these are just starting values to enter, depending on which Comm Format is selected...

The Comm Format selects the communication format, or data type for the module, which appears to be integer in this case, or "Data - INT".

If Data - INT is selected, your I/O entries are at the indicated "16-bit" resolution. If you had 4 bytes of Input data, then you set the Input Size: 2 (16-bit).

As I'm sure you are aware, these manifolds provide a "Valve Side" and "Discrete Side". The Discrete Side allows you to add Discrete I/O Modules, and the Valve Side is where your Valve Solenoids go, obviously. So there is a possible I/O count from both sides, depending on the configuration.

If, for instance, you only have 2 x 16 valve banks, on the Valve Side, and no Discrete I/O Modules on the Discrete Side, then your I/O count is only based on the Valve Side, making it a "bit" simpler.

The total allowed on the Valve Side is 32 Valve Outputs, of which your 2 x 16 are using up. So that's 4 bytes of Output data. But also, for each Valve Output, you can have an enabled Status Input Bit, which means there is also 4 bytes of Input data. So, if you only have 2 x 16 Valves on the Valve Side, then this should be your Valve Side I/O Sizes, 4 bytes Input and 4 bytes Output. That translates to 2 integers Input and 2 integers Output, when set to Data - INT.

If you jump from Page 83 to Page 88, you will see an example of the Generic Module's setup. The Assembly Instances, for Input, Output and Configuration are provided here. Configuration Size should be left at "0".

Skip on again to Page 90 and you get an explanation of what I've outlined above regarding the I/O counts and how they are derived. Page 91 then gives you a Worksheet for toting up the I/O sizes. There is, you'll notice, a default Diagnostic Word of data (2 bytes) sent back no matter what the configuration is. This is probably for the Manifold itself? I've haven't read further on that.

So if you look at Example 2 on Page 96, you will see a setup using all 32 Valve Outputs. So the Valve Side I/O count is as per above. Add the 2 bytes for the Diagnostic Word and you get your total of 6 bytes Input and 4 bytes Output. This translates to 3 integers Input and 2 integers Output when set to Data - INT.

This is what I reckon you should enter for the I/O Sizes if you only have the 2 x 16 Valve banks added to the Valve Side of the Manifold, and have Data - INT selected for the Comm Format. If not INT, then try SINT with 6 Input and 4 Output sizes.

If you are struggling with this, give us the exact part number, or assembled part number of the Numatics G3 manifold configuration (as Ken already requested). The many different options can greatly affect the final I/O sizes you will require.

A side note to your last update...

I haven't looked at anything to do with Phoenix for you with regard to EDS files, but for the Generic Module properties, if a Vendor specifies an Output size of "0", then you must set the Comm Format to "Input Data - xxxx", as there is no Output data. So if you currently have "Data - DINT", then change it to "Input Data - DINT". This will actually disable the Output field.

Regards,
George
 
Ask George how to get to the pub. I dare you. :)

The fact that the Type and Code of the actual device differ from the EDS proves conclusively that the EDS is not for that device, so that's why you still get yellow question marks in the browse. It's not important to the RSLogix configuration, so I recommend setting that issue aside.

George's comments about doing an Input only connection if the Output size needs to be zero are exactly right.

The rest of his comments on how to derive the correct I/O sizes for the modular Numatics product are similarly valuable.
 
Ken Roach said:
Ask George how to get to the pub. I dare you.

Ken,

Getting there is the easy part!

Yesterday, the beer was Green. 🍻
This morning, only my gills were Green. :sick:

Happy belated St.Patrick's Day!

G.
 
Thanks guys, you've been very helpful! You've convinced me to pay the exorbitant lifetime member fee just for the pleasure of your company! :)

First the Phoenix block: The support tech came back with "try 101, 3; 193, 2; 1, 0"

I tried it and it didn't work. George responded with his suggestion to set the INT to Input Data -INT, still didn't work with assembly instance at 100, but when I tried it at 193 it worked! So, as with lots of other projects, it was a combination of advice and trial and error that made it work.

Next issue with the blocks, I used their IP Config tool to set the address. After powering down, it reverts to BootP again. I tried browsing it with Explorer, sure as heck there was an html page. All in German of course. I set the IPConfig from BootP to Static, it asked for a User Name and Password. Back to the vendor: he sent back "admin, private". First module, it worked and retained the address. Second module, it rejected the password! Third module and fourth module, password worked. I went back to the hotel.

This morning I checked my e-mail, no response yet from Phoenix on any of my issues yesterday... a guy walked in and suggested trying admin, admin... what the heck, I tried it and surprise, it worked!

I am posting this so that if others read this with the same issues they may get some resolution without having to go through the same process. I also plan to write a more general blog post concerning eds, gsd and Generic modules.

The frustrating thing about all of this is that the modules have been out for years and the Phoenix guy had to go to his specialist in Germany to get the answer. Even then it may not be right... who would have guessed 193 on the input assembly instance?

Then I had to go through the whole deal with the IP configuration... why even have an IP config tool if it doesn't set the address to static after it's done? And I also have four blocks with 2 different passwords. Once somebody has been through this procedure it should be posted somewhere you would think... and the eds files are still a problem.

Now for the Numatics valve bank. I do have the manual and made my guesses based on the pages you mentioned, but until a couple of missing connector arrive I have no way to test it. The eds file was sent to me by the vendor; it is actually a 580 rather than 501 or 503; they claim it is correct. We will see after I get the connectors. My initial issue with the Numatics was simply that I couldn't get the device to appear in my tree after importing the eds, even though there is a Parker Hannafin device visible. How did it get there if not via the import? This is the customer's computer I am using since it is permanently connected to the system, the device is not on my computer even though a Cognex and SMC device are.

Again, thanks for the help. If nothing else, it has inspired my next blog post!
 

Similar Topics

We need a ControlLogix processor to send and receive data from a 3rd party device using Ethernet. Basically we need to open a TCP connection...
Replies
4
Views
4,364
Hi everyone i have a customer, who wants to show an alarm on the machine, if the I/O forces are enabled and set, on at ControlLogix L81E with...
Replies
3
Views
138
Does anyone know of a way to detect if someone is online with the controller in ControlLogix (from logic) I'm thinking that maybe there is a CIP...
Replies
7
Views
293
I've never paid attention to this, is this normal?
Replies
13
Views
419
Hi. I need suggestions. I want accumulate operating hours from a simple XIC condition, so I'm thinking a RTO with a 60000 or 3 600 000 preset, 1...
Replies
7
Views
225
Back
Top Bottom