PJM_labview

Here are a few comments and answer.The mks.llb file is missing The VI appears to have been made under LV 5.0 (so you will be ok in LV 7.0 base) The VI call 146chart.vi appears to be an example of how to communicate with your instrument (this is the good news). The not so good news is that the code quality is poor. Finding out what's going on in this VI will not be too easy for a begginner. Hope it help. PJM

This is not a direct answer to your question but more a general answer about recursion and LabVIEW. Typically in LV you can implement recursion in 2 ways: The reentrant self Call By Reference (CBR) is the first way (this is the method you mentioned in your question). The while loop stack method (Stack) is another way. In the Stack method, the work to do is store in a shift register and after every iteration of the loop more work may be added to this stack. The recursion ends when there are no more work to do. Note: The Stack implementation is almost always faster than the reentrant CBR. I read somewhere, a long time ago, that every recursive algorithm can be implemented using the 2 previously mentioned methods (in other word, you can convert a CBR implementation to a Stack one and vice versa) and so far it is my experience that this is true. So, back to your issue; it might be possible for you to convert your recursive CBR implementation to a Stack implementation. PJM

And FLOOP, You got to love this name! PJM

Bug Description: If you create the attached VI and put a custom probe (which happen to be a conditional string one by default) on the queue refnum wire and run the VI, LV crash (regardless of the queue element type). If you put a generic probe everything is fine. Mostly the problem arise when LV decide all you want are custom probes (even when you just select right clik>Probe [and not custom probe]) and put a conditional string custom probe by default on this type of wire. Workaround: Be sure never to have a conditional string probe on queue refnum wire. PJM Download File:post-121-1156258747.vi

Bug Description: If you create the attached VI and put a custom probe (which happen to be a conditional string one by default) on the queue refnum wire and run the VI, LV crash (regardless of the queue element type). If you put a generic probe everything is fine. Mostly the problem arise when LV decide all you want are custom probes (even when you just select right clik>Probe [and not custom probe]) and put a conditional string custom probe by default on this type of wire. Workaround: Be sure never to have a conditional string probe on queue refnum wire. PJM

Attached is another version derivated from Jim version 3. Download File:post-121-1156222854.zip It has the following new functionalities: - GetData is fully asynchroneous (it will not be locked by the GetDataToModify and it will always return data). - Access to named object from asynchroneous process through the create.vi. Drawbacks - To be able to have a fully asynchroneous GetData another queue is used with a copy of the data (if someone can figure out a way to get this without making a copy...) - The create is more complicated (the GetDataToModify, SetModifiedData and GetData are still very simple). Any comments and/or improvements are welcome. PJM

Jason,Well at least you can be sure some people will be using the LEGO Mindstorms NXT stuff PJM

Richard beat me to the punch!I have not use the matrix or the xcontrol yet (although I will certainly in the future). About the new file IO, they may be better, but in my opinion the implementation was not well done (and I am beeing nice saying this). The change of default behavior mentioned by richard, the primitive overloading through right click (with no change on the icon primitive) and the new icons result in a very bad user experience for me (and for a lot of other as well). That their performance have been improved might be true, but this is not what I retain from their usage. Another grip: why is "file dialog" now only an express VI! in the palette. If I want the primitive only this is painfull! In regard to variant, I am missing the type string from the flatten/unflatten to string primitives. This make variant introspection, in the spirit of the OpenG variant tools, pretty much no longer possible for new data type. Retain wire value, or "after probes" are pretty cool. It has already helped me quite a bit. Scrollabar on array. Well, I can see some good usage for that. Just my 2c as well PJM

I can unfortunately confirm that. I talk to some NI people at NI Week, and it is indeed dead PJM

Mandrake (now called Mandriva) just works fine. I beleive NI has a recommended list somewhere (and mandrake is part of if). PJM

Well, there is a proposal to delete this wikipedia entry (see attached image)... PJM

Interesting...

Guenther, I have had that grip about cluster frame thickness now for a long time as well. This *feature* makes array of cluster very hard to use in a UI (as you just found out). In your particular situation there is an alternate solution. Use the colorbox that has a frame for the top array. You can customize this one frame thickness in the control editor. See attached VI Below Download File:post-121-1152208599.vi PJM

Thank you, we actually won! Nex step, beat Italy in the Final (wont be easy).

Yes it is possible. Look at this link on the OpenG website for detail information as to how to do it PJM

Yes, I am aware of the issue. Actually if you dig around in this scripting forum you will find a lot of utilities suffering from the same problem. NI Changed the class Name. The easiest solution, in the case of utilities I wrote, is to add casestructure to the list in Get Container Objects.vi and in Get Container Objects.vi [if you want it to remain usable in previous LV version (like 7.0 or 7.1)]. Attached below is an untest version with these changes.PJM Download File:post-121-1152027991.llb

Thank you all. PJM

This remind me that I believe NI is using this technic in LV 8.x for the option window. For those interested, go poke in "NI Root\LabVIEW 8.0\resource\dialog\PreferencesDialog". The top level is "PreferenceDialog.vi".PJM

I did made a wizard using subpanels in LV7.0. At the time, I encountered a few "quirks" (dont want to say bugs) that made this somewhat instable (I eventually got it running fairly well). All together, I dont know if this was worth the effort to try this (at least this was a great way to learn about subpanels ) as opposed to use a tab control. Although, if you are in a multi developer environement, this could be a good thing to use so you can have developers working independently on separate "screen" of the wizard. The ability to reuse screen independently of the wizard can be nice too (although I never had to do so).By the way, did you know that you can typedef a tab control so the enum (that enumerate the tab) is updated automatically ? PJM

Mark, it is missing a bunch of VIs from your "universal utilities" folder.

Look at the array palette, there is everything you need there. For finding example go to the menu "Help>Find Example". PJM

Given his latest blog entry, I think it is safe to say he was involved.PJM

This is good to know, as I waste a LOT of time figuring out why I could not read back file saved with LV 7.1 using the overloaded LV 8.0 "read from text file" primitive (which has two right click option which means it has 4 modes of operation and the same icon for all 4!). So, I am another very frustated user in that regard. PJM

and there is a EXAMPLE - Python Client to LabVIEW Server using variant to convert data to and from python here PJM