ShaunR

Can't wait to see the screenshots. Congrats.

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.

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.

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.

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

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

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

Someone got out of the wrong side of bed this morning

Trent 1000 Jet Engine

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.

You are connecting to an SSL address (https) but not configuring the internet session to use SSL. Put a "ConfigSSL.vi" after the open.

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

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 ). Yes. Although it will be a lot of work for you and you'll really struggle if you want cursors at some stage. I don't use either so I don't know. Try some matlab forums.

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.

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).

Indeed. In fact it's the same as trying to set the revision number less than the current revision for a VI where it will object with error no. 1077 (which maybe is what it should be for classes rather than 53). My opinion is that version numbers should be able to be set to whatever we want, however.

It's a shame that the conditional disable structure cannot tell what version of LabVIEW it is. I've got a "Tick Count" vi that uses the perf counter method on windows, the normal (1ms) one on the others and it would be great if I could put another case in there to use this little gem for when I'm working in 2010 and greater so it uses the best available (I have to work in 2009,10 and 11).

I was able to set both class and lvlibs without any problems. How are you calling the VI, i.e. what app refnum are you using? (I ran it standalone) A little later....... I can get error 53 if any of the Major, Minor, Fix numbers are zero. But works perfectly if they are all non-zero Aha! You cannot decrement the version of a user class. So if you are trying to set it to a lesser value, it fails with 53.

Correct. But that doesn't mean you cannot do it.

I've played around quite a bit with LabVIEW plug-in architectures over the years and they have always fallen short. They work great in development and for modular development, but for deployment, you end up with either having to distribute the plugin source with the deployment/updates (which you might not want to to do) or removing the diagrams (and having a plethora of distribution updates for each target in each LV version). It wasn't always the case, but now LabVIEW can create DLLs and it makes a lot more sense to use these. Whilst you don;t get away from distros for each target. You at least don't have to create distros for each LV version that the customer may use (and there are a lot of them). They can be loaded and unloaded at run-time, written in any language (including LV) and the plugins can be developed on any platform. Why faff around with LabVIEW specific methods when the OS already provides an elegant one.