Leaderboard

I just discovered by accident that if you copy a primitive VI (like add) then edit the icon of a VI and paste , you get the icon of the primitive? I am sure a lot of you already knew this, but I thought I would share, because it was a nice surprise to me. Now it will be easier to create new icons. Fab

I've been pretty scarce for the last 3-4 months so I just found this thread. If you're already using LapDog for messaging why not roll your own actors from scratch? They're not terribly difficult to write. LapDog doesn't care about the nature of message senders/receivers, nor does it care what kind of message is sent. If you want to use the command pattern and actors, create your own "Command" class as a child of "Message," give it an "Execute" method, and subclass that for each unique command. (I've been thinking about creating a LapDog.Actor package, but to be honest I haven't needed to use actors much.) In fact, your code may very well be simpler in the long run if you create your own actors. The downside of creating and using prebuilt frameworks is the framework needs to be flexible enough to handle a wide range of user requirements. Adding flexiblity requires indirection, which in turn adds complexity. If you have a lot of actors to write then you could create your own Actor superclass with a Launch method and subclass it for your concrete actors. I wouldn't do this. It's giving the business components (motor controller, etc.) responsibility for deciding how the data is displayed. Display is the responsibility of the UI code. Since the UI doesn't know what business component (bc) is on the other end of the queues it receives, you could have the UI send a Request_ID message to each component so it can map each bc's messages to the proper UI display. Then the UI decides what controls/indicators to show based on the response from the bc. Or, what I might do is create a BC_Token class containing a MessageQueue class for sending messages to the bc and a BC_Info class containing information about the bc at the other end of the queue. Your "initialization" code is going to be figuring out which concrete classes should be associated with each channel and creating the appropriate objects. During that process the initialization code would also create an appropriate info object for each bc it's sending to the UI. It packages the two things together in a BC_Token object and sends it to the UI as a message.

Here are a couple of VIs I wrote for a tool that used the MCL. The first iterates over the MCL ItemNames to determine the max width. It looks at each cell's formatting to see if font customization have been made. Use the output to set the widths (AKA autofit width). MCL Get Max Col Widths.vi The second colors the rows with alternate colors. MCL Set RowColors.vi The assumption is that you have already deferred panel updates. These could probably be optimized, but they worked for my project.

The UI lock is indeed weird. After you unregister an event registration refnum, I'm not sure if you're supposed to be able to reuse it. I'm under the impression the way one usually handles dynamically registering/unregistering events is by using null refnums for unregistration: Dynamic Registration LV10.vi

Victory! That output terminal will not be needed as of LV 2012. There was a (bug / unimplemented optimization -- depends upon your view) that made LV add a copy at certain upcast coercion dots. This compiler (fix / upgrade) will have performance benefits for a wide range of LVOOP applications. The change was implemented months ago, so this API doesn't get credit for finding the issue, but the compiler team verified your VIs do benefit from the change. I would therefore recommend not putting it into the API as removing the terminal is a possible mutation issue, and not having the output terminal for a read-only operation is a much better API overall.

You're not the first person to suggest we look alike...

You can also drag and drop the icon of one vi to another vi without copy/paste. No keystrokes required... (front panel to front panel)

