Tomi Maila

Hi All, I was investigating the LabVIEW 8.5 variant type library. What caught my interest are five last items in the library namely GetUserDefinedTagInfo.vi SetUserDefinedTagInfo.vi GetUserDefinedTagRefnumInfo.vi SetUserDefinedTagRefnumInfo.vi GetRandomNumberForType.vi I interpret that the four first VIs allows us to specify type properties when using LabVIEW scripting or XNodes with typed items. Could these even allow us to create our own reference types. Perhaps these tags could be properties like appearance and wire appearance. Let's assume we start from some reference type, then define the exact reference type with SetRefnumInfo.vi to be something like UserDefinedRefnumTag. If then go on by using the two SetUserDefined... methods above properly, could we actually have our own type? Could we script our own reference typed controls and indicators for our XNodes? Could we even be able specify the wire appearance? Could we use the GetRandomNumberForType.vi to make the type unique? Just some questions that popped into my mind... Could someone help me to reverse engineer this issue. I'd really love to have my own reference types for my language extension... p.s. The VariantType.lvlib can be found under LabVIEW 8.5\vi.lib\Utility\VariantDataType Cheers, Tomi

Hi, I'd really like to see support for recursive typing also outside LVOOP so that a reference type such as a queue could refer to the type that encloses the reference type. I see no reason why not to support such types. Reference types are not allocated at compile time so there would be no infinite memory allocations. Example 1: Linked list Typdef List.ctl { Element : I32 Queue : Queue of List.ctl } Example 2: Tree Typdef Tree.ctl { Element : I32 Children : Array of (Queue of Tree.ctl) } Example 3: Recursive VI VI Recursive.vi { Connector Pane { reference : Strictly_typed_VI of Recursive.vi } } I tested this last case as I wasn't sure if this would work but it doesn't. The strictly typed VI reference on the connector pane doesn't act like a typedef so it doesn't update as VI connector pane gets updated. As a result when you browse for a connector pane type and select the VI itself, it uses a fixed connector pane before the connector pane change and doesn't dynamically update the connector pane change to the reference on the connector pane. Simple Tomi

Hi guys! Great job adding balancing algorithm to the tree! Now that we have a balanced in-place OOP map for objects it's feasible to ask how does this tree perform compared to LabVIEW build-in map namely variant attributes. To my experience variant attributes peform well. They accept any data type and not oly LabVIEW objects. So the question is, if there is actually some real reason to use this LVOOP implementation of map instead of variant attributes. Is this implementation perhaps more memory efficient for LabVIEW objects? Has anybody done any testing? Tomi - Is having a headache after 12 hours of XNode development.

I ran some tests with this. I didn't notice any difference in the speed of different connector panes. However I noticed that parallel nodes or structures on a block diagram run with different speeds consistently i.e. in a non-random manner. So take care where you place your most time-critical loop Download File:post-4014-1194527735.zip for LV 8.5 Tomi

QUOTE(neB @ Nov 7 2007, 09:54 PM) Do you have any estimate how much longer does it take to call a VI with say two inputs and two outputs versus a VI with the default connector pane? Tomi

QUOTE(PJM_labview @ Nov 7 2007, 07:20 PM) Thanks I'll use the Help ability then to specify the palette icon. I just got ready my first actually useful set of XNodes that are not only playing around but actually meant for powerful programming tools Tomi

Hi, I've developed some XNodes that I now want to add to functions palette. The problem is that I don't know how to define the palette icon for an XNode. If I add MyXNode.xnode to functions palette, then for some reason LabVIEW shows the icon of MyXNode.xnode:Help.vi and not the library icon. Has anybody succesfully defined the palette icon of the XNode? Tomi

QUOTE(Giseli Ramos @ Nov 6 2007, 07:22 PM) All memory management functions are available for shared libraries. CINs are not needed and I don't recommend using CINs. You can even call memory management functions from LabVIEW directly as if they were exported functions in a DLL by using LabVIEW.exe as the library in a library node for the development environment and the corresponding runtime DLL (LVRT.dll or something) for the runtime environment. Tomi

QUOTE(PJM_labview @ Nov 5 2007, 07:26 PM) Do you have any idea where these two ability VIs can be called from? Tomi

QUOTE(Gavin Burnell @ Nov 5 2007, 05:20 PM) Thanks a lot Gavin! The Variant Type library solves all my problems! I didn't know it existed. Or actually I came across it a long time ago but for some reason this information no longer existed in my active memory. And for those interested, a somewhat functional version is attached. Download File:post-4014-1194287745.zip QUOTE(Gavin Burnell @ Nov 5 2007, 05:20 PM) NI doesn't appear to have shipped the update DVDs to academic site licensees in the UK yet. The same applies to Finland as well. We always get a package of DVDs with an obsolete versions of LabVIEW. That's why we always download the (Windows) evaluation version from NI web site and activate the downloaded version with our site license key.

