jgcode

That is my preferred use case too. I should note this is all LabVIEW desktop-type stuff. In FPGA (a little in RT too), flat sequence structures are your friend

Hi Alex These are some pretty fundamental things that I suggest, rather than searching in this case, you create the code stubs and just run and test them. That can be an equally fast way to find things out. Here is a start for you: <edit> Ton beat me to the post </edit>

Ok, sorry for the scare To clarify what I meant: LV2009 The Close VI, by default, will not write to the config file if it has not changed. E.g. Therefore you can perform a read and it will work in ProgramFiles using the defaults. LV8.6 The Close VI, by default, writes the configuration file each time. E.g. Therefore you can perform a read and it will not work in ProgramFiles using the defaults. It just a default, but I thought the change was interesting to point out. as I got a different behaviour when the same code in different LabVIEW versions. The Open VI has 8.6 on it, but Close VI is upgraded to the new one. Therefore I was just wondering if this change to the API was done as a request from users, or to facilitate e.g. ProgramFiles read-only by NI (conforming to VISTA/7 standards or something etc..)?

You are too kind! Cheers JG

I forgot to say LV2009 for me.

Thanks for posting the link

I ran this on Windows 7 and it works fine. Both loops continued to increment the index with the browse dialog open. I even switched execution to user interface and it worked fine. Is this feature OS dependent?

I thought we just had an update?

That is great! Thanks Crelf, would you mind going into detail on this as it is something I have had to put thought into recently. We predominately do application releases, but there's probably 10-20% who want to pay extra for the source code. I guess my question is: What is the best way to provide elements of <your company's> reuse library for clients that purchase source code whilst maximizing the protection of your IP? What do you mean by two repositories? Obviously the packages need to be name spaced the same so the code does not need to be relinked? How is the external packaged versioned wrt the internal package? One project I would like to do is too look at a tool or build hook that will apply security to the VIs i.e. as you mentioned password protect (API and subVIs), strip icons, labels, hide names on the FP etc.. (subVIs only). I even like the way JKI create a HEX string and rename the subVIs - thats cool. Are you able to comment on the how your tool works and it's implementation in the release cycle of your source code distribution for a client project? And details will be greatly appreciated. Cheers JG

Surely there has to be a nicer fix!!!

Great point! I thought I read somewhere that with VISTA and 7 there was a push to move stuff out of the registry? I.e. amped up security there too for write access. Is anyone else fond of the registry - and how does this translate across platforms? (have only programmed Windows OS).

This bug? is really annoying - can anyone get this to work? Is there a workaround? Cheers JG

If this is a route consider, then here is a link to a previous discussion with examples. Cheers JG

Thanks for the example Ton. This is what I want to do, but was unsure of the context of the statement. Cheers

I know writing to ProgramFiles is not allowed in VISTA onwards, but was allowed in 2000/XP (only with admin installation, default user account - which is probably most cases) However, does anyone do any "read only" stuff in ProgramFiles? The 2009 Config API by default does not write to disk on Close anymore and the Read Text (but not Read Binary) when set with the Read Only permission works in ProgramFiles. Alot more application are "portable" these days - being able to run off USB etc.. or moved around in location. Does anyone utilize this for read-at-startup-only type configs? Or is it considered a big nono? Cheers JG

Hi Crelf Thank you for replying. To clarify: I am chasing the definition of the word unpackaged in the context Do not include unpackaged OpenG code in relation to submitting LAVACR Certified code. For a library-type dist, I would definitely do what you are suggesting, but it is for a tool-type dist so I want to know that all the dependencies are definitely included at all times (so my tool will never be broken / and I never had to do any checking on launch aka OGPB APIs). Otherwise it is up the user to have everything correctly installed. I understand your point on server size, but for a small tool-type dist, it will only add a little size for a couple of VIs that I need to include (so server size consideration should not be a big issue in this case, LAVACR rules are). I understand if I threw some OpenG subVIs in a zip folder with my src than that would be bad for everyone. But I want to know if I create a dist with (e.g. OpenG) dependent VIs all saved in an llb (and namespaced inside) along with my other support subVIs that this will be ok I am worried that if it is out of its original package (.vip/ogp) then it is considered unpackaged meaning a llb type dist would not be LAVACR Certified. Another example is VIPM internal dependencies' are only included if they are linked in the dist (it is not the whole package) and those files (can) get renamed with the namespace as well, and stored in a llb. So that must be covered under the packages license to do this? Would this type of dist be LAVACR certified? On a side note I must say thanks, as I came across a post of yours a while back that suggested to include a .vipc file list (no physical packages) I didn't know you can do this! It is brilliant way to pass dependencies that are on the VI Package Network (i.e. Open G - so thanks) and keep the file size down. Esp with links to MGI monolithic library and a few large OpenG packages

Dear Mod(s) Am I able to include OpenG or MGI VIs (renamed) in an llb for distribution along with my source code. Or does "not unpackaged" strictly refer to vip/ogp packages? For example, if I use VIPM and I want to include packages as internal dependencies is this a violation of the LAVA CR Certification? Thank you for your time Regards JG

I think you are still going to have trouble converting the data to a string like that unless you do it using chunking or something similar. You should be able to use the same example I have posted and stream the data to disk. Just wire in the SCOPE data to the for loop.

Aside from the great-looking Xcontrol, posting tutorial videos is a great way to see the code in action. This would be great for all LAVACR entries. I may steal your idea in the future

I am no electronics guy but I had a sensor this week that outputs e.g. 0-20mV that went through some amp and came out as 5V TTL. Sweet! It was a sensor for speed so the output got converted to pulses (RPM). It was gear from the manufacturer but I am sure you can do this. Anyways if you are after NI gear the Low Cost M Series DAQ is a great way to go e.g. 6221. If you need to go cheap as there is also USB 6008. Both of these have sibling devices worth checking out too. It depends on your specs (resolution, budget etc...)

Sorry, what I meant was, drag and drop onto desktop, if this works then drag and drop onto BD. (Chrome does this too but IE does not).

Yes the code originally failed on the string conversion. Having the array in memory would slow things down I would imagine. Well I ran it without the 0 wait in with respect to that comment. It always worth adding a zero wait to free up the CPU with While Loops - nothing worse than an unthrottled loop. As it was quite resource intensive I thought it would be a good idea for the For Loop in this case. Great to see someone else recommending the TDMS format. The new TDMS 2.0 format in 2009 has some great improvements (support for scaling properties, streaming directly from DAQmx, faster - bypassing the TDMS and Windows buffer straight to HDD etc..) We use TDMS (or rather gTDMS) for embedded systems but I believe there is now VxWorks support for TDMS 2.0.

I know this doesn't help: But I use Google Chrome and right click to select "Save Image As..." - so that browser works ok. <edit> Ton - can you drag and drop the image with FireFox? Chrome supports this </edit>

Hi Simon I did the maths and you are definitely trying to save more than 20MB... 400MB in fact My question to you is - do you need the entire array in memory? If not stream the data to the disk. Additionally may I suggest a binary file and not ASCII for such a large file? You will save a lot of space (and it will be faster as it does not have to convert binary to ASCII etc...). E.g. Binary DBL 3.14159265141592 = 8 bytes ASCII text 3.14159265141592 = 16 bytes There maybe some LabVIEW guru's who can suggest a more optimized approach. The code worked on my PC - but it took a while! You may wish to span it when it reaches a certain size as well

Ooohh! You got me good