Tomi Maila

QUOTE(chrisdavis @ Apr 29 2007, 05:01 AM) Yes this is what I meant. Tomi

Hmm.. I wonder if it would be possible to wire this with LabVIEW in real... http://www.bcboxes.com/flasherjj.html Too bad that I already published my article on object-flow programming in my EXPRESSIONFLOW blog yesterday, this image would have made a nice illustration of what object-flow really is all about... Tomi

Hi, Make your instrument class generic and derive (inherit) your specif instrument from this generic class. This way you can later switch the instrument and your applications using the instrument class don't need to notice anything. Tomi

Just to report that I've now build a few packages with OpenG Package Builder and installed them with VIPM and it all seems to work great! I'd really like to thank everybody who has participated in creating these tools. Tomi

Thang, I would really appreciate if you would post screenshots of the relevant parts of your code instead of posting your complete projects make you questions as clear as you can not referring to other threads I'm willing to help. You must however understand that everybody me including reading this forum are busy and may not have time to start debugging other people's projects. That's why it's necessary to make answering the questions as easy as possible for them. The more prepared questions you can make, the better answers you will get and the more people can answer you. Currently most of the readers read your post but as it doesn't make any sence without following the links and downloading your project, the simply ignore it. Help your self by helping us. Tomi

I just posted an ExpressionFlow article: I guess you may find it interesting. If you like it, you should bookmark it with one of the social bookmarking tools (click the bookmark link next to the timeline image in the article). That may help us to get readers and comments from outside the LabVIEW community. And don't hesitate to participate the discussion. I'd love to hear you comments on the subject.Tomi

I took a look at your VI. First don't make your process VI a dynamic dispatch VI but a normal VI. So remove the dynamic dispatchness from the connector pane. Second you don't pass your process VI any data, not event the queue reference you use to pass data around. You need to pass the queue reference to your process VI somehow. One way to do this is to create a named queue. If a queue with the same name already exists you get a reference to this named queue. So create a named queue "ProcessQueue" in the "Launch Process.vi" and enqueue your object to this queue. Then create a named queue "ProcessQueue" in the "Process.vi" and dequeue the object from the queue. This way you can pass your object to your process VI. Just make sure it's not dynamic dispatch VI... Tomi

QUOTE(chrisdavis @ Apr 26 2007, 07:37 PM) I meant the backward compatibility of non-NI created software that would rely on the fact that VI is a single file and an executable such. I guess the correct word would have been forward compatibility of such software Tomi

QUOTE(Jim Kring @ Apr 26 2007, 06:32 PM) But we would loose the backward compatibility as many LabVIEW programs expect VI s to include both source and binary. Tomi

QUOTE(Ben @ Apr 26 2007, 04:12 PM) I doubt that NI owns any assembly line for sales packaging. Comapnies usually outsource this kind of things. It's really a business decission. Tomi

QUOTE(dannyt @ Apr 26 2007, 02:57 PM) You would never need to check-in the archived VI only the source .vis files. The archive files are there to provide backward compatibility with single source+binary package. Tomi

