ShaunR

Where does the licensing scheme even remotely touch password security of VIs? Anything license related is really handled in the LabVIEW kernel itself so not sure what the ability to unlock a password protected VI would do there.

I never said it was. I was simply pointing out that NI wouldn't "cry" over a password protection hack and that since the licensing has been compromised; they would be more concerned about that-if at all

Great post!

Do you know how to integrate test unit, rspec, cucumber and fitnesse into LabVIEW?

I'd like to manage my tests from Ruby since it's free tools are much more advanced than what I found in LV.

Do you think this is a good idea? Is it possible at all?

If not, do you know how to best implement the agile process in LabVIEW?

Thanks in advance,

Dror.

I know nothing about Ruby...and probably never will. But I would imagine the test tools for it are aimed at that environment in the same way as they are in Labview and (probably) not compatible. If you want to manage your tests in Ruby. Write the tests in Ruby! Whats the point of mixing and matching technologies and the headaches associated with getting them to play nicely (activeX springs to mind).

Agile development is language agnostic. It is also discipline independent since it is a group of project management methodologies. So the answer to how do you implement it in Labview is "the same way you would for anything else". I personally use M$ Project and. at a push, will use Excel - it's not really important. The key point is for some of your incremental release gates (cycle results) to coincide with major milestones on a more encompassing, linear plan (since that is what the upper echelons of management prefer).

IF this work,NI will cry.

Nope, It affects the users more than NI. Ni are probably more worried that their whole licensing scheme has been compromised since 2009.

Are the two solutions you're considering 1) propogating the fault state up through the component hierarchy, and 2) not propogating the fault state up through the component hierarchy?

If it is..... I would choose No3. Each module is configurable to do No1 or No2 to it's immediate owner.

I understand now... I think my brain is on autopilot.

That does eliminate the trailing Set Sequence, but the functionality doesn't change--it still makes loop B execute one "extra" time.

You are changing the requirements now

I started wondering how to prevent the extra occurrence, so I added a timeout and removed the tailing Set Occurrence

Or-ing "THE" =0.

On the surface it seems like that should work, but there's a subtle race condition. Because the WoO has a timeout it is possible for loop B to read the stop button, exit, and reset before loop A has an opportunity to read it. With an infinite timeout that will never happen. I suppose you could put the button reset in a sequence structure and wire outputs from both loop A and B to it, but that feels kind of klunky to me. The other alternative is to set the timeout longer than the time between occurrences, so it will only timeout once the occurrences have stopped being generated. That doesn't seem like a very robust solution.

Just OR the =0 with the stop and it will work without an extra occurrence and without a timeout..It is a sequencing issue rather than a race condition-as with AQs version.

Occurrences do have a timeout.

I stand correct4ed (when did they add that then?)

The main reason occurrences behave differently than the other sync objects is because occurrence refnums are static. The refnum is created when the VI that contains the Generate Occurence function is loaded, not when it is executed. That means that a VI which is reused, say in a loop, the Generate primitive will return the same occurrence on each invocation. This is often counter-intuitive to those that don't understand the mechanics of how occurrences are created and can lead to some serious bugs due to previous values being in the occurrence.

IMHO this is how the other primitives should behave (and that includes diagram, project and control refs). I've lost count of the number of times I have had to correct others' code because the refs aren't closed. It is these primitives that are counter and intuitive rather than the occurrence. Oh for the days when Labview meant you didn't have to worry about memory leaks.

The fact that they're created on load is also the reason there is no need for a destroy primitive. Memory leaks don't happen because repeated calls to Generate Occurrence in the same VI always return a reference to the same instance.

The behavior is very useful if the primitive behaviors are understood though. They just work completely different from all the other synchronization primitives.

Seems to me that they work similarly to a notifier (since they have a timeout) without the pit-fall of memory leaks.

Care to elaborate? (I've never used occurences and I'm finding it a bit confusing.)

Because the local variable will be evaluated well before the first loop reaches the large number and will present a FALSE to the stop terminal. Everything (in the second loop) then waits for the occurance. Once Loop 1 actually fires; loop 2 then proceeds with the FALSE, goes around again and then waits, once more, on the occurance-which never arrives since the first loop has already terminated.

This is why no-one uses them. Its too easy to get race conditions that hang your app because they don't have a time-out.

