ShaunR

Can't help with the problem. But maybe can explain how it is different It is a "plug-in" control and resides in the "\resource\PlugInControls" directory. As far as I'm aware, it is an undocumented interface allowing controls to be created from external DLLs and resources. I have a feeling it was the way NI was going for custom controls before they decided on Xcontrols.

Sorry to hear that dude. I'm in a slightly different position that I'm about to throw in the towel. But JKI seem to be sucking up any and all LV programmers. Maybe there's a chair there with your name on it already

Well. My 2 cents. In practical terms; to transmit data over TCPIP you only need to know the length (ignore transport layers-at the application layer). How you bundle that data into the payload is irrelevant as long as you know how many bytes you are expecting. So simplest and most effective is a n-bit length and then your payload. You can use delimiters, but then you cannot send binary data without escaping it all and/or you have to put a lot more logic into your software to keep reading and testing data to find the end. That ticks all your boxes, for sending and receiving. It's the payload, however, that you need to decide how to package to make it "future" proof. Abstract the interface from the data and treat them separately. Once you have decided on how you are going to package it, it will either be a simple case of adding a length byte and transmitting, or the packaging will dictate that you use delimiters and (probably) some bloaty engine to parse it.

Definitely "L-Vish". Explains 2011 to us halflings

Touche

I wouldn't expect language like that from you of all people, Crelf. Are you going to give yourself a warning?

Budgie smugglers underneath?

Don't forget to turn off debugging

Better make that 2009 too

A simple (not fool-proof) way is just to read the volume serial number of the USB stick. There's the "Windows API" in the CR tat will allow you to do that. Alternatively, you could read the device ID out of the windows registry.

Your proposal will work well. It''s a centralised system and is proven to work well on small scale apps You could also consider a "de-centralised" system where each "module" (your serial thingies) is a producer AND consumer so that data can not only be streamed from them, but control messages can be sent to them. Consider, for example, that your new UI module wants to stop one (or all) of the serial modules - a common requirement. In a centralised system, the responsibly for that lies with the messaging node (your consumer) since it is the only part that is aware of the "STOP" message. At that point, things can get ugly as the app grows since now it's no longer just a consumer (just processing data), it's also a controller - so the responsibility boundary becomes blurred. In a decentralised system, you can (don't have to...but can) pass the message straight from the UI to one or all of the modules directly. It doesn't stop you having a centralised processing point for data being emitted from the modules. It's just a little more "modular" in terms of how everything can fit together.

Well. I've got no idea what you are talking about. However. A LV picture speaks a thousand words so a quick glance at your code and it looks like you are just wanting to detect sign changes between 2 arrays of doubles? If this is correct then I would do something like this:

Xnodes don't quite work like that (you would think it was similar to an Xcontrol...But it isn't) They are basically pre-packaged script nodes that are programmed to generate code when executed. So the xnode in question has lots of script to create a CLN and all the function parameters to interface to the DLL. The result is that at some point (not sure exactly when, maybe after compilation, or when you press the run button) the xnode runs, then creates the code and it is this generated code which runs in the place of the xnode - In this case a CLN in the UI thread. It's a lot of [script] code to generate a relatively small amount of real code that could have been created as you described and wrapped in a polymorphic VI for the adapt-to-type (no need for the intermediary DLL then and it wouldn't have to execute in the UI thread).

Xnodes don't quite work like that (you would think it was similar to an Xcontrol...But it isn't) They are basically pre-packaged script nodes that are programmed to generate code when executed. So the xnode in question has lots of script to create a CLN and all the function parameters to interface to the DLL. The result is that at some point (not sure exactly when, maybe after compilation, or when you press the run button) the xnode runs, then creates the code and it is this generated code which runs in the place of the xnode - In this case a CLN in the UI thread. It's a lot of [script] code to generate a relatively small amount of real code that could have been created as you described and wrapped in a polymorphic VI for the adapt-to-type (no need for the intermediary DLL then and it wouldn't have to execute in the UI thread).

Depends on which way you are looking at it......... Set it up once in MAX (make sure it all works). Export an nce file. Add it you your project. and set it in the installer. Once you build your installer you will only need to put it on a CD or USB stick or whatever and install it on any machine So effectively you use MAX to create your hardware "template" and then roll that out with the installer which will take care of configuring the target machines hardware. Your software will always use the same taks/channels regardless of which machine it is on and, as long as you put the C ID and DEV ID somewhere (file name is good if you just want to see at a glance in xplorer without opening files), you'll be able to track the results to the hardware. I would suggest also adding the date to the file name (e.g 2001-01-21) in that order then when you view the results you can sort them in explorer. Additionally, you can set the file date as a directory name and store your results by date making it easy to identify what was tested on which days. But it's just personal preference (one directory with lots of files or a few directories with a few files)

Use the same name (in the tasks/channel/hardware configuration) or all the DAQ devices (say cDAQ). In your results file also save the DAQ devices serial number (you can read this using a property node shown below) and the computers ID (anything that identifies a unique computer - computer name, network card, IP address, HD serial etc). This way the executable will run on any suitcase, with any PC/DAQ (as long as they are all the same) but will save data that is traceable to a particular suitcase PC and/or a particular cDAQ.

Strings are arrays of bytes.

A normal non re-entrant VI is a singleton

Set the vi to subroutine (assuming you are using a sub-vi vi in a for loop) and you'll probably halve those times

Nothing in comparison to dynamic dispatch.

Well. I thought I'd get my hands dirty and take the xnode apart. You are right. It doesn't just call moveblock. In fact, it doesn't call it at all!. It calls "GetValueByPointer" in "lvimptsl.dll" (that might call moveblock). But, more importantly (as you surmised), it does this in the UI thread (presumably because the dll isn't thread-safe). So. You're on a roll , That's the reason it's so slow (and totally unusable for 99% of my apps). But your suggestion works a treat

....done that...bought the tee-shirt.....

Thats ok. Just write a quick proxy filter to modify it on the fly (if your not using firefox). Make sure you add to the version info field "IT ARE ANALLY RETENTIVE NUMB-NUTS " (in capitals so it's easy to spot in their logs) Oh the joys of local admin privileges

The point is. Under windows. No dialogue based password system is 100% secure whether it's from NI or not (although I bet NI wouldn't have to spend as long as me circumventing VI passwords ) Password protection is like a key to your front door - it only keeps out law-abiding citizens Of course. I'm a law abiding citizen, so I would never consider circumventing NIs protection .