viSci

Could you compile your LV code to a DLL?

How about this... https://github.com/mnaberez/tdms Wow, this just goes on and on... http://pytdms.sourceforge.net/

Also don't forget the TDMS Excel Plugin. and this... http://originlab.com/index.aspx?go=Products/Origin/ImportingData/ThirdPartyFormats&pid=1047

I use static vi references for this purpose and put them in an unused state machine case. Of course this only works if you have a fixed library of vi's that you will need to call dynamically.

TDMS Rocks! I find it to be very fast for writes and reads. So fast that I now use it as a core data store for my DAQ applications that need to be able to acquire data and simultaneously read out and display the data. You can easily emulate the kind of real time historical data viewer that you get in the distributed system manager using this capability of TDMS.

Ok, the light is starting to brighten, it is basically like linked lists. Hard to believe, but in all these years I have never setup a database, I always used ordinary files or TDMS. Thanks for the pointers!

I have a TDMS file structure that holds calibration tables each with associated DUT header information (SN, Model Number, Manufacturer, etc) assigned as Group Properties. In SQLite it seems that I must lay everything out as a flat table, first columns being the DUT header variables and then the last column being a blob or xml string representing my cal table data. I was wondering if I am overlooking some better way of organizing the data...

I use it primarily for Citadel and NSV events and it has worked well. The Distributed System Manager interfaces with Citadel and provides powerful historical charting capability. For those 2 features I am not sure that it is worth the money but in my case the customer had no problem paying for it. I think it is theoretically possible to create NSV events without the DSC but I have not been able to crack that nut yet.

Here is another option for simple logging capability - http://sine.ni.com/nips/cds/view/p/lang/en/nid/209116

Yes, you can use the GetPlotAtPos Method and use the Mouse Move event (and use the Coords event data) for the pane that contains the graph and you will get a Plot Number output for the plot trace that is closest to the mouse cursor.

Another possibility, which I have done is such cases, is to use the Set Waveform Attribute vi to set the desired channel name in the waveform itself. For channel name and units the attributes are: NI_ChannelName NI_UnitDescription Once you do this then graph or charts will use the attribute to set the plot name. Also this is nice if you are using TDMS data storage which also uses the attributes in it's internal naming conventions.

I have been using the property saver vi's and they are very useful but slightly buggy in LV 2011. One example is that for any controls that have a scale (sliders, graphs, etc) the property Uniform Marker Spacing seems to always get turned off. I looked into the code but did not see anything that looks incorrect. Has anyone had any luck fixing such version incompatibilities?

You can also use the attached vi to determine the array element click on and then use the array selection properties to produce a highlighted effect on the selected element.Find Arrary Element Clicked On.vi

Some food for thought about distributed process message passing. http://www.se-radio.net/2011/08/episode-178-akka-with-jonas-boner/

Wow! Konstantin Shifershteyn is a monster LabVIEW programmer. Amazingly it still works perfectly for Graph Controls even though it was last compiled in LV 8.5. Unfortunately it uses many deprecated properties and thus is not really safe to use I really wonder why NI could not give us a hand with this kind of thing.

The link to the Property Saver vi is broken. Could someone please repost? Thanks!

Unfortunately the Save Instrument method is not available in the LV run time and I would not want to place that restriction on this application. I am trying to create a way to save all of the properties of a graph control. There used to be a property saver vi that was alluded to in some posts from a few years ago but the link is now broken. (I imagine it would be pretty hard to keep that kind of vi working for each release of LV)

I have ventured into the area of hydraulic controls development working with heavy machinery and am starting to think that I will need some sort of liability insurance in the event my software should damage equipment or cause injury. Is it common for consultants to carry this type of insurance, ever had to use it? How much coverage is needed? (I usually hear that 1 million is typical). Any recommendations on companies that provide these services?

Ok I give up. Apparently this can be done but I have looked under every scripting rock and cannot find it. Any hints?

Hmmm, that's sounds like a good idea Yair! I think this might be a good candidate for some HyperGraph LVOOP.

I am working on a emulation of the Distributed System Manager that will work with TDMS data. I am using subpanels on a tab control to support being able to dock HyperGraph (my version of) instances. I am stuck on how to be able to generate new tab pages on the fly. In the meantime I will just have some number of blank subpanels within parent tab pages.

Well actually there were no significant points taken off for documentation. No one ever said the code was obscure. In fact no explaination was given, just an oops and a grade change. You could argue that the naming of your top level the 'VIEW' and the subpanel process the "Controller' in your init state was a pretty big hint.

Yes, be careful with architectures that are more advanced than what is typically submitted. For my CLD, I used a MVC architecture with a subpanel plugin Controller process with messaging to the 'HMI' View. This seemed appropriate since the fictitious system described would in practice be designed with an embedded controller and HMI. I initially failed and assumed, since 2 qualified engineers had reviewed my exam, that I had misjudged the rigorousness of the exam. Despite the 'all grades are final' statement, I contacted NI and it turns out that somehow they missed entirely the 'process' code that was in the solution project. I did finally pass, but clearly understood that no credit was given for the more 'professional' i.e. robust and flexible approach. That to me is misplaced emphasis. It seems to me that if there was more time, most could add comments and better vi descriptions, but understanding the best architecture to use is garnered from experience and skill.

If the finest minds at NI think that NSV's are abhorrent, then maybe they could recommend an alternative for cRIO based SCADA applications that need features such as OPC or EPICS binding, citadel data logging, PSP capability (efficient NSV-NSV and NSV-control binding, NSV events), IEEE 1588 timestamping, DSM capability, etc. (and no most of us do not have the time to invent a 'tcpip-link') Is it possible to develop a NSV best practices to minimize race conditions and wide open global accessibility. Perhaps the use of project scoping, NSV class wrappers, etc. I have had good success with NSV's in cRIO based SCADA applications. I did go through a severe learning/tearing my hair out period, but now NSV's (1000's of transactions/s on a cRIO) appear to be reliable. BTW, I never have any sort of issues like spontaneous NSV un-deployment. However I do not use NSV's as a streaming conduit, my only use of buffering is for a command channel with reply notification based on NSV events.

In the past I have bought into the whole NI DSC/NSV technology for my cRIO based SCADA applications. I really like the SVE Publish Subscribe Protocol and the all the built-in features like NSV-NSV and NSV-LV control binding as well as the Distributed System Manager and DSC Citadel data logging. The problem is that it is a closed system, for example even though the SVE supports SV events, in LabVIEW this functionality is not exposed and you have to buy the DSC just to get such a basic capability. Also NSV's are cpu intensive, if you wanted to use them to emulate a CVT then you will hit the cpu% ceiling rapidly. I think, at least on the read side, the SVE could offer a more efficient interface for getting current NSV data. I think in the future I will consider an open tcpip based architecture.