Ton and Jim, Thanks for extensive answeres. > [BUILDING PACKAGES WITH OPENG PACKAGE BUILDER] > Subfolders are not added recursively. This is an annoying limitation, and one which I would love to remedy, ASAP. There are two must have features: - adding files recursively boolean option - for each include files pattern, excluding files that match another pattern (with recursive boolean option as well) Do you Jim have time to work on these two? Additional nice to have features would be: - adding support for project file (lvproj), a library (lvlib), a class file (lvclass), XControl (xcontrol), XNode (xnode) in such a way that all items referred in these files will be automatically included in the build. Notice that items of project files can also be project files so these files need to be iterated recursively. - ability to exclude certain files from the project >>I tried to add dependencies but I couldn't get them to work. VIPM didn't complain of dependecies even though I added them here. Should or can the Revision number be included in the version number in dependency management? >Yes, revision numbers can be used in dependency declarations. Ok. There is a bug in the Package Builder that doesn't allow adding the dependency in the form x.y-z but requires it to be of the form x.y.z. When I added the dependency in the form x.y.z it didn't seem to work correctly with VIPM. So there is also a bug in the VIPM as it should generate an error and not try to install a package for which dependency is not found. >>In the Script VIs tab, What is the interface for the VIs that can be used here? >There is no defined interface. The VIs are invoked with the VI "Run" method and are not passed any data. If the VI has an "error out" indicator, it will be read by VIPM after the VI completes execution. If no data is passed to these VIs, how do I find out the installation location, the source location etc? It may be hard to execute any meaningful actions if the installation parameters cannot be accessed. I suggest that VIPM would set up some way to access all the build and current build step related information from the custom build steps. >Ton: Be warned that the current version does not have lvclass support, the next version should have. What do you mean by lvclass support? What would it do? > [INSTALLING PACKAGES WITH VIPM] >> I can add add local Packages to the list of packages from the Package menu. Can I remove packages from the list somehow? >There is no simple way to do this, right now. It would be nice to have remove funtionality in the UI. >> Can I add Packages by remote URL, not just files? >No, VIPM does not have such a feature. I've made a note of it and we will consider it, for future development. I strongly recommend JKI to adopt the mechanism that is used for Eclipse plugins. Eclipse has a default package repository in a similar way as VIPM has a default repository. However Eclipse allows users to add any number of custom repositories as well. These repositories are specified by an URI. The repositories can be local (file://) or on the network (http://). >Thanks for your interest. Keep the questions coming and I'll do my best to address them I'd like to see embedded version of VIPM that I could include in my application to manage my software related packages. I will not need this feature yet, but I guess I will need it later on. Do you think this would be possible? I ask this now because if this is not possible, then I may still need to reconsider if VIPM is the right solution for managing my tools. Tomi

QUOTE(dannyt @ Apr 26 2007, 11:11 AM) I don't think that this actually can change. Object-oriented programming allows to hide implementation on source level but there is no way the implementation can be hidden on the binary level. As long as LabVIEW embeds all the binary code to the same files as contain the source code there is now way to prevent these files from changing when the classes they rely on change. I'd like to see source files and binary files to be distinguished in the future so that by default the VIs would be archive files (ZIP) that contain a XML source code and a separate binary. For novice users this would appear as if there was no change compared to what VIs are at present. However there should be a project level option to save the source part of the VI into a parallel file hierarchy with extension .vis (VI source). The binary files would still also include the source files but the separate source files would only contain a URI of the binary file. <example> My Documents\My Project\My Project.lvprj (XML where each item links to both .vis and .vi) My Documents\My Project\source\A.vis (XML file with VI source only) My Documents\My Project\source\B.vis (XML file with VI source only) My Documents\My Project\binary\A.vi (ZIP compressed archive with both VI source as XML and separate binary) My Documents\My Project\binary\B.vi (ZIP compressed archive with both VI source as XML and separate binary) </example> This would allow much better integration with present source code control tools. Even XML merge would in principle work for the source files, although I'm not sure how usable it would really be.

Hi guys, I've an idea for next coding challege. The idea would be to use LabVIEW to write a utility for PC fan speed automatic configurable control and temperature monitoring. As the hardware support part would be too complicated for coding challenge, the utility could interface with SpeedFan DLL that takes care of the hardware layer. SpeedFan also includes a GUI but I think you guys can easily make a better one using LabVIEW. If this coding challenge produces a nice and usable LabVIEW application for fan speed control, this application could also promote LabVIEW as a general purpose programming tool among other users. Tomi

