Adding a new data types

[pierrer]

Hi,

I'm currently trying to use a GSV instruction in an AOI but i get block when it's time to create the parameter for the instance name.

I do know that i need to create an IN/OUT parameter. My problem is to give the right data type to the parameter (which is the MODULE data type).

Currently, i don't have the MODULE data type in the predefined one. Can someone help me add the correct data type in my list or help me recreate the data type?

Anything that i could try to copy to make my own data type ressembling the one i need Anything that i could directly import to my program would be even more appreciated.

Or maybe just redirect me in the right direction

Thanks in advance

[JaxGTO]

Unfortunately you can't pass a module in a AOI because it's not a data type. It is an exact module reference you select from the available modules in the IO tree.

[collinsd70]

Correct me if im wrong....

But I did this exact same thing the other day. To pass a data type of 'MODULE' in an AOI; you need to be using RSLogix V24 or higher. It needs to declared as an In/Out Parameter.

When I rolled back the version- it then became incompatible; then the only solution was the collect the GSV outside the AOI then pass in as an Input Parameter.

[Geospark]

Originally Posted by JaxGTO

Unfortunately you can't pass a module in a AOI because it's not a data type. It is an exact module reference you select from the available modules in the IO tree.

Hi again,

For one of your Logix 5000 projects, where you have modules added to the I/O Configuration, if you go to the Module-defined section in the left hand side explorer, you will see the generic module-defined data types for all your added modules. Incidentally, if you've previously added certain modules but then deleted them, their module-defined data types may still be there. If a module type is currently not used in the project then the data types may be deleted. That's just a pedantic "clean-up" tip for those interested (but may also be useful to the OP here).

The actual instances for each module type added and their module-defined data type tags are of course viewable under Controller Tags.

So while they are indeed an "exact module reference" i.e. predefined, of which we choose to add as I/O modules, there are still made up of module-defined data types, of which are transparent to the End User, and usable with an AOI.

But, only under certain circumstances...

Originally Posted by collinsd70

Correct me if im wrong....

But I did this exact same thing the other day. To pass a data type of 'MODULE' in an AOI; you need to be using RSLogix V24 or higher. It needs to declared as an In/Out Parameter.

When I rolled back the version- it then became incompatible; then the only solution was the collect the GSV outside the AOI then pass in as an Input Parameter.

No correction required. You are on the money...

Before Logix Designer v24 you had the individual IN and OUT parameters available within the definition of an AOI. These parameters pass AOI argument tags by value only and are synchronous with the execution of the AOI instance, and hence slower. The value is referenced once during the execution of the AOI and is then not referenced again until the next execution. They are also restricted to the atomic data types only - SINT, INT, DINT, REAL and BOOL.

At v24 and above, the individual INOUT parameter was added, among other things. This parameter now allows us to pass AOI argument tags by reference. As such the value of the tags are not passed, only the reference. It is therefore asynchronous to the execution of the AOI, and hence faster. The tag is referenced during the execution of the AOI and may change again during a single execution (important to know). Most importantly here, it is not restricted to just the atomic data types but also supports arrays and structures i.e. message, motion group, all axis, and module data types.

So now we know that as of v24 we can use module-defined data types as a reference with INOUT parameters, but what good is it?...

New feature in Studio 5000 v24.00 -

Access to the Module Object

You can now reference a hardware module from within an Add-On Instruction using an InOut parameter with the MODULE data type. Full access to the hardware module from inside the Add-On Instruction allows you to generically reference the hardware module in the Add-On Instruction program code, and then connect to a specific hardware module through the InOut parameter in a GSV or SSV instruction. This includes access to the path to the module through the Path attribute in the instruction. You can then reuse the Add-On Instruction with different hardware modules without changing the Add-On Instruction program code. You can also write reusable, encapsulated routines to abstract the hardware so that you do not have to identify a particular hardware module in the routine. These features give you an increased amount of encapsulation which allows for a higher degree of modularity.

