Tomi Maila

QUOTE(Neville D @ Aug 21 2007, 08:04 PM) Because that's how you become a real professional Knowing how to do what somebody already has done...

QUOTE(brian175 @ Aug 21 2007, 05:36 PM) Actually when I ran the 'LAVA tryout' installer after having installed 8.5, it only had installation options for LV 8.2 earlier. I meant if the installer will support 8.5 as well. I guess I can simply copy the files to 8.5 but I didn't try it Of course it would be nice to have all the new properties and methods supported as well Tomi

Hi Brian, Are you planning to make a LV 8.5 version of this tool? Tomi

LabVIEW can use multiple different ways to pass arrays between LabVIEW and external code. The options are Array Data Pointer, Array Handle and Array Handle Pointer. Array Data Pointer passes a one-dimensional pointer to the array data. EDIT: This I think means 'datatype*' which is the same as 'datatype[]' hence the name one-dim pointer Array Handle passes a pointer to a pointer that points to a four-byte (I32) value for each dimension, followed by the data. Array Handle Pointer passes a pointer to an array handle. If your C function expects other data types, you need to create a wrapper for the function in C to make the call. For detailed information see the pdf below. http://www.ni.com/pdf/manuals/370109b.pdf

Actually both of the categories you posted didn't match the question. The correct category would have been LabVIEW general or LabVIEW development environment (but not both). I don't know the answer. However in the help of LabVIEW 8.x LabVIEW command line options are explained. Did you search LabVIEW help for 'command line' before posting?

QUOTE(Ale914 @ Aug 20 2007, 11:13 PM) I'm not very familiar with Teststand but couldn't it be used as a unit testing framework as well? As far as I've understood Teststand allows writing LabVIEW based tests and automating any sequence of such tests. Unit tests are actually not that different from hardware tests etc. Of course the price of Teststand may not be suitable for pure unit testing purposes.

QUOTE(bourne identity @ Aug 20 2007, 10:52 PM) As a student of electronics and communication engineering you should definitely learn them both. If this is not possible, try to get evaluation version of them both and learn the difference by yourself. However your question is rather general. It's like asking what's the difference between China and India. If you have particular application in mind, it may be easier to ask which suits better for this particular application. However, I try a little.... LabVIEW is a visual programming language and Matlab is a text based programming language LabVIEW is a dataflow language and Matlab is a imperative language LabVIEW suits very well for hardware integration, Matlab suits very well for Matrix algebra LabVIEW suits very well for interactive applications, Matlab suits very well for data visualization LabVIEW suits better for general purpose programming LabVIEW code is much easier to debug and as visual programming language LabVIEW code contains much less bugs LabVIEW code runs faster than Matlab code, at least in most occasions LabVIEW can run and call matlab code Matlab has a wider OS support, LabVIEW runs on hardware other than normal computers

Did I know understand it correctly. You have a generic decoder interface. Then you have specific decoder interface for your mpeg decoder. You have generic settings interface for all the settings. Then you need to implement the settings interface for the mpeg decoder? Then you don't need one but two class hierarchies; the settings hierarchy and the decoder hierarchy. You would need a generic decoder class and a specific mpeg decoder class. In addition would need a generic settings class and a specific mpeg settings class. Then you could use composition to set the mpeg settings class as a private data element of your mpeg decoder class. I trying to draw the picture with a little too little information. Was this something you were intending?

QUOTE(Pana-man @ Aug 20 2007, 07:47 PM) First you are misusing inheritance here. As decoder is not really a setting, you should not make decoder to inherit from setting. Instead, you should put setting class into the private data of decoder. To access the private data of setting class, you need to create methods to the setting class and use these methods within the methods of decoder class to access the settings class private data. In LabVIEW all private data is really private and not protected. That means that you can access the private data only trough class methods when you try to access it outside a method of this class. QUOTE(Pana-man @ Aug 20 2007, 07:47 PM) At the behest of Tomi... I am posting here. Under the hood, so to speak...the decoder class is instantiated, there is an U32 handle that is a pointer in memory for the decoder that is being utilized. The same is also true for the settings. ... My "work around" is to write a VI (property node, in the settings class) that extracts the U32 handle for that instance of settings, public properties.. that I can call and then store in the decoder class. Well maybe this is not a work around, but it seems to be I should be able to attach the settings to the decoder, and then access that data through passing in the decoder class to it's method of initialize. If you need to extract the U32 handle from the settings class private data, you can only do this within the class itself. If you need to use this handle in a method of decoder class, then you need a method for the settings class to get the handle. This method needs to be public as LabVIEW OOP doesn't have any other kinds of ways to access other classes private data. However I don't know if you need to have the settings class public? It's possible to put multiple classes into a (lvlib) library. Then you can define some of the classes within the library as library private. This way you can have internal classes that may be visible to other classes within the library but not outside the library. I may have understood something incorrectly, please ask for clarifications if everything wasn't clear.