Crossposted to OpenG forums. However I thought that LAVA is really the correct place for these questions as OpenG forum is pretty dead. GENERAL Most of my software development nowdays is developing LabVOOP class libraries. Until now I've been developing classes "in-place" i.e. in their final location. Until now this has worked reasonably well as long as I've kept backups up to date. Now this path has finally reached it's end and we need to move to more sophisticated development process with an extra build step. So I want to develop my libraries in one location, build an installer package and install the package to another location. I decided to go with the combination of OpenG Package Builder and VI Package Manager as dependency control is a must have when there are multiple related libraries with inter-library dependencies. LabVIEW application builder don't allow me to specify package dependencies which will eventually lead to problems to library users and that would mean support requests to me that is not an option. First some general issues. My LVOOP classes depend on one another. Mostly the dependency is such that one class depend on another class but not vice versa. The dependencies can be inheritance, composition or usage on block diagram or front panel. I've been thinking of a package model in which I build independent classes first and install them to their final location using VIPM. Then when developing classes that depend on these independent classes, I link the dependent classes to the independent classes in the installed location and not in the source location. An example could help here. <EXAMPLE> Let's assume I have classes A, B and C. Class C depends on classes A and B Class B depends on class A My source file locations for A, B and C are My Documents\A, My Documents\B and My Documents\C respectively. I'd like to install class A to <user.lib>\A, class B to <user.lib>\B and class C to <user.lib>\C. So I first develop A in "My Documents\A", build a package from it and install it to <user.lib>\A. Then I develop class B in "My Documents\B" and link it to class A in <user.lib>\A. Then I package B and install B to <user.lib>\B. Finally I develop C in "My Documents\C", link it to classes A and B in <user.lib>\A and <user.lib>\B, build a package of C and install it to <user.lib>\C. </EXAMPLE> The issue that is open to me now is that if this is really wise way of doing the build process? The downside of this process is that if I want to modify something in all of the classes A, B, and C, then I cannot do that in a single project but I need to first modify A, then install modified A, then modify B, then install modified B and so on. This may be complicated when the project contains multiple dependent classes. Any recommendations and experience on this issue? BUILDING PACKAGES WITH OPENG PACKAGE BUILDER OpenG Package Builder is currently at version 0.1.0alpha6, so it's a pretty young product, however very nice and after some playing around quite intuitive as well. However it doesn't contain any help and when something is not clear, I don't find any answers. So I decided to ask them here. In General tab there is a version and a release number. Is version number and the release number combined to a form major.minor.release or are version and release number complitely independent of one another. In the Package Files tab, if I create a new file group and use file mask *.* for source files, are folders in the source directory included recursively into the build or do I need to manually select each sub folder in the source hierarchy In the Package Files tab, if I chage Group Source Directory a message pops up "Abosulte value of dependent paths may be either kept as is or revised according to new base directory". What does this actually mean? In the Package Files tab, there are a few replace modes. If I select "Is Newer" what actually is meant by newer in this context? In the Platform tab, I'd need to require LV 8.20 or newer but this option is not yet supported. Perhaps somebody can make the modification... In the Platform tab, What are allowerd values for the OS string? What is meant with "OS is greater than <some string>"? I tried to add dependencies but I couldn't get them to work. VIPM didn't complain of dependecies even though I added them here. Should or can the Revision number be included in the version number in dependency management? In the Script VIs tab, What is the interface for the VIs that can be used here? INSTALLING PACKAGES WITH VIPM VI Package Manager is currently at version 1.0 and is pretty polished and very easy to use. I have some VIPM related issues I'd like to ask here: I can add add local Packages to the list of packages from the Package menu. Can I remove packages from the list somehow? Can I add Packages by remote URL, not just files? I didn't get the dependency management to work but I guess this is an issue of package builder. Best regards, Tomi

QUOTE(dannyt @ Apr 25 2007, 03:30 PM) I'm afraid Danny, that what really happens is that every single VI in your project needs recompiling quite often. My experience is that if you for example change the private data cluster of your class, then all the VIs using this class need to be recompiled. This on the other hand may require changes on other classes and so on. Often the whole project needs to be manually recompiled by pressing Ctrl+Shift+Run as there are still some bugs in the LabVOOP compilation project. So the project recompilation is far from being limited to public interface VI changes only. As a result the number of VIs you need to check-in and check-out in LabVOOP projects is going to increase rather than decrease. Tomi

I've been gettin similar error messages daily in LV 8.20 and sometimes even with LV 8.2.1. As LabVIEW still works flawlessly, I've not really paid much attension. Reinstalling LabVIEW doesn't help. I've never used FPGA so it cannot be the only reason for these messages. Tomi

QUOTE(tibobo @ Apr 24 2007, 09:10 PM) Follow the link below and select call NI or email NI from the options in the page. http://sine.ni.com/apps/utf8/niae_asc.main''>http://sine.ni.com/apps/utf8/niae_asc.main' target="_blank">http://sine.ni.com/apps/utf8/niae_asc.main EDIT: It seems they still don't have 8.2.1 in the list of LabVIEW version.... Select 8.2 instead. If a NI person is reading this thread, you know what to do. The local NI support will then help you further. Try to make your bug report as detailed as possible so it's easier to debug. Provide all the needed files to repeat the problem and provide step by step instructions what to do to get the problem to appear. Tomi

QUOTE(Omar Mussa @ Apr 24 2007, 08:08 PM) Nice Tomi

