eaolson

QUOTE(dsaunders @ May 3 2007, 12:00 PM) I think the problem becomes that, if you have multiple threads enqueueing, it is possible that they will conflict. See Aristos Queue's post http://forums.lavag.org/index.php?showtopic=3406&st=15#' target="_blank">here.

QUOTE(Tomi Maila @ May 2 2007, 02:46 PM) Perhaps I'm being a bit thick, but what's the disadvantage to protecting a fixed-size queue with a semaphore? I can see that multiple Enqueue points might experience a slight delay when enqueing.

QUOTE(Michael_Aivaliotis @ Feb 28 2006, 01:14 AM) I just don't think it's necessary here. On a site like Slashdot, where there are hundreds of thousands of users, it's necessary to winnow out the chaff. But here at LAVA, the signal to noise ratio is quite high. I don't think I've ever even seen an honest-to-god troll here. I think the "Activity level" ratings for each user are as much information as is really needed. I'm not sure how big the community actually is, but it seems like the number of regular posters could be measured in the few dozen.

QUOTE(crelf @ Apr 24 2007, 03:31 PM) http://forums.ni.com/ni/board/message?board.id=170&message.id=123262&requireLogin=False' target="_blank">This thread from the NI forums suggests that they can write metadata to a png.

For the first time, I need to create a DLL from a LabVIEW application that can be used by external code, probably C++. There is a great deal of information on calling a DLL inside LabVIEW, but not very much that I can find about calling a LabVIEW-created DLL from an external application. Can anyone point me to any reference? NI used to have a document Using External Code in LabVIEW, but I can't find a "Using LabVIEW in External Code" sort of document. Some things are minor, for example the error cluster is defined in the created .h file as: typedef struct { LVBoolean status; long code; LStrHandle source; } TD1; That's reasonably straight-forward, but the TD1 name isn't very descriptive (I'm guessing that stands for Type Definition 1). Other clusters get TD2, etc. Is there any way to change these names to something more helpful? I worry that, if my DLL changes, these will all be renumbered, and that will make maintainability a nightmare. Other things are considerably more confusing. I have a function that returns a timestamp in LabVIEW. In the .h file, this function gets a prototype that looks like: void __stdcall GetTime(TD1 *errorInNoError, HWAVEFORM targetSTime, LVBoolean *timedOut, TD1 *errorOut); The only definition I can find for HWAVEFORM is in extcode.h that LabVIEW drops in the DLL folder: typedef IWaveform* HWAVEFORM; And the only reference to IWaveform I can find is also in extcode.h, where it is defined as: typedef struct IWaveform IWaveform; I can't find any other definition or even reference to IWaveform.

QUOTE(Tomi Maila @ Apr 9 2007, 11:39 AM) Oh, I realize that. And I'm sure it's no coincidence that NI is headquartered in Austin. I just thought it was interesting that no other US cities were listed. So I'm wondering, is Austin in particular a hotbed of LabVIEW development, or are the NI folks themselves doing a whole lot of Googlin'?

QUOTE(Tomi Maila @ Apr 8 2007, 03:07 AM) For some reason, I am amused that the #1 city for LabVIEW and National Instruments searches is Austin, TX.

QUOTE(Nullllll @ Apr 6 2007, 09:05 AM) This question has the same deficiencies as the http://forums.lavag.org/resistorANDlabview-t7323.html' target="_blank">last one you asked. Namely, a lack of detail as to what you're trying to do, what hardware you're using, and what you've tried so far. For example, what's a sun follower?

QUOTE(alfa @ Apr 1 2007, 11:55 PM) All this time, and I didn't even know she was French.

I'm trying to be good and arrange all my VIs appropriately in project libraries*, marking each VI as public or private as I go. But I have found that, when a polymorphic VI is called from outside a project library, LabVIEW uses the access scope (public/private) from the instance VI, not the polymorphic VI. It seems that the scope for the polymorphic VI is simply ignored; you can even call a private polymorphic VI, as long as the instance VI is public. I assume this has something to do with how the actual instances are dropped on the diagram via the polymorphic VI. Is this the intended behavior? It just doesn't seem like the way things should be, at least not in my head. The attached example contains a project library (Case Lib.lvlib) with three VIs: Poly (private) Case DBL (public) Case I32 (private) There is also a Use Case DBL VI that calls Case DBL via Poly and a Use Case I32 VI that calls Case I32 via Poly. Use Case DBL runs fine. Use Case I32 has a broken arrow. Originally, I had made a library with a public polymorphic VI and private instances, because that's what makes intuitive sense to me. Calling the polymorphic VI from another VI didn't work because the instances were private. (Does this nomenclature bug anyone else? A library has always seemed to me to be a actual collection of things, not a separate file containing metadata about a group of things.)

QUOTE(Tomi Maila @ Mar 29 2007, 01:41 PM) So can a shift register. The initialization happens on each call, which makes an initialized feedback node not so useful for an LV2 global. I was just trying to point out that comparing a feedback-method global without First Call? and a while-method global with it is like comparing apples to oranges. Execution times, 10^8 iterations: (YMMV) feedback-method global with initialization only: 1272 ms feedback-method global with initialization and First Call?: 4693 ms for-method global: 4600 ms while-method global: 4200 ms

QUOTE(Tomi Maila @ Mar 29 2007, 12:42 PM) There seems to be a constant folding bug with your updated VI. The output is always 0. I think this is a known issue. I don't know if this will affect the speed of operation or not. You also don't have the same First Call? or case structure as in the other examples. When I add them in, it seems to be quite a bit slower than the other two methods. (The difference between the While and the For methods is only about 1% for me.)