We have deployed quite a few Object-Oriented applications on RT on cRIOs now. We did encounter some serious issues early on (see below for what I can remember off the top of my head) but now that we know how to work around these our applications work great (and within the confines of what we do working with objects on RT is very easy to do). Relevant problems and solutions: 1) Performance issue accessing objects within another object. We had a set of individual objects to do specific things and added these objects as attributes inside a larger collection class, using accessor methods to pull off each of these, and then performing operations as appropriate. (That is, one object was a collection of other objects.) Our tests showed that in this circumstance (lots of objects within another object) the execution time to access an object in the collection was prohibitively lengthy for our RT applications. We improved performance (and the API was easier anyway) by putting the objects inside a cluster instead, which is OK since this was strictly a collection and had no behavior itself. (Note that accessor methods otherwise seem to work just fine.) [This is an issue in LabVIEW 2010. We haven't tested it in LabVIEW 2011. I do not know what the root cause of this issue is.] 2) Also in LabVIEW 2010, we encountered many issues with builds. The build times were extraordinarily lengthy and more often than not failed (meaning it would complete on the same code maybe one out of five times). National Instruments helped us around this issue (thanks, NI!) in a couple ways, but most importantly we learned that we could avoid these issues by minimizing source interdependencies in our code. We began implementing interfaces (OK, not Java-style interfaces but our own version of interfaces), which dramatically reduced interdependencies between different sections of our code. This had a huge impact and we haven't had a problem with a build in many months now. (The use of interfaces results in a better application design in any case!) 3) For the record, we also encountered issues with debugging in the earliest release on RT (stepping into a dynamic dispatch VI didn't always work correctly) but we haven't seen this in LabVIEW 2010. 4) Also for the record, the RTETT traces do not show which dynamic dispatch VI is running (as of LabVIEW 2010). This hasn't been a big problem for us in practice. Now that we have "conquered" these issues, working with objects in RT is typically a quite pleasant experience for us. So, go for it, but use interfaces! [i remembered that I had started a similar topic very nearly two years ago here: http://lavag.org/topic/11928-lvoop-on-rt-stories-from-the-field/page__hl__%2Bobjects+%2Bon+%2Breal-time__fromsearch__1, The only comment there is my initial comment.]

I finally decided to write a real application using OO on RT. I am wondering what experiences others who have tried this have had. Maybe we can help each other avoid the same issues? I did write a couple small test projects using OO on RT and found that they worked fine, albeit a little more slowly than the comparable cluster-based implementation (which is what I eventually used for my previous actual subsystem code). Accordingly, I decided to implement the next subsystem in OO on RT, hoping that this would allow me to take advantage of 1) reusable code (common to subsystems), 2) object-oriented patterns (State Pattern, particularly) and 3) ownership of data and methods in a class (to take advantage of OO file management and structure, which makes the code much easier to debug and maintain). I found writing the code wasn't markedly different from working on My Computer (not surprisingly). I did encounter a number of bugs with the project and file management, but these weren't huge and probably are platform independent. In the end I had an application that did indeed offer me the advantages I listed above. When I attempted to deploy the code, though, I encountered a number of pitfalls and bugs, some of which I think are major. (I am awaiting resolution from NI on resolutions of some of these issues, so the jury is open on them. Maybe they have something to do with the particular code I wrote, although I can't see why.) One note. A test I ran with a trivial implementation of the State Pattern showed that writing a (featherweight) object to another--at least in this instance--using an accessor method takes > 140 us (on a cRIO 9074). So... if you use a model where you pluck off an object, have it do something, and then put it back in your model (which is a common thing to do!) and you don't have this at a level where this is private data, you can only do about three of these actions each millisecond. In my case I had a class that no longer had methods but was just present for hierarchical organization, but I had to get its member objects with accessor methods (since I did this inside a method belonging to a higher-level class), and I did this a lot. I found it expedient to convert this class to a cluster and performance dramatically improved. So... maybe someone else will find it helpful to think carefully about where to use accessor methods for objects within objects. Anyway, if anyone has tried OO on RT and is willing to share what they have learned (maybe some workarounds for issues encountered), that could be helpful.

Wow I'm a little ashamed to say that I've always done a print screen, pasted my whole screen into Mspaint, then selected just the primative I wanted, copied and then pasted into the icon editor. Also I believe that Flickr allows you to search for images in the public domain, or royalty free. The site is massivly slow for me at the moment so I can't check but I think that's where I saw that feature.

You can paste just about anything into the icon editor and it'll try to bitmap it: That's a great tip - but remember to respect the copyright of the images you find

Another icon trick which might be well known ... if you go into Google Images search and type in 32x32 png (size: icon) you will get all the icons you can possibly need. You can narrow the search for specifics (stop, go, etc) Right click, copy and paste it in your icon editor.

Ah ha! If my verbiage didn't make it obvious, I thought it was also somewhere else. You can see how often I've needed one. It does look much better in Icon view (which is what I use anyway, now that I pay attention to what I'm saying). The reorganization does help, either way.

You could use the following code to set all cells of mclb to the same format. This not a "clear formatting" method, but it works and it's efficient. Regards, Olivier FormatAllCells.vi