Naity

Hi, Thanks Baldrick My time has come too, I'm passing it this Friday, so reading all your tips helps

Hi Pulp, I can't convert it down to 2011 for now. To convert it down it reaquires the conflicts to be solved... And if I solve the conflicts the project is useless. If I have some more time later today Ill recreate it. Regards

After testing, it seems like the LabVIEW Compiler does not allow to change a class instance inside a DVR. I wanted to try my 2 ideas experimenting 2 new design pattern (the "David Copperfield Design Pattern" which makes object disappear and the "Nicolas Flamel Design Pattern" to change lead into gold). I did not try the Nicola Flamel one but the compiler refuses the Davbid Copperfield one: So I suppose my point of the previous post is partially invalid. Still, I am skeptical on the fact of using the in Place Structure outside the class methods. What speaks again coding a method which copies the the current DVR Object into a normal object? Thanks

Hi, First of all, I just realized I got some stuff wrong on this toppic. I did not see at first that Petehorn and Monzue are not the same users and my message was more ment for Petehorn. Sorry for that. Secondly, I tend to disagree with what u said (not the use of both object and reference for a class instance, but the use of in place structures outside the class methods). Not to pollute the thread with 2 parallel discussions, I opend a new thread in the OOP.section with some follow-up questions to your post. The link is http://lavag.org/topic/16866-use-of-in-place-structure-outside-a-labview-class/ Cheers

This thread is a follow up to the point discussed in another thread. I opened a new thread to avoid polluting the previous thread with a second discussion. The link is http://lavag.org/topic/16669-universal-fgv/?p=103311 and I want to react to a message from JohnMc86: Hi, I get the advantage of working with both DVR and Objects. However I am still very sceptical about the use of the in place structure to read the object directly in the main VI. I see the DVR Based Objects a really safe way to work with class while making sure they are initialized and to avoid data copies. Working with In Place on the main VI theoriticaly gives me the right to remove an initialized object from a reference and replace it with another object from the class or, even worse, a non initialized object. I am really sceptical on the "well coding" of this based on that point and also based on the fact that you are then manipulating an object outside a method. Is it really the best way to go? Would it not be prefearable to write this function in a method (like "Copy Object" where the object in the reference is duplicated and both object and reference are output. Or a "To Object" and "To Reference" Method with some error handling algorithm to make sure the object input of the "To Reference" method has correctly been initiated or is the same instance than the one that has been called from the "To Object" method)? I ma still "new" to the GOO world, so there might be some subtlety I do not see. Cheers

Hi Pulp, You can try to call 2 subvis with the same name, saved on 2 different folder and called by 2 diffeent VIs. The project explorer might not like it. You can also try to copy your user.lib to your project folder and call some VIs from both locations. If you want some conflicts to start from, see attachment. Regards Project Explorer Tools.zip

Hi, I am not sure I understang the last question you asked (should you use a gasp global?). Just to point 2 things out in addition to the post of Yair: DVR over Classes are indeed very powerful (to make sure you can use the same object instance in 2 loops for examples). However it is advised not to allow to use the In Place Stucture outside of the class method (it can be forbidden in the class properties in the Inheritance menu). This mean only working with the DVR in the main program and getting the object instance only inside your FGV. This also means using a create and destruct method to instanciate your class. Using DVR you can still use most of the common OO Design Pattern as the classes references are castables. HOWEVER you can not define the Class Reference Input Terminal of a method as dynamic dispatch terminal. This means, if you want to use dynamic dispatch methods, you have to wrap them around a static dispatch method which would get the object out of the reference (it basicaly obliges you to use the channeling pattern for dynamic dispatch methods). Summary: * DVR are good. * The object should only be accessible from the class method * You should use a create and a destruct methos tocreate the object and delete it * References are castable * You have to use the Channeling Pattern for Dynamic Dispatch method from a class reference Hope this helps

It can't be attached. Bluetooth is wireless... ->[]

Thanks for the summary. I did not know about this conditional disable for FPGA, grat thing

It shouldn't. So far I know it is not an algorithm and thus it does not need an clock cycle to be created nor to be passed to a subVI. However I might want to doublecheck that

Yes, I was refering to this palette (to both registers and block memory... even FIFO if you need them). Also they do not apply to a single VI but to a single target (you can not define a bloc memory for a single FPGA VI, it physically does not really make sense as the VIs don't exist after compiling no more). If you need to, you can pass their reference as parameter to a sub-vi. I am not sure about what you mean with "Would I need a different top level vi for each target, since each target has to define its own resources?". If the question is "do I need to create a different "[FPGA] Main.vi" for each target?", the answer is no. It is not a need (and it is the main advantage about thos functions). Theoretically, you can simply copy the VIs to another target, compile and it should work. However it is depending of the ressource usage. A spartan 3 and a spartan 6 do not have the same ammount of slices, gate, LUT and memory available. If you try to use more memory than available, the compilation will fail. However this problem is the same when you create the register and memories in the project explorer. Cheers

Hi Dalku, it is true that, due to the different model of the FPGA Target, you can not simply load the bitfile from the Spartan 6 LX45 to the Spartan 3. Your FPGA VI needs to be recompiled. The "easiest" way to write code so that it is as portable as possible is, in my opinion, to have as much items in the VI and as little in the project. This mean, using target scoped block memories, registers and FIFO. You can create those items directly in the VI (the functions are in the "Data Storage and Transfer" palette) and thus can simply copy your VI to another target without needing to recreate the project items: they are hard-coded. Hope this answers your question. Cheers

Factor 500... Could do better! Just kidding, you did a very great work

Well, it is not how I would have built it either, but previous comments sounded like it was not possible at all. I just wanted to check for myself.