QUOTE(Kevin P @ Aug 20 2007, 07:21 PM) I tested converting an array of I32 to an array of U32 and then writing it to an indicator. I wrote another VI that was identical but lacked the convertion. The convertionless VI took less memory according to LV profiler in LV 8.5.

Jim mentions Jeff's wire in his blog post. What new infromation did you people get related to Jeff's wire during the NI Week this year.

QUOTE(Aristos Queue @ Aug 19 2007, 05:07 PM) I think LabVIEW type system should be changed into one handed, preferrably left handed. You can either use left handed types or right handed types in your applications but left handed and right handed types cannot be used jointly in the same application. I guess I'm becoming mentally closer to the fifth dimension...

QUOTE(Irene_he @ Aug 19 2007, 06:13 PM) Actually I always set my decimal point symbol to '.' because NI has tried to localize some of the VIs to use local decimal point symbol. This seems to cause more problems than it solves. For example there was/is a bug in TDM file that tdm functions used system decimal point in the TDM XML file. As a result the TDM files were not working across systems using different kind of decimal point.

QUOTE(i2dx @ Aug 19 2007, 10:12 AM) It's general knowledge that people from the States don't know what's going on in the rest of the world. We had at least one representative from Europe. I guess ExpressionFlow was the only European community that got on that famous slide Off topic. North Korea got it's own domain .kp finally. Now this thread and LAVA forum is tagged for secret service investigation from North Korea

QUOTE(i2dx @ Aug 19 2007, 10:05 AM) Which one is that? How many users did NI ignore?

QUOTE(Aristos Queue @ Aug 18 2007, 09:47 AM) There is always the possibility to encapsulate the tests into classes so that each test has its own class and all tests derive from common parent class. The classes test express the http://en.wikipedia.org/wiki/Command_pattern' target="_blank">command design pattern in that they have 'evaluate' dynamic dispatch method for evaluating the test. Now we can write a VI that takes an array of test classes as arguments, calls evaluate for each of them until it one of the tests evaluate to TRUE. Then it returns the index of this test in the array. If none of the tests evaluate TRUE it returns -1. The returned index can then be passed to case structure. This is an overkill for the example in this thread. But this is not overkill when the tests are complicated and actually encapsulating the tests into classes can make the application design much cleaner easier to read.

QUOTE(Daklu @ Aug 18 2007, 01:19 AM) You forget that more than one of the case may be true simultaneously. Then the result would not be 2^n but something else instead. I think manually computing the proper case is too error prone. Therefore I suggest the following modification. The loop part can be converted into a subVI. Also while loop can do the same thing but this new (8.5) for loop is a little easier to use. And this is a good excuse to use it... http://forums.lavag.org/index.php?act=attach&type=post&id=6678''>http://forums.lavag.org/index.php?act=attach&type=post&id=6678'>http://forums.lavag.org/index.php?act=attach&type=post&id=6678

My educated guess is that LabVIEW will not reuse buffer in type conversions in any situation. This is confirmed by 'Show buffer allocation' tool at least for I32 -> U32 conversion (assuming the tool works properly). LV 8.5 in-place structure doesn't help as the input and output type must be same when using the structure. You can fairly easiy test if

I strongly disagree with Jim's original suggestion of changing the functionality of typecasting primitive. Consider a future in which all LabVIEW primitive types would be actually build-in classes, and would behave as such. Then an array would also be a class type by itself. Now if we change the behaviour of casting nodes for arrays, these nodes would behave an incorrect way when arrays would be classes by themselves. So the correct way to do this is to make arrays classes them selves and modify the cast operation so that would return an array of type Generic Class.

