Skip to main content
T
Tanquen12-Amethyst
12-Amethyst
December 14, 2022
Solved

How to know when KEPServerEX will require its own tags? Why only for writes?

  • December 14, 2022
  • 2 replies
  • 4305 views

I'm working on a system with around 12 Channels and different PLCs with different KEPServerEX drivers.

We converted a PLC program to run on a test 1756-L73 ControlLogix 5570 controller. I only had to update the Wonderware InTouch tags items/addresses in the database from something like (B3:7/3) to (B3[7].3) and everything seemed to work fine.

Now we have the production PLC and its a 1769-L33ER CompactLogix 5370 Controller. Again, everything seemed to work until we tried to write to an address in the PLC. All addresses can be read but the only way to write to an address in this PLC is to create a tag in KEPServerEX and use the OPC quick client to change the value. I can then change the item in the InTouch DB to the new test KEPServerEX tag and that will work.

None of the existing PLCs in the KEPServerEX configuration have tags configured. Just changing from a ControlLogix to CompactLogix requires tags to be added into KEPServerEX but only for writes?

I hope I'm missing a setting or something.

Best answer by aservetas

There is no easy way to determine when tags will be required with this driver due to the ability to set a default datatype within the device properties.

 

During the device creation process, the wizard prompts the user to define a default data type for all tags requested from the device. If this is left unchanged (and set to 'Default') then the driver will not know what the data type of the symbolic tag name is until the tag is first read by the driver (unless it is defined in a static tag within the project manually or through the use of Automatic Tag Generation).

 

OPC Clients, when issuing a dynamic address request to the server, will be notified of the updated data type for future use in both read and write operations. It is up to the client to act upon that notification and update the item reference accordingly. Our OPC Quick Client has this feature.

 

Non-OPC client applications (such as Wonderware InTouch) do not receive the data type modification notification, so the client may not have the correct data type when issuing a write request to the server. Subsequently, the server will reject the write request due to the data type mismatch.

 

The error code indicating a data type mismatch is returned to OPC client applications in the WriteResponse() notification and this can be seen in OPC Diagnostics, however non-OPC client applications do not have a visible diagnostics layer, so no error code can be seen and the write attempt appears to fail for no valid reason.

 

There are two options to prevent this from happening.

 

First: Set the default data type in the Device Properties to the most common data type programmed in the controller for all symbolic tag items. That gives the driver a data type to use when attempting to complete the dynamic item write request operation. Most of the time there is a chance that it will succeed.

 

Second (preferred): Append the item definition in the WonderWare/InTouch Tagname Dictionary with the @[Data Type] modifier of the item that is being called from the server's address space. This is common practice and is recommended with all non-OPC client applications.

 

Example:

 

Channel1.Device1.Tag1@Float

or

Channel1.Device1.Tag2@Boolean

 

For Wonderware/InTouch, the channel name and device name are typically aliased to match the Topics defined, so all you should need to modify in the Tagname Dictionary is the Item syntax to contain the @[Data Type] modifier.

 

Best regards,

 

Andy Servetas
Principal Technical Support Engineer | Kepware Technologies

2 replies

T
Tanquen12-AmethystAuthor
12-Amethyst
December 14, 2022

P.S.

They also wanted to use the latest PLC firmware so we are using 34 on the 1769-L33ER CompactLogix 5370 Controller. A few months ago I'd downloaded the latest version of KEPServerEX 6.11.XX and it's manual says (if I'm reading it correctly) it supports upto version 33.11 so I downloaded 6.12 and it list upto 34 but it did not help. Guessing the 1769-L33ER is the same as 1769-L3? There is no 1769-L33ER in the list.

 

CompactLogix 5370 (1769-L3)             20.11 - 33.11

 

Tanquen_0-1671042258462.png

 

A
aservetas15-MoonstoneAnswer
15-Moonstone
January 11, 2023

There is no easy way to determine when tags will be required with this driver due to the ability to set a default datatype within the device properties.

 

During the device creation process, the wizard prompts the user to define a default data type for all tags requested from the device. If this is left unchanged (and set to 'Default') then the driver will not know what the data type of the symbolic tag name is until the tag is first read by the driver (unless it is defined in a static tag within the project manually or through the use of Automatic Tag Generation).

 

OPC Clients, when issuing a dynamic address request to the server, will be notified of the updated data type for future use in both read and write operations. It is up to the client to act upon that notification and update the item reference accordingly. Our OPC Quick Client has this feature.

 

Non-OPC client applications (such as Wonderware InTouch) do not receive the data type modification notification, so the client may not have the correct data type when issuing a write request to the server. Subsequently, the server will reject the write request due to the data type mismatch.

 

The error code indicating a data type mismatch is returned to OPC client applications in the WriteResponse() notification and this can be seen in OPC Diagnostics, however non-OPC client applications do not have a visible diagnostics layer, so no error code can be seen and the write attempt appears to fail for no valid reason.

 

There are two options to prevent this from happening.

 

First: Set the default data type in the Device Properties to the most common data type programmed in the controller for all symbolic tag items. That gives the driver a data type to use when attempting to complete the dynamic item write request operation. Most of the time there is a chance that it will succeed.

 

Second (preferred): Append the item definition in the WonderWare/InTouch Tagname Dictionary with the @[Data Type] modifier of the item that is being called from the server's address space. This is common practice and is recommended with all non-OPC client applications.

 

Example:

 

Channel1.Device1.Tag1@Float

or

Channel1.Device1.Tag2@Boolean

 

For Wonderware/InTouch, the channel name and device name are typically aliased to match the Topics defined, so all you should need to modify in the Tagname Dictionary is the Item syntax to contain the @[Data Type] modifier.

 

Best regards,

 

Andy Servetas
Principal Technical Support Engineer | Kepware Technologies

T
Tanquen12-AmethystAuthor
12-Amethyst
January 11, 2023

I had found this out some time ago by looking at the larger InTouch app that had many different PLC in it and I saw that some CMD tags that needed to write to the PLC had the "@ boolean" appended to the PLC item address in the the InTouch DB.

 

Thanks so much for taking the time to answer this question.

 

"First: Set the default data type in the Device Properties to the most common data type"

I guess you could do that for one, like discretes but then integers and floats would not work. It's too bad there is not other way for KEPServerEX to glean the data type as configured in the InTouch DB.

 

 

Terms & ConditionsCookie settingsAccessibility statement