-
Posts
393 -
Joined
-
Last visited
-
Days Won
32
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by vugie
-
Openening the VI Properties takes a long long time
vugie replied to Milchbilch's topic in Development Environment (IDE)
QUOTE (Milchbilch @ Nov 17 2008, 12:29 PM) 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) 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 If I understand the second problem correctly, you need to get a function pointer to a VI to pass to the simulation DLL. This is rather tricky, but someone found a roundabout way to do this using LabVIEW's .NET callback functionality. Check out the solution here. 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.
-
When do you use Subroutine priority?
vugie replied to Jim Kring's topic in Application Design & Architecture
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) 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 You might also want to use a popup dialog which is ended with an Enter keystroke, since it's a bit more user-friendly. It would be too similar to your solution then...
-
QUOTE(Yen @ Feb 29 2008, 11:27 AM) 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?
-
QUOTE(Yen @ Feb 25 2008, 09:32 PM) In fact, interesting coincidece... What else do you work on? QUOTE(Yen @ Feb 25 2008, 09:32 PM) By the way, I didn't manage to use it. The DLL call simply returns 0 all the time. It might be because I'm using a bilingual keyboard, but I doubt it, since I could type the char. Explicitly pointing it to user32.dll didn't help either. Using attached VI You can test how this function in user32.dll works with your keybord. Or even better press the key you want to use as a prefix, notice number that appears and enter it to a constant on the left side of top loop (marked with arrow).
-
QUOTE(tcplomp @ Feb 25 2008, 07:20 PM) I can't upload them now, but they are not necessary - simply delete all instances
-
QUOTE(crelf @ Feb 16 2008, 03:59 PM) OK. As you suggest I contionue this topic here. I also invite you here, where I showed another tool of mine.
-
So after some cleaning up (which in this case means few hours of work beside repairing broken code ) I can put on the table what I have. The main file is VIpreVIEW.vi. You have to open it, fill all paths, sizes, etc. and run (not very professional, isn't it?). After some work (depending on VI complexity) it will create a lot of files at target path. Most of them are temporary files, but I do not delete them yet for debug purposes. Open {name}.html file in a browser and watch the result. I included SWFtools binary in this package (it's GPL) but I don't know how it is with all that legal stuff. Know issues: it is sloooow sometimes it is even slooooower additional 1px black line appears at each case (it is not an issue in alternative flash players as Gnash) tips appear even for objects in hidden cases (still don't know how to solve this) tips appear for each object (even not necessary, like comments) and often display sth stupid - this is for debug did I mention it is slow? many others Any comments are welcome, particularly if someone has an idea how to speed it up a little. I already tried to convert it to non-recursive version. Although I had some problems, it seems that recursion is not the reason. I think now that a bottleneck is speed of switching cases externally. If it is true, the stack version of algorithm should work even slower. And of course GUI in final version will not look like this. [moderator note] Attachments to this post are missing due to server error. We apologize for the trouble.
-
In the meanwhile I wrote a simple tool for speeding up coding in LabVIEW. I was little bit frustrated by searching for frequently used blocks again and again in palletes. Some time ago I worked with application with console input (like AutoCAD) where I was able to create macros for any command sequence. I created a set of macros giving them very short names and then I was able to call them just typing 2-, 3-keystrokes commands (I had to press enter each time). So here is my try to reproduce such functionality in LV. This VI is running in background monitoring all key presses. It looks only for commands preceded with "~" key (without shift) - to distinguish from normal typing. Commands may consist of alphanumeric characters only and may not be longer than 10 characters (not case sensitive). Commands are defined in _definitions.vi file. The only item in this file should be a case structure with separate frame for each command (name of the frame is the command itself). Frames may conatin whatever you want - it will be put into block diagram after typing a command. I predefined four commands: ADD, MIN, MUL and DIV (I guess that these shortcuts are descriptive enough ) So run VI, bring up the block diagram you work on and type "`add" ("`" is same key as "~", or at least should be - don't use shift while typing) and appropriate block will appear in the diagram at the cursor position. I used Windows DLL for catching the keys, so it will not work on Linux - I don't know whether sth similar is possible on Linux Known issues: error handling is not perfect - partially because I wanted to keep the code clear, at least in this stage. Strange things may happen if you type the correct command when the topmost window is not block diagram in edit mode. when cursor is outside the window during typing, block will appear in hidden area when cursor points inside any structure (i.e. For Loop) block will appear "over" it (with a shadow) - so you have to drag it a little to drop it into the structure blocks are put using ordinary copy and paste, so the clipboard may be overwritten (I did not found any better and working method) very, very fast typing may not work - it is because I didn't want to scan keybord too frequent if you will type sth very, very quickly after a command (or click a mouse), additional block copy appears So please test it and let me know whether is is useful for you.
-
QUOTE(Aristos Queue @ Feb 15 2008, 07:48 PM) Definitely yes, but not now - this is probably most ugly looking code I wrote ever... You know - patches for patches for patches... Anyway it works. It requires rewriting at least to let me understand my code <img src="http://lavag.org/old_files/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /><br />But I can describe the scheme. First stage is diagram analysis. I'm taking a shot of whole the diagram and then parsing it recursively (which is one of reasons why the code looks like this) classifying all nodes to switchable ones, subVIs, functions and terminals. For each of these I store bounds, label and description in tree-like structure. For each switchable node I switch between nodes taking a shot of each and parsing them recursively same way. Then it is needed to parse the front panel (it would be good to switch between tabs if any). It is not implemented yet - in example I just glued the image of panel manually in the middle of the process <img src="http://lavag.org/old_files/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /><br />Then all pictures are being saved to PNG files. At this stage user shoud decite what he want to show - which subVI to include, determine size of an animation, whether to show tips and what to put there, etc. Probably only initially selected part of code should be processed. All this stuff is not implemented yet. For generating SWF files I use Swftools (<a href="http://www.swftools.org/" target="_blank">http://www.swftools.org/</a>). As the name says it is a set of tools for dealing with SWF files <img src="http://lavag.org/old_files/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" />. One of these tools is a compiler for text based flash generation scripts (see the examples on the webpage). I created a set of sth like script templates for various object types (including some ActionScript also) and traverse the diagram tree replacing keywords in these templates with picture names, labels, etc. and glueing pieces together in order to create one big script file which may be compiled by calling external program. This is probably not very elegant and efficient solution and I treat it as a proof of concept. I would like rather to directly generate flash file using i.e. Ming library (<a href="http://www.libming.net/" target="_blank">http://www.libming.net/</a>). But Swftools were easy too learn - it is my first experience with Flash. Learning and creating wrappers for Ming will be quite big task - collegue of mine already started to work on this. Another advantage of Ming is that it uses less resrictive LGPL licence (Swftools is GPL). So forget about BSD, but I think it should be enough for such a tool.<br />So as you see lot of work is to be done...
-
First of all I would like to welcome everybody at LAVA forum. I'm reading it from time to time since my LV beginnings. Although I was not active at all, each time I had a problem, or wanted to learn something new, I was able to find the answer somewhere here. Thank you guys. Now to the point. I'm using my national LV community portal and my experience is that due to graphical nature of VI's code very often it is quite hard or at least inconvenient to describe a problem, help to solve one or share an idea. One way is to publish VI itself. But not everybody uses same LV version, VI is often dependent on number of subVI's, type definitions or libraries, downloading and opening VI takes time, particularly if one is doing something else at the same time. Another way is publishing a screenshots. But in this case you have to use a graphical editor to arrange subcases (with some trouble if you have nested conditions), crop the picture, etc. Diagram may be larger than screen causing additional problems, and large pictures posted at some forums may destroy layout (which is not a case here AFAIK). I know that there is a Code Capture Tool - frontly speaking I did not try it yet, but for sure in does not solve all these problems. So this is a background for my idea mentioned in the title - interactive VI preview. A preview which would allow user to switch between front panel and diagram view, to swich between subdiagrams within a Case Structure, Diagram Disable structure or Stacked Sequence independently on nesting level, which would allow to zoom and pan the view, see descriptions of elements and allow to enter the subVI and browse it the same way. Natural way to realize such idea is to alayze the VI (using dark and legendary method called scripting ) and to generate result as dynamic HTML or Flash animation. I decided to use Flash as it is mor compact and easier to embend (forums often support it) and here is the first result: http://vugie.republika.pl/mult/mult.html (sorry for the icons - it took me 2 mins to make them...) I hope that browsing this example is natural: you can drag diagram with mouse, switch cases using arrows, zoom with magnifying glass. Additionaly tips with name and some text appears when cursor is over an element. Of course this animation was generated automaticly with a preliminary version of tool I called VIpreVIEW. This is very early stage of development and is not advancing very fast as I do it in my spare time (which I do not have to much). So I decided to share this idea with you, just not to loose the motivation . If anybody is interested, I serve with details.