ShaunR

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.

I wouldn't worry too much about performance to begin with. Getting everything mapped out and functioning is (IMHO) more important since the optimisation does not prevent it's use and can take a while due to it being an iterative process (this can be achieved with each stable release). If you are looking at making it directly compatible with other apps for viewing, you will need to insert using the "string to UTF8" and recover using the "UTF8 To String" vis as the methods Matt and I use do not honor this. UTF8 Conversion Because to use the Moveblock you have to use 3 API calls rather than one (Get the pointer, the size and then Move it). That's not the reason

Interesting. So your SIF is "untyping" and "re-typing" using strings also. Not sure what the "Culture" is for since file formats are locale agnostic. Is this to cater for decimal points and time? I'm also not sure of the need for a "Strategy" interface unless it is just from a purist point of view. After all. If you wire an object to the Serialize class you want it saved right away before you read it again, right? Perhaps you can expand on the use case for this? I think the only real difference from what "you would like to see" and what I was envisioning is that the SIF Converter would actually be one of the Formats (JSON probably if it were up to me) meaning that the "Formatter" coverts from JSON to the others (they override the default). However, that is an implementation specific aspect so as not to re-invent the wheel and there is no reason why it cannot be a propriety syntax I suppose one other difference is that I would probably not have the "Human Readable" interface and each file format (binary, JSON, XML et. al.) would have a discrete "Formatter" for it's implementation. In this way, different file formats have a unified interface (JSON in my example) and the formatter/file saving is a self-contained plug-in that you just pop in the directory/lib

Any USB device is going to be limited in it's current capability (both sourcing and sinking) and usually only 5v - You didn't say which relays (5v/12v/24v). You are much better going for a PCI solution such as the NI-PCI 6517 which will operate 12v and 24v directly without intermediary hardware (32x125mA max or 425 mA per single activated relay). You'll also have more than enough current headroom to add LEDs that can burn retinas at 100 paces If it is a 5V relay, you can still use the same card, but you may have to put a resistor in-line to drop the lower (off) threshold depending on the relay. Most of the time you can get away without this however.

You might want to take a look at Dispatcher in the CR which may give you most of what you want.

Well. To be fair, Rolf was on the trail with a lot less info than I (gotta be worth a "like" or two).. His next post would have been the same once he saw your files.

OK. Reinstalling the GCC compiler with the latest version fixed the spurious references (0 bad, 6 stubs). I'm set to go for the next step. Woot.

Multiply your array values by 255/Z Amplitude for displaying. [e.g Value * Round(255/1.76859)]

No. The SQLite amalgamation code is untouched. All differences are via the in-built defines or features. Yes you can just drop in the sqlite3.dll (renaming it of course). But there are features enabled that, are not enabled by default from the sqlite.org dll (foreign keys for example). The dll available from sqlite.org also doesn't support encryption. Up until now. I've just recompiled the binaries with the latest version when I released a new API version. That was fine whilst the API was fluid since my updates where faster than the sqlite ones. Now, however, the API is updated far less often than the binaries and since they are distributed as part of the API package and installer, I don't really want to update the API version just because there are new binaries. It's been coming for a while. I just need to get off my arse and do it They probably use a x-compiler from linux (really must get me one of those ). So what you are saying makes sense. I'll do a grep on the Mingw source/includes and see what turns up now I know where to look.