MikaelH

I agree that by value should be used where ever it’s applicable. By most of my classes are instrument drivers and there I can’t live without references. Some other classes are Singletons and others uses shared aggregation, and therefore it makes my life easier to use one type for all of them, because if I forget that a particular class is by value I get really strange errors ;-) This is an example of the different looks and feels when using composite aggregation. ByRefByValue.zip Cheers, Mikael

Hi I would of cause not even consider by value unless I really needed the highest speed. This is a reference solution: Farm.zip As an initial design I wouldn’t add the complexity of the List object, and have the array of animals direct in the Farm attribute. Cheers, Mikael

See this post regarding this: http://lavag.org/topic/11081-tab-control-bug/ Cheers, Mikael

I like Logitechs slims design for that use. http://www.logitech....ection=overview (www.logitech.com/index.cfm/keyboards/keyboard/devices/192&cl=my,en?section=overview) http://www.logitech....ices/3848&cl=my,en?section=overview (www.logitech.com/index.cfm/keyboards/keyboard/devices/3848&cl=my,en?section=overview) Cheers, Mikael

Sure it's one solution, but assume that I use the local variable for the Tab Control and use a local variable for the string. And then suddenly we need to update this code to also gray out the string control, so I change it to a property node to disable the control and at the same time I use the same property node to update the value of the string control. But of cause I now know about this problem so I have to change the updating of the tab to a property node. But I have 5 LV developers in my team and I can't do all updates myself so maybe the developer I assign this task to might not remember this. Cheers, Mikael

I like the property node since they have Error in/Out that makes the me in control of the flow. But the property nodes are slow. This code takes around 8 ms, but if you change it to the property node it takes 10 seconds. That is because the control works in Synchronous mode. You get the same time if you set the control to "Synchronous Display" but still uses a local variable. So my conclusion is to always use the Property Node when updating a Tab control. Cheers, Mikael

Hi GDS users The last release has a bug that we missed in the testing phase of GDS. I’ve attached the file that you need to replace in the GDS folder. GOOP_CheckClassState.vi This file is saved in 8.5 and needs to be saved to your current version of LabVIEW. Step 1: Remove the Read-Only flag of the file “EndevoProvider.llb” in the folder: C:\Program Files\National Instruments\LabVIEW <Version>\resource\Framework\Providers\Endevo Step 2: Open the new file “GOOP_CheckClassState.vi”, and save it into the llb: EndevoProvider.llb, replacing the old one. Step 3: Restart LabVIEW. Sorry for the inconvenience. ------------------------ Edits--------------------- Just created a new release candidate for GDS that has this fix. http://goop.endevo.net/GDS/GDS_P8P_85.zip http://goop.endevo.net/GDS/GDS_P8P_86.zip http://goop.endevo.net/GDS/GDS_P8P_2009.zip Cheers, Mikael

Hi I suggest a database, a fast one The table has to be optimized for high speed inserts and queries/searches. When I get data from a table to show a plot and it contains huge number of values, I let the database do some decimation of the data, i.e. Take the first 1000 values and convert it to 1 value, the next 1000 values will be value 2. For this decimate function I have 3 options (Max, Avg, Min) the database uses when converting 1000 values to 1. Also every night you can let the database create records in an aggregation table that contains some pre-calibrated values and is optimized for queries only. Use this table when the user doesn’t need live data. Another thing, I always save the raw data as well in the database in a Special table and then let the database do the Math to “Calibrate” the raw data to the real value that is stored in a separate table. This approach is good if you want traceability. E.g. After a sensor gets recalibrated, and you noticed that it has been using the wrong calibration constants. In that case you can just recalculate the old data so it becomes correct. Cheers, Mikael

I better report it so we might get it fixed until next NI-week :-) I've always got my code working with some workarounds. One way is to use the Property Node of the Tab Control when changing the value. Sometimes I use a SubVI to change the Tab like this: This also saves some Block Diagram Space. But then I have to make sure the Tab is a Type Def and that can create some other issues. Cheers, Mikael

