chris754

You're missing something, but its tough to tell what you are doing wrong without code. Are you calling the parent class override method? You should be. The parent class override method will automatically call the correct child class method. Do you have dynamic dispatch enabled on the override methods? This should be as well. Using an array of Parent class is fine, no need for an array of variants or anything like that.

*always on a friday, right when you turn your laptop off.

I agree that in all likelihood that it would, but it could cause phantom bugs, that happen once-in-a-million times, and we all hate those.

I would also be careful with you local variable of "triggered" that is set to FALSE. There is no way, right now, that this is guaranteed to execute before or after the FOR loop, possibly causing unintended behavior. I would move it somewhere where you can guarantee the correct order of operation.

source control. try svn, git, or any other flavor you like. I like tortois svn myself.

I see what you are saying mje, but what of call and forget vis? You can have a situations where the Main VI has stopped and closed, but the secondary top level vi continues to run undeterred. Do we now call this the top level vi? or is it still a sub vi?

I understand what you are saying. We have a program that loads a bunch of modules that can be independent in-and-of themselves. Each module has a top-level vi that becomes a "sub vi" when called through the larger program. Why not sub-top level vi? I think that is relatively clear in purpose. It says that this VI can be run independently, but also is part of a larger hierarchy in which it is not the main. It is a dominant branch in a root system. Or another idea would be to relate it to management. You have your top-level (CEO if you will), then manager VI or supervisor VIs, then your subvis.

Interesting. Are you sure that the Port still exists when you try to reconnect to it? Maybe Windows hasn't created it yet? Maybe you need a delay before you begin trying to connect. Other than that I'm not really sure what else could be going on.

Here is my watchdog example. Just threw this together this morning, so not the greatest coding job, but shows one way I implement this type of thing. Just run the Test-Main.vi. It will launch an "actor" (not a real actor, but something to act as one). If you use the abort, the watchdog will kick in a close the clone, if you use the stop the shutdown will kick in and close the actor. I use a user event within the actor to tell my watchpuppy to stop if the actor has finished its task. WATCHDOG EXAMPLE.zip

Will do. I should be able to find sometime to drum up a reduced version of this to show my implementation without the noise of a larger program.

Correct. I have a watchdog.vi in the top-level VI, with watchpuppy.vi in each actor. The watchdog sends out an event every so often (about 1sec), if the watchpuppy doesn't receive an event in say 1.5 secs, it aborts the vi. I can post an example if you'd like. They are easily removed or disabled later if you decide you do not want them in the final version. Although I usually keep them.

Why not put watchdogs in the VIs that will automatically kill the actor when the you main VI is off, at least for testing purposes. This is what I typically do in these types of situations, as then I do not have to worry about finding any rogue processes.

I would hazard the LabVIEW loses track of the port when it disappears. Try using the VISA Find Resourse after switching to D2XX and see if it appears in the list. I would bet that it doesn't. I'm not sure how to force LabVIEW to refresh its resource list during runtime, LabVIEW seems to refresh it for me. I would make sure that the port is properly closed using VISA close before switching back and forth, I see that you did this, but maybe it was done in parallel or something? It's tough to tell without seeing code.

I've done this in the past. I found it easiest to use a template and change the controls as needed using scripting. Building it from scratch each time is a lot more work.

I like to use events for my stop/shutdown sequences. Without seeing code though it makes it difficult to see if it would make sense for you. I like events because it get's rid of polling/local variables.

I've encountered this with an exe loading an llb. What was happening was the llb needed to include an NI VI. When it wasn't included labview would search for it and eventually found it, but then this window appears, once you include it, it goes away. This often happens when the EXE is built with "remove unused members of project libraries" checked. For instance, in my case, the VISA commands were missing and needed to be found. So I would look for instance like this or try unchecking the box and see if that does you any good.

Doesn't "use labview 8.x file layout" do this under advance? or am I misunderstanding what you want.

yes, sorry, I meant cos not sin, thank you.

IN either case the shift register should be removed. In error in closing one reference should not prevent others from closing.

Integral of b*sin(ax) = -(b/a)cos(ax)+c Derivative of b*sin(ax) = ab*sin(x) In you example a=1, b=1 and c=1. They all have an amplitude of 2, but your integral is shifted up 1.

Oh, I see, I misunderstood your problem.

Check out "List Folder.vi" in the Advance File Function palette. This will get you all folders/files in a directory. So once you built the directory path you could loop through all the INIs.

Indeed, just plain-old byref oop. Anyway, I have found the error (sort of). I make a copy of the original data and put that data into the generate event VI. If I put the original data into the generate event, the problem goes away. I now just need to find a way around this. The data must get destroyed by labview at somepoint, however, I do not know why this is because the data was placed on a shift register, and therefore was still in use. Still working on a test VI for this (busy time of year right now).

I will try to make a test VI to show what is happening. The destroy VI only gets called on a shutdown event, and I'm sure that that has not been triggered. As far as implementation I take a labview class and stuff it inside a DVR and pass the reference around, I am not sure what the name is for this type of implementation.

Note that the first image does not work, and the second does. The "Copy" VI is simply the "Always Copy" function.