Adding a new data types

[Geospark]

Originally Posted by ASF

...upset by things on the internet...

Yeah, coz everyone knows that people ain't real on the Internet!

Originally Posted by ASF

...If the OP is still following...

Hopefully the OP is (but remember, there'll likely be many more readers in the days and years to come ).

Another feature available for the PowerFlex 525 drives that I thought of after is the complimentary FactoryTalk View Faceplate to further enhance the AOI experience. This can display a multitude of valuable drive information at runtime, for those using this visualization platform.

Did you get to play with v31 after?

[ASF]

Originally Posted by Geospark

Did you get to play with v31 after?

I had a brief play around. My first thought was "ow, my eyes!" and after 10 or 15 minutes poking around I stand by that assessment. It's genuinely fatiguing to look at. My graphic design friends would be in the foetal position if I made them use this software for more than an hour.

Also the new toolbar for the PLC online/offline etc selector is very poorly arranged and makes me wonder what they were trying to achieve. Was there actually a reason for the complete overhaul, or did they just lose the design files for the old one and have to metaphorically throw all the components into a shoebox and sticky tape them together to make it work the night before launch?

The drive setup does look to be more useful than previous iterations, but not terribly intuitive at first glance. Although I'd attribute at least part of that impression to the fact that the graphics were starting to hurt my head by that stage.

[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

[LoganB]

I would totally pay money to listen to a podcast with George and ASF talking about controls and engineering.

[ASF]

Originally Posted by LoganB

I would totally pay money to listen to a podcast with George and ASF talking about controls and engineering.

How nice to hear! I rather suspect that many people here would pay money to have us shut up

[LoganB]

Originally Posted by ASF

How nice to hear! I rather suspect that many people here would pay money to have us shut up