QUOTE(Nesreen @ Nov 5 2007, 02:21 PM) Each VI has a front panel. So perhaps you should make two VIs. Surely you can make more VIs as well... Cheers, Tomi

Hi, I've a problem of getting my simple XNode to properly adapt to input type. This Xnode is a simplification of a real problem I'm trying to solve using XNodes but if I manage to solve this, then I should be able to solve the real problem. In the attached ZIP I've an XNode wrapper for Preview Queue Element primitive. Its purpose is simply to wrap the Preview Queue Element as an XNode and behave exactly like Preview Queue Element. When a queue is wired to the input, the XNode 'queue in' and 'queue out' terminals should be adapted to the queue type. This is currently working properly. What I fail to implement is getting the 'element' output terminal to adapt to the queue element type. When user changes the type wired to 'queue in' input, Adapt to inputs ability is called. This abilitity now replies with two messages Update Terms and Generate Code. The Update Terms message instructs LabVIEW to call GetTerms3 ability and the Generate Code message instructs LabVIEW to call Generate Code ability. The order of these two messages is important; if Update Terms is not called prior to Generate Code, the Generate Code ability doesn't have terminals of proper type and hence the preview queue element node generated would not properly adapt to the queue type. The problem is that I find out the queue element type only after I've generated the code by inspecting the element output terminal type of the generated Preview Queue Element node. Now I should update the Xnode terminals according to this new information I receive after I've generated the code but I cannot get LabVIEW to call the GetTerms3 ability multiple times per input change. Even if I send the Update Terms message multiple times, LabVIEW only calls the GetTerms3 ability once. So I need your help in finding out a way to get the output to adapt to input so that the output type depends on the input type but is not the same as the input type. In this example case the output type should be the element type of the queue type wired to the input. The attached XNode is for LabVIEW 8.5. Download File:post-4014-1194268900.zip The XNode Manager tool in LAVA code repository simplifies the development process. If you need any help in scripting when trying to solve the problem, don't hesitate to ask. Queue controls are of class type TypedRefNum and queue constants are of type Constant. The TypedRefNum class has a property Element which gives you a referenece to a queue element type control. TypedRefNum has as embedded element control in a similar manner as a single element cluster has a single control. You can replace the element with a new element using Replace method of the Control class. Cheers, Tomi

QUOTE(Justin Goeres @ Oct 31 2007, 10:54 PM) This Script Wars proposal of yours sounds interesting. How about making the fighting VIs evolve autonomously so that they constantly become better and better without human intervention. Perhaps LAVA should have a few script wars servers so that we could start fighting... Fact of the day: LabVIEW 8.5 scripting has 257 classes, 1118 method names and 3214 property names. Do already you know them all?

QUOTE(Michael_Aivaliotis @ Oct 31 2007, 12:58 AM) I had performance issues previously a month back but they disappeared when I turned off the snapshots. Maybe you're experiensing the same thing.

Now that you have the source code of the share library, the simplest thing you can do is use LabVIEW memory management C functions. So pass an empty LabVIEW I32 array to your C function as an argument. Select pointers to handles as data passing method when configuring the library call from LabVIEW. This passes your LabVIEW array handle to your C code as a pointer to LabVIEW array handle. An array handle is a pointer to pointer to the actual array data. The first d elements (long) specify dimension sizes for a d dimensional array. The dimension sizes are followed by the actual array elements. Now that you receive the array handle as an argument to your C function, you can resize the array handle to meet your needs using the following LabVIEW C memory management function. See LabVIEW help for detailed information on the function usage and arguments. MgErr NumericArrayResize (int32 typeCode, int32 numDims, Uhandle *dataHP, int32 totalNewSize) This allocates memory for your LabVIEW array according to what you specify and depending on the datatype you use. After you have allocated memory for you LabVIEW array, you should set the dimensions of your array. Simply write the dimensiondata to the struct I described above to the position in memory determined by dataHP returned by NumericArrayResize. Now your array is LabVIEW compatible. Then write the array content. After your C call exits, your LabVIEW code sees the new resized array and LabVIEW can even automatically dispose it. This was a rather short introduction to quite a complicated concept. See the following to sections Fundamentals / Calling Code Written in Text-Based Programming Languages and VI and Function Reference / Connectivity VIs and Functions / Code Interface Node Functions / Memory Manager Functions from your LabVIEW help. The bottom line is that you can allocate LabVIEW datatypes from your C code and this is the technique you should prefer. You shouldn't under normal circumstances pass C pointers to LabVIEW but to write or copy your data into LabVIEW compatible memory model and pass this back to LabVIEW. The only case where I think C pointers need to be passed to LabVIEW are when you are using C pointer to refer to some sort of C object and are using the pointer only to refer later on to the same object by passing the pointer back to your C code. In this case your pointer acts as if it's a reference and LabVIEW doesn't directly use the reference but only passes it back to C code when it needs to interact with the referenced object. Cheers, Tomi

