OK, thank you.
I was looking into the size limitations in the meantime. I know the issue is now resolved, but for record, here are the current default transport quotas as used by QuickOPC 2016.2
<TransportQuotas>
<!-- The default timeout in milliseconds for operations (used by clients) -->
<OperationTimeout>120000</OperationTimeout>
<!-- The maximum length for a string value in any message -->
<MaxStringLength>1048576</MaxStringLength>
<!-- The maximum length for a byte string value in any message -->
<MaxByteStringLength>4194304 </MaxByteStringLength>
<!-- The maximum length for any array in a message.
Note that some protocols do not distinguish between bytes and arrays.
In these cases the binding will choose the larger of
MaxByteStringLength or MaxArrayLength-->
<MaxArrayLength>65535</MaxArrayLength>
<!-- The maximum size of any message -->
<MaxMessageSize>4194304</MaxMessageSize>
<!-- The maximum buffer size
This value controls how big a block of memory the transport layer allocates.
Setting this value to a large value will reduce performance and use a lot of RAM -->
<MaxBufferSize>65535</MaxBufferSize>
<!-- The lifetime of a SecureChannel in milliseconds.
This specifies how long the server will keep a broken channel around while waiting
for a client to reconnect.
Not used by HTTP or .NET TCP bindings -->
<ChannelLifetime>300000</ChannelLifetime>
<!-- The lifetime of a SecurityToken in milliseconds.
This specifies how long a security token can be used without renewal. -->
<SecurityTokenLifetime>3600000</SecurityTokenLifetime>
</TransportQuotas>
I was about to write that they are unlikely to be a problem, because they are relatively big.
Best regards