ShaunR

Also...... you need to put the boolean control terminals inside of the case for that control otherwise when you press them they will not pop back to thier FALSE state. e.g

As far as I'm aware, lv can only load a dll of the correct bitness so I envisaged at least 2 zwrapper dlls (one x32 & one x64 if you stayed with an intermediary) even if you managed to thunk down to a single 32 bit zlib (expecting 4 dlls in total though). There's obviously a trick I'm missing and can't wait to see the solution. PC on next day delivery?

Is it the wrapper dll or the zlib dll thats crashing?. I've have a zlib dll that I'm using successfully in LVx64 if that's what is causing you problems. I'm not using it for zip files as I'm currently using the LV shipped ones (although it is compiled with the minizip 64 bit functons - not sure if you use them or not ). It passes all the zlib and minizip tests and labview isn't complaining (or dying) when compressing buffers. Anyhoo. I'm attaching it in the hope it might save you a bit of time.

I don't think your program is doing what you think it is doing. Your top loop is updating the indicators every 1 second. And your bottom loop will show you the new value about 0.25s after that. The "lag" is because you are only updating the command2 indicators every 250 ms. Set the 250 ms wait to zero and they will change instantly. You would be hard-pushed to measure the read/write time of a local variable (which would be a few cycles of the computers clock).

I think that'd be great. There's very little in native labview for encryption (for free ). It must be nice to have so much free resource to work on your little nuggets

The only real (practical) way out of this scenario is to use a database which handles locking,delayed writes and concurrency for you. Thats why websites run off databases and not file systems.

Bingo! It's not really an x32 on x64 problem. It's an x32 in windows7 problem. there is only a finite number of addresses that can be gotten with a 32 bit number. Problem is, they are all towards the top end of the range since Win7 hogs most of the bottom. Without switching to X64. you will still be limited in the address space so 20 is probably the best you can hope for. The trick is, how to offset those addresses against the Windows7 OS to claw back some memory for your app. Try having a read of this. It works on Windows 7 (I believe and have been told, but never tried). where have I heard that before

Vartor provide a "Crypto Pack" which (IMHO) is well worth the $20 especially as it comes with full source. It has (amongst other things) AES.

Why not just use the "Deny Access" vi (should be in LV7.0 - under file IO>>advanced file functions).

How hard is it to tx data and power through metal? My mains plugs do it pretty well

If you are having difficulty with firefox. Open the image in a new tab before dragging to the desktop. It can be a bit of a pain in firefox. (it's even worse in chrome) You can tell it's a snippet because it has the hand,arrow and lv icon in the top left of the diagram image. It also has the labview version in the top right.

If you are using exploere, just drag the image from explorer to an empty diagram. If you are using firefox, drag it to your desktop then drag it from there to an empty diagram. VI snippits are png image files with the actual code embedded in the image. When you drag the png image to a diagram, labview will re-create the code.

Good choice. Just stick some length bits on the front (u64) and you are good to go.

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: