LogMAN

Exactly. I agree, selecting pull-down menu takes time, but as I get used to it over time it goes faster and faster. Also you just need to do this like two or three times a hour after adding new controls / indicator (as I write programs). I frequently use CAD application too, but I always liked the way LabVIEW does not automatically snap in position. actually it does make some things easier for me (on large VIs with many wires). Best solution might lie in between (like turn on / off snap positions by hot-key). I disagree if it comes to mixing everything up, since this would make a VI even more unreadable. How about adding a tool where you can design your own control / indicator symbol of a cluster / class or any complex type? ...(That would possibly make things even more complex......) I agree, flipping between BD and FP is not a solution. In my opinion, if you even need to switch between BD and FP, your VI got to large and you should consider using SubVIs. But using large icons does not solve this problem too, since they also do not show all information about your type. So what I usually do is using the help window while programming large solutions on classes or other object related projects (It will tell you more as you could possibly show on any icon). sense of humor at the end? Let me say just this: Thanks for adding large icons, they helped me a lot when I started programming in LabVIEW. Thanks for letting me choose between large and small icons, I really appreciate this. Whether my VI benefit from small icons or not depends on my particular VI and my specific way of programming. I suppose a bad programmers VI will be unreadable no matter which icon he or she uses, am I right? If you want to know something about your VIs readability, just open a VI you wrote one or two years ago! Just got thinking: Maybe we are running in circles on LabVIEW, like when you are beginner, you use large icons, at some point you switch to small icons and when you are professional you might switch back to large icons... I'm pretty shure there has been a similar singularity here on LavaG.

Haha... I'm so sorry, couldn't hold back. Getting more serious: I'm sorry for you, not because of icon terminals, but about globals and explicit naming... +1 +1 +1... I like that Actually this is also my style. More readable, easier to find terminals, less space, more flexibility. You should use your own style of programming, but please don't mix everything up, that would make things unreadable. You know LabVIEW can automatically align your terminals by two clicks? --> I always spend time to clean up code, since it will come back to me after some time (easier to maintain). As I started programming in LabVIEW, I liked using icon terminals. At some point they just bother / disturb me and I switched to small terminals. I understand the 'problem' of object or reference types, but I don't understand what you could possibly miss on small terminals for standard types like string. I would say standard types are best to read on small icons. If you don't understand standard type coloring, you should properly change glasses... If you don't remember the type of your object, just switch to FP (icons on FP are much more readable than icon terminals on BD). Cheers, LogMAN How comes LavaG post editor does not know words like "LabVIEW" or "LavaG"???

Hello ! You can change positions of variant elements by using the generic 'position' property (you should have discovered that). Apperently the 'bounds' property is read only, exept of the FP itself (panel bounds) and some elements (e.g.: XControls). Is it possible to change 'bouds' property using VI scripting in future versions of LabVIEW??? (I use LV8.6 with VI scripting, but there is nothing there) I generally use a VI to automatically resize the FP size to the largest decoration (frame) or to full screen. --> This is good to show multiple windows in same size. But that is no solution if you also want to change particular element sizes. You will have to do that manually. I recommand doing it manually, since you need to fit controls to it's contents and your personal visual style. LabVIEW does help you with tools to automatically align elements and fit sizes (There are three pull- down menus available): http://zone.ni.com/reference/en-XX/help/371361E-01/lvhowto/aligning_objects/