We had some problems although they upgrade process was generally easy. Our projects are all using LVOOP. With one of the classes we had a problem where a class in a project complained to be "not loaded". When we tried to open the class directly from Windows Explorer, the LabVIEW told the class file to be corrupted. Another problem we had was that with one particular mail level VI in our project, after running it four times, LabVIEW vanished i.e. crashed adn all windows disappeared immediately without any error messages. First we thought this is purely LV 8.5 related issue as we hadn't encountered it in LV 8.2.1. We tested the VI in 8.2.1 version of the project again and it appears that there occurs and exception in external code we are using. LV 8.2.1 catches the exception and gives an error message. LV 8.5 vanishes. One bug I've also encountered but I've not yet reported it to NI as I had not had time to test how to reproduce it. When I changed the name of a class type control in a private data cluster of another class, the name change didn't penetrate to member VIs. All bundle and unbundle nodes still appeared as if the name had not been changed. Compiling the project with ctrl + shift + run didn't help (if I recall correctly). So there seems to be some book keeping issues related to class wire item naming in LV 8.5 but this doesn't affect runtime properties.

I can confirm that we had also similar problem where a class in a project complained to be "not loaded". When we tried to open the class directly from Windows Explorer, the LabVIEW told the class file to be corrupted. We dealt with the problem by reverting this particular class back to LV 8.2.1 version from our source code control repository and reopened it again in LV 8.5. This seemed to work. We have not yet tested if it actually stayed that way after closing and reopening LabVIEW 8.5. Tomi

My opinion is very close to Aristos Queue's view here. I'd however add a True Color class above the 24-bit image to allow 32-bit images to be added later on. I could also consider creating a single wrapper class for all LabVIEW image types and use this class as a private data member for all the other classes. For example 8-bit image could have a LabVIEW image in it's private data and delegate functionality to LabVIEW image. p.s. AQ, do you think it would be possible in a future version of LabVIEW to make it much easier to use composition? I'd like to have an option to create new delegated method so that LabVIEW would automatically generate the method to have the same interface as the same method in a class in private data. So should I have a method jump.vi in a class in my private data, I could make LabVIEW to automatically create a method to my class that would delegate the call directly to jump.vi. Tomi

QUOTE(ardi @ Aug 14 2007, 09:41 AM) Ardi, welcome to the LAVA forums. LabVIEW has a feature called remote panels. With remote panels you can publish your VI front panels using LabVIEW web server. Remote panels are not to my knowledge included in all LabVIEW packages but they are included in at least LabVIEW professional that I'm using. Should you package not have remote panels, you can purchase remote panel support from NI as an add-on. As you didn't mention which LV version you are using, I assume you are using the newest release 8.5. Probably this is not the case. However in LabVIEW 8.5 there are two relevant items in the tools menu: Wbe Publishing Tool and Remote Panel Connection Manager. Both of these tools do what you'd expect. Use web publishing tool to publish your VI front panel on the web. You must enable LabVIEW web server from LabVIEW options as well and configure your local firewall so that they allow the traffic to LabVIEW web server. As a new member to LAVA forum, you should read http://wiki.lavag.org/index.php/Forum_Guidelines' target="_blank">LAVA guidelines. Tomi

QUOTE(tcplomp @ Aug 11 2007, 07:14 PM) I definitely agree Should we try to organize Advanced LabVIEW conference during the European NI Days in Barcelona. European NI Days take place in April or something. This would be an excellent excuse for all the LAVA gurus from all over the world to visit one of the nicest cities in Europe. Would you guys like the idea?

I didn't attend NI Week so I cannot judge if the presentations were interesting or not. However, IMHO, I'm don't think we should accuse NI of not organizing interesting sessions for us advanced users. If we feel NI Week doesn't provide enough content for us, we can always organize ourselves some additional program. This is how it works on all other fields of science and engineering, the community organizes the conferences. Why should LabVIEW developer conferences be different. I'm even confident that if we would organize some program, NI would be more than happy to take care of practical issues such as providing conference rooms and such. Tomi