QUOTE(Tomi Maila @ Mar 29 2007, 10:38 AM) The feedback method has four buffer allocations inside the outermost for loop. The for method has five and the while method has six. Could that have something to do with it? I'm not sure how constant folding will affect those or exactly what happens when a loop element (i or N) is left unwired.

I hesitate to jump into this thread, but I will anyway. QUOTE(Aristos Queue @ Mar 26 2007, 05:21 PM) Why wouldn't the whole Error class tree start at General Error? It seems that that would have some sort of basic error functionality that was extended in the subclasses. What's the advantage to making them siblings? (In Java, for example, everything inherits from a general Error class.) I can sort of see the need for multiple classes of errors as prototyped in this example. But how would a VI that was expecting, say, a Network Error behave if it was wired a Device Error instead? Those are sibling classes. Would there be an implicit typecast up to Abstract Error and then a typecast down to Network Error? (My experience with LVOOP is a bit sketchy at this point; apologies if that's a blindingly obvious question.) The whole error IO paradigm as it stands in LabVIEW only makes sense if a VI can accept an error and pass it down the line as far as it needs to go, possibly into and out of VIs that are not aware of that particular error customization. Is it envisioned that this will change in the future, or will error clusters be replaced with Abstract Errors? I kind of see Tomi's point. The only reason to have a specified User Defined Error is if the other error types are not user-definable. Does this mean I won't be able to sub-class off of DAQ Error?

QUOTE(fungiscience @ Mar 20 2007, 05:08 PM) I'm working from memory here, but I don't think so. If your task is configured for 30 channels, you need to update all 30 channels at once. What you can do is keep track of the current output values in an array, update only the array element you want to change, and use DAQmx Write 1D DBL NChan 1Samp to write the entire array to the hardware. You could also set up each channel in a different task, but that becomes complicated if you want to update them simultaneously.

QUOTE(Jim Kring @ Mar 18 2007, 02:37 PM) I had the same problem, and logging out and logging in didn't fix it. Then, I tried doing the same specifically from the wiki main page, and it worked. I think the LabVIEW-focused wiki is a great idea. Just don't forget there are Wikipedia articles for LabVIEW, OpenG, and even Jim Kring.

Just to make sure this horse really is dead ... I was thinking the error being thrown was incorrect, and so brought this up over at the NI forums. I was wrong; the regexp is just malformed. I think the "G[b|i]" element should really be "G(b|i)" and the outermost [ and ] should be ( and ). You can't next square brackets or use parentheses inside square brackets.

QUOTE(LV Punk @ Mar 12 2007, 01:55 PM) You're welcome. Actually, I just saw it as an opportunity to sharpen my regexp skills, which aren't as polished as I'd like them to be. This error seems to have something to do with nesting an [] inside an () inside an []. When I take away any one of those elements, I stop getting the error. Now, is this a malformed regexp, or is it a problem with LabVIEW? (Told you my regexp skills weren't as polished as I'd like them to be.)

QUOTE(LV Punk @ Mar 12 2007, 10:21 AM) That's the sort of thing that can make you wake up screaming. The error seems to be in the "G[b|i]" part of the string. If I take that out, the error goes away. I assume it's supposed to be "G(b|i)"?

QUOTE(Jeff Plotzke @ Mar 6 2007, 09:27 AM) I had a strange problem some time back with a front panel graph not updating quickly when targting an RT host from a Windows computer. I tried a handful of things, and the problem went away; I'm not sure which one was responsible. Someone over at the NI forums claimed there was a known bug in 7.1 when doing full duplex Ethernet communications that slowed everything down. http://forums.ni.com/ni/board/message?board.id=170&message.id=149970#M149970' target="_blank">http://forums.ni.com/ni/board/message?boar...=149970#M149970

QUOTE(crelf @ Mar 9 2007, 08:17 AM) I just noticed that, if you use the block diagram grid, LV places a one pixel wide gap around wires, but not around VIs or controls/indicators. So, for a wire, the grid stops one pixel away, but not for a sub VI. I can't believe I just saw this. Is there such a thing as being too detail-oriented?

QUOTE(PaulG. @ Feb 7 2007, 07:33 PM) Hey, at least it's a happy ending.

QUOTE(JFM @ Feb 23 2007, 02:07 PM) Timestamps are absolute times, not relative ones. So (23-Feb-2007) - (22-Feb-2007) = 24 hours makes sense, but (23-Feb-2007) + (22-Feb-2007) doesn't. After all, what should the result of "Wednesday plus Thursday" be, and would it be different from "Monday plus Tuesday"?

QUOTE(Michael_Aivaliotis @ Feb 22 2007, 11:32 AM) He's talking about collecting 16 channels of data at 1kHz for 200 hrs. By my quick calculation, that would be an 87 GB data file. I'm sure that's not impossible, but it probably opens up entirely new avenues of challenges. Does TDMS perform any compression on the data it streams to disk?

QUOTE(Jeff Plotzke @ Feb 18 2007, 01:58 PM) Ah, but it is! You can't directly interface with the mouse, but you can read mouse input sitting on a serial port. I wrote the http://forums.lavag.org/downloads.html&showfile=73#' target="_blank">Serial Mouse Driver in the CR because I needed to get that very sort of user input under RT.