Of course!! In many cases it makes sense to take the time you need to develop a 'better' solution (even If your collegues don't agree). For example if you develop an test application which will be used on multiple targets and get changed or more advanced over time. The problem is, generally (In my job) you don't know if it will be used more often in the future. However in many cases if you use the 'easy' solution, someday it will kick you back in the ass (or one of your collegues if you are lucky) and you will ask yourselve why you didn't use the 'better' solution in the past. <<-- you know that solution? | You may use this solution! -->> But which solution is the best? --> depends on your problem My experience on this matter is that in many cases you will programm the 'better' solution someday, even if you program the 'easy' solution today. So just programm the 'better' solution if you get the time. Please notice: There is often more than one 'better' solution. Your solution is the best of course!!! Greetings, LogMAN

Hello, KeA If I understand you the right way, you've got a framework implementing an class (interface) for loading inherited classes (components) dynamically. Your components implementing sub- classes, which are instantiated somehow. How do you instantiate your sub- classes (modules) within the components (statically / dynamically)? If you statically instantiate your classes, the application builder will respond errors as you receive, because your modules (sub- classes) have the same VI names / hierarchy. In that case I recommend you changing the VI names to match a specific pattern which does not cause VI name collision (e.g.: <Class name>.<VI name>.vi --> CModule.Class Initialize.vi) You could alternatively change your code to dynamically load the modules at run time (since they share the same VI names). In that case you need an Interface class, loading the inherited modules. If you dynamically instantiate you classes you'll receive errors if you run your application in development environment (LabVIEW) once and then create the source distribution of your modules, because LabVIEW already loaded the class in memory while executing and will only unload if you close your project (or LabVIEW). In that case you should reopen your project in LabVIEW and create the target solution without execution the application in development environment. The application should be able to dynamically load classes even with same named VIs, since class member VIs inherit a class specific prefix in call chain. (<Class name>::<VI name>) Greetings, LogMAN

Wow, that's a hard nut... Just as precaution: Create a second "initilize array" for the CHAR of "Model", I don't know if LabVIEW handles the array correctly. dwCameraID should be U32 Also switch back "number of cameras" to U32. Everything else seems good to me... You should play around a bit, especially with the configuration dialog of the dll. There are some options about the threading (UI thread / ... thread) - The data format (Handle by value / Pointer to handles) is also interesting. Has anybody more experience in calling dll files with structures???

OK, according to the dll manual (as I read it) you have to change your cluster to an array of cluster which has the same number of elements, as the number of cameras at your system (1 element in your case). you can receive the number of cameras using the function "is_GetNumberOfCameras ()" of the dll (but for now the constant is much easier). If that does not solve the problem, try the following: Change the "number of cameras" value from U32 to I32 --> depends on how LONG values are represented in the dll. You might also try changing the data handle from "handle by value" to "pointer of handle" In the dll configuration dialog there is a tab named "Error checking", just set it's property to maximum to receive error messages from LabVIEW. LabVIEW might show an interesting message pointing to the particular problem. Note: It's recommend to change the error checking back to normal before finishing the project, maximum error checking might cause problems later.

Hello, durnek60 First of all, change the string constants (SerNo / Model) of your cluster to arrays of bytes (numeric U8 in LabVIEW), since chars are arrays of bytes. The arrays must be initialized (at least 16 elements for each) or the dll will write data in places which are already in use by LabVIEW -> might cause LabVIEW to crash!!! The DWORD values should be at least U32 values. The last DWORD value (dwResrved) should be at least U32 and must be initialized like the char values. I recommend initializing the arrays using the "initialize array" VI of the array palette in LabVIEW (just to be absolutely sure). Hope that will help you. Sorry, can't help you with the configuration dialog, since I don't have an LabVIEW installation on my current system. If the problem does occur anymore you should also share the error messages and the configuration dialog of the your dll call. Greetings, LogMAN

Hello guys, I run into an error similar to this post (actually the same, but I don't like the answer and it's old). I'm trying to change an build specification for an installer, which contains multiple exe- files with the same target directory. (LabVIEW 8.6.1f1) Some of the exe files use the same *.dll file (lvanlys.dll) which is automatically included by the application builder. I've already used the same project a couple of times and LabVIEW has never complained about anything. Just now I've added another application and nothing works. What am I doing wrong? Is there a way to tell LabVIEW everything is OK? (Since it's the same file, so what) I don't want to seperate the exe- files in own directories. Greetings, LogMAN

