Yair

...in this case, using the third method in 7.0 with an array of 10,000 elements leaves 1300-1400 of the elements in their original locations, which is a rather large margin of error (13 percent). Since this method is based on the random number generator and the number is around this range every time I run the VI it seems reasonable to assume that this is a property of the random number generation which is reflected through using this method.

I asked the cryptographer friend I mentioned about this and he provided me an explanation which shows that this is not LV's fault. He said that we can discard the number of times an element is switched more than once back to its original position as statistically insignificant and just look at the number of elements which were never moved.

Then, he said that the formula for calculating the chance of an element not being chosen was defined as

which means that the larger n gets, the closer the result is to e^-1. Then, he said that the chance of a single element of our array NOT being chosen is ((x-1)/x)^2x (it can be chosen once in each selection and we select 2x numbers because we select 2 random elements in each iteration.

He also said that the formula shown earlier only gets to e at infinity, but it gets very close to e at a very early stage, so basically that equation will be very close to e for any number above a certain number (let's say 20 or 30). With some simple power math he showed that the expression I wrote is equal to e to the power of -2 which comes out to 0.136, which is the result I got and means that LV's random function is now cleared.

That's why they sell it in Germany as "Fosters - Famous Australian Beer". Nobody want's to drink it @ home => they have to sell it somewhere else.

I once saw a German wine expert tell Jeremy Clarkson the same thing about Blue Nun wine - no one in Germany likes it, so they send it all to the UK.

I had read the term years ago in the novel "The Moon Is A Harsh Mistress" by Heinlein (one of the best scifi novels of all time in my opinion.)

Amen to that (although I can't say I read that novel). I could see how someone going through the various LL books would resort to drinking a lot of beer as a solution, though. Those books can be extremely hard to follow properly. It's almost like a space (soap) opera.

Why this option of using some other compiler instead of LabWindows CVI couldn't be possible. All it requires is will from NI to put some effort on it. There could be a new High Performance LabVIEW toolkit that would use high performance compilers from other vendors. Of course it can be that LabVIEW generates code that is far from ANSI C and only LabWindows could be used to compile it.

I believe you've misunderstood Rolf on this point.

LV does not generate C code, but machine code. There are some exceptions (like LV embedded or (I think) the PDA module), but not the PC version.

If I understand Rolf's explanation correctly, he meant that if you build your VI as a DLL instead of an EXE, LV will use the CVI RTE to generate parts of the DLL. At no time is the LV code translated to C.

Still, I steadfastly deny any responsibility and suggest Yen be subjected to the :beer: Shiner Bock Beer Torture :beer:

Don't try to dodge your accountability! You've sown the seed!

Anyway, I guess this admission will get me thrown out of the forums permanently, but - I don't drink beer, so it wouldn't work on me.

There. I've said it.

Now you can have your way with me.

and in Kermit's famous words: "We now return you to your regular scheduled programme..."

Didn't work last time...

Maybe we should invoke Godwyn's law so the thread is closed...

Although I'd thought of doing that, I figured it'd be in bad taste

Noooo.....

hat are you talking about?

It looks great!

No one will stone you!

You should do it!

People will love it!

Really...

BTW, it seems the forum itself really didn't like your change of the avatar -

Oh, and it's no trouble - takes about a minute with Imageready.

Too bad the LAVA avatar can't fade from Kermit to Mel and back ...

Who said it can't?

However, you can copy the constant from 7.1 and add it into the menus in 8.

Although, if there are new errors for 8, that enum won't include them.

Define your errors in advance and make sure the code knows what to do when encountering each error. Make sure to have unique error numbers.

You can try looking at the error handling section here for an article and some VIs.

If you still need to do serial communication, there are serial VIs for the PDA module (old style serial, no VISA). I don't remember using them, but they should presumably be in the Instrument I/O palette.

But would have loved to see a balloon tip, on a front panel object.

Then just do something like the attached example. I copied the image from Word and used it to replace the frame of a string indicator. The balloon even appears near your control.

Download File:post-1431-1149069054.vi

I believe this should answer your question.

Reminds me that I actually need to properly get into this myself one of these days.

As an addition to emulating the windows explorer behavior, if you're using the Key Down event, you should consider using the Key Down? event instead and discarding all the clicks for the illegal characters.

As Neville pointed out, the student edition is basically identical to the FDS, but one other thing which is rather annoying about it is that every front panel will always have the watermark of the student edition. If you're working with a large enough resolution this should hopefully not bother you too much.

The wireless stuff can be implemented through the Bluetooth or TCP functions (I recommend the TCP over Wi-Fi) and it is extremely easy in LV.

You should consider the fact that if you are completely new to LV you might have trouble producing a complex application - LV is much simpler to learn and use than other languages, but it's paradigm is somewhat different, and to produce quality results in complex systems requires some experience.

P.S. Stay away from the base version (the $1,000 one). It lacks some important stuff (like the ability to configure event structures).

Pay attention, this is complicated.

Open the Example Finder (Help>>Find Examples).

Go to the search tab.

Search for "Excel".

Open the example which shows how to do what you want.

Run it.

An approach that immediately comes to mind is using the picture control - you will need to recognize the number of unique elements and how many connections each one has and decide where in the picture you want to display each one.

Drawing the arrows is a joke (just create a subVI which recieves the start point and end point and adds the arrow head based on the angle) and writing text is not a real problem (you can easily create another subVI which will even write the text in a filled circle or rectangle), so the main challenge should be the code which decides where to put each element.

My work here is done

Maybe I should have thrown "I'm MELTIIIING" in there as well.

When I went to that page, I thought "Fair enough, don't think I'd ever need it, but okay if that person needs something like that in their personal toolkit", and then after a few seconds I thought "Hang on a minute..."

I think that to see why this was nominated here you have to actually open the VI (although it is true that the description also shows that the VI is far from being generalized enough).

Here's a new one for the worst of the net

Ow!!!

My eyes are completely burned now. I can't see! I CAN'T SEE!

You can paste exisiting VIs on to the block diagram of a VI and then wire it up.

I thought the point was to get rid of the subVIs.

There are two things that could solve this. One thing is a complete overhaul of the formula node, making it a complete C compiler within labview, as it should be IMO

Rolf will probably jump in soon enough to tell you that integrating a C compiler into LV is something that would be a huge undertaking and not worth it because that's exactly what LV is not (and you should always listen to Rolf). When he will tell you this he will probably also say that if you're already content to write this in C, you might as well use a real compiler and build the DLL.

Isn't it nice that time is bidirectional and I can tell what will happen in the future?

I haven't played much with dynamic code generation, but as far as I know this is more complex than copying and pasting - you have to select only functions and wires (not terminals) and then you have to replace the existing code and link the pasted code to the appropiate place.

As far as I remember wires don't appear properly in the Objects[] property and so probably need to be handled seperately. Also, this will probably make your code really ugly (although if this is only for execution this should matter less). The other thing I would be afraid of is the reliability of thing - you wouldn't want your code to be messed up because the programmer overlooked something or because a scripting feature wasn't fully developed.

If it's that important, it's probably better to do it manually or to write it in a single VI in the first place.

Can you create a specific example showing whatever you think the problem is?

I remember testing the remote FP methods and properties in 7.0 and they worked fine. I assume they were tested for 8 as well.

Ok , I will consider that as soon as find a job.

Looks like you should post to this thread to show that being a CLA does not automatically mean you get a job.

I can see the Edit button for my latest post, so, apparently I can edit it, but how can I edit my earlier posts?

You need to be a premium member.

Just follow the link in Chris's signature.

Another thing, since you're working with multiple LV versions -

I don't know about DAQmx, but at least for FieldPoint, the FP Driver installed on your development machine with 8.0 (FP 5.0) takes the place of the older FP driver and can not work with LV 6.1 and below. So, if you have LV 6.1 and you install 8.0, you will find that you can't use FP with your old LV version anymore. Just something you might want to watch out for, in case there is a DAQ equivalent or if you're using FP.

And the OpenG file toolkit includes something along the same lines (saving anything (and everything)to an INI file).

I haven't done any LV<->Java communication, but using the LV TCP functions is simple and you can find several examples in the example finder (Help>Find Examples).

Basically, you get a byte stream which is represented as a string. Normally, in the LV implementation, the sender calculates the size of the data and sends a 4 byte string (an I32) which tells the reciever exactly how much data it's going to get. That way, you can always read 4 bytes to get the size of the data and then ask for that size. You can do a similar implementation in your code, where you would (for example) always send x ASCII characters representing the length of the data.

You can convert the string to a U8 array using one of the functions from the string palette and (if necessary) you can reverse the endianess of the bytes by using the VIs in the Advanced palette.

I would advise that you stick to sending simple ASCII characters and not try to format more complex data into something that LV will understand.