Mike Ashe

Doesn't sound mean to me, sounds like Joe has a sense of humor about himself, which is rather healthy.

Both. I did two, I delegated two, the driver portion I mean. Hmmm, thats what I was told about interfacing LabVIEW directly to the VME bus from a Xycom PC for my first LabVIEW project in the early 90's. (LV 2.5.2) I didn't believe the NI rep, so I just went ahead and did it, rather quickly too. It involved writing about 80 CINs, but it turned out that that was a very useful skill to have. A short while later I wanted to add Windows help files to the same project and call that from LabVIEW and was told the same thing, impossible, so I did that too, at which point the NI rep stopped telling me what couldn't be done and started asking me to lecture at the local users group meetings. Good quess, but wrong. I suspected the same thing and told the Harris rep. I had quite a long talk with the project manager. No occurrences, etc. They added a menu item to the VI execution system options to run in the POSIX equivalent of Ring 0 and when you selected that option you activated a menu to pick which interrupt (if any) to hook to. NI supplied LV source under NDA (the code, not the fact that they supplied it, so its okay to talk about) and a little bit of programmer help to tweak the LV execution stack. When interrupt X fired LV stopped whatever else it was doing (unless it was servicing a higher priority interrupt), pushed the current setup on the stack, then placed the ISR VI on the top of the stack and executed it immediately. VIs designated as an ISR had some limitations, but nothing more than what you limit a C ISR from doing. They also had some extra hardware memory privileges in order to function as an ISR. What it did, it did quickly and got out, at which point LV returned to application level. Now at this point he did not explain whether LV shifted itself from Ring 3 to 0 and back to 3 or if there were in fact 2 execution engines, one running entirely in Ring 0, etc. Forgive me, I'm mixing system metaphors, this was a POSIX system.The point is that the architecture was simple, robust, worked well and was relied upon to do mission critical testing. I was told NI mixed and matched different layers of the LV system, taking the compiler layer from Mac and the hardware abstraction upper layers from the PC and producing, with some tweaks, something that worked pretty quickly on the Harris powerPC based hardware. I was told that it wasn't that big of a deal to do. To quote Yoda, "Always with you it cannot be done..." Actually, the Harris solution was simple, done the right way and therefore would port over pretty well. I'd bet a beer that somewhere, somewhen, someone at NI did this already. LabVIEW for linux started out as someones hobby horse, a lot of nifty items in LabVIEW do. Linux and undo were both available years before release, but you know this. Not if it has already been developed and just needs to be ported and some tweaks. Agreed, its not a bad option if the other is still not available. It is always nice to have a range of techniques/levels of effort. But given the hardware knowledge needed for both it is probably easier to just write the Kernel driver, DLL, and LV wrapper VIs to call the DLL, at least it was the last time I did this. I haven't kept up with the latest driver models, like for XP.

I have an application that would benifit from a timeline like what you see on a video, audio or animation editor. My first thought is to code it up using a picture control and a lot of code, but I am also looking at ActiveX controls or even open source code that has such an interface. Has anyone coded up something like this or know where to get ActiveX or open source controls/code? Thanks!

Hosed is the right word. Welcome to X.X.0 releases.... Oh well, I've had a glitch or two in some of my x.x.o releases The good news will hopefully be that it is a single point failure with an easy single point fix, either in 8.0.1 or a quick patch from one of the NI elves. I really need D&D to work in EXEs for a project I'm estimating/scoping now. That means I have a little time, otherwise I'm looking for an ActiveX control and I really don't want to do that.

If you search MSDN on multimedia function calls you can find the correct function and DLL to switch. Then use the LabVIEW Call Library node to call this function.

1. RTFM 2. If the school doesn't have LabVIEW try to get them to at least buy a copy of the student edition, or spring for one yourself, it's about $75.00 last time I checked. 3. Study the example VIs 4. This is a professional forum (note the forum name...) so don't expect a lot of help from most of the people here, that isn't cold, just historically accurate, but if you do items 1-3 above, and then come back with some specific, intelligent questons you'll probably find lots of help. Good luck.

Bummer. Last hope might be a saving throw from one of the NI demi-deities... I've got to check if this bug is just the listboxes or also in the tree control, sigh...

minor tweak to make your process time more accurate: move the output indicator arrays outside the sequence structure to the right and fill them after the calculations. On my system that lowered the measured time by an additional 20%. It also more accurately reflects how this algorithm will behave as a subVI.

