05-09-2007 08:58 AM
Salut.
Here is an exploration of an alternative/complimentary direction to LVOOP that can be chosen to enhance/accelerate the code creation and manageability in LabVIEW. I willingly posted this on Info-LabVIEW, LAVA and NI's forums, in order to reach the largest base of opinions possible. I propose that everyone who is a member of LAVA post's there, to try and limit the redundancy. I did not want to post it only on LAVA and go to Info-LabVIEW and NI's forum to say "Go see this on LAVA" because not everyone wants to become a member of LAVA and I would like to get their opinions to.
I plan on gathering all the information and publishing it on an FTP site.
MS Word version
ftp://all:Password1@ftp.cephom.ca/AnotherVIEW.doc
Browser version
05-09-2007 02:38 PM
05-09-2007 02:49 PM
05-09-2007 04:09 PM
05-13-2007 03:16 PM
Made an update to the document. Between ******* below
5.3.3.3 AnotherVIEW Implementation
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”.
*******The data that would need to be accessed by parallel process just needs to be “encapsulated” in a functional global variable. A software could consist of basically 2 main hierarchical clusters, 1 for the dataflow in a wire, and the other in a global for parallel processes that need access to it if required.*******
Also tiny links for those who were not able to use the previous hyperlinks
MS-Word
HTML