Hi, Jubilee You are free to add any VI or control of your choice to the palette, but project files will not work (even so I've never tried). Using Tools -> Advanced -> Edit Palette Settings you'll get two palettes (function palette / control palette) just right click on the particular palette and select AddVI(s) on the functional palette and AddControl(s) on the controls palette. You can select class member VIs just like 'normal' VIs. (Exception: public/protected VIs might not work from the palette) I don't know how xnodes are working on the palette, but it should work either. To your question 2: Note: I'm not trained in license stuff, but have some basic knowledge. Using open source software funtionalities to create new software (even commercial) is no problem, but the source code is protected by the license and copyright. Therefore, using the JKI RCF is OK, but don't copy or use it's source code unless you have the right. You should read the license of JKI RCF. Software is protected by the programmers license. His or her license must be part of the source code or the entire project. (Text on the FP or BD / file in the directory) Is software protected which does not provide any license information? -> I don't know, seems to be free for use, if you ask me... Of course there are different types of licenses: BSD: This license allows you to freely use the code for even not open source software. GPL: This license forces you to put your software on the same license as the source code and you have to provide your own code for free. LGPL: This license allows you to use the open source software even for not open source software, unless you don't use the code directly (as sub-VI), but as own library (DLL). And much more... Note: all samples above are much more complex than I could write. You better read some articles from wikipedia or the particular license provider. You might also directly ask the programmer. I recommand to only use free software for commercial use, if it is protected by BSD, which allows you to freely use it. I also recommand to provide code which has been programmed using open source software. OK, much writing, less information... To your question 4: JKI RCF bundle wire plugin Greetings, LogMAN

Just guessing about multithreading.... That king wasted a great chance, but hey, the developer somehow is alive, check out this page: toaster pc There is just no space for a toast....

Double that answer! Validate you data before putting it into the buffer!!! -> Less headache in the future, believe me. Why not only putting the last scan data into the buffer, since this seems to be the one to be used? If you can't validate which scan data is worth to be used, even an LIFO buffer will not help you, since the last element in the buffer could also be invalid. Note: Even if you enqueue the last element of the queue, you have to handle the remaining ones or your buffer will grow... Greetings, LogMAN

Great idea. I know some people who think if they don't see the canvas, the program is using the memory more efficient. (I havn't yet proved that) I should upload a wallpaper collection for you (slide show).

It's not like my programs are perfectly designed at the beginning, but sometimes there are some functions I know I will use more often, so I take the time to make it more readable! The only thing I do always is correct wiring, because it makes it easier reading code after a day or so. You know: You can do 80% of work in 20% time, but you'll need 80% time getting the last 20% work done! (I forgot who said this sentence first ) So, after finishing a program in LabVIEW, I go through the code writing it more readable and placing documentation all over my VIs. It's hard work, but it worth the time. However - Your code is much more readable as most of the code I have to read all the day. Code like this: Caution: Bad code! is very common! One thing that's really great with your project: The way you organize your VIs in your *lvproj. So, don't worry and keep on programing, writing code more readable one step after another. (Do one thing better each project - ) Your MView programming language is well designed, as far as I concern. Even if I don't use your project as is, It's a great base concept for me to write a similar distribution! I was going write a similar project like yours, but I'm to lazy for taking the time of a concept like your's. So, thanks! I don't know much about memory management in LabVIEW, so it might worth the work of writing a new post (Interesting question). You could write an external DLL in a conventional language, using it in LabVIEW as "Memory" (Not Recommanded) You might try some of the 'In place element structure' functions (LabVIEW 2009 and 2010 are getting better with that step by step.) One thing about your memory management just now: It's an interesting way of thinking and writing something like heap and stack (pseudo, but however) in your project! Nice to read and something to use somewhere else... Thanks for that kind of idea too. Greetings, LogMAN

