Jump to content

mabolas

Members
  • Posts

    12
  • Joined

  • Last visited

Posts posted by mabolas

  1. Hello,

    Recently I'm trying to get my CLA and this is my third time practicing this example.

    I took about 3 hour and 20 minutes to finish it.
    (Actually I planned spent 3 hour to finish it , it's already the third time, I barely analyzed it , just coding)

    The first hour I took was for establishing ancestor classes, set up public data, sharing mechanism / VI
    (open/close queue references, access data base, main running VI framework.....etc)

    The second hour I spent on modules (error handler, user console, display console and sensor )

    The third hour is implementation of the main module : Controller 

    and I took another 20 minutes because some requirement tags I have no idea where to put.


    I know lots of people suggest do not use OOP in CLA, because it takes too much time.
    But I've been used to OOP style and not very familiar with tradition QMH programming.

    Something Still Confusing me , it's appreciated if leave some comments or suggestions to me.


    1. I still think it's not fast enough, did I put too much code or redundant comments in it?
    (when I took my CLD, lots things slowed me down, like nervous,misunderstanding questions, strong AC, noise...etc , I think those will happen again in the CLA, )

    2. Did I comment in the proper way ? Did I comment clear enough for developers?
    (which is the NI examiner), if I don't build any child message class (for saving time),
    just leave the comments to tell how to build them, is that OK? I'm not sure whether I leave enough comments for understanding 

     

    3. I didn't build the timer FGV module, instead, I encapsulate a "local timer" in to controller.lvclass and directly manipulate it in the loop, is that an acceptable method in CLA?

    (I use this method in real world a lot, since I just need a local timer in one loop, I do not need set up another timer FGV to confuse me in the project)

    4.Also the example has a data base module, I do not either. It's more flexible to me let the ancestor class 

    handle the data base then share it to every child class.

    Elevator.zip

  2. I sorta agree.  I mean on the surface I wonder why do I need a VI for every read/write property?  Why can't I just specify what data is public, and if that data is read only, write only, or both.  Then have the property node work without needing to write a tons of VIs, even if the majority of it is done through scripting and templates.

     

    But having a VI for these actions does add other flexibility.  Like if I perform a write I can have that VI do more than just set some data, it can also manipulate the data or perform some other action other than just a bundle by name.

     

    That does make we wonder why NI choose to do what they did, and allow public data accessed through a property node, via a VI call.

     

    Sometimes I do manipulate data members via data access VIs, but only in static dispatch VI.

    And I didn't mean erase this specific method from LVOOP, I just hope LVOOP could provide another way more easily to set up public data members.

    It also makes LVOOP has similar property as other OO language.

    I think it will help LV programmers to communicate other OO language programmers.

  3. Recently I use more and more LVOOP to build my project, the access data through property node helps me a lot.

    I don't need back to project explore to find out where the data member access VI is.

    (Sometimes it takes me lots of time if it's a big project , and most of time just annoying.....)

    And I can easily access the parent data too.

     

    One day suddenly I feel this action treat those data members really similar as the public data.

    To be honest, I don't know any details in computer science opinion how NI made this and what's the

    difference inside between public data and data access through property node.

    As a user , I decide following the concept of duck typing

    "it looks like public data, it acts like public data, and it's public data to me" 

     

    And I wondering, have NI ever consider make LVOOP has the public data declaration like other language?(Like C++ or Java)

    in the class , one is private data cluster, the other one is public data cluster, all the public data could be accessed through

    property node , so that we don't need manually create data member access VI anymore.

    When I select multiple member and create the data member access VI, tones of front/back panel pop out, I had manually save those VI one by one. It's a little bit inconvenient to me, especially when I build multiple classes and each class has multiple public data members.  

     

     

    I know the NI white paper about LVOOP said they didn't decide let the class has public data yet.

    But I really wish LVOOP has such declaration, it makes LVOOP much easy to use and much like other

    traditional OOP language.

     

    Dose anyone has similar idea as mine?

     

  4. Are you using any Call Library Nodes in your code? If they are from NI libraries they are likely ok but anything else is suspect. Badly configured Call Library Nodes or buggy external shared libraries have the potential to create exactly such problems.

     

    And LVOOP has the potential to be extra susceptible to such corruptions, but unless your LabVIEW installation itself got corrupted somehow is by no means the cause of them.

    Sorry, reply it so late.

    No, I didn't use any Call Library Node in this project, it's just a small project for some simple purposes.

     

    And, although my Labview installed correctly, your description remind me that once I indeed messed up

    Labview itself, it was a bug that caused infinite loop popping out the dialog.

    I couldn't press abort bottom, so I had to enforce shutting down labview.

    Seems after this corruption, the LVOOP started crashing Labview.

     

    Would it cause LVOOP unstable too?

     

    Should I recompile all of the programs which LVOOP involved  in?

    Or just methods/properties of LVOOP  would be enough?     

     

    There's another thing I'm worry about , this is a small project, I could easy rewrite LVOOP or even the whole project itself.

    And it also just take a little time to recompile all VIs.

    But once it happen to a large project, will there be any better and quicker solutions to save project?

     

    Thanks : )

  5. One previous article, almost the same situation as mine.

    http://forums.ni.com/t5/LabVIEW/Access-violation-0xC0000005-at-EIP-0x013C7314/td-p/2258546

     

    http://www.ni.com/white-paper/13164/en/#213279_by_Category the Issue # 213279, still unsolved.

    I'm not sure whether anything related with my problem.

     

    Someone helped me test my program with LV2013, and the crash still happened.

    I guess somehow the dynamic property nodes being stuck at the previous address of the pointer,

    so it loaded the wrong value, or crashed since the address of pointer is no more in computer,

    or occupied by other program(maybe OS itself).

     

    I just don't understand, why rename the dynamic dispatch property node could save it , and why this problem happened again and again at different class dynamic dispatch property node.

    post-50257-0-47358400-1412747620.jpg

  6. Thanks the information.  : )

     

    Now I'm using LV2011.

    This situation sometimes not just ouput the wrong data, getting worse, it crashed Labview.

     

    The erroe remained , crahed LV again and again.......even I reboot the computer......

     

    I google the error code(Access Violation, 0xC000005),

    seems not only me but happened everywhere.(Maybe not the same, but very similar.)

    I'll read more articles to see more discussions about it. 

×
×
  • Create New...

Important Information

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