Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by LogMAN

  1. 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 solu
  2. 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. &
  3. 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
  4. 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???
  5. 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 "pointe
  6. 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 (j
  7. 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
  8. 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
  9. 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....
  10. 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
  11. 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).
  12. 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
  13. 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!!! (Mo
  14. 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
  15. No wonder I never encounter an error like that. I've never used classes in project libraries. So, problem solved ... somehow ...
  16. 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.
  17. 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
  18. 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.
  19. 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
  20. 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. B
  21. Just click at the particular entry and change it (as shown in the picture)
  22. 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
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.