Leaderboard

Because it wouldn't solve anything.Instead of a constant, a user might drop a control. The data may come from an Unflatten From String instantiating the default value of the class. There's not really a good way to bottleneck and say "always call this constructor here". Worse, LV data is live from the moment a control is dropped to be copied/pasted around to controls and constants, which means any constructor function would need to be invoked as soon as the control drops on a panel. But the problem is that you might be editing the class right then... there's no guarantee that such a constructor is runnable at any given moment. Originally, I had this idea that we could run the "default value constructor.vi" when the class gets reserved for running, since there's only one copy of the default value and we could update it once. That idea fell apart because RT needs an independent copy of the default value for every allocation. That left me with the idea of flagging every memory allocation that hasn't yet been properly constructed yet and run it on those memory locations whenever the class gets reserved. That option seems viable, although I am worried about the "I just edited the default value constructor VI, now LV needs to update all the memory locations to the new value" problem. Probably not an issue, but I haven't spent any time working on the default constructor issue in the last couple years... the times when someone has asked for this feature has been very rare compared to other requests. It's really not been a priority to find a solution.

Yeah, I figured the loop iterations were already running as fast as possible (with your standard test string, there are only 8 iterations total anyways right?). I'd forgotten/not noticed that the VI was set to subroutine priority. My suggestion above about chopping the boolean array saves a huge 224 bytes!

Interesting. You're right, add in some transport layer and you have a messaging system. In fact looking at your code I realize I've done exactly this for state machines in the past (the person being the model, and each method is a state). You just turned the problem up on it's head for me, I never thought to apply something like that to this problem. Cool indeed, -m

Since you are waiting for your hardware, this would be a good time to think about your environment and how to trigger. Your environment sounds different than an automated assembly line with controlled lighting and a constant rate. The environment will define how you place your camera, your trigger(s) and possibly require lighting control (additional lighting or screening to prevent glare).

Just a quick observation. Does this design trade memory for speed? If so, would this function ever be used in a memory constrained environment such as RT or FieldPoint? It appears that two copies of the string data (as U8 arrays, one reversed) are created to iterate over. Is the LabVIEW compiler is smart enough to only use one buffer for the U8 array data? What does LabVIEW Profiler tell us about the buffer allocations? I don't have 2009 installed, so I can't play with the examples. If there are two buffer allocations for the U8 array data, would there any difference in performance if the 'end trim' loop were to use the same U8 array and simply index from the end of the array (N-i-1) until a hit was found?

Hello! Currently I am working on the same project (License Plate Reading) and I need some guidance regarding the best way for the plate localization. I read that this could be done with connected component analysis, edge detection or some algorithm to determine the plate location by finding the color space of the plate. I can't find enough resources about connected component analysis in LV, but there are some examples for edge detection... I really don't know which is the best method and the simplest to implement. Any ideas will be appreciated.

This is basically the best thing I've come up with for dealing with references. This could easily be converted to a messaging system because it acts on a command class and not a directly exposed API. Of course person could have its own class hierarchy but for the purposes of this example I didn't go into that. Block Diagram All Commands Call "Do.vi" DO.vi unwraps the In place element structure, and calls the dynamic dispatch instance of "Action.VI" which is in the command hierarchy Methods of "person.lvclass" are called within the individual "Action" VIs MultiCommand can call multiple commands without leaving the in place element structure. here is its block diagram, it is a recursive call Here is the output of this group of calls, it shows the unwrapping/wrapping of the reference I think this is basically the most extensible way to do a by reference API ~Jon DVR Intervace 9p0.zip

Sounds like a good setup. First you will want to hook up the camera and acquire the images automatically using the NI Vision Examples. If you are having trouble, NI tech support should be able to get you to that point. How do you plan to select the ROI automatically. That seems like the difficult part, but I'm sure it's possible.

This sounds like a good project to learn about image acquisition. Christopher Relf (http://lavag.org/user/181-crelf/) has written a book about this subject. I'm sure he would appreciate a plug for his book. It's probably one of many places you could start. http://www.amazon.com/Image-Acquisition-Processing-LabVIEW/dp/0849314801/ref=sr_1_1?ie=UTF8&s=books&qid=1302458393&sr=8-1 http://zone.ni.com/devzone/cda/tut/p/id/2808 Eric

Good project and it is very interesting to me but i am also new to labview and eagerly waiting to see reply from other experienced persons.