Thanks, it worked just fine. I know exactly what you mean. Using LabVIEW as IDE makes programming easy like playing a game. But design in LabVIEW is as important as description in conventional programming languages. A good way to clean programming is a design concept. You have to define your programming design and use it in all your programms. (Believe me, after some time it goes easier and easier) Here are some concept ideas I use normaly. They are easy and fast to implement after some training: 1. Do never create wires behind structures, you might search errors for hours!!! (Move wires above or below the structure.) 2. Use one connector pattern in all of your VIs (except of special VIs), with error in and error out connected to opposite connectors at the same place every time. (This will help you creating a "VI line" and using the "flow" concept of LabVIEW. (Even change the pattern of automatically created Sub-VIs.) 3. Do not move wires around like snakes. (I know it's hard at the beginning, so right clicking the wire and selecting "cleanup wire" helps ) 4. Programming VIs, larger than your desktop should only expand in one direction (horizontal, vertical). 5. Use labels on your block diagram for documentation. (I normaly use a special color for documentation labels) 6. If any function might be usefull somwhere else, create a sub-VI. (VI icons should at least have text within) 7. Are you using parallel loops, larger than your desktop? Create seperate VIs for each of them. 8. Move inputs on the left side, outputs on the right side of your block diagram. 9. move labels of inputs on the left border, labels of outputs on the right border. (Implemented as option in LabVIEW 2010) 10. Do never lecture your concept ideas... aaah... I know these concepts does not work always, but it's much easier to maintain your VIs, if you have a clean concept. The "Right Click Framework" is also a good way to clean VIs (Thanks to all). There are two snippets attached as sample for the concept. (First is original, second is changed) Wow, my hands are burning... I'll need something to cool my head. Cheers, LogMAN

Hi, j_meier I think the MView.lvproj file is missing in your new build. However, your code is just amazing!!! Very efficient... It's true, caring large VIs is important and necessary. If you need space on your block diagram, hold the 'Ctrl' key and use the left mouse button to make space. Release the mouse button to commit. Carefull: marking an rectangle will cause all code to move in 2D. To make space in one direction, move your mouse until there is a straight line (almost not visible). Tip: Use a dummy- VI for testing. Yes, it's hard to read and the VIs need some Artwork, but the functionalities are amazing!!! I suppose your code will be used in many projects from now on (Of course after some enhancements). Cheers, LogMAN

No wonder I never encounter an error like that. I've never used classes in project libraries. So, problem solved ... somehow ...

That's interesting... I've attached two files to prove. (TrayIcon.RegisterEvents and TrayIcon.EventHandler are of private scope) Changing the classes content to private will cause the files within the palette to show a red cross. I also need to update my last post: Protected items are shown with a red cross too. Sorry, but if your class is public and you have full access to all contents, it might be a bug.

Hi, vugie The VIs are marked as "private". So, if you use libraries or classes and a VI is marked private, it'll be shown this way. The problem is: You can't use these VIs until your VI is part of the class or library. To solve the problem, open the library or class and mark them as "public". Note: VIs with red crosses are private. VIs with yellow crosses are protected. VIs without crosses are public. Greetings, LogMAN

Hi Suvin, I've saved the snipped for LV86. Distribute.vi There is also the Object_distribution package for OpenG attached (also for 8.6) Object_distribution_86-1.2-0.ogp I suppose you are already using JKI VIPM. Greetings, LogMAN Edit: sorry, VI was broken - now it's fine.

Hi, venky 2810 This should not be a big problem. While building the installer LabVIEW ask you to insert the LabVIEW DVDs. If you insert the DVDs in your machine and selecting the correct drive name it should work. Greetings, LogMAN

two minutes to late... Jim's first.

Hi, Ton I support the answere of mje with one additional thought: I suppose your application is running in two asynchonous loops, which results in multiple threads on your machine. Multiple threads (multithreading) forces programms, which are not using the CPU at this moment to switch to background, so another application could run for a couple of miliseconds. If you execute your sender loop to send the "stop" command, it it's using the CPU completely by sending the command and directly destroying the event, so there is no point for the computer to force the process to the background. By adding a wait functionality, the thread will be halted for just a millisecond or less, even with a zero connected to the terminal. Within this milisecond your listener loop is able to receive the event request to execute. After that, the sender thread comes back and destroys the event. So the behavior you've described is not a bug, but a multithreading dependend problem. To solve this problem, you could force the sender thread to wait for just a milisecond as you did. But this way of programming is not very good, because as mje already said, it results in undefined states. You should consider to add some synchronisation functionality in your code as I would do, or just don't destroy the event, because LabVIEW will take care of that on it's own (also not good style). Greetings, LogMAN

Just click at the particular entry and change it (as shown in the picture)

We have used LV2009 for one large project and never since. That was because of many failures. For instance: Error in Line XYZ in MemoryManager.cpp. LabVIEW crashed with this error every 2-3 runs. Also after we updated to LV2009 SP1... We switched back to LV8.6.1f1 and everything works fine. Also the VI and EXE files were larger (LV2009: 15Mib / LV8.6.1f1: 12Mib) We use almost everything of LabVIEW, except of Mathscript and Remotepanels. Our applications have about 200 - 300 self made VIs. We are in need of better multicore processing, but LV2009 is to unstable. But I think, wether to use LV2009 or not depends on your needs. If you do parallel computing and need more performance using multicore processor, LV2009 might be a good choice. If you only do "normal" stuff, LV8.2 or LV8.6 / LV8.6.1f1 is the better choice for now. Install LV2009 on one computer, load some of your projects and do some tests. (Also perform some errors!!!) Greetings, LogMAN