Yair

A few days ago, I started this thread. That gave me an interesting idea - we could start a sub-forum where people would post (every X days, maybe on odd weekdays) something that means something to them and which others are not likely to know. I think this sort of thing can prove to be very interesting if people choose wisely and should allow us to see some perspectives of the other members we're not used to. Here is a draft of what the rules for this might look like: The content must have intrinsic value. That means that when people view it, they should feel something about it, even if they don't understand it. In my example, both the music and the video are interesting, even if you can't understand them. The content should be relatively obscure to other members. This is not a hard and fast rule, but I don't think that videos which everyone on the internet already saw qualify. The point is to allow people to see "different" stuff. The content can be anything - a video, a song, a saying, a story, a picture, a painting, a game, whatever. It can be sad or funny, moving or silly, emotional or logical. It can have personal value, municipal value, national value, etc. As long as it has value, it's valid. After first posting, you don't have to give any details, but eventually, the source of any content should be disclosed. Of course, you can also do as much explaining as you like when first posting. I think that's good enough for an initial draft. If we do this, we should probably have some way of coordinating so that people post separately. A Google calender with a shared account should probably do the trick, although maybe Michael has something up his sleeve? Personally, I could easily find quite a few things without thinking much and I'm sure others have them as well. Let's see if other people like this idea. Go and take the poll and if you have any thoughts, you're welcome to add them here.

I don't understand what it is you want to do. If you want to change the output based on the type of the input the easiest and most reliable way is to use a polymorphic VI. Another option is to just use DBL which should cover most other representations, I believe. OpenG has a function which does exactly this and accepts DBL. It might have polymorphic versions, but I don't think it does - the cleanest thing is probably to output the double value and then convert it after it leaves the subVI.

QUOTE (Eugen Graf @ Jun 13 2008, 11:46 PM) If I understand correctly, your problem is that the queue reference itself breaks when you change the data type of the queue (even if the data type is a typedef). This was actually changed in some version of LabVIEW (I'm not sure which, but I'm pretty sure it works correctly in 8.5.1) so that the queue reference is automatically linked to the typedef, but if you want to do this on an earlier version, you can. To do this, when you first create the queue reference, right click the reference on the front panel and select Show Control. You can then replace the control inside the reference with your typedef and it will then work correctly.

QUOTE (normandinf @ Jun 13 2008, 06:51 PM) It does happen with the current beta - all you need to do is get a reference to the current VI (e.g. by using a VI class property node).

QUOTE (Justin Goeres @ Jun 13 2008, 06:00 AM) Or ( C) the developer was planning on doing something with the binary data (e.g. save to disk, transfer over the network).

I don't think there is any need to call Douglas Adams for this. I'm not sure if there is any reason why this works with references (it seems to work with any kind of reference), but I would expect it not to work. In any case, I'm guessing that it just type casts the reference and then compares it. That would explain why an empty reference is equal to an empty string. QUOTE (Yen @ Jun 13 2008, 03:13 PM) Actually, attempting to compare to an existing reference crashes LabVIEW, so I'm guessing this is a bug.

QUOTE (Eugen Graf @ Jun 13 2008, 03:08 AM) Actually, you can. And you can do it with queues as well. And even with events. But in general I would have to agree with Justin's notion that there is no one solution to rule them all.

QUOTE (daal @ Jun 12 2008, 10:37 PM) Look at the link Chris added.

QUOTE (Eugen Graf @ Jun 12 2008, 10:00 PM) Can you explain what you mean?

QUOTE (Chris Davis @ Jun 12 2008, 09:11 PM) Did you mean http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=213366#M213366' target="_blank">this post?

QUOTE (neB @ Jun 12 2008, 02:06 PM) These are my two favorite images as well. I want to give it a couple of days and see if anyone else has anything to add before commenting on the rest.