Actually I've been thinking that I should write a wrapper for LVMerge that would always open the correct LabVIEW version for each project. But I've not had time. The functionality could be something like following. Find out VI version of all three VIs to be merged, see this discussion for details. Automatically choose the newest LabVIEW version of the three used Call LVMerge with the chosen LabVIEW version as parameter Would anyone be interested in coding such an application...?

QUOTE(hskupin @ Oct 30 2007, 10:57 AM) You're right. I especially want to specify the LabVIEW version as the registered version keeps changing depending on which verision I've used previously. It's annoying. Tomi

QUOTE(hskupin @ Oct 29 2007, 01:39 PM) "C:\Program Files\National Instruments\Shared\LabVIEW Merge\LVMerge.exe" "C:\Program Files\National Instruments\LabVIEW 8.5\LabVIEW.exe" %base %theirs %mine %merged The above line works for me. I guess the blog editor has changed the double quotes I used into some unicode characters that are not actually ascii versions of the double quotes.

Hi, I noticed that LabVIEW 8.5 ships an interesting XNode called GetValueByPointer.xnode under folder <vi.lib>\Utility\importsl\GetValueByPointer. Has anyone experience what is this node, how does it work and how should it be safely used? Cheers, Tomi

A few questions that help us to answer your question in the best possible way. First are you supposed to release the array from LabVIEW as well? Second do you have access to the shared library source code i.e. can you modify the code if you need to or are you stick with the current implementation. LabVIEW is more flexible regarding pointers within arguments lists than return values. Cheers, Tomi

QUOTE(adriaanrijllart @ Oct 26 2007, 10:57 AM) Actually comparing the control value with control default value is, I think, the best way. It's rather quick and doesn't include slow performance scripting. It also works always whereas scripting can break when you build application. Tomi

Source code control I'm using, namely Tortoise SVN renames conflicting version of VIs when conflict occurs. Then conflicts can be solved with LVMerge and the merged VI saved with the original name. Conflict resolved. What source code control system are you using and how does it handle the conflicts in the same item? Or are you actually not using a source code control at all?

QUOTE(PJM_labview @ Oct 24 2007, 07:07 PM) Timed sequence and timed loop both consits of separate parts. To the left of loop or sequence there is a XDataNode.xnode called Configuration Node. This XNode simply collects inputs and writes then to an indicator called Timing. In addition the Configuration Node makes two external calls two two different shared libraries (DLLs). Nothing else occurs at runtime within Configuration Node. The Timing indicator of Configuration Node is connected to a hidden node at top left of timed loop inner structure called Timed Loop Left DCO. At the top right corner of the timed loop structure there is another hidden node called Timed Loop Right DCO. The Timed Loop Right DCO is connected to the Output Node (see below). The nature of these two DCOs is not known to me. Anyone with more information? My guess is that these are build-in nodes that take care of synchronization. The The timed loop and timed sequence themselves are not XNodes. These two structures are most propably internal structures that are implemented outside LabVIEW scripting. Actually it may be that the DCOs take care of synchronization and the timed structures don't really differ much from their asynchronous counterparts. Inside the timed loop there are two additional instances of XDataNode called Left Data Node and Right Data Node. These are the nodes you can wire timing information from and to. Both these two XDataNodes only read from a control or write information to an indicator called Timing. These two instances don't seem to be connected anywhere, although they have a Timing structure control and indicator on their front panels. One more instance of XDataNode is on the right of the loop, which is called Output Node. This is connected to the Timed Loop Right DCO as stated above. All these three XDataNodes only read from a control or write information to an indicator called Timing. These Timing controls and indicators of XDataNodes are accessed by LabVIEW somehow. To conclude timed structures consist of multiple instances of same XNode that initializes the external timing system and passes data to and from the timing system. However the actual syncrhonization of the loop is done outside LabVIEW written code. There is a external method that

QUOTE(rolfk @ Oct 24 2007, 11:22 AM) Sure

QUOTE(Narudol @ Oct 23 2007, 06:03 PM) Not to my knowledge. However I've not used appletview. I've only used the LabVIEW build-in web server. You need a client LabVIEW application to access the client side USB board. There is no work around to my knowledge. This application can either be 1) a collection of VIs together with LabVIEW installed on the client computer or 2) a LabVIEW build executable together with LabVIEW runtime environment installed on client computer. The second option doesn't require a LabVIEW license on client computer where as the first requires LabVIEW license. To build a LabVIEW application (.exe) you need LabVIEW applicaiton builder that ships with LV Professional or that can be separately purchased from NI. You can distribute this application as a ZIP file to your SCORM users. You can make this application to communicate with your SCORM system according to SCORM specifications or with your LabVIEW server. I don't know the SCORM specifications, so I cannot say how to make the ZIP SCORM compilant or how to communicate over network with SCORM. This is something you have to figure out by yourself. Tomi