-
Posts
158 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by Jacemdom
-
Cannot find how to apply to the LabVIEW 2021 Beta program. There are no products listed there https://www.ni.com/support/beta-program/ Is the program started? How do I apply?
-
Here is very simple VI to read data from Excel using ADO. Excel ADO Query LV8.vi
-
That was before the arrival of malleable VIs. My LV code is now 100% class free 😂😉
-
Just wanted to share this. Not sure if this is the best place but better then nowhere! fvi_lib_array_element_last_get.vim
-
Thanks for the compliment, idiotic was exactly what I was shooting for, but can't speak for rolfk
-
But what if he lives in a tunnel under an aquarium!?
-
If setting the control invisible is aesthetically unacceptable, just put an identical control under the other control.
-
Don't defer panel updates and set slow control (tree) visibility property to false...do update...set to true. Disabled does not work.
-
New version
-
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
-
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.
-
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! It took sometime to see it, but it will now be impossible to back for me! The end of AnotherVIEW to LVOOP...
-
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...
-
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) "a central single VI" 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) "integrating their changes into a central single VI" 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) "a single cluster concept" 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...
-
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:
-
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) 3) The parent implementations would be open and visible to the child implementations. You'd lose the independence of separating implementation from interface. 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) We do need to make the process of creating accessor VIs simpler. 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?
-
QUOTE(Jacemdom @ May 21 2007, 11:48 AM) Delivery date re-revised to 1 to 20 days from now...
-
Salut. Is it possible to rename a lvclass inside a lvlib programmatically?
-
Run-time engine size
Jacemdom replied to Jacemdom's topic in Application Builder, Installers and code distribution
QUOTE(Michael_Aivaliotis @ May 22 2007, 08:20 PM) 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? -
Run-time engine size
Jacemdom replied to Jacemdom's topic in Application Builder, Installers and code distribution
Does someone know what is the difference between the "Web Browser version" LVRunTimeEng.exe 8.0.1 (24MB) and the "Runtime Engine" folder (20MB) included in the complete package 8.0.1 (87MB)? -
Run-time engine size
Jacemdom replied to Jacemdom's topic in Application Builder, Installers and code distribution
QUOTE(chrisdavis @ May 21 2007, 09:14 PM) 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. -
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