Professional OPC
Development Tools

logos

Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

Problem Using WriteMultipleItems

More
16 Jul 2014 21:08 #2083 by ShaneWeatherill
I've switched the code to allow me to configure whether to use WriteMuiltipleItems() or WriteMultipleItemValues(). For my immediate needs, WriteMultipleItemValues() is sufficient, but I'm sure at some point I'll need to support WriteMultipleItems().

You're correct about DateTime.MinValue. It looks like 1601-01-01 00:00:00.000 (which is what I searched for) is MinValue in the Micro Framework, which is what lead me astray.

Please Log in or Create an account to join the conversation.

More
16 Jul 2014 18:26 #2082 by support
Regarding the other issue you mentioned, i.e. that the timestamp does not seem to be written properly using WriteItem or WriteMultipleItems:

It appears that you have found a bug. Thank you for reporting this. In fact, instead of using the timestamp and quality from the DAVtq object, it always writes a zero timestamp, and a good quality. (Note that 1601-01-01 00:00:00.000 is not a DateTime.MinValue, but it corresponds to a zero value of FILETIME structure used in OPC to transfer timestamps).

We have made a fix for it - internally, for now. Please let me know whether you are actually going to use the WriteItem/WriteMultipleItems methods, or just WriteItemValue/WriteMultipleItemValues (in which case you do not need the fix right now). We will release the fixed build eventually anyway, but your answer will influence the release schedule.

Best regards

Please Log in or Create an account to join the conversation.

More
16 Jul 2014 12:22 #2081 by support
Thank you.

I will reply to your other reports later, but for now, back to your original problem with WriteMultipleItems. I have realized that I forgot to give you the most probable reason first:

WriteMultipleItems is for writing the value-timestamp-quality triple. This is a functionality that is new in OPC Data Access 3.0 specification. The error can mean that the OPC server only supports OPC-DA 1.0 or 2.0. Isn't that the case?

You should use WriteMultipleItemValues if your intent is to change just the value. This works with OPC-DA 1.0, 2.0 and 3.0.

Please Log in or Create an account to join the conversation.

More
15 Jul 2014 19:01 #2075 by ShaneWeatherill
I've set it up to subscribe to "Demo.Ramp" and to write to "Boilers.Boiler #1.Simulation.UpdateRate".

Please Log in or Create an account to join the conversation.

More
15 Jul 2014 18:57 #2074 by support
The behavior of different items in the simulation server varies, by design. I'd need to know which item you are writing to, in order to be able to respond to your findings.

Best regards

Please Log in or Create an account to join the conversation.

More
15 Jul 2014 17:35 #2073 by ShaneWeatherill
I've done some more testing and have noticed a few interesting things when writing to OPCLabs.KitServer.2. When using WriteMultipleItems (or WriteItem), the time stamp set in the simulation server is 1601-01-01 00:00:00.000 (DateTime.MinValue) regardless of what is set in the DAItemVtqArguments.

If I switch the code to use WriteMultipleItemValues instead (using DAItemValueArguments), the value updates properly in the simulation server.

It seems like the library is having problems converting the DateTime parameter to something meaningful when writing to the server. In case it matters, I'm monitoring the simulation server using the EasyOPC.Net Demo Application and it is what is showing the timestamp as DateTime.MinValue. It certainly possible that something else is being written and the Demo Application is displaying DateTime.MinValue because it cannot understand the response. In spite of this, it still seems to be something related to how the timestamp is processed by the WriteItem() or WriteMultipleItems() calls.

Please Log in or Create an account to join the conversation.

More
12 Jul 2014 17:34 #2068 by support
I do not see anything wrong with your approach.

Do you get the same error when writing to our simulation server (OPCLabs.KitServer.2)? I cannot verify it myself until Tuesday when I return to the office. But please use otherwise the same code.

Please Log in or Create an account to join the conversation.

More
12 Jul 2014 12:51 #2067 by ShaneWeatherill
I'm using pretty much default settings.

The write routine is as follows:
            List<DAItemVtqArguments> argumentsList = new List<DAItemVtqArguments>();
 
            foreach (OPCItem item in mItemList)
            {
                argumentsList.Add(new DAItemVtqArguments(item.Source.MachineName, item.Source.ServerClass, item.ItemId, OpcLabs.EasyOpc.VarType.R8, item.Value, item.Timestamp, item.Quality, item));
                Tracer.TraceVerbose("OPC Write {0}: '{1}': '{2}' '{3}' '{4}'", mId, item.Name, item.Value, item.Timestamp.ToString(), item.Quality.ToString());
            }
 
            try
            {
 
                OpcLabs.BaseLib.OperationResult[] results = easyDAClient.WriteMultipleItems(argumentsList.ToArray());
                foreach (OpcLabs.BaseLib.OperationResult result in results)
                {
                    OPCItem item = (OPCItem)result.State;
                    if (result.Succeeded == false)
                        Tracer.TraceWarning("Unable to publish OPC Item '{0}' in batch '{1}': '{2}'", item.Name, mId, result.ErrorMessage);
                    else
                        Tracer.TraceVerbose("Write of OPC Item '{0}' succeeded in batch '{1}'.", item.Name, mId);
                }
            }
            catch (Exception exc)
            {
                Tracer.TraceWarning("Unable to publish OPC Values for batch '{0}': '{1}' - '{2}'", mId, exc.Message, exc.InnerException.Message);
            }

The easyDAClient is created once in the thread that handles all write calls and is simply created using easyDAClient = new EasyDAClient(); No other settings are made.

All reads are handled in a separate thread using a different instance of EasyDAClient. Reads are done using:
            int handle = mEasyDAClient.SubscribeItem(mSource.MachineName, mSource.ServerClass, mItemId, mScanFrequency);

Please Log in or Create an account to join the conversation.

More
12 Jul 2014 07:24 #2065 by support
No, it cannot be a tag misconfiguration.

Are you setting the read arguments in a specific way, e.g. changing the allowed/desired read/write method? Can you post the relevant piece of code?

Please Log in or Create an account to join the conversation.

More
11 Jul 2014 21:24 #2064 by ShaneWeatherill
I've written a small application using 5.2 (as I'm required to use the .Net 3.5 Framework) to publish a set of values to a Wonderware OPC server and am getting an error that I don't understand.

The application builds an array of DAItemVtqArguments and passes it to WriteMultipleItems.

However, the values are not updating and I'm seeing the following error in the OperationResult:

No read item or write item function available. The OPC server does not contain a function that can satisfy the combination of requirements (execution method and data source). For example, there is no way to read asynchronously from the OPC Cache if the server only supports OPC-DA 2.0.

Since this EasyDAClient is doing nothing more than these writes, I'm not sure what the error is indicating. I have tested the application with a different OPC server and it does work. Could this be a compatibility issue with this particular OPC Server or could it be a tag misconfiguration?

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.061 seconds