DSC and DataSocket

[mike5]

Hi all,

I'm starting using the DSC module, and since it has it's own shared variable data type, I'm forced to use DataSockets for reading and writing data.

So, the DataSocket Read function has a "connection in" interface. This can take (among other things) connection reference from DataSocket Open function, or a DSC Shared Variable wire.

If I use the latter, is the connection closed implicitly, or what? And if this implies Open/Read/Close how much overhead do Open and Close this bring?

Thanks for any insight.

Br, Mike

[jgcode]

If I use the latter, is the connection closed implicitly, or what? And if this implies Open/Read/Close how much overhead do Open and Close this bring?

I haven't used it for a while - but if I remember correctly after the first read/write, it's a pretty similar speed.

Should be pretty easy to test tho.

[mike5]

Thanks. I gather from your reply, that the connection is closed. You don't get any connections that are permanently open from using calling the Read/Write just once?

Br, Mike

[PaulL]

I'm starting using the DSC module, and since it has it's own shared variable data type, I'm forced to use DataSockets for reading and writing data.

?

I'm not sure what you mean by this. Can you clarify?

[mike5]

DSC module uses totally different Shared Variable type than LabVIEW base. So, if you want to use functions for monitoring SV value changes, you cannot use LV base functions like "Read Variable" on the same variables. But you can use the DataSocket functions like "DataSocket Read".

[jgcode]

DSC module uses totally different Shared Variable type than LabVIEW base. So, if you want to use functions for monitoring SV value changes, you cannot use LV base functions like "Read Variable" on the same variables. But you can use the DataSocket functions like "DataSocket Read".

I am not sure if that entirely true - you should be able to convert one datatype to another e.g. using a transitionary string and making sure the URLs are correct (as they are different).

[PaulL]

DSC module uses totally different Shared Variable type than LabVIEW base. So, if you want to use functions for monitoring SV value changes, you cannot use LV base functions like "Read Variable" on the same variables. But you can use the DataSocket functions like "DataSocket Read".

This isn't correct. We use functions (actually through the Shared Variable API now) to read and write shared variables, and yes, we use the DSC Module. I'd comment more but I'm not even sure what you are saying.

In any event, I recommend that you use the Shared Variable API functions (available in the more recent versions of LabVIEW), not the DataSocket functions, to read and write shared variables. The performance of the DataSocket functions is not as good as that of the methods available with the Shared Variable API (we've tested them ourselves) and I think it's awkward at best to use the DataSocket API to talk to something that isn't (at least expressly) DataSocket communication. (Yes, the DataSocket API can work with shared variables, but again, why use it?)

Paul

[jgcode]

The Shared Variable API is a bit more polished IHMO and recommend using it over DS as well - better error information etc... Although for reasons that escape me, I have used DS over SV-API for particular use cases in the past.

[mike5]

But you can set data value monitors only on the DSC shared variable types. So, what you're saying is that it is best to use both, each for its own purpose?

Br, Mike

[PaulL]

But you can set data value monitors only on the DSC shared variable types.

Sorry, I still don't know what you are saying. Do you mean setting alarms? Shared variable binding?

Generally, the DSC Module adds some functionality (e.g., alarms, logging, security) to the shared variable.

[mike5]

I sorry, I was using EPICS terminology. This is what I mean:

Br, Mike

[PaulL]

I sorry, I was using EPICS terminology. This is what I mean:

Oh, I see! Yes, as jgcode suggested, you can convert the URLs from one form to the other for use with the different APIs. (You can use the string form and do the conversion.)

In practice, we use each of these where we need them (with the respective APIs). At present we only use the top one for shared variable value change notifications. We haven't encountered any issues with this approach.

Paul

[viSci]

Network Shared Variables do work with DSC Value Changed Events. Your code snippet shows only single process SV's maybe that is the problem.

[mike5]

sachsm: I've set the Variable class to almost everything possible, and still the picture looks like this:

Br, Mike

[viSci]

Ok, I looked at some of my code and it seems that I did use the DSC BV Tag URL to register my network shared variable events.

So you maybe correct that you cannot directly feed in a LV SV URL. But functionally, the BV tag URL can point to any conventional SV type.

Also noticed that if I use a LV SV URL and convert it to a string then it seems to work also...

[mike5]

Also noticed that if I use a LV SV URL and convert it to a string then it seems to work also...

Thanks, I didn't notice this. It will be most useful.

Br, Miha