Hi I guess many of you have encountered this issue with the tab control. Is this a bug or something everybody knows about and always just manage to live with it. The problem is that the Tab Control don’t always changes Tab when you programmatically changes is using a local variable, if you at the same time updates a control or indicator using the property node which is located on any of the tabs. Why?? (LV 8.6) //Mikael TabTest.vi

I took this picture on the way to work in Sydney. I had to cover my nose and mouth with a cloth to cycle to work. //Mikael

I think your "Writing VI" to the database also assumes that some data should be returned, i.e. that you ran a SELECT Statement. Make sure you have the option set to not assume a response. Cheers, Mikael

Hi Count the number of attributes and methods you need in the class, then ask yourself does it make sense to create a class out of it. I wouldn't create classes if... ...you end up with a "tiny" class like this: ...you end up with a "property" class like this: Cheers, Mikael

Thank you. This fixed it. I'm happy again //Mikael

Hi My version of LabVIEW is behaving odd when it comes to Data Entry limits. Have YOU seen the same problem? When I open the “Data Entry…” option for a numeric the first time it does show me the right limits for that control. When I open the same option for the next numeric control these values don’t show the correct values. They still show the first opened control’s Data Entry-limits. And if I change the values, that values changes for the other control not the one I open the dialog from. This is in LabVIEW 8.6 Cheers, Mikael

I'm sorry to say that you have to go for the Picture Control. It's lot of work but quite fun :-) Cheers, Mikael

Same here, I love it. //Mikael

Since the device only have one internal clock it can only sample at one frequency, but you can sample on several channels at the same time. //Mikael

Keep up the work on interfaces, and maybe we someday can convince NI (read AQ) to implement this for us I did have interface working in LV 7.1 on GOOP2, where we had to have out own dynamic dispatch code in our base class methods. Cheers, Mikael

Hi all scripting fans I don't like the build in Sorting feature of Event cases in the Event Structure, and though about creating an RCF-module for this. But I can't read the Names/Cases from an event structure. It's easy to do this if it's a Case Structure since you have the Property Node: CaseSel.FrameNames But there is nothing like this what I can find (I might just be blind) for the Event structure. Since there are methods (Invoke Nodes), to rearrange cases in the Event structure, there must be ways of reading the names/objects of every case. Ideas? Cheers, Mikael

I suggest UML, oh I meant OO of cause ;-) These videos haven't been officially released but could been accessed here at the moment. www.goop.endevo.net/GDS/videos/GDSFeatures www.goop.endevo.net/GDS/videos/GettingStarted www.goop.endevo.net/GDS/videos/DesignPatterns www.goop.endevo.net/GDS/videos/StateMachine www.goop.endevo.net/GDS/videos/Debugger //Mikael (soon releasing the new version of GDS with some UML updated)

Interesting question! If you put code inside the TimeOut case, you are screwed. There are many different approaches here, but the easiest one I use is by using a state machine like this: If the TimeOutCounter is zero, I wait for 1000ms before going to the TimeOut case, else a 0 or 1 ms is wired to the TimeOut on the Event Structure, so it goes directly to the TimeOut case if no other events are in the queue. Event2.vi //Mikael

Hi I can’t help you much there. The design I’m looking into is to have the class-data (attributes) as a TypeDef belonging to the class and then put it into the Data Value Reference (DVR) wire. That then goes into the lvclass private data. A update method could then look like this. By using this method the dynamic dispatching will work as usually without having to put an In Place Element Structure around all abstract methods. Cheers, Mikael

Hi For normal/simple implementations I just tell the "public" class what type of objects it should aggregate/create as an input to the constructor, and have a case structure inside like this: And for this design, I normally store the TestInstrument objects in a class attribute belonging to the TestInstrument class. And with a static method "TestInstrument:GetObjectByName", I can retirve the instrument object. But when I develop TestSystem Framwork I use the Factory design pattern. Cheers, Mikael

I'm using LV9.0 64-bit on a Vista machine but haven't tried VISION on it myself, but what I've heard it should work. I did get some other problems for other drivers as NI-Scope that isn't supported yet. //Mikael