vugie

QUOTE (Aristos Queue @ Jan 23 2009, 05:55 PM)

Last year, user vugie posted VIpreVIEW

It allows you to create a Flash application from your VI, so you can post your VI to the web and people can still flip through the frames of the case structures to see all your code. Kind of neat.

I would like only to mention that VIpreVIEW project is not dead but suffers from sickness called "notimeness". I have some children who demand my attention louder than it...

QUOTE (Yair @ Jan 8 2009, 09:20 PM)

And performance issues (memory copies) and you lose the strict typing, so it's not as convenient and has more chance for bugs. I generally only use variants when I need to transfer different data types on the same wire.

Depends what kind of data is passed with q/n. But in general in fact it would be better to use FGV to store q/n references flattened to variant (to avoid many kinds of them).

QUOTE (jlokanis @ Jan 7 2009, 08:41 PM)

A FGV would not work well in this case, but some sort of daemon that opens and maintains the queue's exisitance might work. This would mean I would have to call it to clean up when each hiarchy completed and was closing. This gets complicated if there are many different datatypes for each queue/notifier...

Use only one type of queues/notifieres - variant. You get additional opportunities with variant attributes.

There is another solution - you can store all refs within functional global.

I've just figured out that in case I described when you click on index rectangle, value of array element also changes. So either hide an index rectangle or check whether user clicked there

QUOTE (Norm Kirchner @ Dec 22 2008, 06:32 AM)

The jist is that you generate a reference off of an element in an array,

Register that for the mouse down or choice of event,

have an event structure handle that event and when it fires, use the CtlRef that is presented and suck out the value from the ref or whatever other info you need (although index is not one of those).

There is much simpler approach. Array control has "Array element" propperty, which has Value property of variant type. Reading this property inside event structure for whole array event always gives you value of clicked array element (flattened to variant). If you want to get an index you can get reference of "Array Element" and search for it in array of references created before for your control. The last is not as trivial (AFAIK), at least dynamically.

Also when you put image on front panel as a decoration transparency smoothness is preserved. I was playing around with scripting trying to dynamically change such decoration, but without success.

There are "Get Property" and "Sete Property" private methods in Generic class. They looks like they set/get properties via property index and using variant type. But you have to know these indices. First several thousands (from 0) does not work for simple digital control

Maybe any of our "rusty nailers" knows sth more?

As it is still not clear where to continue the discussion, I cross-post my two cents here:

For some time I use AE based on variant with named attributes. Just to limit constantly number of get/set methods and shift registers in main VI. With such approach I have only one variant variable in main VI and one method for set and one for get. I provide name of the variable to these methods with string constant and check whether attribute exist inside get method. The disadvatage is that I have to unflatten variant to proper type after getting and this takes a place. What I'm thinkig of to solve that problem is to create XNode which would serve as universal get method adapting type of its output basing on input string and type definitions stored i.e. as a named constant in main VI.

Unfortunatelly I have to find some time to deep into XNodes...

And for my type of AE wrapping all other methods in polymorphic VI is definitely a good idea...

QUOTE

Is a Polymorphic VI a good mechanism to conveniently access the members of a "library" (set of related) of VIs?

...but strictly for AE, not so generally. Why? Because usually there are only few methods other than get and set (at least in my AEs) and they are all designed to be used, so loading all of them to memory at once is not a con (BTW bad to hear that Aristos, that means a lot of unnecessary functions are being loaded into memory in my programs - a lot of analitycal functions in LV are polymorphic. I have to think about using their instances directly). 90% of my VIs use 4-2-2-4 pattern so for me this limitation is not a con. So with such approach I'll have only 3 items on AE palette (and I use only one AE per application, see above) - I can keep such a small pallette permanently open, even on my laptop.

The only con I can think of is instance selector - it takes too much place.

QUOTE (shoneill)

I set the VI parameters for this to "Subroutine" ages ago.

It is password-protected in my version

QUOTE (shoneill)

Splin Number based method is fastest I found. I'm going to enclose it in subroutine VI and use it further and I suggest to do so to everyone who perform extensive pixel manipulation.

I just realized that LV "Color to RGB" function from graphics palette in unexpectably slow. I recognized with simple test that it is about 700 times slower than using Split Number function three times to get color components. There is no such issue with "RGB to Color" function.

VI with test case attached

LV 8.2.1

QUOTE (gmart @ Nov 17 2008, 10:59 PM)

