viSci

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.

Hi Steen, Curious to know... what is tcpip-link? Sounds like some cool inter process messaging architecture.

The GOOP overlords must be angry at me... I just tried to download from another machine (windows 7). Got the zip file but the unzip error-ed out about 1/2 way through on the this file

Ran the GOOP4 installer, restarted LV and found LV searching for many files that were not present from the install, is there a companion installation that needs to be run as well?

People - I am talking about LV System Controls. For example take a look in XP at the System Spin Control and compare to what you will get in Windows 7. The XP control with its light blue color and subtle shading is a statement in elegant simplicity. On my Windows 7 machines, this control is very different and not at all attractive to my eye. Of course, I am known to be obsessive about GUI minutiae I always thought it would be nice to create a library of custom controls that looked just like the windows XP system controls. I guess now I have my motivation...

Recently upgraded a number of XP machines to Windows 7 and was dissapointed to see the elegant looking system controls in XP replaced by rather clunky Windows 7 system controls. Is there anyway to get back to the XP style within Windows 7?

Did you setup your SV event to ignore timestamp changes?

Are there any tools to help with the process of Reverse Engineering LabVIEW code to create a SW Requirements Document. I noticed that Symbio has UML tools that can create UML from LV code. If your LV code is not currently OOP will this be useful? It would also be interesting to be able to come up with some useful metrics based calculations to estimate the tasks/time involved in unit testing legacy code. Any thoughts...

For anyone interested...here is what I came up with, a variation of the ZLIB Delete vi which uses the Move Raw vi to transfer each file in the archive to a temp archive without having to decompress and re-compress, very clever! Instead of deletion by omission, I simply rename the identified file. It still seems like there should be a way to do this directly within the original archive, but this will do for now.

Just wondering if there is an easier way to do this. The only way I can see to rename a file in a ZLIB is to uncompress the whole thing, rename and then rebuild the archive. Thanks

First off, are you wiring the error out of your NSV nodes? Do you trap or log any such errors? The Distributed System Manager can be used to monitor RT SVE faults and CPU% which is good to monitor. Has anything changed in your system over the past 2+ years? Do you regularly restart your targets? Do you run on a private network? etc.

Beautiful clean code, thanks for sharing!

Yes, I have the OpenG ZLIB vi's and have a put together a way to extract a single file to disk and then read it. It appears that there are vi's that look like they can setup a zlib file pointer but I cannot see how to read out the data from the internal pointer. Any hints? Ok, I must have an old version, I just looked at 2.5.1 and I do see the streaming vi's. Thanks!

I was wondering if it is possible to open up a ZIP archive and read the contents (text file in my case) without creating a temp copy on the file system. Thanks

I use NSV's all the time and they are reliable when used correctly. If RT hosted NSV's drop off the network then you will receive definite error messages to that effect on any static or dynamic NSV R/W node. Once the RT controller comes back on line NSV's automatically reconnect and become viable. Also any HMI controls or indicators can be easily set to blink or display a red PSP status if the binding NSV goes offline.

Ok, but I do not understand how to stream to the raid disk without having to go through the processor. I presume that you still have to use the IMAQ driver and do a grap on the camera and then do something with the imaq image. It seems that NI only supports triggered image capture not video.