I've always respected your writings Rolf, but here you are missing the point. I agree with what you say about CompactRIO, fine product, works great, etc. I don't (didn't) have an external event that I wanted an NI generic solution. I have had multiple instances where companies I worked for (and two clients since becoming an independent integrator) had a need for a new, custom I/O card that no one made, anywhere. Specialized needs/applications, etc. CompactRIO did not exist then and would not have even remotely worked for any of these applications even if it had. What was needed, and built, was a custom card, initially ISA on the first app, then VME on the next, then PCI on the last two. Each one needed realtime response. I, or coworkers, ended up writing Ring 0 VxDs, then DLLs, then LabVIEW code, etc, to work everything out. I would have liked to have done everything in LabVIEW. I agree that trying to do this in the application layer is a rats nest nightmare. Thats not what I want(ed). I wanted to be able to write the proper device driver layers all in LabVIEW, including having the Kernel level (Ring 0 in old terms) ISR in LabVIEW. This is not race conditions, or other nasties, it has been done in C and other languages for decades. It WAS done in LabVIEW with the Harris NightHawk, but was not available on the PC or Mac architectures, ie something affordable, and it could have been. This still could be on QNX or Linux or OSX or even Windoze with one of the RT extensions, but that doesn't sell NI hardware does it. I first asked for this over 10 years ago and I know several other people who have also asked for it.

I wonder if this is a case of a default EXE behavior that can be corrected with the right INI setting? I'm not near my LV8 box or I'd check this out.

You can pop up on a loop entry node and ask to change it to a shift register, which is great, but asking the compiler to do this for you automatically would create more complaints than compliments. The two behaviors are very different and if LabVIEW did this "for me" at the wrong time I'd scream. On another note, what you are trying to do might be better done in a HW card such as a DSP. Take a look at: http://www.sheldoninst.com/ They have DSP cards that also have LabVIEW VIs to do the DSP programming for you.

I also use wire labels a lot on shift register wires, just to the left of the CASE in state machines.

Select the label, select the color tool, right click on the label and in the color box select the " T " for transparent. No border, no background color. If you want you can then select the text tool, highlight/select the text in the label and go to the Text Settings menu >> Color and in the color box set the text color so that it is just barely visible, or even invisible for that matter. You can later select the text to see the letters.

NI Icon Art Glossary + Artistic Friend with Photoshop + beer = Custom Icon Library ;-)

I used the same basic setup as Michael's first example, but made the event and hence the plugins a bit more generic by making the data type a cluster with a command string and an array of variants. The command string then gets fed from the event handler to a state machine and the variants act as arguments to the command. Minor performance penalty, but flexible. That being said, I tried hard but failed to get that excited over events rather than using queues to do the same things. It was much easier to come up with "how", than a compelling "why".

In a sit down interview situation a quick set of simple problems may tell you more than complex exams. Try giving them a race condition between two loops and ask them to define what the problem is and then solve it.

Sure, how about a simple web browser based on the picture control, that is written in pure G, no external platform specific code. For that matter anything adding capabilities to the picture control might be welcome.

Rumor has it that NI had a VI for the old NI-DAQ that did exactly this type of enumeration of all DAQ devices currently registered to the system. It was not a public VI. Can't say much more, but the functionality existed. Finding and sweet talking the right NI developer might help. Occasionally some of them have whipped up a custom VI for me (sometimes locked, sometimes not) that did stuff I requested that was not in the public view. Good luck.

Hmm, I'm always one to appreciate more power. Could you give a few more details on specific items/capabilities you feel LabVIEW does not yet support that you see in other languages? One that I have always wanted was to be able to hook a VI to run on a specific hardware interrupt, ie to use the VI as an interrupt handler. Yes, there are work arounds here, and I have used them, such as writing a VXD and having it set a LabVIEW occurence, but I am talking about real, preemptive INT handling. There was a LabVIEW system on Concurrent/Harris NightHawk and PowerHawk computers years ago. NI worked with Concurrent to make a modified LabVIEW realtime version that did true preemption, but it was pricey and only ran on the Harris CPUs. For companies that do a lot of hardware work this would be great.

You originally mentioned Linux as an alternative to RT, but then did not ask any questions. Have you definitely decided to go RT. Or is Linux an option? I helped us Linux with RT extensions on a telescope project and it worked very well.

<RTFM> Open LabVIEW, use menu: Help >> VI, Function & How To Help ... Once LabVIEW help opens go to: Creating VIs and SubVIs >> Building Stand-Alone Applications or Shared Libraries (DLLs) Or just search on "DLL" There are about a dozen articles there to help you do apps & DLLS </RTFM>

Well, its not a datalog format file, but you could do this in XML from LabVIEW, then everyone else can read/write. Also, the format of datalog files has bounced around regularly with almost every new version of LabVIEW for quite a while. It also happened to flattened string text files around version 4.0 too. Bottom line, if you save in any NI format, it is wise to make provisions for some kind of upgrade translator tool, when you have to switch your applications/customers to a newer version.

Anyone done this using MySQL under Windows and then made wrappers for both to make the upper level platform independent?

Search on NI DevZone, there is an example that does what you want and includes a library of VIs to use ACtiveX to make a small report in Word, including tables, etc. Creating a Report in Word ... Play around with the methods and property nodes, kyou will find that there is very little you cannot do by modifying this.

If you can live with just quickly checking to see what VIs are in your application and verifiying that none are in the Toolkit path(s), then there is a tool: "VI's in memory (100% G).vi" that is part of the OpenG Tools. If you go fish around on the OpenG website I'm sure you'll find them.