Check for any network printers that can no longer be accessed. LabVIEW looks up printer settings when the VI Properties dialog comes up. If a network printer is no longer accessible, then the dialog times could take while before it times out.

Brilliant! It is enough to chenge the printer in Page Setup to something local and Properties dialog brings up immidiately! Why I didn't know about it month ago when I had to update documentation of 100+ VIs...

QUOTE (Aristos Queue @ Nov 17 2008, 10:12 PM)

a) What version of LV are you using?

b) Does it only do it the first time you launch VI Prop dialog in a given run of LV or is it everytime you launch the dialog?

a) as in profile - 8.2.1

b) first time after bringing VI to front is often longer, but it is not a strict rule. Restarting LV does not change it in statistically meaningful way. I only see it correlates with project size - for very small projects launching dialog is faster - however still not as fast as I would expect from relatively simple dialog (at least visually )

QUOTE (Milchbilch @ Nov 17 2008, 12:29 PM)

When I try to open VI property dialog (from frontpanel or diagram) it takes up to one minute for the dialog to appear!

So when I want to change the VI execution mode e.g. I can right click the icon, select properties and then get ma a pot of coffee before I can change anything. Can anybody else repoproduce this problem?

Yes. Maybe not so long as in your case but it also takes considerably long time for me - from few to even 15-20 seconds, and I couldn't find what it is dependent on.

For such cases I usually use Scan From String function and check whether error appeared. You can also check whether the rest of string contain something more than whitespace or use Scan From String in a loop until rest of string is empty

I didn't get such result in 8.2.1 (although I only reproduced simplified diagram)

Are you sure that it is not a probe related issue? Try to index cluster through loops to generate 3d array and check the array.

Thank you for the answer

QUOTE (ragglefrock @ Aug 14 2008, 03:28 PM)

