Jacemdom

QUOTE(Jacemdom @ May 17 2007, 01:24 PM) Delivery date revised to 1 to 10 days from now...

QUOTE(Aristos Queue @ May 17 2007, 04:17 PM) Those 2 points were the ones to be challenged and the arguments were right on target.

QUOTE(Aristos Queue @ May 15 2007, 12:00 AM) Reply under construction...estimated delivery date 1 to 5 days...

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 http://tinyurl.com/ys7hof HTML http://tinyurl.com/2698ob

QUOTE(robijn @ May 9 2007, 05:08 PM) If you have a single VI to set the angle of that stepper motor, it could remember the last state in itself (shift register) and nobody could corrupt it. Sometimes other shareable "containers" of data are required by parallel processes, but i believe that each situation needs to be considered and that no one way of doing things will solve everything, like putting everything into objects. So for this issue i would either: 1- Query the axis to know where it is before sending another command or 2- Store that value in the a set angle VI in an unitialized shift register

QUOTE(yen @ May 9 2007, 03:52 PM) To stay by value is the actual intention of this exploration...

QUOTE(robijn @ May 9 2007, 11:21 AM) Hierarchy of classes = Hierarchy of clusters QUOTE(robijn @ May 9 2007, 11:21 AM) but only by guaranteeing some things about the life of an object (constructor, destructor, consistency of data) Constructor, destructor and life expectancy, are irrelevant concepts to the dataflow paradigm. More details can be found in the decisions behind the design document. Data exists as long as it is needed. QUOTE(robijn @ May 9 2007, 11:21 AM) Seeing your list of references you must have considered this, so my question is why do you not consider this a problem ? Could you come up with a concrete example of the problem you are talking about?

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 ftp://all:Password1@ftp.cephom.ca/AnotherVIEW.htm

Salut. I have been using an home made deploying tool since LabVIEW 6.x. Somewhere along the deployment, the tool does a save as on the source code of the deployed software. The deployment tool and the deployment software are both link to a library of VIs. In LV6 and 7, i had to rename all the VIs used by the deployment tool in order for the save as to work because of the unique name in memory rules of those versions. In LV8 i did not have to do this because my deployment tool was running in the "NI.LV.Dialog" application instance and the save as was working. Now in LV8.2, it seems that it does not work anymore, i get an error stating that the VI cannot be saved in the current state. And i get this error on the shared VIs. Is there a work around, or will i have to revert to doing a mass duplicate save as for the deployment tool VIs?

I suggest you read that entire link and all the links included in it. It also includes the examples that BigBadWally talked about. LabVIEW Object-Oriented Programming FAQ

http://hannahsmac.magnet.fsu.edu/labview/LVOptionsList.html

I believe the LLB will be seen as one file...you will lose the possibility to submit changes to only one VI...you will always have to check out the entire LLB and submit the entire LLB... I advise to use LLBs just as a quick code package to share code...i don't believe ther is a need to develop using LLBs anymore...even for plugin architetctures, i would suggest to use LLBs just for the deployment of the plugin and not in the source files...

app instances... :thumbup: app instances... app instances... :laugh: app instances... app instances... :thumbup: app instances... app instances... :laugh: app instances... app instances... :thumbup: app instances... app instances... emotions prohibited app instances... emotions prohibited app instances... emotions prohibited app instances... emotions prohibited app instances... emotions prohibited app instances... emotions prohibited app instances... emotions prohibited app instances... emotions prohibited app instances... emotions prohibited app instances... emotions prohibited app instances... emotions prohibited app instances... emotions prohibited app instances... emotions prohibited app instances... emotions prohibited app instances... emotions prohibited Oooh That's the way,(aha aha) I like it (aha aha) That's the way, (aha aha) I like it (aha aha) That's the way, (aha aha) I like it (aha aha) That's the way, (aha aha) I like it (aha aha)

Does not work...explorer opens and i have a box with a little media icon on the top left of it...

Like 10 000 columbian pesos!!!

I just encountered a problem that i had to solve using recursion... I'm working on automaticaly creating a project from a folder hierarchy. I had to think a little bit on what data would i need to do the recursion or stack and then it was as easy as putting a "do what i want while array not empty loop". At each iteration i just use the delete array that automatically gives me the last element by default (wich is feature that i like a lot) and add elements to the stack. I believe that the majority of recursive problems can be solved by that method. Even if there was the possibility to automatically use recursion with VIs, meaning basically an automatic stack creation, is all that effort really needed just to replace a sequence of a couple of clicks (30 seconds) create while loop, create shift register, add delete array, add build array...the rest is needed in both implementations i believe. If someone does a lot of recursion, he could create a code snippet (i don't remember the exact name in LV) on his pallet with a while loop with shift register and delete array...

On a conceptual level need for recursion yes, in my present quest no. I

Did you install the NI-IMAQ drivers on the target PC?

maybe the basics 1 combined with the instrument control could fit your needs as your mass flow controller is probably GPIB or Serial. A lot of instruments are not directly supported by NI, but once you have done a couple with GPIB and Serial it can become easy to create your own "drivers". The majority of instruments i encountered were well documented and esay to interface. Example : You send POW:CHAN1 over the GPIB bus in order to receive the POWer from CHANnel1...i believe this is the SCPI standard...

1) In the beginning of my LabVIEW life, i took the basic and advanced classes of the time and i appreciated the kickstart. This is whar i believe can be obtain from any "corporate" accelerated 2-3 days courses. It opens all the doors and makes you put one foot in each. You then decide on your own or based on the problems to be solved wich rooms you will spend more time in and get to know. 2) I don't believe that the certification adds any value for the moment...maybe in the future...in Canada there are many experienced LabVIEW developpers but only one LabVIEW certified architect! He used to brag about the fact that he was the only one. One of is former employer said to me that he was the only certified architect in canada and i asked them : Does this mean that he is the best developper in Canada or that he is the only one who sees value in getting certified? I don't see a lot CLA or CLD references... 3) It will kickstart you in the LabVIEW and NI Hardware. You will learn the basics of using LabVIEW with NI hardware, wich are really integrated together, wich is a feature that can make your experience with NI products more enjoyable, but as the drawback of not preparing you in case you will not use their hardware. Their courses are not made on a learn a new language basis, but more on a learn to acquire using LabVIEW and NI hardware basis wich as its advantages and disadvantages. Overall i cannot recommend or not the NI training, as they are really dependant on the trainer you will get and i don't know all of them.

I don't believe that the solution to your problems can be resolved with software...It looks more like a "dispcipline/responsability/maturity" issue that can only be resolved by a supervisor, or the supervisor's supervisor, or the supervisor's supervisor's supervisor...and if this does not fix the problem, then

Could this be simplified by saying : You don't see any advantages of using recursion vs stacked iterative implementation, and there could even be disadvantages? I never heard of the Fibonnacci numbers before this topic...i am more interested at the recursion and stacked iterative implementation concepts regarding specifically LV.

Could be to avoid names collisons in LV memory? I use prefixes all the time even tough when there is a large number of VIs i put them in a subfolder, to avoid same name issues in LV, but also in my library. Everyone as a unique name and that way everyone is recognizable by it.