Leaderboard

Name: OpenG Config XNodes Submitter: GregSands Submitted: 08 Jun 2011 File Updated: 08 Jun 2011 Category: *Uncertified* LabVIEW Version: 8.6 License Type: BSD (Most common) These XNodes wrap the OpenG Variant Config routines so that clusters are automagically returned as themselves rather than as variants. The XNodes simply call the OpenG routines, as I didn't want to have to worry about handling (or rewriting) the reentrant algorithm used. XNodes are provided for Read/Write INI Cluster, Read/Write Section Cluster, and Read/Write Key, and should work as direct replacements. Many thanks to Gavin Burnell for his extremely helpful toolkit, and his release of Array XNodes which provided the inspiration for trying my first XNodes. I also use a modified version of the XNode Manager by Aitor Solar to create the initial XNodes. All the usual caveats apply when using XNodes - i.e. don't, unless you know what you're doing, or don't care what happens! Dependencies: oglib_variantconfig >= 2.7-2 lava_lib_labview_api_scripting_tools >= 0.22.2.22 Click here to download this file

Hi Martin -- There's a few solutions you have without purchasing Mathscript! There is an old library called Tripolation - found here. It computes a Delaunay triangulation and interpolates from that, however will not extrapolate outside the convex hull of your data points. Another way to get a Delaunay triangulation is shown here, using the SceneMesh which is part of the 3D Picture control. I've implemented a simple version of Kriging interpolation, which has the advantage of working in 2D or 3D, and of being able to extrapolate (with the usual caveats). In the attached code, note that the Kriging Weights would only need to be computed once for any given geometry, and the interpolation quickly updated for changes in data point values. More complex interpolations can be obtained by modifying the weights on the distances, for example to use a Gaussian or exponential weighting. Cheers ~ Greg Kriging Interpolation Simple.vi

Don't normally go in for this sort of thing....but Front slogan: Class - Simplified Rear slogan: Simply Class Or maybe thr other way round..

Here is my proposition. Inspired by recent LAVA activity... However I haven't read that all And alternative version for the front, which is even more pure:

[Copied Paul's question from another thread to try and keep discussion contained.] Just to make sure we're all on the same page, here's how I use the various terms: Entry Action - Executes one time every time the state is entered, regardless of the previous state. Execution* Action - Executes continuously until the state decides it's done. Exit Action - Executes one time every time the state is exited, regardless of the next state. Transition Action - Executes after exiting one state but before entering the next state. Each transition action is associated with one arrow on the state diagram. (*Also known as "Do Actions" or "Input Actions," depending on the literature.) You're thinking in QSM terms where each case is a state. That's a flawed approach. It requires you to repeatedly exit and re-enter the state so you can monitor the queue for new messages. As you said, you have to somehow keep track of whether we're re-entering this state or entering it from another state to be able to handle entry actions. I skip all that confusion and use separate vis for EntryActions, ExecutionActions, ExitActions, and StateTransition methods. The action sequencing is done by the StateMachine:Execute method, as shown below. The outer loop executes only one time for each state. The inner loop continues executing the state's ExecutionActions method until the state receives a combination of input signals the state understands as a trigger to transition to a new state.