ShaunR

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.

Well. It's not off-topic since it is about code that you posted as an example in this topic . If you are happy to limit the portability of your source distributions, That's entirely up to you (I prefer the input from as many people as possible). One of the beauty's of LabVIEW is that it is multi-platform so anyone with LabVIEW x32/x64 or even linux and a Mac can use source posted on the forum. Only those with windows AND LabVIEW x32 can load your source. What is that saying about "assumptions being the mother of all muck-ups"? This is the very reason that I avoid packed lvlibs at all costs. I see no up-side but one huge down-side.

I would avoid packed libraries if you can. They do not seem to be multi-platform (not even on the same OS). This is what happens if I try and load your library in LabVIEW 2011 x64 (it loads fine in x32).

You need to hook the windows messages to the the LabVIEW front panel (I haven't used the library though). This cannot be achieved with the event structure (I've been wingeing about event support for ages). It can only realistically be achieved with a DLL. Here's the messages you need to look for

More like a couple of months. IE10 has support in-built and that was the only outstanding problem (as it is always with IE).

We kind of hijacked another thread with our SSD benchmarks so I thought it only fair to move them to another separate thread. So if you have a SSD; post the benchmarks here.

Yup. Default values. The writes are a bit low on the posted benchmark 'cos my TV card was also buffering to disk. Force GT 480GB

You can benchmark your disks using the Win32 File IO benchmarks which was designed to show the difference between the native labview functions and win32 IO. If I remember correctly (it's been a while since I played with ETS), the win32 ones should work. If not, there are the native labview ones which definitely work. And just for sheer awsomeness. Here's the benchmark for my SSD

Quite minor now. The versions can be automatically detected (there are only two base variants) and only IE is the difficult one since it must use Silverlight (although the main difficulty is with Javascript detection of the sockets rather than LabVIEW).

Care to expand?

Ooooh. I'm gonna have have to look at my circular buffer VI to see if the "Swap Vector Elements" improves performance

Well. I can only speak two and write one so I try and convince people that I can write several by including programming languages to make me feel better Which you paid the licenses for, right?

I'm a native English speaker and I couldn't give a monkey's about grammar on a forum ...lol Your Dutch must be ultra juiste

I still have a few of the Series 2000 pre-production prototypes, one of which has been running my central heating since 1998 It's a bit of a waste of the controllers' talents-but rock solid! I think the old ASCII Bi-synch and modbus drivers that I wrote are still around on the internet somewhere too

Well. I highly recommend Eurotherm controllers and they have LabVIEW drivers. (Maybe I'm biased though since I used to work for them )

That's the point. IF you are going to make it viewable by other applications, they inherently assume the encoding by the pragma call (PRAGMA encoding; ). Sqlites default encoding scheme is UTF8 but you can set it to others so text in the DB "should" be one of the defined types (none of which LabVIEW supports natively). If, for example, Chinese characters are inserted ( which, in labview are MBCS) then they will not display correctly in other apps.