Programmatically set up MSG instruction

Hi all,

I'm working with a bunch of 842E-M encoders. None of them are doing anything especially high speed/high accuracy, they're just helping me position a shuttle conveyor over one of 8 bins. Each of them have a homing sensor set up which I will use to zero the encoder.

I'm writing a simple AOI to manage the encoders, and I'd like to implement the zero-ing function within the AOI. However, the zero command can only be given using a MSG instruction.

I can use a MSG instruction within an AOI, as long as it's passed as an InOut parameter, and it can't be configured inside the AOI definition. Once I drop an instance of the AOI on a rung, I can click to configure each MSG instruction. This is fine, but setting up a dozen MSG instructions is tedious and prone to user error. The following parameters will need to be set:

Message Type: CIP Generic
Service Type: Set Attribute Single
Service Code: 10 (Hex)
Class: 23 (Hex)
Instance: 1
Attribute: 13 (Hex)
Source Element: [sub-element of AOI]
Source Length: 4
Path: [IP of encoder]


My question is, how much of this can/should I manipulate programatically within the AOI, to avoid the possibility of data entry error? I've read several posts where the indubitable Ken Roach warns that as soon as you do this, you're heading into unsupported territory. But at the end of the day, I figure the risk is low as I'm not dynamically configuring anything - it'll all be based on fixed settings, and it'll either work or it won't.

Here's my current thinking:

Message Type: I can't see any way to change this programmatically. Since the setting I need is the default setting anyway, probably not an issue.

Service Type: I again can't see any way to set this programmatically. Although, would I be correct in suggesting that if I leave it as "Custom" - which is the default - it will work anyway, as long as I ensure to put the "10" in the Service Code field? Which may be moot anyway because...

Service Code: I can't see any way to set this programmatically.

Class, Instance and Attribute: all appear to be easily able to be manipulated in the MESSAGE control block

Source Element: Can't see a way to manipulate this programatically

Source Length: Appears to be the REQ_LEN element of the control block

Path: This I would presumably have to set up manually. Although I am passing the module itself into the AOI as an InOut parameter, so if there's a clever way to poke it's path across to the MSG instruction, I'd be interested to hear it!

Anyone got ideas/suggestions/experience/helpful info to share?

If its a one off static config wouldn't it be easier just to create one, configure it and then just copy the tag. That would get you most of the settings.

If you are set on doing it programatically you could pass two msg blocks to the AIO with on being the prototype or template that you could copy to the working msg tag and parametise on startup but the inability to set the source element seems to be a big problem for that.

I did notice that the source must be stored somewhere in the message structure that we don't have access to because you can delete the message instruction and when you make a new one and add the message tag, the source element is still configured.

Geoff White said:

I did notice that the source must be stored somewhere in the message structure that we don't have access to because you can delete the message instruction and when you make a new one and add the message tag, the source element is still configured.

Click to expand...

Yeah, that's the sort of thing that makes me wonder if there's not a few more undocumented, unsupported tricks I can play here to make things simpler. I mean, I'm generally wary of getting cleverer than is really necessary, because I have to consider those who will maintain the system after I leave. But if it's all wrapped up in an AOI, and thoroughly tested and functional, and all the user has to understand is set this tag to 1 to zero the encoder, then I think that I'm probably okay in this instance.

Export as a rung (with AOI) will preserve MSG configuration. Then you can import it multiple times using Find/Replace during the import to create new set of AOI tags including new message instructions.
See example with Stratix and/or DLR Faceplate in the Sample Code library.

ACM is another method that allows similar process.

Although I am passing the module itself into the AOI as an InOut parameter, so if there's a clever way to poke it's path across to the MSG instruction

Click to expand...

If you are passing Module, then you can extract Path using GSV then copy it to the MSG: GSV Module <instance> Path <Path Tag>

Here is path example for AOI.
Please note that GSV returns only 2 bytes for LEN, while STRING needs 4 bytes. But in any case LEN is 82 max

Thanks, I'll give that a try!

As far as importing and using find/replace, my main desire here is to put together a package that I can come back to three or four years from now, drop in my AOI, and just have it work, without having to refresh myself on how all the messaging is supposed to work. So the more I can do inside the AOI, the better. My current plan is to put the MSG inside the AOI, do as much of the configuration in there as I can, and then put a "MSG configuration error" output on the AOI to indicate if it hasn't been set up correctly. Then when I go into the AOI to track down the source of that error, I'll find a rung comment with the remaining settings that need to be changed to make it work. Not quite as seamless as I like to make things, but better than digging through manuals every time!

You can't set MSG Service code programmatically, so Rung Export/Import is the only choice.

Yep. Once I get the path working, Service Code and Source Element are the only two outstanding things that I can't change. If I could get the source element to work I'd be happy, because the Service Code is forced to 10 if I set the service type to "Set Attribute Single". If that one drop-down is the only thing I have to set, I figure I'm close enough to self-contained. Is there any clever way to get the instance tagname of the AOI from within the AOI? e.g. if my AOI is called "Encoder_123" then the source tag for my MSG instruction will be "Encoder_123.PositionCommand". If there's some way of extracting the instance tag name within the AOI using a GSV or some other trick, then I could easily build the source element programatically. Of course, even then I still don't know of a way to enter it into the MSG configuration automatically.

Service type will not stay because it's a simple drop down driven by the service code.
I wrote many AOIs with messages so I know that there is no way around these.
You have to remember that all configuration is in the MSG tag. Every time you create a new tag, you start with blank list.
Source element must be Controller Scoped InOut parameter as well. It can't be part of AOI

If you want to try program parameters instead of AOI then you may have some luck: V31+ allow to use MSG as a Local Program Tag. I never got this going.

It is so frustrating trying to make an elegant AIO when you keep running into RA implementation limitations

Testify!