Nice, but how does one implement it?...

676548 - Using GSV instruction in AOI in RSlogix5000 v24 and higher
Access Level: Everyone

pierrer,

I've my fingers crossed that you are using v24 or above?...

Regards,
George

[collinsd70]

Good stuff George 👍🏻, thanks for clarifying this..

If the OP needs some examples, please let me know.




Regards

Daniel

[pierrer]

I've my fingers crossed that you are using v24 or above?... - Geospark

Sadly i only have the version 20. Is there a way to create my own data type that would ressemble the MODULE one and that i could use to replace it in my version 20?

Or is my only solution to migrate to version 24 or higher? (if i would prefer not to execute a GSV instruction outside of the AOI)

Just to be clear, i want to use the GSV instruction to monitor the communication between my program and my drives PowerFlex 525. Maybe i should find another way to monitor the communication that would not require me to use a GSV instruction.

[collinsd70]

Hi Pierrer

I had the same thought as you...the only solution I could think of was to try and pass MODULE in as a STRING but unfortunatley you cannot pass STRINGs into an AOI.

The only solution I have is to enable the GSV outside the AOI then pass in.

On some of my PLCs running <v24 I am using the technique as above for all EtherNet/IP Nodes. Any other PLC running >=V24 I am using the AOI fully encapsulated with the GSVs


Regards

Daniel

[pierrer]

The only solution I have is to enable the GSV outside the AOI then pass in.
- collinsd70

Thanks for the info.

I also think I'm gonna have to use this method to have my AOI working.

[daba]

Originally Posted by Geospark

Before Logix Designer v24 you had the individual IN and OUT parameters available within the definition of an AOI. These parameters pass AOI argument tags by value only and are synchronous with the execution of the AOI instance, and hence slower. The value is referenced once during the execution of the AOI and is then not referenced again until the next execution. They are also restricted to the atomic data types only - SINT, INT, DINT, REAL and BOOL.

At v24 and above, the individual INOUT parameter was added, among other things. This parameter now allows us to pass AOI argument tags by reference. As such the value of the tags are not passed, only the reference. It is therefore asynchronous to the execution of the AOI, and hence faster. The tag is referenced during the execution of the AOI and may change again during a single execution (important to know). Most importantly here, it is not restricted to just the atomic data types but also supports arrays and structures i.e. message, motion group, all axis, and module data types

George, the InOut Parameter type has been around since AOIs were introduced in version 16 ...

[daba]

I believe I have just done what the OP wanted - I have added an InOut parameter called "ModuleTag", of data-type "AB_1756_DI:C:0" (just one I chose at random), to an AOI definition. Then in the logic of the AOI I can reference anything in that parameter tag, and, because it is passed by reference, I can read and write without the need for separate In and Out parameters....


This is Version 16 I'm working on for a client...


EDIT : Forgot the AOI passing the module-defined tag ....

[Geospark]

Originally Posted by daba

George, the InOut Parameter type has been around since AOIs were introduced in version 16 ...

Yep, good spot daba! I've used them for years so that should have stood out to me. But I wrote that without re-reading it or thinking beyond what I was recalling at the time. Something I normally don't do too often.

I accidentally, or lazily, referenced the InOut parameters as having been a new addition in v24 but now that I think about it I was recalling the addition of the PROGRAM scope parameters feature added at v24, which of course also includes InOut parameters.

What was, definitely, and more importantly here, added at v24 is the predefined MODULE data type that I think the OP was referring to not having in their v20 project...

Originally Posted by pierrer

...I'm currently trying to use a GSV instruction in an AOI but i get block when it's time to create the parameter for the instance name.

I do know that i need to create an IN/OUT parameter. My problem is to give the right data type to the parameter (which is the MODULE data type).

Currently, i don't have the MODULE data type in the predefined one. Can someone help me add the correct data type in my list or help me recreate the data type?...

