Jump to content

Naity

Members
  • Posts

    23
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Naity

  1. 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:

    dbb1bff0-04ee-4852-929b-61ee1d274302.jpg

    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

  2.  

    I would suggest it is not as black and white as that. If you are trying to guarantee the correct use of the object in a reference design that is correct.

    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

  3. 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:
     


    I would suggest it is not as black and white as that. If you are trying to guarantee the correct use of the object in a reference design that is correct.

    However I have used designs where I still make the methods take the object directly and the application is in charge of dealing with the DVRs. There are a few advantages:

    • [*]The class is more reusable, it can be used by value or by reference. [*]DVR is a form of communication, the application architecture should and can dictate the communication method, not the library. [*]You can decide what functions are 'atomic operations' i.e. you have methods A, B, C. If each method passes a reference to another and you have two loops you could have the execution order A1,A2,B1,B2,C1,C3 or any other combination. If the methods pass objects you can wrap all 3 inside a in place element to guarantee A1,B1,C1,A2,B2,C2 or 2 then 1


    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

  4. 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

  5. Thanks for the response.  I assume you're referring to the "VI Defined Registers?"

     

    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

    • Like 1
  6. 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

    • Like 1
  7. Why wouldn't build array and array index work?

     

    When you build an "array of array" with the build array fonction, you can either concatenate those array into a bigger one from same dimention or create an array of n+1 dimension. This array could then be indexed again:

     

    array.png

     

    It does have some caveeats, like all the array will get the size of the bigger one, which also might need some additional code tu reduce it to its original size. but it still remains possible.

     

    About the XNode, I downloaded the code but I never heard of them before, so I can not be anyhow critical in my review. Still its a great tool and I am also looking for a idea of a function to create with them.

     

    :thumbup1:

  8. I am glad I could help.

     

    On a more general note, your actor.lvclass is the topmost parent. However, you can also define methods for dynamic dispatch in its child which would be overriden (I am not sure of the correct terminology in english) by its grand childs. This is what is done in this example. 

     

    Good luck with the tutorial

  9. Hi,

     

    you might find your answer page 9 and 10 of the document:

     

    Page 9 you will find the hierarchy of the framework. Notice that the LevelController.lvclass is a child of the TimedLoopController.lvclass

    Page 10 you are asked to create a Uptade method from the dynamic dispatch template for the timed loop controller class

     

    I think you either forgot to create TimedLoopController.Update() as I Method for dynamic dispatch (which can be solved as described by Mike and Me) or you forgot to define LevelController.lvclass as child from TimedLoopController.

     

    I hope this help :)

  10. The only thing that remains would be what the aVarId value needs to be. The description is totally cryptic and might be a very good candidate to have understood wrong.

     

    Yes, it might be that. As I understand the document, it might be a char*

     

    The "it begin with v" lead to think that the aVarID could be a string.

     

    Cheers :)

     

    EDIT: I did not read carefuly the function prototype at the beginning of the post. It might also as well not be that.

  11. Lurker since a little while (around since as long as I got to learn LabVIEW... which means 2 little years). I registered today (I wanted to do it since a while... but never did). My contribution might be little due to a lack of experience, but it's a great place to learn.

     

    I'm 25, was born and studied in France (University of Lyon) where I graduated before starting my studies anew in Germany. I wrote my thesis by NI in Munich and got to know LabVIEW there. I'm since Application Engineer by NI Germany.

     

    I mostly like music and creating colorful wires between squared blocks to make screen look pretty (im not talking about Super Mario Bros Bondage Edition).

     

    Cheers  :thumbup1:

    • Like 2
×
×
  • Create New...

Important Information

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