Unfortunately not, I have to admit it is not high on the priority list.

Best regards

Thank you

Zbynek

Alright, then let's leave the subscriptions aside. Regarding the arrays, can we close it assuming that you will try to add the arrays to win32ole, but if that doesn't work out, let us know so that we can plan for a different resolution?

Thank you. There are two things here.

1. Working with multiple items.

It is kind of hard to do something alike, if arrays are not supported. I think we already have had a request like this once, coming from some kind of different programming environment, but with a similar limitation. The best way, of course, would be if win32ole is extended to support arrays in VARIANTs. In my view, it should not be too difficult, but it is not something that we can or want to do.

The other solution we have contemplated was to simulate the arrays using something else. The current thinking is that we may support a use of "Scripting.Dictionary" objects (msdn.microsoft.com/en-us/library/x4k5wbx4(v=vs.84).aspx ) in place of input and output (result) arrays. We would allow integer (or even arbitrary) keys to serve the purpose of array indices.

You should be able to create Scripting.Dictionary using win32ole, and then access its methods to get and set the elements in the dictionary. Do you think it would work on your side? If so, however, this is something we cannot do quickly. It'll have to be put into the development plan, with earliest chance to see it in production something like October/November 2014.

2. Subscriptions.

This depends on win32ole again, and is, in fact, much more difficult to do, so I am not surprised it is not supported in the current version of it. We need a support for connection points/events/outgoing interfaces in OLE automation. It should be doable as well, but with a larger effort in the win32ole area.

So I am rather pessimistic about whether win32ole will ever have this kind of support - but you need to figure out with the authors to see if this is truly the case.

From the very beginnings of the EasyOPC component, we have, however, anticipated usage scenarios where subscriptions are not feasible. An example of it might be a Web app with just HTTP connection that is periodically asking the Web server for OPC data. The EasyOPC component internally sets up a an OPC subscription when there is a (periodic) Read detected, and then it tries to maintain that subscription at a suitable update rate. Subsequent reads, if/when they come at the right time, do not physically hit the OPC server, but are server valued from the component's "memory" instead. There are also some parameters to tweak this behavior. The disadvantage is that you do not get full control of the internal subscriptions, and guarantees of the update rate etc.; but at least you get the most of the performance benefits associated with using OPC subscriptions versus calling OPC Reads periodically.

Of course your need may be to have "real" subscription - I do not know how the above fits your scenario.

Please let me know your thoughts.

Thanks for raising an interesting topic.

From OPC Labs side, we currently do not have much (if anything) on this (Node.JS). I would be happy to hear what the obstacles and requirements are. We have already met with a problem of using arrays, and have contemplated adding a support for arrays to be replaced by dictionary objects.

Which language are you interested in using? Is that JavaScript directly?

Can you point me to the documentation of the win32ole module you mentioned? I would like to evaluate whether there is something that can be used for subscriptions.

Also, do I understand it correctly that you have a made a kind of "Hello World" solution with QuickOPC.COM in Node.js, with at least reading a single tag, and that it works? - but you are looking for efficient ways of expanding it?

Best regards