You must be using v24 or higher to use the predefined "MODULE" data type anywhere in the project. That is not a specific module-defined data type, such as "AB_1756_DI:C:0", but a generic module data type specifically called "MODULE". As I mentioned, it is a special Module class used to access the CIP Module Object within modules under the I/O Configuration.

Originally Posted by daba

I believe I have just done what the OP wanted - I have added an InOut parameter called "ModuleTag", of data-type "AB_1756_DI:C:0" (just one I chose at random), to an AOI definition....

If you read their comments above, I don't think that is exactly what they wanted?...

The OP, I gather, already knows that they can select any specific module-defined data type from their project for an AOI InOut parameter, as you have demonstrated. But because this is a specific data type reference, it ties the AOI definition to that specific module data type, for each instance of the AOI in the project. Now that has always been fine if you want to create a generic AOI for a particular data type, like an input or output module where there are several of those type modules in the project. But the slight downside has always been that if you have several different I/O modules with different module-defined data types then you must create a separate AOI referencing each of those specific module-defined data types. Not a huge pain, but a bit of time all the same. Of course, once you've created an AOI for one project that references a particular module-defined data type, then you can reuse it in subsequent projects. This gives us a certain level of generic or encapsulated module access, but not total.

What the OP is trying to do, I gather, is generically reference any module-defined data type from within a single AOI definition, so as to allow the generic selection of whichever module-defined data type is required when the AOI instance is created. By creating an InOut parameter of data type "MODULE", which is only available since v24, we can now generically reference any module-defined data type at AOI instance creation, and then select the actual module to reference.

This "new" feature (MODULE data type) now makes module access from within an AOI, and especially using GSV/SSV, truly generic, encapsulated and reusable. A single AOI for all module access. Something users were looking to have introduced for a good while before v24 came along.

It's a subtle but powerful change and perhaps hard to spot at first, unless you've used it or read about it. But welcome nonetheless.

I'm sure the OP could confirm for us whether all their "references" here to "MODULE" were specifically referring to the new "MODULE" data type introduced at v24, or to module-defined data types in general?

Thanks again for the spot!

Regards,
George

[pierrer]

Just to confirm, i was really talking about the "MODULE" data type as i wanted to have a way to specify an AOI which one of my drives it needs to poll, throught a "GSV" instruction, to monitor the communication of the drive with my PLC.

Hope it's clearer this way even if i doubt it little bit

[ASF]

I just recently updated my Powerflex 525 AOI to use the GSV online check exactly as you're wanting to do. Before that, I had another method of checking if the drive was online from within the AOI. It's quick-and-dirty, but it works.


