Phillip Brooks

I'm not sure, but isn't "GetRawSocketFromConnectionID.vi" found in the TCP_NODELAY.LLB of that KB the the same as "vi.lib\Utility\tcp.llb\TCP Get Raw Net Object.vi"?.

Since an integer value has no NaN or ±Inf equivalent, some real number is required. The existing function uses defaults of zero and one, so this would be consistent. The fact that an integer zero or one output can be interpreted as a Boolean was simply an observation. (Maybe default input values of 1 and 20 would be in order for the D&D folks ) I like the 'Max and Min' function rather than the absolute value. I think we would have to subtract one from the improperly entered High value (less than low) and then round up in order to get the proper distribution. That would make the function overly complex. Since the function name contains "in range", should we change the labels for the inputs to 'a' and 'b'? If so, how do you select which one to make required? (Maybe both? Neither?) Please note that there is fairly complete collection of VIs for various data types and some extensions (like random array elements) located in sourceforge. They were submitted some time ago by dafemec as part of the thread I copied and pasted from. So; I start a thread about a random array subset vi. A suggestion was made to maybe be a bit more simple and extend the existing random number function. I create an example, the find a nice collection of stuff. This stuff includes datatype specific versions of the function that started the whole discussion. What do we want to do? Should we load the sourceforge files into this thread? Links: Random Number Sequence - Within Range (I16).vi Random Number Sequence - Within Range (I32).vi Random Number Sequence - Within Range (I8).vi Random Number Sequence - Within Range (U16).vi Random Number Sequence - Within Range (U32).vi Random Number Sequence - Within Range (U8).vi Random Numbers - Within Range (CDB).vi Random Numbers - Within Range (CSG).vi Random Numbers - Within Range (CXT).vi Random Numbers - Within Range (DBL).vi Random Numbers - Within Range (EXT).vi Random Numbers - Within Range (I16).vi Random Numbers - Within Range (I32).vi Random Numbers - Within Range (I8).vi Random Numbers - Within Range (SGL).vi Random Numbers - Within Range (U16).vi Random Numbers - Within Range (U32).vi Random Numbers - Within Range (U8).vi Single Random Number - Within Range (CDB).vi Single Random Number - Within Range (CSG).vi Single Random Number - Within Range (CXT).vi Single Random Number - Within Range (DBL).vi Single Random Number - Within Range (EXT).vi Single Random Number - Within Range (I16).vi Single Random Number - Within Range (I32).vi Single Random Number - Within Range (I8).vi Single Random Number - Within Range (SGL).vi Single Random Number - Within Range (U16).vi Single Random Number - Within Range (U32).vi Single Random Number - Within Range (U8).vi

By Jim Kring (Copied from OpenG forums; posted there 21 April 2008 - 05:17 PM) Proposal I propose that we add support to the "Random Number - Within Range" for integer values by making it a polymorphic function that outputs a uniform distribution for integer inputs (that includes both the Low and High input values). Behavior for floating point inputs would remain unchanged. Background There have been a couple recent discussions about generating random integers with the "Random Number - Within Range" function, shown below: When using the "Random Number - Within Range" function with integer inputs, most people (incorrectly) assume that the output will have a uniform distribution of integers between High and Low. When, in reality, the High and Low values will have half the rate of occurence than the values between High and Low, as shown in the screenshot and example VI, below: EXAMPLE___Problem_with_Random_Integer_Generation.vi Let's look at why this happens. Say we have a range from 1 to 10. Values from 1 to 1.5 will be rounded to 1. Values from 1.5 to 2.5 will be rounded to 2, values from 2.5 to 3.5 will be rounded to 3, ..., ..., .., values from 8.5 to 9.5 will be rounded to 9, and values from 9.5 to 10 will be rounded to 10. As you can see, the values of 1 and 10 each occur in a range of 0.5 out of 9, whereas the values of 2 through 9 each occur in a range of 1 out of 9. 1 and 10 have half the rate of occurence of 2 through 9. The solution is to extend the total range to High + 1 and then round the output value down, as shown in the screenshot, below: With this correction, the distribution is now uniform, as shown below: Open Issues Convert to Poly VI or create a new, seperate VI for integers? 25]The Polymorphic VI can be named "Random Number - Within Range.vi__ogtk.vi", so that replaces existing instances of the DBL implementation in users' code. For users' existing code that is inputting floating point values into this function, the DBL poly instance will be used and thier code will remain unchanged. For users' existing code that is inputing integer values into this function, the new integer implementation instances will be used. This choice relies on the assumption that the new integer behavior is desired whenever integers are wired into this function. An alternate approach would be to simply add a new, seperate VI for the integer types -- e.g., we might call this Random Integer.

This OpenG Review is closed. Based on Jim's suggestion in my post Select Random Array Indices, I submit this VI: 'Random Int Number - Within range'. The existing OpenG Random Number VI would presumably be renamed and added to a polymorphic VI. I chose I32 data types for compatibility with array indexing functions. The default values of one and zero allow this to be used with 'Not Equal to Zero?' to simulate a coin toss. Discuss. Random Int Number - Within Range__ogtk.vi UPDATE: I was going to provide a link to the existing OpenG 'Random Number' documentation. A Google search found that Jim already submitted something similar to the old OpenG forums, see here. Jim mentions that the high and low are negatively biased and solves this by adding one to the high value and then rounding down. I think his is better. Rather than duplicate Jim's post and test code, is there a way we can import the discussion from the OpenG board to the LAVA board?

