From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
01-11-2017 05:57 PM
In my lab, there is a Veristand program comunicating with DaQ system that controls all sensors and actuators.
Recently, the lab bought a additional device, which is not connected to Veristand. I made a LabView VI which streams data from the device with TCP/IP communication. My final goal is implement this VI to Veristand model, so that all data (from the others and the new device) can be monitored and logged together.
Here are what I have tried so far.
1) Convert VI into a veristand model, implement it on the Veristand program.
FAILED, because both DaQ system and new device requires separate TCP/IP address, when I added the model to the Veristand program, it did not work.
2) Make a new target device (only for communicating with new device) in Veristand program.
FALED, It was possible to get the data from the new device(seeing in on the screen), but unable to log it because of data sharing error.
I do not want to make additional investment (such as buying a reflective memory module), so I would like to solve this issue in software-wise manner. Is there any solution for my current problem?
Thank you very much,
Changhoon
Solved! Go to Solution.
01-12-2017 09:06 AM
Hi hoon747,
The most robust solution would be to create a Custom Device that will interact with your instrument's I/O, pull in the necessary data, then write it to a file with all the other data you are acquiring. That said, custom device development is nontrivial, so it will take some changes to get VeriStand to correctly interface with the LabVIEW code (since the code must be wrapped appropriately so that VeriStand can make sense of the code).
A Custom Workspace Tool may be a better solution. Basically, any VI that you have can be built into a Custom Workspace Tool and have the same functionality of the VI originally. The advantage is that development time is cut significantly, but the disadvantage of a Custom Workspace Tool is that they operate (relatively) independent of the rest of the system and will not be able to interact with I/O from other channels unless you explicitly set up the workspace tool to do that. If you are content logging a timestamp and your third-party instrument data in one log file and the rest of your data in another, a Custom Workspace Tool might be the way to go. Here's some additional documentation:
http://www.ni.com/tutorial/14421/en/
01-13-2017 05:21 PM
Thank you very much for your comment.
Actually, what I did was this: I made an executable labview VI program (which pooling data from the new experimental device), and connect it with current Veristand program by using “open workspace manager reference.vi” and “set single channel value.vi”, which is a part of Veristand pallet in LabView. By using those two, I can add user channels which can be used in Veristand.