I do not think there actually is a "problem" - this is the way things are supposed to work.

QuickOPC has built-in default for maximumAge (I think it is 1 second). You cannot globally change the default, but you can specify the maximumAge with each read call.
Reading from device corresponds to maximumAge of 0. Positive numbers denote specific maximum age, in milliseconds.

There is an implicit conversion from Double to UAReadParameters, which means that in many cases you do not have to construct the UAReadParameters explicitly - simply put a number of milliseconds in place of read parameters, and it will compile and work.

Best regards

Hello.

BadWaitingForInitialData is not really an "error", in the sense that the server is allowed to return it when the data is not available at the moment. If this happens, the application code must deal with it somehow - for example, repeat the Read after some time.

There are multiple factors that can influence whether the error appears or not. For example, a "first" Read of a specific item may cause BadWaitingForInitialData, because the server cannot realistically give the data at the moment, but a subsequent Read some moments later will succeed. Also, When you Subscribe to an item, the server will start watching the item for changes, and can use the values obtained for the subscription when doing the Read, preventing the error in some cases. So a workaround might be to subscribe to the item, if you can do it upfront.

One more reason for it can be that the default parameters for Read (in QuickOPC) specify maximumAge = 1 second. This means that the server is not *required* to actually perform a read from the device, if it has a reasonably fresh value. I can hypothesize that it can also return BadWaitingForInitialData. You can try enforcing the Read from the Device by using a code similar to the following:

Best regards