Jump to content

Jacemdom

Members
  • Posts

    158
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Jacemdom

  1.  

    21 hours ago, drjdpowell said:

    Indexing tunnels (conditional or not) follow a preallocation strategy of filling a larger-than-initially-needed array (later cutting the unneeded elements), while the “Build Array” primitive allocates a new array of exactly the right size on each iteration.  So there is a lot fewer calls to the memory manager with an indexing tunnel.

    Was aware of this but was not aware that this was also the case in initialize/replace scenarios.

    More info on the subject here http://forums.ni.com/t5/LabVIEW/Why-is-indexing-conditional-tunnel-3x-faster-than-shift/m-p/3570173#M999382

    Thanks :)

  2. LabVIEW resets enum values all over my project. This of course leads to all sorts of nasty bugs.

    I was first able to track this down to certain types of modifications I would make to the enum value list in the typedef; LabVIEW would get confused, and then reset all enums of that type in the project. However, I've also seen cases where there's no clear reason for this global enum reset, or where LabVIEW would only perform this reset in some locations.

    I also suffered from enum reset issues. I developed some update rules to avoids such issues.

    Always do one action on one item at a time and apply modifications after each update. Example :

    1- Change name #1

    2- Apply to all

    3- Change order #1 to #3

    4- Apply to all

    5- Delete #5

    6- Apply to all

    7- Add new item before #4

    8- Apply all

  3. Hello,

    A tool for those who make extensive use of enum type definitions.

    infoEnum is a donations supported, LabVIEW VI add-on built to help LabVIEW software designers who build complex softwares using enum type definitions to control the different events and actions occurring in the software. It allows to see which enum values are used were and also find the unused ones easily.

    Details here.

    products_infoenum_guide_en.gif

  4. Yes, LabVOOP is my baby, and it can be easy for me to get defensive about design decisions.

    If LVOOP is your baby then i must now admit that you are a pretty good father and i would love to meet the mother!

    What seemed to be an ugly baby when i first saw it, as grown into a remarkable and attractive young programming tool! wub.gif

    It took sometime to see it, but it will now be impossible to back for me! ohmy.gif

    The end of AnotherVIEW to LVOOP...worshippy.gif

    • Like 1
  5. Part 2 in 0.1 to 74 days...

    I will rephrase that to "Part 2 in 0.1 to 74 VENUS days"...

    When i wrote this analysis it was mostly based on theorethical knowledge...part 2 will be written after having added more practical knowledge using LVOOP...

    So i have now approximately 47 years left to come up with part 2...

  6. Reply part 1

    QUOTE(Aristos Queue @ Aug 28 2007, 09:24 PM)

    Live/Face to face = multiple communication channels (visual, sound etc...) at an infinite refresh rate

    eMails/Forums = one communication channel (visual) with at best an average practical refresh rate of 0.0016Hz (10 minutes from send to response)

    In this thread, the average refresh rate is a magnificient 0.000001509414Hz or 184.030 Hours...

    It is slower...but as its advantages, like letting things settle down and allowing the thoughts to develop at their pace. It is also less stressful, as slower acquisitions rates puts less stress on the hardware...

    QUOTE(Aristos Queue @ Aug 28 2007, 09:24 PM)

    an expected central architect that knows everything"

    AnotherVIEW does not require a central architect that knows everything.

    QUOTE(Aristos Queue @ Aug 28 2007, 09:24 PM)

    AnotherVIEW does not require a central single VI.

    QUOTE(Aristos Queue @ Aug 28 2007, 09:24 PM)

    "the central architect to do all the implementing"

    AnotherVIEW does not require a central architect to do all the implementing.

    QUOTE(Aristos Queue @ Aug 28 2007, 09:24 PM)

    AnotherVIEW does not require to integrate changes into a central single VI.

    QUOTE(Aristos Queue @ Aug 28 2007, 09:24 PM)

    "to limit the hierarchy extension only to those who can edit the hiearchy file"

    AnotherVIEW does not require to limit the hierarchy extension only to those who can edit the hiearchy file.

    QUOTE(Aristos Queue @ Aug 28 2007, 09:24 PM)

    AnotherVIEW is not a single cluster concept.

    QUOTE(Aristos Queue @ Aug 28 2007, 09:24 PM)

    "Tying all the classes together"

    AnotherVIEW does not require tying all the classes together.

    QUOTE(Aristos Queue @ Aug 28 2007, 09:24 PM)

    "children being designed such that they depend upon a particular implementation of the parent"

    AnotherVIEW does not require children being designed such that they depend upon a particular implementation of the parent.

    Part 2 in 0.1 to 74 days...

  7. Salut.

    LV 8.5 personnal favorite

    It is possible to create a project of an entire code repositery (librairies and projects) and simply click view caller and subvis on an item to see where it is used and what it uses. Combine with the auto-update folder option, it is possible to open that project to see what will be the repercussion of a change.

    :thumbup:

  8. QUOTE(Aristos Queue @ May 15 2007, 12:00 AM)

    What if development was to be organized in a way that there would be a central or master architect on every project that would design the overall architecture of the software and design the clusters at the same time, as there is probably already a lead architect in organized development teams.

    This architecture would basically consist of a hierarchy of domains and associated actions to be performed on them, by entities of particulat natures. It is believed that this is the basic of all computer programming, performing actions (functions) on data. This data can be organized in a hierarchical way and a list of actions can be created for each of them, thus designing the entire app.

    A standard naming scheme was created to support this idea, and at the same time added some untaught of benefits, like never having a VI in memory with the same name, as no 2 VIs can have the same name in this scheme as they would do the same thing. It also allows to verify that the problem is coherently solved by the fact that if a function name cannot be found, it is because: 1- there is a missing domain or 2- the frontier/s between some domains is/are not where it/they should be or 3- A function does more or less of what it is supposed to do (a function called something like Acquire.VI that also saves the acquisition data to file). It also allows to automatically include dynamic called VIs in a build as they are associated with a dynamic nature.

    The nomenclature of what are called entities (Vis, TD, Globals etc.) consists of 3 basic parts:

    1- The nature: What is it? (TD=Type definition, GLB=Global, FVI=Flow VI, DVI=Dynamic, UVI=UI VI etc.)

    2- The domain : On what does it act? Example: The function generator's(FG) power level, the oscilloscope scale

    3- The action: What does it do? Set the scale, set the level etc.

    This translates into FVI_FG_Power_Level_Set and FVI_Oscilloscope_Scale_Set. In this implementation the 3 parts are separated by underscores, but any convention can be used, as long as it is a standard among a particular team.

    So the basic job of the principal architect would consist of generating the overall domain architecture and then concurrent development could start.

    He would also be responsible to update those clusters as they would be directly linked to the overall design and it would serve the purpose of making sure that he knows everything that is going on at that level. The cluster would also be constructed in a hierarchy of type definitions, allowing work to be done on sub-domains (child classes) if necessary. Creating all the data definition/containers needed by a software is not a long task compared to the creation of functions, that is in LabVIEW (dropping a control in a cluster). The archietect could also decide to leave a particular domain TD empty to let someone else decide of the particular data needed by that domain. As the data structures are all created during the design phase, concurrent development of code could then proceed and mainly consist of function creation using the already defined inputs and outputs.

    This Methodology is currently under use and as been under development for the last 7 years. It as proved to clarify, accelerate and enhance the development, while keeping inline with the original dataflow implementation. The functionalities discussed in AnotherVIEW could allow to push this way even further.

    QUOTE(Aristos Queue @ May 15 2007, 12:00 AM)

    2) You couldn't dynamically load classes -- every descendant would always be in memory.

    As the proposed approach separates clearly data from functions and that the data cluster type def is the structural equivalent of a class, this means that yes all classes would be in memory, but what would that memory cost be, if all data contained mainly consisted of null/empty values? It would basically only leave the clusters definitions in memory, would that be significant in todays multi gigabytes of ram systems, even in multi megabytes systems? You could still load the functions dynamically, significantly reducing the memory usage, as the majority of bytes reside in function definitions vs data container(TD) definitions.

    QUOTE(Aristos Queue @ May 15 2007, 12:00 AM)

    Is this valid considering that in dataflow the data is naturally separated from the functions, in contrast as in OO design where methods and properties are merged in one object?

    QUOTE(Aristos Queue @ May 15 2007, 12:00 AM)

    As far as "all data would be public"... you are hereby banned from using the word "encapsulation" ever again. The disadvantages of public data and the advantages of private data have been so thoroughly talked about in so many forums I'm not going to go into them here. We do need to make the process of creating accessor VIs simpler. But making public data would be a disservice in the extreme to developers

    As stated in the document,

    QUOTE(AnotherVIEW v2)

    All data would be public by
    default
    and it could be possible to restrict access to a certain elements in the Hierarchy by right-clicking on it and selecting restrict access to those VI's and consequently the unbundle and bundle function would only allow this data to be accessed when used in those VI's. More complex behavior could be added directly in the configuration of the "eTD" used in conjunction with "eBundle" and "eUnbundle".

    Therefore creating private data.

    QUOTE(Aristos Queue @ May 15 2007, 12:00 AM)

    Is the added debugging complexity also being worked on, specially probing, that I believe to be a drawback of the chosen implementation? I believe that the ability to follow and look into the wire as been one of the main strength of LabVIEW and loosing that decelerates my ability to write working tested code.

    QUOTE(Aristos Queue @ May 15 2007, 12:00 AM)

    Something like that structure is being toyed with for getting classes onto targets that have to have fully preallocated data -- every object on those targets would be a composite of fields such that the whole was capable of containing all possible descendants (obviously no dynamic loading on those platforms).

    Does this mean that standardizing everything to this idea could simplify the architecture of LabVIEW itself? Could you have dynamic loading on those platforms, if dynamic loading only consisted of dynamically loading functions?

  9. QUOTE(Michael_Aivaliotis @ May 22 2007, 08:20 PM)

    I could spend the time and figure it out, but you can also do this yourself. Just download both run-times. Extract them and look at the folder contents. You will see several clearly labeled msi install files for the full runtime which are related to various add-on features.

    To rephrase the prior question,

    Does someone know what is the difference between the "Web Browser" version, that cannot be fully unpacked with winzip or winrar, and the contents of the "Runtime Engine" folder that is extracted from the complete package and with the path being LabVIEW_8.0.1_Runtime_Engine.exe\Products\Runtime Engine\lv80rte?

  10. QUOTE(chrisdavis @ May 21 2007, 09:14 PM)

    while it is true that the full install is 90 mb zipped, you may want to look at all of the msi files that are packaged together in the default runtime engine to see if you can weed out what you want. i.e. the LabView 8.2.1 runtime engine itself is only 25 MB (acceptable by your standards) and it may serve your needs.

    After all for a MS Office add on you probably don't need TDMS support, data socket support, etc. You'll have to play around with what gets installed, but if you try you may find everything you need for less than the 20ish MB.

    And then a dim light at the end of the tunnel is seen...maybe its the end of the tunnel or...the train!

    Will look into it and post back the results when available.

  11. Salut.

    Anyone knows if NI is planning on reducing the run-time engine size? Currently working on a software that is planned to be released commercially (MS Office add-on) for the masses and the engine size is a big drawback. Don't want to advertize "get this little 5MB tool, but for it to work you need to download this 90MB engine, just like Java, but a lot bigger". ActiveX callbacks are not available before 7.0, so it will probably be the chosen version. It is twice as big as 6.0.2, but 4.5 times smaller than 8.2 and the same size as te .NET framework that a lot of people have downloaded. So 20 MB is believed to be acceptable by the majority, but not 90MB.

    Just had a brief moment of a possibility to go down to 6.0.2 using event queus instead of callbacks, but they cannot see the events needed...also noticed that i am used to the auto tool...i am sitting there hovering the terminals waiting for the tool to change in 6.0.2...so back to 7.0...

    http://forums.lavag.org/index.php?act=attach&type=post&id=5908

×
×
  • Create New...

Important Information

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