Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by LogMAN

  1. You're right. Should have tested it...
  2. Well I guess you could cast your class to a more generic class (within the 'Read Trip' implementation of the child) and then call the parent class implementation of your 'Read Trip' method.
  3. Shoot the guy whose using the German IDE There is AFAIK no way to change the IDE- Language of LabVIEW exept for an re-installation. That is why you order your LabVIEW in a specific language.
  4. I use a switch for these kind of broadcast very often and I don't have any trouble with them... The behaviour might however change depending on your device and networking structure (I did never use the broadcast on a local network with server and such stuff...) As for the router itself I'm pretty sure they don't like to see broadcasts... You should use seperate ports in my opinion. I'm not very deep into networking too, but I think it's kind of 'bad style' to use the same port.
  5. You might want to take a look into the Bootstrap Protocol which is standartized in RFC951 and quite common for such kind of tasks (at least in my business). This protocol basically uses the UDP broadcast address on port 64 ( I guess ) to request any compatible device. The device will respond on the port 65 of the broadcaster. The broadcaster is then able to specify the IP-Address and some more parameters of the target device.
  6. Besides your algorithm there is also a issue for systems since Windows VISTA where Microsoft changed some parts of the underlying networking behaviour. In my applications I commonly have a seperate network interface which I use for PLC communication on a 1ms timebase. But the system (Windows 7) could only handle ~10ms or slower. Anyway, if you use a Windows system newer than XP, try following batch command: netsh interface tcp set global autotuning=disabled For me this already solved the problem...
  7. Yes, I was actually refering to exe files.
  8. If I would like to implement a couple of VIs which are licensed under the LGPL for an application in my company, then I would have to build a packaged project library (PPL) in order to prevent a licensing problem. The PPL can then easily be linked as external library from the build. This will obviously get more complex if I want to implement LGPL licensed VIs from several sources (which I can't pack into one PPL as I understand the license). I would have no problem with the BSD license, since there is no copyleft. Therefore the BSD license is prefered from the view of a company and for the sake of maintainable source codes. Greetings, LogMAN
  9. LogMAN

    Loop timing

    Hi Grey, If I understood you correctly, each iteration of your loop takes 3 minutes, but you want it to be 5 minutes. In my opinion you can just place a 'wait for next ms' next to your active code (in parallel) within your while loop and set it to 5000ms. Greetings, LogMAN
  10. Hi AustinCann, You should ask the NI support if they would update the code for you (they will do for shure, if you have a support contract). It is of couse necessary to send your code to them and you obviously need a support contract. I don't think it is that easy to receive evaluation versions of 6.x, 7.x and 8.x, unless NI has some platform for that (which I've never seen). Greetings, LogMAN
  11. Hi mike5, I'm not that deep in ZIP, but as far as I remember, ZIP files store their content in blocks. If you create a large ZIP in one solid block (which is very common), it is always neccesary to extract the whole ZIP in order to get one single file. So, for your question: Extracting one single file is not really slower, but used on a solid ZIP, it takes the same time as extracting all at once. If you extract 2 files one-by-one, it would take double time! It might be much faster, if you build a ZIP with a block size of e.g.: 2MB for a huge amount of small files, so you would be able to extract a single file in less time. Please correct me, if I'm wrong Greetings, LogMAN
  12. I know it's slightly off topic, however: 1) Most wire kink are caused by terminals not fitting together (like I want to connect 2 input terminals / constants to one 4-2-2-4 Sub-VI). I actually want my wires to kink in a specific, readable way. I can only imagine using such a solution to align my input - output terminals (like error in - error out) together. But I can actually do this by two clicks, so this solution would save a couple of clicks. However, it would allow more easy programming if I can switch it on / off. 2) We can actually do this by using the alignment tools as I wrote on 1) if you select both terminals before. If this is done automatically it will cause headache on my side, since I don't want all my controls to fit together. 3) I think this would be interesting in a way like Microsoft (I know, bad word ) does it in their Form designer. I think this subject worth it's own thread (Maybe already existing... ). Greetings, LogMAN
  13. 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.
  14. 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"???
  15. 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/
  16. LogMAN

    Ugly Solutions

    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
  17. 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
  18. 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???
  19. 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.
  20. 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
  21. 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
  22. 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
  23. 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....
  24. LogMAN

    FIFO vs LIFO

    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
  25. 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).
  • Create New...

Important Information

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