Steve Watts

Our own, LCOD based statemachine and unnamed but packaged queue. Covers 99% of our needs, what others call actors, we tend to call services and are only employed when background stuff is needed. Each service will be based on the template above.

Thanks all for your responses. If I had the time and patience I think Yair's answer is most intriguing on a variety of levels. I love the idea of a custom palette VI.

Hmmm, sorry about my silence, I don't appear to be getting notifications. Many thanks for your answers. The use case comes from having colour coded VIs for specific functions, going from the project is too slow. I didn't think of express VIs, this might give me the immediacy I'm after. (I'm after 2-3 clicks with no navigation from the block diagram ideally) A quick drop short-cut could also work nice, although having such things in the function pallette is my preferred option. The issue with a tool is similar to my issue with coming from the project, it means navigating away from the block diagram. I really wasn't expecting this to be so tricky. It's interesting the things that catch you out!

Hi There, this is my first in a while. I started with a pretty simple requirement. I want to drop a variety of template VIs (VIT) onto my block diagram and I want them to act as VITs should do (i.e. come up as an untitled vi to be saved) I want this to happen from the function Palette, because this is where I do most of my work. So blockage #1 is that VITs don't register on the palette Being sneaky I thought I'd make a VI and embed the VIT in it, calling it from the function palette with the Place VI contents (merge VI to us old hands) Blockage #2 is that it drops it on the block diagram as a VIT!!!! :angry: :angry: So it appears my last hope is to do some LabVIEW scripting (I can generate it fine using my standard component building tool), but I still want to be able to drop a VIT off my function palette. So the question is can I drop a vi from my function palette that detects it's been dropped and chucks up a template vi to be saved. It all started so simple, but now I just want to beat the problem down (I hate being restricted) Lots of Love Steve

Think I'll probably only be drinking (bit late UK time for eating for me!!), thanks for organising Steve Watts

Dual monitors work best for me, 1 set to 1280x1024 for the block diagram (which generally is big enough, I can only fit so much logic in my head). The user interface is on the other screen and usually set to 1024x768. Most customers/industrial PC's can now handle this.

You can get the .dbc file output to an XML format and this is then fairly easy to read in LV. I don't know specifically how this is done from the Vector db, I think it's just a menu option.

It must be harder to program like that, than to do it properly! :laugh:

OK, The drivers I have consist of single calls to a DLL, there are in excess of 40 seperate VI's with little or no descriptive documentation (i.e. how to use type documents). The worst of these has 2 inputs and 20 outputs. All the examples concentrate on the complex capabilities of the card. All I want to do is output a 32 bit word to one channel and receive it on another!!!! I believe that drivers should be designed to simply do the simple things, and gradually get more complex as the tasks get more complex. I've seen some excellent equipment completely undermined by drivers that have been written by someone who has no experience in LabVIEW.

I'm having enormous fun trying to decipher some ARINC drivers. Too cheer me up what's the worse set of "Professional Drivers" you've used and what made them bad? :headbang:

We nearly always give the source code. The only time I got a little twitchy was when a joint project with a competitor was proposed. Nearly lost my nerve!. Our point of view is that we are designers not source code salesmen.