It will work correctly IF you put the occurance and the local into a sequence structure that guarantees the local is read AFTER the occurance (another reason no-one uses them since they don't have error terminals and forces you to use those pesky sequence structures.)

I had a conversation with our chief architect whose been working on LV since version 0.1 and who created the occurrences long long ago. Here is THE correct way to use occurrences:

First build a system which polls busily for whatever it is the occurrence will signal. You need to be able to determine the state of things without an occurrence. This creates a correct, but inefficient busy waiting implementation. Once that works, add an occurrence to alleviate the inefficient waiting. Do not remove the actual polling. In other words, use the occurrence only to indicate that "it is probably a good time to check on that thing...".

In other words, start with this:

and then go to this:

As I understand it, occurrences don't have thread safety on their state because they are the building blocks by which thread safety for state in higher level APIs is built.

That won't work.

Sry for gettin off topic here, but Shaun- noobie question, is there a way to set up your structures to have color tint like the for loops ya just posted by default? So every time I lay a for loop its tinted yellow, while loops blue etc etc...

and also- if I did this, would it stick with the vi if I were to send the vi to someone or edit it on another computer?

thx!

-pat

I just set the block diagram background colour in the preferences. I use a different colour for each LV version so I'm aware of what version I'm in. I also use it as a "completion" indicator". I start out with all the diagram in a colour and set cases, frames etc it back to white once that frame/module or whatever is completed. That way I (or my colleagues) can see at a glance where I need to do some more work.

Yes. It sticks with the vi.

So how do you hack it then...

Should you really be asking that question?

The byte sequence will change every re-compile-so it is unlikely to persist exactly as in that post across versions or even the same versions with different bitness. But at some point you have to say "Is it? or Isn't it? a correct password" and finding it is easier if there is a dialogue since you know where to start.

I think most of NIs password protected files are purely to hide the terrible coding. Not that bothered if someone sees mine.

Really?

I had a hunt as to aid the discussion. I could only find this in OPP from your LAVA CR files but I may have missed it?

Your snippet obviously is missing your reuse subVIs - do you mind posting?

Cheers

-JG

I also think the we should polymorphize the API here too for the Error Code input.'

Should we support an array of Errors In too?

This would mean a total of 4 VIs - most likely with the Error In array as a thin wrapper around the above mentioned VIs (no function changes).

I have made this into an OpenG Review.

Ahh. I see what you mean (I thought it was at least in Dispatcher-have to check)

Here they are).

There is nothing special about the clear error. It is just a control and indicator unwired.

These are my versions of the clear error and clear specific error (you can find them in many of my submissions to the CR) that uses far less realestate and can be placed between property nodes (and similar) without having to route wires around.

Thanks for the link to the software. Unfortunately, I got the same negative results. I had actually played with a lot of these settings by hand using this article. The issue isn't aggregate TCP performance, it's that the TCP Read just seems to go to sleep every once in awhile for a really long time.

Just one final thought on this (probably not relevant). I have seen exactly what you describe when a machine has Bluetooth . The 5- 8 second freezes go away when the Bluetooth adapter is disabled. I never got to the bottom of this since the machine didn't need Bluetooth, so I just disabled it.

I got bit after copying and refactoring a project, then installing the new application on the same PC as the original. The new installer deleted the original app and the old installer would quit when I tried to reinstall it. An NI AE told me how to fix it here.

Good point......

Don't forget to press the "Generate" button to regenerate the product code in the version page if your copying an installer.

I feel like I've posted this before but can't find it anywhere...

Occasionally, I would like to copy an exe or installer setup from one project to another. Is this possible?

(I'm using 8.6.1)

Not really.....but...

The project file is xml. So in the past I have cut and pasted the section

<Item Name="Build Specifications" Type="Build">

.....

</item>

and it worked fine.

Yup. I do it the same way as sachsm.

All I can say is to invest (going with the stock market theme) in OpenG - if you are interested in becoming an OpenG Developer please PM me!

I thought I already was . Isn't my name on an openG FP somewhere?

They never drop and the sky's the limit ...

Naaah. I'd prefer it like like JGs. You would have made a huge profit in only 3 weeks.

I'm not sure, but isn't "GetRawSocketFromConnectionID.vi" found in the TCP_NODELAY.LLB of that KB the the same as "vi.lib\Utility\tcp.llb\TCP Get Raw Net Object.vi"?.

I believe it is (or at least a wrapper for it).

This is the prototype it (TCP Get Raw Net Object.vi) uses as the call to LabVIEW

int32_t NCGetRawNetObject(uint32_t nc, uintptr_t *netobject);

It is just a typecast to get the nc parm from the connection ID.

Well. there is an "Addons" palette. So shouldn't "Addons" be in there? I know your post is against top level folders but I also don't prefer bunching other tools in the labview installed locations as I prefer separation between the standard labview installed software and addons/toolkits.

It's already a case that we have to drill down 3 or 4 layers of folders to find (for example) the TCPIP vis. It is that that causes menus to roam across the screen rather than having them further up the hierarchy. There is (as I have mentioned) the addons folder. There is also the User Libraries and Favourites on the top level which rarely have much in them...if anything. Better use of the top level palette folders would make more sense. But we are being told that we shouldn't use the User Libraries folder?

Why is it that we do not get the fine-grained thread control for CLNs as we do for VIs - or is it that "execution systems" in LabVIEW are not explicitly threads?

The execution systems consist of a number of (typically 4...up to 8) threads. In this respect, you are specifying a smaller "pool" of threads that labview should use for a particular VI or set of VIs rather than explicitly defining which threads things run in.