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.
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.
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?
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!
Could you please share your thoughts about problem shown below?
Thanks in advance.
LabVIEW 2013 f2, 32 bit
When trying to read a value of tag from third party OPC server which is not widespread software using NI DSC OPC client we got empty data.
The type of tag in OPC server is Array of U16 and OPC server continuously writes array of values into that tag. However, NI DSC OPC client (and Distributed Systems Manager as well) defines type of that tag as String, thus can not read value of that tag (I suppose that NI OPC client is trying to treat variant data which holds array of U16 as string and because of conversation error issues empty data).
At the same time Kepwareâ€™s OPC client defines type of that tag as a String as well, but can read the values of that tag which holds Array of U16 (I suppose that Kepwareâ€™s OPC client after getting error, while converting Array of U16 into String, starts to look in datatype defined into variant itself).
Can the descriptions above explain the problem and if yes then what can we do to read the value of tag with DSC? Is there any opportunity to get more deep access to NI DSC OPC client to make some changes in order to work with customer OPC Server?