QUOTE(eaolson @ Apr 24 2007, 06:27 PM) I think you can simply edit your .h file and rename the typedefs to what ever reasonable name you like. The C calls ignore the parameter names and the only thing that actually matters is the function name and the correct memory model for the parameters. QUOTE(eaolson @ Apr 24 2007, 06:27 PM) Other things are considerably more confusing. I have a function that returns a timestamp in LabVIEW. In the .h file, this function gets a prototype that looks like: void __stdcall GetTime(TD1 *errorInNoError, HWAVEFORM targetSTime, LVBoolean *timedOut, TD1 *errorOut); The only definition I can find for HWAVEFORM is in extcode.h that LabVIEW drops in the DLL folder: typedef IWaveform* HWAVEFORM; And the only reference to IWaveform I can find is also in extcode.h, where it is defined as: typedef struct IWaveform IWaveform; I can't find any other definition or even reference to IWaveform. Accessing waveforms from C is not supported. You have to use the waveform components for the connector pane of your C interface VIs. Then inside the VI compose your waveform from the components or decompose the waveform into its components depending on whether you are passing data to or from the VI.

Hi Omar, I'm happy that you have joined to the group of few who have really used LabVOOP for something serious. Excellent advices from you, I must say. I join your views. Thanks for recommending my blog EXPRESSIONFLOW. Although I try to conver LabVIEW Object-Oriented Programming related issues in my blog, the blog will not replace a good text book. I recommend reading one of Brian Eckel's Thinking in... books. Perhaps Thinking in Java would suite best for LabVIEW programmers. It's available as a traditional book as well as free electronic form. Omar, I'm interested in your experiences on LabVOOP together with source code control system. Until now I've been developing so that I make manual backups of my whole project. It's not the most elegant solution. I've been thinking of moving to SCC but the lack of experience on SCC together with LabVOOP has prevented me from the transition. I guess now you have this valuable experience. I'd appreciate if you would share the details with us. Would you like to write an article on the subject to Expressionflow? I can create you an author level account there... The SCC issues I'm especially interested in are LabVIEW requires all the files to be renamed or moved in LabVIEW so that links between files don’t get meshed up. This is especially important when using LabVOOP. On the other hand I think subversion requires files to be renamed or moved in subversion so that the revision history doesn’t get meshed up. How LabVOOP requires often recompiling the whole project. As a result each file in the project, even the files you didn’t edit, gets changed. How does this affect the usage of version control software. Regards, Tomi

You may want to read the LV Scripting readme in the Scripting forum here at LAVA.

Updated situation. I pressed the ignore button and the installation finnised. Then I used VIPM to uninstall all OpenG packages which worked ok. Then I uninstalled LV 8.2.1 for the Nth time. Then I removed the LabVIEW 8.2 installation directory manually as there were not any important stuff left there I guess. Then I reinstalled LV 8.2.1 again and it installed without errors. Now I've to see if I can get my OpenG packages back in place. Jim, would you like to add repair installation button to VIPM that would allow users to repair broken package installations... Tomi

QUOTE(crelf @ Apr 24 2007, 04:44 PM) I'm a physicist too from my education. I worked for a few years for the industry, not in the field of physics but in IT R&D. I planned new technology and business concepts together with a handful of startups. I returned back to research world as the projects in a large enterprise were not challenging enough mostly because our enterprise never had money to actually implement anything. However I gave up physics and now work on Bio-IT, a field of applying IT to biosciencens. The work is challenging now, although the resources are not the same as they were in the industry. So much time is consumed in constant funding applications, one after another. That's frustrating.

Crossposted to NI Forums. Hi, I was forced to uninstall LV 8.2.1 and reinstall it. When I'm reinstalling LV 8.2.1 I get an error message This error is somehow related to the fact that after uninstalling LV 8.2.1 LabVIEW 8.2 installation directory still remains with some stuff in the user.lib and other folders. I'm always using OpenG packages and I didn't uninstall them so that may be the reason. I also used DataAct class browser with LabVIEW. The problem is that I cannot uninstall my OpenG packages before I can get my LabVIEW installed again as VI Package Manager reposinsible for installing OpenG packages doesn't work without installed version of LabVIEW. And I cannot get my LabVIEW correctly installed because of this error. I can press ignore and the installation procedes but I don't know whet it didn't do because of the error. Has anybody seen this installer error before? What does it mean? For now I press Ignore. Tomi Maila