mulit data type UDT Messaging

[Rockwhale]

I have a project that requires messaging between two PLCs a few STRING, DINT, and INT values. We usually create something like a DINT[20] and convert the STRINGS and INTs to DINTs. This is then set up in a message to the other PLC. It has been requested that I create a generic UDT with multiple single element (DINTs INTs and STRINGs) and then message the UDT. Is it possible to use the MSG instruction to message a UDT that has a multi data type structure?

 

[dmroeder]

I have a project that requires messaging between two PLCs a few STRING, DINT, and INT values. We usually create something like a DINT[20] and convert the STRINGS and INTs to DINTs. This is then set up in a message to the other PLC. It has been requested that I create a generic UDT with multiple single element (DINTs INTs and STRINGs) and then message the UDT. Is it possible to use the MSG instruction to message a UDT that has a multi data type structure?

It is absolutely possible to message a UDT. I'd recommend that you create the UDT on one machine, then export it so that the other machine can import it. Rather than simply try to re-create the same UDT in the other machine. Everything has to match on both ends.

 

[Ken Roach]

Everything has to match on both ends.

To emphasize: the UDTs must be identical.

Each data type, and each data type name, and the order they are in, must be the same.

That's why import/export is best.

The classic CIP size limit is 504 bytes, but modern devices may support the large connection format which I think is 4 kilobytes.

 

[Rockwhale]

To emphasize: the UDTs must be identical.

Each data type, and each data type name, and the order they are in, must be the same.

That's why import/export is best.

The classic CIP size limit is 504 bytes, but modern devices may support the large connection format which I think is 4 kilobytes.

I did export/import the data type and am getting IOI Syntax Error when messaging

 

[daba]

I did export/import the data type and am getting IOI Syntax Error when messaging

I've never used Export/Import : I simply have both projects open on my PC and use good old Copy/Paste....


Copy the UDT from one project, and Paste it into the other, and it has never failed for me ....

 

[dmroeder]

I did export/import the data type and am getting IOI Syntax Error when messaging

Be sure that the tag's created in both PLC's match what the MSG is configured to read or write. Make sure "External Access" parameter for the tag is Read/Write, not None.

 

[daba]

Be sure that the tag's created in both PLC's match what the MSG is configured to read or write. Make sure "External Access" parameter for the tag is Read/Write, not None.

I was always under the impression that the unhelpful "IOI Syntax" error was due to incorrect size, structure, or naming inconsistences, and nothing to do with "External Access". But I but my teeth on this way back, so the external access attribute may be the culprit.

If the tags are created from the same (copied) UDT, then there should be no issues.

Maybe I'm old-school, but it works for me, in that a tag in a remote PLC that I am reading in to my PLC inherits the same tag-name...

An example (made-up) ...
Widget_Data : a tag in the Widget-making PLC that can be produced, message written to another PLC (ugh!), or message read by another PLC.

It will always convey the meaning that it is data created, and maintained by, the Widget PLC.

Meanwhile, in any other PLC that consumes, reads, or receives (yuk!) that data, it will always convey the meaning that the data is created, and maintained by, the Widget PLC.

See the same meaning ? It keeps it simple ....

So, any data that needs to be "got at" by another, create it's structure (UDT) and name it (TAG) so that the same UDT and tag-name can be used everywhere ! Tracing data becomes a doddle, and so easy to follow through the processes. e.g. Widget_Data.Type has the same meaning across all PLCs.

I'm all for keeping things simple, and I have seen some absolute nightmares in comms over the years ....

I have learnt that a simple solution to IOI Syntax Errors is to delete all the associated tags and UDTs from paired processors, and to use copy/paste to re-create them, both UDTs and Tags. Often sweeping things under the rug doesn't dissociate everything important.

 

[dmroeder]

I was always under the impression that the unhelpful "IOI Syntax" error was due to incorrect size, structure, or naming inconsistences, and nothing to do with "External Access". But I but my teeth on this way back, so the external access attribute may be the culprit.

If the tags are created from the same (copied) UDT, then there should be no issues.

Maybe I'm old-school, but it works for me, in that a tag in a remote PLC that I am reading in to my PLC inherits the same tag-name...

An example (made-up) ...
Widget_Data : a tag in the Widget-making PLC that can be produced, message written to another PLC (ugh!), or message read by another PLC.

It will always convey the meaning that it is data created, and maintained by, the Widget PLC.

Meanwhile, in any other PLC that consumes, reads, or receives (yuk!) that data, it will always convey the meaning that the data is created, and maintained by, the Widget PLC.

See the same meaning ? It keeps it simple ....

So, any data that needs to be "got at" by another, create it's structure (UDT) and name it (TAG) so that the same UDT and tag-name can be used everywhere ! Tracing data becomes a doddle, and so easy to follow through the processes. e.g. Widget_Data.Type has the same meaning across all PLCs.

I'm all for keeping things simple, and I have seen some absolute nightmares in comms over the years ....

I have learnt that a simple solution to IOI Syntax Errors is to delete all the associated tags and UDTs from paired processors, and to use copy/paste to re-create them, both UDTs and Tags. Often sweeping things under the rug doesn't dissociate everything important.

I saw a tech not that says the external access being None, or Read Only when writing will produce the IOI syntax error.

edit: BF20263

 

[daba]

I saw a tech not that says the external access being None, or Read Only when writing will produce the IOI syntax error.

edit: BF20263

Sounds logical that it should, now that I think about it.

To be fair, I extremely rarely use "External Access" = None, and fairly rarely = Read Only.

What I do find annoying is that you create just one tag as "Read Only", and that sets the style for subsequent tags you create. Very annoying to have to go back and edit those tags you didn't want read-only ....

Similar scenario is when you create a Controller-Scoped tag, it set's the scope for subsequent tag creations.

Case in Point - you attempt to create a program-scoped MSG tag, and the software tells you it can't because it has to be controller-scoped. So you change the scope, and create the MSG tag, then forget to reset the scope when you create the next 200 or so tags...... So, instead of the software just telling you it can't create a program-scoped MSG tag, why doesn't it just create it controller-scoped anyway, with pop-up message telling you what it did, and not remember that it has switched scope, so you can then proceed on your way unhindered...

 

[dmroeder]

What I do find annoying is that you create just one tag as "Read Only", and that sets the style for subsequent tags you create. Very annoying to have to go back and edit those tags you didn't want read-only ....

Haha, I did that just the other day.