ShaunR

yes but they are not even wired now so as said, and as far as I know LaBVIEW will see it as deadcode and remove it when the code is compiled.

Wiring through error clusters (if they exist) is recommended since if someone wires them up it will clear any errors on the wire from previous operations which is unexpected bahaviour.

I get a memory is full error for a size of 1 million

Thats because I cut and pasted your seed, method so it's not surprising (i.e you were trying to fit 1,0000,0000 x 1,000,0000 chars in memory)

In my tests this did not perform as well as the others. It would usually be 4th or 5th place in any array size. Not terrible but not the method I would prefer.

There's no pleasing some people

A bit of lateral thinking?

An alternative to the toolkit could be a command line call to FTP the files. I think the toolkit version is the clearest solution, but if all you want to do is this one function you may be able to do it another way. All though it is just $500.

Windows has a built in FTP command line program (just FTP at a command prompt). I've never used it but I assume it has the ability to login to a server and send a file over.

I'd forgotten about that.

You can even give it a script filename with all your commands and upload entire directories with the GLOB command.

You will need the LabVIEW Internet Toolkit if you are going to do it from LabVIEW.

e.g.

Can't wait to see the screenshots. Congrats.

So I embarked on a little journey this morning. Many times when developing code I have the need to search an array of string for some pattern. Usually I am looking for some set of characters in a string and then I need to get the whole string, and possibly the index that the string was found in the array.

<snip>

I know this is such a simple task, and for most cases it doesn't matter, but I was wondering what others have found. Is there a method that is generally preferred more? My thoughts would be that Method 1 would have been the fastest, since we only have to iterate over the items once, instead of an OpenG method, but I do realize the Build Array is an operation which can be bad for memory.

Well. For me anything that doesn't use 3rd party products is preferred

But generally when we are talking about this sort of thing we are also talking about convergence on a solution for the final optimisation step. As was indicated with the "Fast Trim"; using LabVIEW parallelism will always converge faster since the worst case is a solution is in the middle (if split over 2 for loops) rather than at the end. This however comes with the caveat for this case in how do you tell one loop that the other has found it without introducing complexity that mitigates the benefit.

I haven't tried your example (I don't have the JKI toolkit) but in theory enabling parallelism of the for loop should also yield benefits although I have yet to see a real world scenario where it actually does.

I'm not a fanboy for ActiveX (or .NET or COM or anything else customers require), but I'm curious as to the statement to stay clear of ActiveX in professional role?

Well. Ignoring x-platform considerations and that fact that Active X is built on windows 3.1 technology (A.K.A legacy). It's very easy to write Active X components very poorly and since you don't have the source. you can't do anything about the memory/reference leaks, GPFs and hangs that abound with Active X controls, They always look like a very easy solution, but I forget the number of times they have turned out to be anything other than a pain in the arse, sometimes risking the project. Additionally. If an active X control does go down, it invariably causes strange behavior all around the OS meaning that you end up on lots of wild goose chases trying to figure out whats wrong. IMHO you are far better off not considering them to begin with and you will still have a full head of hair well into your 70s.

They have bitten so hard in the past, that teams that I manage now are banned from using Active X and if a supplier only has an active X driver to interface to their equipment, they are disregarded regardless of the quality/performance of the hardware.

I went from 2009 to 2011 so I'm not sure which neat new features are from 2010 or 2011. The changes for me aren't some thing I can't live without, but I do use some of the newer features all the time.

Well. Probably 2010 because 2011 was supposed to be a "stability and performance" update (which when compared to 2009.....wasn't ) rather than a "look at all these cool features" update. (I'm not holding my breath for 2012 either )

Active X is a (legacy) Microsoft windows only technology. You will not be asked to do anything that is 3rd party dependent (i.e Active X .NET, windows API) although that does not prohibit using those technologies to achieve the requirements. The purpose of the examinations is to ascertain your LabVIEW skills, not your knowledge of the platform.

CSV only means "Comma Delimited Values" and as JGCode pointed out, it is only linked to Excel because of windows associations (it is not a proprietary formatted "Excel" file that can only be opened with a Microsoft product). In fact. I highly recommend you stay well clear of active X not only in the exam, but also in your professional role.

This list of 10 things might make LabVIEW a bit nicer for me as an NI customer, but I see nothing that helps me make my product better for my users...

I'm always afraid that if they did introduce something awesome enough to make me upgrade from LV2009; they would stick it in a toolkit

