SuperS_5

Hi, Do you know how to do this by hand? LabVIEW has all of the primitives required, if you do now want to use mathscript. Mathscript is not very difficult, just takes some patience and reading the help file to learn.

If you want the event structure to be responsive, you must make it the bottleneck in the loop execution. So execution should be mostly waiting for an event, not a millisec timeout. If the wait primitive is required, you will have to fallow what jcarmody has said. Any state that makes the execution wait for any undesired amount of time will cause the UI to be unresponsive.

Hi, I don't use .Net controls, so I could not find a permanent solution. The "contbounds" property node is settable while running and retains the chosen value until the VI finishes execution. Although I must be set every execution, it will at least be the right size while running.

Congratulation! Happy holidays.

IMO, it's best to open the visa session, then close it at the end of your program....

Agreed. The existence of the 'Automatically Close VISA Sessions' setting in the IDE has always irked me.

Thanks for reminding me. I totally agree, but just wanted to quickly spit out an example. (I was rushed, you know how regular work can suck up all of your time)

Hi,

It seams that you have to use the dynamic registration terminals to get the appropriate events on your event structure. It seams like the Front Panel of the embedded VI is not accessable to windows, or whatever code LV uses in the set cursor primitive. Using this current vi ref like this allows for "localization" ....sort of.

I hope this is what you wanted. It is very late, and I am seeing doubles.

Hi, The LabVIEW Help file does tell you exactly how to do that. In any case, here is a sniplet if I understand what you have requested:

Thanks for the redirection. Unfortually this problem has been very sporatic, and I am bairly able to notice it, except when it really messes up things. I am still attempting to make it reproducable.

DVR = Data Value Reference

I had to look that up. My method would be a memory hog, but, still without a memory leak. The DVR method would be more efficient, and essentially the same external functionality, but with more programming.

PS. That link did not work, but I did find other NI pages on it. Thanks for the translation.:thumbup1:lol

I guess I missed that post. I didn't get the "DVR" part. (The first meaning that I think of is Digital Video Recorder, but I know that I am just confused Past job experience.) I suppose its the same, but I was thinking a simple vi with an unregistered shift register. I would put all of the "real time" data processing code there instead of the x-control. That way the X-control would just pull it out of the "buffer." I guess it wasn't such a light bulb moment after all.

PS. I just realized that I used x-node above, where I meant x-control.

Hi again. I was looking at a some other code, and had a light bulb moment. If you update a stack instead of the x-node, and call the x-node, which reads from that stack, allows more control over the queuing. Of course this means a lot more coding, but at least no memory leak if done correctly. Although I am only guessing, I think the x-node is called by the UI thread. This method, allows for the stack to run in a separate thread, with its own priority. When used in your example, I had no memory leak, while using a free running loop to update the x-node and stack.

Edit: I forgot to add that you would call the x-node using some other data. I used an empty array, but, theoretically any data could be used. The x-node data-type could even be something totally different.

While I was trying this out, I realized that the download is a zip and not a VIPM package. I made a VIPM package, using your readme documenation. Should I upload it here, or did you have some reason for not making a VIPM package?

It would be cool to work on this too. I guess the biggest question for me now is how would I participate?

I looked through this tool. Looks interesting, but very similar to the state-chart module. I tried to use the "Replace - no attributes" method, but, it always failed for me in LV8.6. Replacing to "Replace" and the "Params" disappeared, but everything worked after that. Learning how it parses Dia took some experimented, but, worked great when I got used to it. It is definitely pretty quick, and that is one point against the state-chart module.

Hi, This looks really neat. How is the progress on the Roadmap?

You don't want to get 4 hours in and suddenly get a "file in use error"

I have been bitten by that before.

I think the list of things that we DON'T like is a whole lot shorter, and probably easier to run though. What we do like will go on, and on, and on.... <now where is that energizer bunny>

Yes that runs without an error since it doesn't time out (it returns before the timeout is exceeded)

Ton

dohh..... Should have known that. I guess it is time for more coffee.

Running this in LV2010 worked without issue. (used "ping www.google.com" for cmd line)

Shaun's faster than I am

Shaun may have been faster, but, you wrote an exceptional post. Good work. Definitely wiki level

But from 2 days earlier. This problem shows that you can do a lot in 2 days

Some kinda of source control is usefull there. I use SVN, but, it is not the only solution. Commit often, and you don't have to worry about zip files, and which version is which. Even with one developer and one computer, it is worth the effort to learn.

PS. A corrupted VI is what caused me to take the jump to source control. Saved me, many times over.

Sorry for bringing up a old post, but I couldn't find anything similar, and seamed like a good place.

I have been seeing some issues with LV2010, when saving->closing->reopening a VI. Sometimes some objects are moved on the BD and/or the FP. It is very hard to trace down because it appears to be random. Sometimes after loading a VI, things are moved. After fixing, and saving, then reloading, most times it is OK, but sometimes it too has moved objects. It gets really annoying when the BD becomes unreadable, or the FP no longer looks nice.

Hi,

Although, I am not sure if it is the "Best" way, one solution is to use a database. (My personal experience) The EXE and Run-times/extra installers are zipped and put into the database. The program checks for a new version, downloads it, and installs over it's self.

Stability is always nice. I guess for now we have to be careful in the way we deal with x-nodes.