A passing argument...
pierrer said:
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.
pierrer said:
...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.
pierrer said:
...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
pierrer said:
...Maybe i should find another way to monitor the communication that would not require me to use a GSV instruction.
ASF said:
...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