LabVIEW has a built-in function in LabVIEW.exe called MoveBlock. You call it much like a DLL function in the Call Library Function Node, except you type in LabVIEW instead of a DLL name. MoveBlock can copy from a source location (the malloc'd struct from the simulation) to a target location (a LabVIEW cluster with 6 doubles). See chapter 6 of this PDF for more info on the function prototype for MoveBlock. There's possibly also an appropriate function that resembles malloc that you can call directly from LabVIEW to avoid needing a wrapper DLL at all. Check out AZNewPtr for instance.

I didn't play arount much with these functions, but such solution seems to work. But how it will look like with built application running with runtime engine only?

QUOTE

I knew this article and I tried to reproduce this functionality some time ago but without success (I had problems with compiler as I'm totally not familiar with NET environment). However, I wasn't strongly determined to do that...

I have another issue around this subject:

ODE is designed to let to compile it either for single or double precision computations. It simply uses some macros to set input parameters for ALL (400+) functions to float or double. I would like to reproduce such design in my wrappers. All type definitions I use I built using abstract type Real which holds now Single type. So changing this type to Double obviously updates all other types. But for CEF Node I have to uniquly determine numeric input type. As most parameters are passed as values I can't use Adapt to Type which passes only pointers. Have I to use Conditional Disable Structure? I discovered some time ago that extensive use of disable structures decreases performace. And beside that when I wire to certain function parameter from my Real type I get coercion dot even when parameter type and type inside Real agrees. I understand why it appears, but will it influence on performance? What approach should I choose to be able to be able to bulid my library for either single or double precision?

Another point. Most functions in ODE as first argument uses ID of something (world, body, joint, etc.) it operates on. It's simply a pointer to proper structure. I currently use UInt32 to handle it. But what if the DLL will be compiled for 64-bit architecture? Maybe should I use Int64 from the start? Will then 32-bit DLL behave properly?

I'm writing wrappers for Open Dynamics Engine, which is open source solver for rigid multibody systems (BTW, anyone interested in it?). It has very clean and well documented C API (although it is written in C++) and does not require to write any additional DLL wrapper. With one exception. It uses quite unusual way to retrieve values of forces in particular constrains. For each constrain you want to retrieve force during simulation, you have to allocate defined structure (6 floats) and pass its pointer to special function before the simulation. During simulation loop values in allocated structures are updated automaticly and there is no function to read them (what for it would be if you program in C...). But how to to it with LV?

One idea I have is to create additional DLL with 3 functions: 1st allocates memory for the structure (or even for given number of bytes to make it more universal) and returns a pointer, 2nd reads from the pointer and return value (or string to be casted to whatever you want) and 3rd deallocates memory. Simple but ugly and leads to memory leaks if LV wrappers user won't care to deallocate memory. Are there any other ways to to this?

Another point, but less important. ODE provides simple but convienient functions for 3D visualisations (rather for debug purposes). But it works using callback - you have to pass a function with main simulation loop, so making any DLL wrapper for that (until it is not LV DLL) does not make sense because all LV wrappers become unusable. Anything changed with that in 8.6? I mean is it possible in any way to directly pass a strictly typed VI as callback function?

I used LinMot motor and controller. It had not LV drivers, but it was very easy to write such for RS232. Worked very good.

I've written a simple VI (attachment) to read OBJ files.

Some features:

• reads triangles only (actually I don't remember how it behaves when it reaches quad - hope that ignores it)
  
• reads vertex information as well as normal and texture coordinates information when present
  
• reads objects and their names
  
• doesn't read faces groups (ignores commands)
  
• doesn't read material information
  
• doesn't check against any errors
  
• is almost not commentet
  
• generally works
  

Because was not writing it for displaying purposes, I can't provide any example quickly, but it should be quite simple. There are some issues with normals handling because OBJ has one normal per face vertex, not for vertex itself. Any questions - ask.

There is also C++ library libobj which may be wrapped in order to use with LV, but it uses callback so wrapper will take a little effort.

I'm working now on sth like raytracer and I use subroutine priority for all subVI's performing geometrical computations such as kd-tree searching, intersections calculations, operating on vectors, etc. Inside these VI's I also use many DLL calls. I noticed about 30% speed increase comparing to normal priority. I also performed some benchmarks trying various solutions for ordinary dot product calculation and one using subroutine was fastest. I have this benchmark somewhere if someone is interested.

BTW, I found recently a key in labview.ini file which enables "Inline SubVI" option in context menu. I inlined all subVI's of my main kd-tree searching VI (also all nested ones) and it resulted in 150 times (!!!) speed increase. I thought it was already optimized... I suppose it is because closing a part of code in subVI is a barrier for most optimal data-flow (waiting for all signals before executing subVI). But this is for another discussion...

QUOTE(Yen @ Feb 28 2008, 08:00 PM)

By the way, you can use the input device VIs to monitor for keystrokes in a platform indepedent way. They even recognize the grave key in my keyboard.

I verified this method, but it captures key presses, not releases. When I implemented key release using this VI, the tool takes 90% of processor time while typing... On the other hand it's multiplatform...

QUOTE

It would be too similar to your solution then...

QUOTE(Yen @ Feb 29 2008, 11:27 AM)

Would you be interested in adding it as another option inside the CCT? That would provide the tool with the options of either capturing an image or a flash demo.

It is interesting proposition but there are two issues. At first, my employer is a sponsor of time spent for this project and therefore credit and link should be included in both GUI and SWF (however it has not to be anything covering half of the window). Second one in the license - definitely binary of script compiler should be included in distribution (it's GPL), so whole the project should be GPL and contain also source code of compiler (but I'm not sure about it). So keeping CCT BSD licence will be rather impossible. But I may be wrong, I'm not too familiar with license issues.

What concerns embedding, beside swf also its dimesions should be known, because browser pointed directly to sfw file stretches it to window size. BBCode contains tag to embed flash ... checking whether it works here...

http://vugie.republika.pl/mult/mult.swf

... works, but forces to reduce flash size to pretty small values...

Here[/post] is an example how it should look like

The problem is:

I'm taking a reference to a topmost VI and set some properties to some objects on its block diagram using SetTag method of GObject class. I'm getting references to these objects from selection list, so I do not care where these objects are located. Now I would like to store information on which objects I modified (lets say using SetTag method of top level diagram). Storing references themselves obviously does not work, because they change each time VI is closed and opened again. So how to identify an object somewhere deep in diagram structure, not to have to traverse whole diagram each time VI is opened, searching for the particular tags?

I thinked of creating sth like object's address by recursively checking what is and index of the object in its parent's AllObjects[] property. But such approach is somewhat too complicated, as not all block diagram objects exist in AllObjects[] array (i.e. wires do not), so they need special handling. I'm also not sure whether such addressed would be "resistant" to modifications in block diagram.

I'm working on tool which would dynamicly "tie" comments to particular objects - i.e. to top-left corner of a loop to keep it there even if loop is resized, or to a wire. It may be also more general block diagram grouping tool (Yen, don't even say this...). So it would be good to store information about groups created when VI is closed.

BTW - GObject class has a Traverse method - anyone knows what is it for and how to use it?