There are two BOOL tags within your PF525 data structure (whose exact name I can't recall off the top of my head) called something similar to CommLogicCtrl and CommFreqCtrl. The first is true when the VSD is configured to receive a start/stop command by ethernet, and the second is true when the VSD is configured to use the ethernet speed reference. Now, I don't actually use these tags for anything within my AOI, because, well, if I'm not controlling start stop or speed over ethernet, why am I talking to it at all? So, to check if the drive is online, I unlatch those two bits and wait 250ms. If the drive is online and communicating normally, it'll turn at least one of them back on sometime in that 250ms (as long as your drive is configured to update at least that fast, adjust the time if not). So, after my 250ms is up, if both bits are still off, the drive is offline. If at least one bit has turned back on, the drive is online, and I turn them off again ready for the next test in 250ms time.

The reason I use both tags is because there are some instances where I've had to use hardwired start/stop logic and give the speed command over ethernet, or where I start/stop the drive over ethernet but the speed command is by analog signal from a legacy device. It's very unlikely that you'll ever be giving start/stop and comms from a source other than ethernet, and yet still trying to talk with the drive via ethernet. I've had it happen exactly twice since the PF525 was released, and I use them a lot.


Hope that helps!

[Geospark]

Originally Posted by pierrer

Sadly i only have the version 20. Is there a way to create my own data type that would ressemble the MODULE one and that i could use to replace it in my version 20?...

To answer your question at face value - you can replicate many Predefined or Module-Defined data type structures by creating a User-defined Data Type (UDT). However, there are still a couple of things here that would prevent you from doing so -

1. The "MODULE" data type is listed under the Predefined data types but it is not exposed to the End User. You cannot create a module reference tag of your own without knowing its structure. It is special and only used to access the generic Module Object within a CIP module device. It is, in fact, not really a data type but more a CIP "Class". Also, while "Module-Defined" data types for hardware modules are exposed to the End User, they too are structures...

2. For v20 - (and as I've explained) you only have the "Input" and "Output" parameters available for an AOI definition which only pass reference tag values. These parameters do not support passing structured data types. Only the "InOut" parameter at v24 or higher supports the passing of structured data types or arrays, and by reference, not value.

So even if you could create your own "MODULE" or "Module-Defined" data types, you have no way of passing them with an AOI for a GSV/SSV instruction to reference them.

Originally Posted by pierrer

...Or is my only solution to migrate to version 24 or higher? (if i would prefer not to execute a GSV instruction outside of the AOI)...

Yes, if trying to implement a GSV method to accomplish your goal.

Originally Posted by pierrer

...Just to be clear, i want to use the GSV instruction to monitor the communication between my program and my drives PowerFlex 525...think I'm gonna have to use this method to have my AOI working.

Using a GSV to access module "EntryStatus" and "FaultCode" attributes is, in my opinion, the best way to determine if a module is status "Running" with respect to the controller. You can also timestamp the event so you can retrospectively see when a non-running or fault condition may have occurred. If you still want to consider using the GSV instruction in v20 to accomplish your goal...

47624 - RSLogix 5000: Using the GSV Instruction to Check Module Status
Access Level: TechConnect

1049147 - How can I monitor the Ethernet connection between my PowerFlex 525 drive and my controller?
Access Level: Everyone

552012 - PowerFlex Drives: Monitoring the Connection Status of a drive via a ControlLogix Processor
Access Level: Everyone

Originally Posted by pierrer

...Maybe i should find another way to monitor the communication that would not require me to use a GSV instruction.

Originally Posted by ASF

...I had another method of checking if the drive was online from within the AOI. It's quick-and-dirty, but it works.

There are two BOOL tags within your PF525 data structure (whose exact name I can't recall off the top of my head) called something similar to CommLogicCtrl and CommFreqCtrl...

Hi my friend, just me "hole picking". I know it's "quick-and-dirty" and has probably worked and been available for all "your" drive configurations, but just a little "did-you-know?"...

Input Status Tag:
CommFreqCnt = Main Frequency -
0 = Not Controlled by Active Com
1 = Controlled by Active Com

Input Status Tag:
CommLogicCnt = Operation Command -
0 = Not Controlled by Active Com
1 = Controlled by Active Com

These two Logic Status Word input tags are "Module-Defined" when you are using "Velocity" Mode. Within the Drive AOP, as you know, we can change this to "Position" Mode. This "Mode Select" option changes parameter C122 [Cmd Stat Sel] in the drive. If an application is using Position Mode, say with an Encoder feedback, then the Logic control is usually via the feedback and the speed reference is a preset frequency. As such, these two Logic Status Word input tags are not required for this Mode and are therefore not "Module-Defined".

Now you may say...

"...in that case why would I still have Ethernet communications to a drive in this sort of Position Mode?..."

Well, there may be a few reasons, such as wanting the ability to programatically or user modify a preset frequency for various steps, etc. But the simplest reason may also be just to monitor a drive's status, as we're considering here.

Granted, Position Mode may not be as common for many applications out there, and you may certainly have next to never worked on one with all the PowerFlex 525's you've done, but they do exist. That's the only reason I would mention it. If someone with a Positioning Mode application was attempting your method in an older project then they would certainly have been scratching their head thinking "what's he on about?". Other than that, not a thing in the World wrong with it.

As an alternative method, here is another little "did-you-know?"...

Note: This is available on the PowerFlex 525 only and is only for the Embedded EtherNet/IP interface (not the optional 25-COMM-E2P)

If you can afford, or have a spare Input Datalink, then way down the vast list, and belonging to the Fault and Diagnostic Group, you should find "683 - Com Sts-Emb Enet" - (type 683 in the field to find it quickly). This will Module-Define an extra INT input tag - "...I.ComSts_EmbEnet".

F683 reads back an INT but normally when communications are healthy the INT value will only display, or "appear" to display (I'll explain in a minute), as 3 digits decimal or one-hundred-and-eleven "111" (can be 4 digits if a higher level error is present; max value = 1911). Of the 3 digits normally observed, the least significant Digit 1 (right-most) represents the Embedded EtherNet/IP Receive (Rx) activity and the second or "middle" Digit 2 represents its Transmit (Tx) activity. Digit 3 (left-most) represents the Embedded EtherNet/IP "Active/Inactive/Faulted" status.

At the default module RPI of 20ms, and with a healthy connection to the drive, the 3 digits will appear to be static at "111", but in reality the Rx/Tx digit updates are actually faster than the software can display their transitions. At this RPI, if you watch for long enough, you may see the values "flicker" to "0" once in awhile. For demonstration, if you increase the RPI to say 100ms or higher, you may then start to see the Rx/Tx digits transition.

One method here could be to toggle a condition based on one or both of these transitions, and if either are static for a preset time, then flag a comms loss condition. I've not used this method and have only considered using it before, so it would need testing.

Similar to ASF's method, I have used this method before - if you continuously map this input INT to another INT and then continuously zero the value of the mapped INT, then the module should indirectly write a non-zero value back to the mapped INT after the next scheduled RPI, else time out and flag a comms loss condition, if the value equals zero for the preset time. You could also zero and mask examine just Digit 3 for this purpose but I don't go that far.

Mixed into that - you also may have the scenario where the comms have not been lost but the Embedded EtherNet/IP interface may be "Not Active" (Digit 3 = 0), or the interface may be connected but "Faulted" (Digit 3 = 9).

I also don't go this far, but you could additionally examine the Digit 3 value for "0" or "9" (or equals "1") value before you zero it to check comms. This way you can halt the zero instruction and flag a "Not Active" or "Faulted" condition instead.



I also know that for some applications Datalinks can either be available or only to be used at a premium. In those cases there is one other method similar to the "lets zero something and monitor it for a change" method above (and ASF's). You could similarly look to the value of the ever present Module-Defined Logic Status Word - "...I.DriveStatus". This INT is the one that changes in its content based on which Mode (Velocity/Position) is selected. But we're not concerned here with the contents, just the INT value.

Without getting into what each BOOL within the INT represents for each Mode; suffice to say that for either Mode, the Logic Status Word INT should always be a non-zero value when there are status conditions being actively reported back from the drive. So if we likewise continuously zero a mapped copy of this INT, it should refresh to a non-zero value after the next RPI. So again, we can time this zero value out to a comms loss condition.

This cat is getting well flayed!

Regards,
George

[ASF]

Originally Posted by Geospark

Now you may say...

"...in that case why would I still have Ethernet communications to a drive in this sort of Position Mode?..."

Well, there may be a few reasons...

I knew someone would call me out on that one, and I rather suspected it would be you

There certainly are applications where my approach doesn't work - in my 7 years as a systems integrator I have found exactly two. So in both those cases, I used the GSV method instead. I could have used another datalink as you also suggested, but my PF525 AOI has the datalinks fully utilised.

If you don't have GSV available due to firmware restrictions, and/or your datalinks are all used up doing more useful things than checking to see if your drive is online, my quick-and-dirty fix will in most applications get you up and running (which is, let's be honest, pretty much the motto of quick-and-dirty solutions everywhere)