Jump to content

Recommended Posts

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

Link to post
Share on other sites
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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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?

Link to post
Share on other sites

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".

Link to post
Share on other sites

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).

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

post-162-0-21827700-1331129680.png

post-162-0-84977900-1331129680_thumb.png

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

post-162-0-01117000-1331132366_thumb.png

Link to post
Share on other sites

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

post-162-0-01117000-1331132366_thumb.png

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

Br, Miha

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Vitali
      Hi.
      I use shared variables on several projects on different nodes. On some of them, after rebooting the OS, the variables restore their value (as it should be), on others this does not happen. I use Windows 10 and approximately the same setting. Does anyone know where I can search in the OS settings or LabVIEW to get predicted DSC behavior after rebooting the OS.
      Sincerely, Vitaly.
    • By ensegre
      This is a DSC module question: has anybody here experience with building standalone executables which include shared variables bound to DSC modbus i/o servers? I have an issue with deployment, possibly related to licensing. I posted on the dark side, but haven't got feedback yet.
      https://forums.ni.com/t5/LabVIEW/shared-variable-bound-to-Modbus-i-o-not-working-in-deployed/td-p/3809801
      TIA, Enrico
    • By ensegre
      I wonder if someone ran into this and has a good suggestion about. I have a DSC project, in which it looks just right to organize hierarchically my shared variables. Like, e.g.

      Now this is easy to do programmatically, see the attached project. The problem arises when building an application. It would look as if the plain way to do it, would be to create a build specification which includes the additional libraries, and select their deployment in the "Shared Variable Deployment" tab. However, this doesn't seem to work for nested libraries as in my example. The only possibility seems to add in "Always included" each of the contained libraries. But by doing like this the hierarchy is flattened.
      If I include like this,

      then the variables within the container library are not deployed at runtime.
      In my example project:
      open the project in the IDE, run DeployAllSharedVariables.vi, then CheckDeployed, and see the result (all four variables found with their nested paths) build and run DeployFlatLibraries and see the result: four variables, but flattened paths build and run DeployHierarchicalLibraries: only the two variables in the unnested SimpleVariableLibrary are there. I've searched a bit, and only came up with this document, which (for >2009) says "just check the checkbox". Nor the help page says much either.
      I wonder if I can do what I'd like only compiling separately the libraries, and loading them programmatically afterwards, both in the IDE and in the exe. Which probably is sane, but inconvenient for the first attempts.
      TestDeploy.zip
    • By ensegre
      I'll be doing a SCADA for a high vacuum system. I have not yet settled on the graphic style of the hmi (skeuo, flat, diagrammatic, whatever), but I'd like to do something slick. I have looked at DSC controls: 3d pipes somewhat do the job, but all the rest is crude. Looked into the DSC images navigator, images are sooo 2002, and again little specific to lab. Have looked at https://www.openautomationsoftware.com/downloads/free-hmi-symbols/, images are pngs and not too much choice either. Searched a bit the net and found nothing.
      I miss specific elements like vertical turbopumps, guillotine gates, vacuum chambers, ideally scalable. I'm tempted to inkscape down my path of personal crap-art, but I know it will end into another bad trip. Is there anyone who can suggest a nice source of suitable elements?
    • By dterry
      Hello all,
      I recently was presented with the task of integrating a Mitsubishi PLC into our systems. After a good deal of googling, I think the best (maybe only) way to get the data out is going to be via OPC, thanks to their proprietary Melsoft protocol. If anyone else knows a better way, feel free to stop me here.
      Now, we are currently expanding our data generating capabilities (hence the PLC), and I have been thinking about rearchitecting the way we collect data from all over our facility to be more flexible.  Since I may be required to use OPC anyways, I was considering using an OPC server to aggregate all of the facility data, and then redistribute to control rooms, historical logging, etc.  To do this, we would need to integrate our cRIOs and operator PCs into the OPC environment as well.
      I don’t see OPC mentioned very often (in fact it returns 0 results on LAVAG), and a lot of the stuff I see these days seems to be more “roll your own” or lower level (raw TCP/UDP, 0MQ, Network Streams, Transport.lvlib etc.) rather than a monolithic abstracting bridge like OPC. Unfortunately, I won’t have time to roll my own in the near future, but LVRT supports supports OPC UA, so I could potentially integrate the cRIOs fairly easily.  Unfortunately, I think I would have to use LabVIEW DSC (or datasockets...) to integrate the PCs.
      I would be very grateful if anyone has the experience to comment on the following or anything else related to using OPC.
      What are viable update rates for OPC tags?  I will need at the very (very) least 250 ms update rates.  Is OPC typically low latency (time from data generated to to client received)? Does anyone have a recommendation for a product (NI OPC, Kepware, etc.)? Is OPC still popular, or are there other options for data aggregation that would be better suited to a new application? What are the options for logging and alarming with OPC? What are the options for talking to OPC from LabVIEW? How robust are the OPC connections in regards to reconnecting if a wireless connection is temporarily lost? Thanks in advance!
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.