Most toolkits for DB work (including NI's toolkit) already use ActiveX. If Notes supports ADO or ODBC, you should be able to connect to it through that using any of the available toolkits (e.g. NI, LabSQL, ADO toolkit, etc.).

As the title says, I'm interested in opinions.

I still have a couple of those graphic calculators (with the instruction manual, of course), although I must admit I was never geeky enough to program seriously in them. I did do a bit of programming in boring classes, but if memory serves, it was mostly animations.

I'm not sure you should get so hung up about the term "node". Personally, I think of any structure, primitive or subVI as nodes, but if you take Stephen's C++ analogy ("Nodes are the functions that read those variables and write new variables") then the answer to your question is yes, because the wires are separate. Personally, I don't think this level of detail should go in most tutorials and you can probably find better terminology. As a side point, QUOTE (Eugen Graf @ Jun 9 2008, 11:46 PM) In both cases, a copy of the data may be made, but LabVIEW tries to optimize the memory usage and reuse existing buffers when possible instead of allocating new ones. This can happen both in case structures and in subVIs and is not always easy to predict. If you want more data, a search for "inplaceness" should reveal all kinds of stuff.

QUOTE (Eugen Graf @ Jun 9 2008, 10:51 PM) The wires on separate sides of the tunnel are not the same wire.

I would agree with the notion of not hiding indicators. I set the front panel origin to 0,0 and always place the controls and indicators which should not be visible above that line. That leaves room to expand the FP downwards.

QUOTE (ragglefrock @ Jun 9 2008, 06:08 PM) Ah, yes, that would make sense, and I knew there was a reason I was sure of it. Creating the test should be simple - just pass the reference using a global. The reason you couldn't test it is because you probably missed a subtle point - the thing that maintains the reference is not the VI, but the hierarchy. You have to remove the top level VI in the hierarchy from memory. This mistake is easy to make when using LV2 globals - if you create the reference in one hierarchy and then use it in another, it will go invalid if the first hierarchy is removed, even though you keep using the same VI. I can't test this at the moment, but I ran into this myself in the past as well, so that explanation should hold and would expain Ben's example.

QUOTE (jbrohan @ Jun 9 2008, 12:40 PM) At least the eee should be available with XP. It's more expensive than Linux, but still much cheaper than any other laptop. I've been thinking of using it for the same purposes, but didn't get into checking it yet. Buying a single LabVIEW for Linux license will only be worth it if you're going to have a lot of these stations, since the cost will not be just the license, but also the integration and management (e.g. SCC, cross-platform bugs, etc.).

If the basic format of the file is the same, then all you need to do is read the field names and put them into a ring and let the user select which fields they want. Alternatively, you can have them mark the text in a string control and use the selection properties to determine which field it is. As I said, I personally don't really understand the structure of the files, so I can't help that much.

I'm still not clear on the details, but maybe this will help: Instead of attempting to train the software, why not just write code for each case and then run each one until you don't get an error? Alternatively, you can try writing identification VIs (which will only attempt to identify the format and then return the format type. You can have one VI for each format and build them using a standard connector) and then run those until you have an answer. If you're asking about actully parsing the file, it seems to me that the Match Pattern primitive might help you, but it's hard to tell exactly.

QUOTE (rolfk @ Jun 6 2008, 03:11 PM) I was certain of that as well, but it seems that is not accurate. You can see that by running the attached VIs (8.0, but I'm pretty sure I saw the same in 7.0). If you stop the one which created the queue, the queue still exists. You can even have another VI which will write to it just to see that. QUOTE (ragglefrock @ Jun 6 2008, 07:20 PM) One assumption I made is that the server VIs must be in memory before the client tries to access them. These do look much simpler and that requirement seems reasonable, but you might wish to wrap it and output a nice error.

I still don't understand exactly what it is you want to do (and probably won't without some examples), but in any case, if you cross-post, you should include the link in both posts, so that people can see what replies were given in the other thread.

QUOTE (martin@aerodynamics @ Jun 5 2008, 02:24 PM) For what it's worth, I got two of them (recommending that I take some courses "based on my results") even though I didn't actually take the exam - I only clicked the link and I don't think I even got to the first question.

I can't say I fully understand what you want (an example of a file with what to search for would be nice), but you can easily search a single column by indexing it and using Search 1D Array. If you want to search things by pattern, you might wish to hold the array as a delimited string, search the string itself and then find the number of delimiters before the match to know which cell you're in. Talking to Excel is reasonably easy using ActiveX and there are some examples in the Example finder. Just note that the ActiveX interface change between Office versions, so the computer you develop on needs to have the same version of Office as the computer the program is being run on. Alternatively, you can connect to Excel using ODBC and use SQL to extract data from it. That could handle the searching as well. I don't remember the details, but searching for Excel and ODBC or ADO might even find you some example VIs.