Hello.
as agreed over email, options 1 and 2 do not look realistic at the moment.

Can we please start with option 3. I propose a simple test first - try the same Write operation with our OpcCmd utility (which uses the same underlying QuickOPC libraries). The thinking is as follows: If the problem shows up with the OpcCmd utility as well (and is not limited to VBScript coding only), it would make the troubleshooting easier. The OpcCmd utility already contains some built-in tracing features that I can instruct you to turn on; or even if they need to be enhanced, we can do it on our side; sending you an updated OpcCmd would be easier that requiring you to rebuild your program and even make changes to it.

I assume you have installed QuickOPC using the Setup program. In such case there is an icon in the Launcher app to start the OpcCmd utility in the interactive mode
Choose "Interoperability" (A) mode when starting the OpcCmd for the first time.
Note that certificate trust may need to be established, if OPC UA secure communication is used. There will be prompts to trust the server certificate in OpcCmd; plus the server side needs to trust the client.

Can you please do so, and then enter the following three commands, and report the results here?

Best regards

Hello.

The OPC UA Type of the node you are writing to is Float: reference.opcfoundation.org/Core/Part3/v104/docs/8.15 . This can guarantee a precision of 6 decimal digits. So you are not dealing with QuickOPC limitation. The limitation is in the server, or its configuration, or the choice of the node.

I will send you some info about options 1) and 2) via email. If doing them turns up to be not realistic, I will provide instructions for option 3).

Best regards

Hello.

In OPC UA protocol, the value being written must precisely match the data type of the node. What you are asking about (...method of dynamically determining appropriate TypeCode ...) is what QuickOPC is supposed to do automatically, in order to relieve developers from passing in the precise type (which in some cases is not even doable because the type model in the language is not the same as the type model as in OPC UA, so the corresponding types may not even exist, but there might be something "close enough" available). This expected behavior somehow is not happening in your case, which was the case of the original BadTypeMismatch error. So if you want that behavior, we need to go the detailed troubleshooting path. That will require, in order of preference, either 1) us reproduce the problem here - i.e. get a copy of the server and the configuration that exhibits the problem, or 2) us getting remote access to connect via OPC UA to the server, or 3) you obtaining WireShark captures and other trace information (per our further instructions, and possibly multiple iterations). Let me know if you are willing/able to help with some of these options.

Regarding " the specified TypeCode does cause written value to lose decimal precision if value is not whole number": Please explain why you think so. I do not see why the precision should be lost.

Regards

Thank you.

Everything looks OK on your side, I do not quite understand why the Write does not work. It looks like that QuickOPC has determined the node's value data type as Int16, whereas the server says it is OPC UA Float. Ideally I would like to get to the bottom of it, but for now, please add following line, and retest:
Regards

Hello.
What you are doing looks good in principle - although in some cases, there is a necessity to explicitly define the data type for writing. We need to figure it all out.

Questions:
- Are you able to write to the very same node using UaExpert?
- Can you please send a screenshot of UaExpert when this node is selected in the "Address Space" pane - either the whole UaExpert screen, or the Attributes and References panes at least.

Thank you