Richard_Jennings

Thanks for the great tool! It's sooo much better than mangling JSON by hand. I have an issue with the tool not handling variant data correctly. I have a cluster with a string and a variant. When flattened to JSON the variant name is an empty string. {"SN":"2016D8A1D86C","":{"ChaSt":"Ready","LocRemCtl":"Manual"}}. The variant attributes are correctly included in an embedded JSON string, however converting back to a cluster omits the attributes. Thanks, Richard

I like Project Locker It's free to start, and I've never had an issue.

I agree 100%

Very nice Especially like that it is platform neutral.

QUOTE (Jim Kring @ Apr 1 2008, 09:37 AM) Hi Jim, We touch on threading and execution priorities in "LabVIEW Graphical Programming". "The one exception to the time-slicing feature of each execution system is when a VI is set to run at subroutine priority. A subroutine VI will always run to completion within its execution system. A thread running a subroutine VI can still be preempted by the RTOS but no other VI running in the same execution system as a subroutine VI will be able to run until the subroutine VI is finished." Johnson, Gary W. "LabVIEW Graphical Programming" (McGrawHill, New York, 2006) 391. I use it occasionally to optimize a crucial VI, or protect a critical resource, but as Michael pointed out, usually it's better to use LabVIEW's defaults. Repeatedly calling a subroutine VI can negatively impact execution. just my $0.02, Richard

QUOTE(DaveKielpinski @ Dec 25 2007, 08:58 PM) Hi Dave, #2 - unless you are trying to make your application impossible for anyone else to debug Dataflow and the ease of debugging a LabVIEW app by another programmer would be thrown out the window. XControls provide a great way to enhance a UI without unnecessarily complicating the block diagram, but hiding an elaborate messaging scheme would - I think - be the wrong way to use them. Richard

Hi Eric, I'd tried that this weekend, but some of the events used in the GUI were not available in 7.0. Richard

File Name: Virtual Logic AnalyzerFile Submitter: jenningsr@earthlink.net File Submitted: 4 Jan 2007 File Category: LabVIEW Development Environment The Virtual Logic Analyzer is a development tool for monitoring VI execution. It is especially useful for optimizing the performance of multi-threaded, parallel applications. Monitoring Data and Timing information over an entire application can provide unexpected insight into performance bottlenecks. The VLA Probes use the OOP model Stepan Riha of NI introduced at NIWeek 97 and the Virtual Logic Analyzer concept is based on the presentation "Monitoring the Control and Timing of VIs" by Dana Redington at NIWeek95. There are two parts to the Virtual Logic Analyzer: Probes, and the GUI interface. Probes are meant to be as efficient as possible, but do not place them in a MHz type loop. Instead place them in strategic locations where you can monitor program flow. Each VLA Probe is a reentrant vi that monitors your program's execution by timestamping data during program execution. Simply place this vi on your block diagram and connect the required Tag and Data inputs. Remember that dataflow governs LabVIEW execution. Be sure to give each Probe a unique Tag. Probes can be on a local or remote machine. Because Probes are OFF by default they can be left in an application and individually switched on or off later with the GUI application. To view and interact with the probes run the Virtual Logic Analyzer application. In the Info tab of the VLA application is a multi-column listbox with a live display of active probes. Double-click on a probe to turn it on in the application you are monitoring. You can turn on as many or as few probes as you need. Live data is displayed in the graph on the Data tab. Note that data is only displayed for probes that are turned on. Ideally the VLA GUI interface should be run on a separate computer from the application being monitored. This eliminates the GUI overhead from impacting application performance. The VLA interface uses VI Server calls to interface to the Probe Registry. Click here to download this file

Hmmm... at $295.00 for the online training course I think you're better off buying Jeffrey & Jim's book AND mine and Gary's book. I'm a little biased towards ours :thumbup: LabVIEW Graphical Programming, 4th Edition McGrawHill, 2006 We put a lot of work into making sure it covered all the material on the CLAD and the CLD. There are even some practice exams for the CLD. I wouldn't use the CLD as a study guide for writing good LabVIEW applications. In general, I found the application requirements written in a way that almost forces you to use antiquated architectures - polling, etc... i2DX has some good advice above. Just remember it is a timed test Richard

Try using the find and replace feature! Edit >> Find and Replace You can search for functions, VIs, Globals, typedefs, etc... Richard

Lot of parallel loops there :-) Remember a while loop always executes at least once. I believe your loops are executing twice because you are reading the "stop generation" local in the outer loop without any data dependency on the inner loop. Solution - pass the value from the stop generation local in the inner loop out to the outer loop and use it to stop the outer loop. In your example the outer loop reads the value of the local (F = keep going) and starts the inner loop (based on your case selector). When the inner loop terminates on stop generation, the outer loop executes one more time. As for why your application won't stop - chances are the queue is waiting for data that will never come. Kill the queue using one of the data writer loops instead. I hope this is understandable. Richard

I think the features you mention get zero mention because they have limited benefit As others have pointed out - you have to have the professional version for XControls to be useful. Arrays as UI elements are generally a bad idea, so the fact that they have scrollbars is not really a bonus. Afterprobes - we'll see. Matrix data type - Exciting to some I guess. File I/O primitives - A lot of file utility VIs were thrown out with 8.0 and fundamental changes made to the primitives that I think are flawed. 1) the default mode of the read primitive in text mode is to terminate the read at an EOL. The ability to chunk through a file line by line is great, but I don't think it should be the default. 2) You cannot set the read mode via a control or constant. The only way to change the read mode is through a pop-up. The only way to determine the read mode setting is through the same pop-up - there are no visual cues. So - I don't think the file I/O primitives have taken a step forward. Variants - they needed a performance enhancement! Do you have a benchmark for how much slower they are over data passed by wire in their current implementation? My favorite feature of LV 8 - the ability to work on multiple targets. My least favorite features - the project and the arbitrary reorganization of the palettes. Each time the palettes are changed, my productivity decreases because things are no longer where they should be. -just my two bits. Richard

We have a couple of new LabVIEW authors - Jim Kring, Peter Blume. Any others? <shameless plug> Gary and I just released the 4th edition of "LabVIEW Graphical Programming" </shameless plug> McGrawHill is making plans for me to be on the expo floor signing books each night. What other authors will be there signing their wares? Richard

oooh! There we go - instead of presentations we can have a WWE style grudge match! It's unfortunate they're at the same time. I would have liked to attend your presentation Norm. Richard

See you there Jim! BTW how did JKI become the "poster boys" for NIWeek 06? That's awesome. Richard