It definitely could be an endian-ness problem, but your characterization of LabVIEW is not quite right. LabVIEW flattens to big endian but in memory (any typed data on a wire) it matches the endian-ness of the CPU. Since all our desktop platforms are now x86, they all run as little endian. So the problem would be that his data is big endian and LabVIEW is treating it as little endian. Don't mean to be pedantic but I don't want someone to come along later and convince themselves all LabVIEW data is big endian.

I always get the terminology round the wrong way (has to do with a boolean array in LabVIEW having the LSb on the left). Thanks for pointing it out.

So. What I said before, but swap the terms.

You state that only the most significant bytes are used. This is a little unusual since an encoder is usually a counter. It is more likely that the number is little endian wheras LabVIEW numbers are big endian (i.e. you may have to reverse the bits to get 0-2^n).

Get.vi

Not at all - I just cringe when I see obvious engineering talent wasted on marketing

I prefer to think of it as sponsored art and really no different from commissioning a statue.

Whilst I applaud the coolness of this effort, if I was an engineer on this project I can't imagine feeling particularly satisfied that I'd used my talents in a worthwhile way to make the world a better place.

Someone got out of the wrong side of bed this morning

Thanks for the suggestion and link. If I cannot get LabVIEW bent to my will then I'll consider it.

Thank you! That did seem to help! I had tried using it (ConfigSSL.vi) at one time with this test code but had no luck and got scared away from it by all the inputs to the VI that I did not know how to use. After your suggestion I tried it again. My first try again yielded the error #42 but then I saw that the VI had a default-True boolean input telling it to check/use all those other inputs. I set the "verify server" input to false and the error went away and, based on the redirection and cookie I'm seeing, it appears like the login worked!

Thank you!

Yeah. If you are behind a natted router it will fail (as it cannot do a reverse DNS lookup to verify the server). But you've figured it out.

I am trying to use the HTTP Client VIs to implement a version of the C# code found HERE. Unfortunately there are no NI examples of how the client VIs are to be used and my various attempts to string them together only seem to result in "Error 42" (LabVIEW: Generic Error) from the POST vi, rather than returning the headers and body text.

I have also tried using DOTNET calls and was at least able to get the login page returned but could not seem to trigger the login.

I switched to the HTTP Client VIs because they offered an alternate hope and I could at least see where to attach a cookie file with them (though a cookie file may not be the same as reserving space for a session cookie).

Any guidance would be appreciated!

You are connecting to an SSL address (https) but not configuring the internet session to use SSL.

Put a "ConfigSSL.vi" after the open.

Sometimes I dream about a world where LV could abort CLNs.

I maybe just remembering through rose tinted spectacles, but I believe LV 7 could

HI ShaunR ：

You donot attached the Draw Grid.Vi

where are the X SCale space Cluster array from?

I'll leave you to figure that out. I've opened the door. It's up to you to walk through (take the red pill ).

You mean that Labview can plot the same look like the first picure.

Yes. Although it will be a lot of work for you and you'll really struggle if you want cursors at some stage.

what about DIAdem or matlab?

I don't use either so I don't know. Try some matlab forums.

HI ShaunR ：

Thank you !

I am a beginer ,so i can not understand your Vi.

I donot konw X SCale space Cluster array include what?

can you pass me you VI?

The image of the example is a labview snippit so that you can drag the image into a VI. The clusters are just the default clusters if you right click on the terminals and select "create Constant" (apart from I have changed the line colour from yellow to blue). The version of LV I am using is buggy in that it doesn't show the contents of the clusters in the snippit, but if you import into a VI, they will be there.

However. I have attached the example as this may be easier for you. You will still need to modify the Draw Grid.VI, as I have shown, since that is a VI shipped with LabVIEW as part of the Plot Graph function and not mine - you will need to modify your locally installed Draw Grid.vi.

The abort button is supposed to stop the VI immediately,

It used to. Now you have to wait for LV to finish scratching its arse (yeah I'm looking at you serial port VIs)

With the chart/graph controls you are using; you cannot.

You will have to draw it yourself with the picture plots.

The picture plots come with VIs for drawing xy graphs, however, they do not expose the grid line type so you will have to edit the sub VI that draws the grid (or draw everything yourself from scratch-which I think you will end up doing eventually to get the same look and feel as the first image).

Picture plots are here

.

You create your graph and draw it like this:

You will need to look inside several sub-vis to find the Draw Grid.vi and modify it like so:

Then when you run it you get this:

Check your array index. I the index is -1 or greater than the elements in the array the output will be the default (0 for numeric, empty string for strings).