ShaunR

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.

Bloody hell. They've released 3.7.14 already?I'm definitely going to have to separate out the binaries from LV source (which I've been thinking about for a while now). I'm looking at the dll shipped with the SQLite API For LabVIEW (for obvious reasons). I too cannot find any references to them in the source and, the DLL Dependency walker says they are not bound. Still. The LV 2011 SP1 DLL Checker says they are there. If I run the DLL checker on SQLite.orgs DLL they are not listed (as you have shown), but if I build the dll from the source amalgamation (I use GCC under MingW) they appear. It isn't a straight comparison, however, since the API DLL has encryption and different compiler settings. It'll take me a while to incrementally build everything back up from the original amalgamation to where it is now to identify the "bit" that drags it in. It may even be the compiler dragging it in. Maybe. One step at a time. I'm not too worried about file system support since there are a plethora of methods built in to the SQLite API. Especially now that they support Windows 8 RT and WinCE (note that the RT stand for run-time not real time as I first thought...lol) . They have implemented #define switches for the differing WIN APIs. There is bound to be something but hell, "It's only software"

I agree. SQLite is made for these systems. With my recent success with compiling for the Mac (and because a couple of people asked me about it recently), I decided to look into it. VxWorks is a long way off due to a lack of hardware for development and testing. However, I have an old copy of the Pharlap ETS so that is "supportable" in theory. First step though is to get the unsupported kernel calls addressed and I have had some success with that. I'm now down to 3 (from 13). Can't for the life of me find where the AddAtomA, FindAtomA and GetAtomNameA are referenced so it must be an indirect dependency. I know it's a while ago this was posted,and you succeeded in compiling for Pharlap. Have you looked at this more recently?

I'm not really understanding then since the charts/graphs display as many pots as you wire to them.

The property node Legend>>Number of Rows?

Attach your your code (source and compiled). Our crystal balls are not working at the moment.

Another thread perhaps?

If you also route the "requestor" requests through the "Wait on Responses" (no need for your dotted line then) the you end up with the "Dispatcher" that I've been describing.

Indeed. In fact. The only safe way is to have a specific Destroy (I'll be eagerly looking at the solutions here, since I have not found one other than the wrapper). If you use a ref counter and clean up when the count reaches zero (within the modules). What happens if the modules get called sequentially? The first module will create the queue, release it and therefore destroy the data since the counter is now 0 (no other modules have obtained a ref). When the next module in the sequence needs it it will be gone. This is the race condition that occurs when they are all running asynchronously.

I believe this may break the license agreement. Added my own emphasis