The only use case I can think of might be related to unicode or multi-byte char sets, but that brings byte order into play, and I think this dark side community doc has some functions that can do this already... https://decibel.ni.com/content/docs/DOC-10153

On my OpenG Comparison Tools palette, there is one item (Data Changed). I would suggest that since there are no 'typical' nodes that we could standardize on a the larger 'Select' triangle along with a 5-3-3-5 pattern. Rationale: OpenG comparison functions will be extensions of existing functions and require additional inputs/outputs. 5-3-3-5 allows us more choices for the inputs and outputs. The larger node provides additional room for text inside and differentiates the node from the native node. Comparsion.vi We could also make it an Express VI

It does look a bit odd. Sorry, I'm on 8.6 with no time or resources to have 2009 around.

If I recall correctly, the code in the disabled structures is treated the same as a comment in text based langauges. It does not get included in the built executable. LabVIEW does allow you to build a 'debug' exe. I don't know if the disabled code would be included or not...

I was going to suggest the same thing, but after years and years of working for managers who all have their own style (beauty is in the eye of the beholder) I was going to let it go. As a natural extension of functions, I think it should be consistent with the other comparison palette functions (in line). I would suggest the Boolean 'strict' option be shown similar to other NI functions such as Array of Strings to Path and labeled 'strict case'.

If you look carefully at some of the LabVIEW posts regarding Nagle's Algorithm, you can find references to (or actual) VIs that you can use to toggle Nagling on a PER CONNECTION BASIS within your LabVIEW code. You certainly can make changes in Windows (via the registry) but this will affect all apps.

SuperSercretFunkyBlackWireThatDoesWhateverYouWant = TRUE[/CODE][/font]

I don't know, but there IS on on the OpenG Variant palette... http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-Variant-constant-to-the-Cluster-Class-amp-Variant-function/idi-p/1083987

I looked at some of the riffle posts on the dark side and noticed that riffle seems to be part of the FDS. Base folks wouldn't have this function to use. The other thing is that the array to be riffled is modified and must by an array of DBL, CDB or I32. My example does not use the data array as an input, only the size and number of elements to select. It would work for an array of clusters etc... Maybe an OpenG riffle function for base users and arrays of other types is useful?

My use case was for product sampling. We receive lots/batches of serialized products that we test for performance and prgramming. The sample size depends upon the previous lot/batch success rate. I perform the selection in Labview and update a database on pass/fail. We also have a device that is characterized by a polynomial. A lookup table for every step setting was in excess of our storage capacity. We collect a series of points, perform a fit, and then randomly test a couple of points against the polynomial for accuracy. When I took this random elements code (really badly done) and rewrote it, I remembered an NI forum post about randomizing a deck of cards and couldn't remember the name of the function. I guess riffle used with array subset would be the ' NI' way to do it. Thanks for reminding me!

I was recently cleaning up some awful code and extracted this piece as a general purpose function. I have problems with using VI Package manager at work and also still run LabVIEW 8.6.1, so I don't know if a recent OpenG function similar to this exists. Select Random Array Indices.vi

Lets say you have a very large file that you want to verify (the LabVIEW 2011 image ) Before extracting and installing, you might want to verify the file. The time to generate the MD5 from the downloaded file may be significant. If you are going to compare the results of a time consuming operation with an invalid string, you will be wasting time (by re-downloading a file that may be good). It is not easy to visually read or count the characters of an MD5 checksum...

The RFC states that it must be lower case... http://www.ietf.org/rfc/rfc2831.txt Let HEX(n) be the representation of the 16 octet MD5 hash n as astring of 32 hex digits (with alphabetic characters always in lowercase, since MD5 is case sensitive).

There is a function in LabVIEW to generate a GUID. See this post. Maybe an OpenG wrapper VI to call this function?

Since you are waiting for your hardware, this would be a good time to think about your environment and how to trigger. Your environment sounds different than an automated assembly line with controlled lighting and a constant rate. The environment will define how you place your camera, your trigger(s) and possibly require lighting control (additional lighting or screening to prevent glare).

Just a quick observation. Does this design trade memory for speed? If so, would this function ever be used in a memory constrained environment such as RT or FieldPoint? It appears that two copies of the string data (as U8 arrays, one reversed) are created to iterate over. Is the LabVIEW compiler is smart enough to only use one buffer for the U8 array data? What does LabVIEW Profiler tell us about the buffer allocations? I don't have 2009 installed, so I can't play with the examples. If there are two buffer allocations for the U8 array data, would there any difference in performance if the 'end trim' loop were to use the same U8 array and simply index from the end of the array (N-i-1) until a hit was found?

Considering that my math skills are roughly those of a 5th grader, I wanted to know where it came from. This wikipedia entry has the history and some details... http://en.wikipedia.org/wiki/Hearing_the_shape_of_a_drum This begs the question, can I smell the color of a fruit?

Jim has a nice one; http://lavag.org/topic/14745-lava-gets-an-upgrade/page__view__findpost__p__88542 More LAVA, less blabla

Where the hottest LabVIEW ideas flow... lava, LabVIEW, (data)flow... get it? I got nothin'...

Only foolin'. But... The DisplayLInk drivers for iPad work as advertised. You can use your iPad as an extended display under Windows... Set the iPad screen as my primary to move the Window toolbar to the iPad... http://itunes.apple....d411678720?mt=8 Install the PC client, and also install the app from iTunes (currently free!)

It was still showing LV 2010 when I posted this morning. The pages must be slowly rolling over to 2011 versions.