Leaderboard

Hi, I posted a new blog post on worker pool design pattern to expressionflow. Worker pool - a design pattern for palalle task execution in LabVIEW if the link above doesn't work, please copy paste the address below to your browser: expressionflow.com/2009/11/04/worker-pool/ Cheers Tomi

As for the error you have to at first extract geometry from the object (using Drawable property) and then cast it down to SceneMesh. But vertices you get this way will be always the same as they are in reference to owners frame. In order to get real position of the vertex you have to multiply it by objects transformation matrix (easy to get with property). If the object is a child of another object (which could be a child of another object) you have to go up to the root of the tree multiplying by subsequent transformation matrices.

It sounds like you also have a good case for the use of a Hardware Abstraction Layer (HAL) as discussed in the 2011 Developer Day presentation here. This covers some concepts regarding removal/substitution/inclusion of instrumentation components using LVOOP techniques. I found it quite educational and informative. All of the example code slides and scripts are there for download. The situation you are coding for sounds like the conceptual "ideal" poster child for OOP techniques. The architecture you use needs to handle the variability of hardware, tested units, operators, etc. that occur from maintenance/growth of long time use. Jason

I'll throw out one idea to address the unknown number engines running. Tomi wrote about a Worker Pool here. http://lavag.org/topic/11362-worker-pool/page__p__68339__hl__worker__fromsearch__1#entry68339 I did my own version before reading how to do it better and used a control that I could write the target class (Child of generic "Do Something" class) to control its character. Handling various hardware interfaces in a "instantly infinately configurable" manner is a question above my pay-grade (free). Preventing conflicts between the various Workers accessing that I/O is something I'll sit-back and wait for others to advise. Ben Can we put restratints of any kind on the I/O demands or do we we have to allow for high throughput performance? WIll hardware be in the same area, room building city...? Ben

You probably don't have VI scripting enabled in the labview enviornment. do a quick google search and it should tell you how to do it depending on the version of labview you are using (it requires a download pre 2010 i believe) a couple of pointers for your script, load all the VI references first before modifying. sometimes save dialogs will come up if you do not do it this way as they enter/leave memory. I would modifiy the code to do the following: one for loop to load the VIs (get the VI reference) one for loop to modify (disconnect from library, then test if it is a control, if it is, set it to standard control) one for loop to save them all to a new path. one more for loop to simple "save" them (do not put in a path) you have to double save because you are moving subVI dependencies and that is important to the loaded VIs. So even though you are saving the VI you modified, you have to resave to account for repathing. Do not save copies. The references will get all out of whack with cross links if you try to load your new copy VIs. just backup your work first in case something gets hosed. one more thing, when you get all dependencies in the library, feed it the constant string "VI" you don't have to for this particular .lvlib since there are only VIs in it, but if there was a virtual folder or something else it would break your script. ~Jon I'd modify it for you but I can't upload code right now. Its probably better in the long run that you learn to do it anyway. ~Jon

You can disconnect a VI from its owning library with the "disconnectFromLibrary" method. As far as disconnecting all the typedefs from a library of VIs, I'm not aware of any way to do this without scripting. The best way to do this would be to 1. open the library reference (I prefer to open a VI in the library, and use a "library" property node read.) 2. Invoke node on library "Get All Decedents" and get the Control VIs from this 3. Read the "VI Reference" in a for loop of the decedent results. 4. Set the "VI Control Type" property to control. 5. Save each VI with an invoke node save. 6. While you are at it get all the standard VIs and "disconnectFromLibrary" method. 7. Save standard VIs 8. Save the library. That will disconnect all typedefs by saving them as a standard control instead of manually disconnecting them in each VI (that is a huge pain, I wouldn't even try.) the disconnectFromLibrary method will take them all outside of the .lvlib as well. Before you try any of this, make sure you back everything up, including the projects that use this library. Additionally I would run your script from the same project instance as the one that you use these VIs in. Sometimes Labview gets confused otherwise when you reopen the project. ~Jon