# Specific Change to system.opc.writeValue in 8.1.27 **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [September 5, 2023, 1:50pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763 "2023-09-05T13:50:57Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![rbachman](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rbachman/32/43718_2.png) [@rbachman](https://forum.inductiveautomation.com/u/rbachman)\ **Post date:** [September 5, 2023, 1:50pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763/1 "2023-09-05T13:50:57Z")
Does anyone know what specifically changed with the **system.opc.writeValue** function in 8.1.27? ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/9/0999711a0953b52226ae708f4f17e4e5196f4716.png) We updated over the weekend from 8.1.26 to 8.1.28 at one of our facilities, and we are seeing some odd behavior when using this function. I am confident there were not code changes to the way we are using the function, and I know that **system.opc.writeValue** was around well before 8.1.26. ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [September 5, 2023, 1:53pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763/2 "2023-09-05T13:53:50Z")
[Ignition Release Notes for Version 8.1.27 | Inductive Automation](https://inductiveautomation.com/downloads/releasenotes/8.1.27) ---
**Author:** ![rbachman](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rbachman/32/43718_2.png) [@rbachman](https://forum.inductiveautomation.com/u/rbachman)\ **Post date:** [September 5, 2023, 1:58pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763/3 "2023-09-05T13:58:55Z")
Thank you; I have looked at the release notes, but I'm not quite sure I understand how the change is affecting our code. I'm going to post our code here to see if anyone can help me identify out the change may have affected our code. I believe the line that is not working properly is line 87. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/f/df0b8e176e1f28d64e8673f0177f210ed5d0223b.png) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 5, 2023, 1:59pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763/4 "2023-09-05T13:59:47Z")
print/log `value` before that call, see if it's a raw value or QualifiedValue Also - what value does this function return now? Did it change? ---
**Author:** ![rbachman](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rbachman/32/43718_2.png) [@rbachman](https://forum.inductiveautomation.com/u/rbachman)\ **Post date:** [September 5, 2023, 3:03pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763/5 "2023-09-05T15:03:21Z")
The `value` is a raw value, but I think I know what is happening now: The write is failing whenever I try to write a string/unicode value to a tag on the PLC that is actually an integer/short/float tag. I suspect that the issue has something to do with converting the `value` to a `QualifiedValue`. In the screen shot below, I printed the name of the tag, the `value`, and then the `type`for the `value`. If the `type` is `unicode` and the actual PLC tag is `short`, a 0 gets written instead of the intended value. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/d/3da4c5a2ba7dd7245f1d932510d4123ff59923e8.png) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 5, 2023, 3:08pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763/6 "2023-09-05T15:08:19Z")
Yeah, there was some unintentional behavior change here... I think we reverted some of it (looking for details), but **in general you shouldn't rely on implicit conversion between string and integer types to be done for you.** details: previously, when coercion failed, we would just write the original raw value to the server. If it ever happened to work after that it was server-specific behavior that ignores OPC UA strict typing requirements. A change in 8.1.28 unintentionally changed this to write `null` or `0` when coercion failed. This was reverted in 8.1.32. ---
**Author:** ![rbachman](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rbachman/32/43718_2.png) [@rbachman](https://forum.inductiveautomation.com/u/rbachman)\ **Post date:** [September 5, 2023, 3:12pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763/7 "2023-09-05T15:12:44Z")
Okay, thanks. This one is a bit of a challenge because we're pulling in the values from a 3rd party database, and _all_ of the values are string values. We do a conversion on a couple of the values that we know should be float values, but in the past, we just sent all of the values as they were and let the conversion happen automatically. I should also mention that our preference is to use **system.tag.writeBlocking** in this case instead of **system.opc.writeValue** (or **system.opc.writeValues** ), but we were having a very odd timeout issue with this specific PLC. The support ticket for that issue is #73376. For now, we have reverted to using **system.tag.writeBlocking** , and I'm hoping the update may have fixed the timeout issue. 🙂 ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [September 5, 2023, 3:15pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763/8 "2023-09-05T15:15:23Z")
Are you doing anything with the returned Quality? Have you considered using `system.tag.writeAsync()`. How quickly is this script likely to be called, and where is it most likely to be called from? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 5, 2023, 3:19pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763/9 "2023-09-05T15:19:32Z")
> [@rbachman](#): > > _all_ of the values are string values. We do a conversion on a couple of the values that we know should be float values, but in the past, we just sent all of the values as they were and let the conversion happen automatically. Yeah, tricky situation. You're relying on undocumented behavior in what I presume is one of the older AB drivers... it's not even something you can expect to happen with the newer drivers - they should return `Bad_TypeMismatch` as the spec requires. ---
**Author:** ![rbachman](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rbachman/32/43718_2.png) [@rbachman](https://forum.inductiveautomation.com/u/rbachman)\ **Post date:** [September 5, 2023, 3:21pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763/10 "2023-09-05T15:21:29Z")
In the ticket with IA (#73376), IA support indicated that writing asynchronously most likely would **not** fix the timeout issue we were seeing because it appeared to be an issue between the OPC server and the PLC. At the time, we captured a bunch of Wireshark data, and we were able to show that the PLC was responding, but Ignition was reporting a timeout error nonetheless. > Yeah, tricky situation. You're relying on undocumented behavior in what I presume is one of the older AB drivers... it's not even something you can expect to happen with the newer drivers - they should return `Bad_TypeMismatch` as the spec requires. @Kevin.Herron I am wondering now if the timeout issue was related to the data type mismatch as well. I think we may need to add some code to try to change the data type to a number before we write to the PLC. We have a fairly generic function for this, which could be a challenge. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 5, 2023, 3:23pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763/11 "2023-09-05T15:23:16Z")
Tough to say... I would expect that using an Ignition tag and `system.tag` functions would be the solution, because while the OPC client does only minimal implicit conversions to support writing OPC UA types that don't exist as Ignition tag types, the Ignition tag system does loads of automatic/implicit conversions. ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [September 5, 2023, 5:08pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763/12 "2023-09-05T17:08:31Z")
> [@rbachman](#): > > We have a fairly generic function for this, which could be a challenge. The configuration should have the `dataType` of the tag in it. I would try something like this: ```python from java.lang import Throwable from com.inductiveautomation.ignition.common import TypeUtilities def write(tag,value): try: tagConfig = system.tag.getConfiguration(tag) coercedValue = TypeUtilities.coerce(value,tagConfig[0]["dataType"].javaType) return system.tag.writeBlocking([tag],[coercedValue]) except Throwable, T: #Do something as a result of the error. Coerce will throw a ClassCastException #if it fails to coerce the value. So you could catch that specifically to do one #thing and then catch Throwable separately for general errors. print T.message ``` Of course you could also read the dataType directly which would avoid the case that it isn't included in the configuration (which isn't guaranteed according to the manual). Also, as an aside, I would update the comments in that script as they don't match what the function is actually doing anymore. Looks like a read function was copied and just the code was changed? ---
**Author:** ![rbachman](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rbachman/32/43718_2.png) [@rbachman](https://forum.inductiveautomation.com/u/rbachman)\ **Post date:** [September 5, 2023, 7:44pm UTC](https://forum.inductiveautomation.com/t/specific-change-to-system-opc-writevalue-in-8-1-27/78763/13 "2023-09-05T19:44:31Z")
@lrose Nice catch that our comments are not up to date. 🤣 After I wrote my last comment, I started thinking that I can probably grab the data type from the tag somehow so that I know what I'm trying to convert the data to. Thanks for the possible code to get that idea rolling!