David Boyd

Just curious if anyone else sees this the same way I do... If I create a user event for a simple scalar datatype (which I probably never do anyway), the event data is of course returned as the scalar value, with the data name label intact. But, when I use a cluster as the datatype, LabVIEW discards the cluster label and returns the elements of the cluster as individual items in the event data. I have no option to get the entire unbundled cluster within the event case. The workaround is to add an 'extra' cluster frame around my original cluster, and of course, name-label the outer cluster frame. Does this seem syntactically inconsistent to anyone? Is there a compelling reason for the way it's implemented? Dave

Another trick I've used is to run a second plot which gets the value 'NaN' until I want to mark an event in the plotting. I then plot a point at -Inf, followed by +Inf, then return to plotting NaN. This guarantees a vertical line draw that does not affect autoscaling behaviors (nor is it affected by scale changes). The visual effect is to have a hairline vertical marker appear over/under the other trace(s) in the chart at the sample of interest. Dave

QUOTE(Aristos Queue @ Jan 29 2008, 12:29 PM) I'm thrilled at the rich store of knowledge I've tapped into about proper syntax. Thanks, Stephen. And of course, I'm always happy to hijack a thread. What were we discussing again? Dave

QUOTE(Aristos Queue @ Jan 28 2008, 02:46 PM) Did anyone else note that AQ used properly nested parentheses in his reply? Does anyone else besides me notice things like this? My brain throws syntax errors when I read peoples' posts containing improperly closed parenthetical notes. Dave

QUOTE(Daklu @ Jan 11 2008, 01:24 PM) Perhaps you were recalling comments made about using VSS keyword expansion tags inside VIs? The catch is that the keywords must be of the fixed-length type to avoid corruption of the VI file, which is a binary stream. I'm sure in the past I posted here or on NI forums, or possibly Info-LabVIEW, about using such VSS keywords in VI descriptions (though they could potentially be placed anywhere, as BD or FP free text, BD constants, etc.). There are many useful keywords, f'rinstance: $Author:$$ModDate:$would possibly expand to$Author:dboyd$$ModDate:2008-01-11 19:17$ but to use them in a VI you need to specify them as (note the double-colon): $Author:: $$ModDate:: $ so they'll always occupy a fixed bytelength when VSS expands them. Is this what you meant? Best regards, Dave

QUOTE(jzoller @ Jan 10 2008, 02:36 PM) To add to JoeZ's point about differentiating between multiple barcode targets - I typically turn on an option on the BC reader which adds a preamble to the scan which tells what barcode format (30f9, UPC, Codabar, code128, etc) was detected. Between that and the length of the scanned item, I hopefully can uniquely determine which of the targets the user 'hit'. (You can also disable unneeded code types at the scanner, to perhaps avoid users scanning a bag of Cheese-Its and feeding your app bad data ) It helps if you can have some say in how the product barcodes are encoded/formatted, so you can accept user input in arbitrary order.Dave

QUOTE(Louis Manfredi @ Jan 9 2008, 04:12 PM) Louis, Not sure if you meant a handheld barcode reader, as opposed to a fixed solution for scanning items passing by on a conveyor, so I don't know if my experience/recommendations are relevant. I've used various Intermec handheld devices, such as: Intermec 1552/9245 wireless handheld gun (pistol grip type), interfaced as a keyboard wedge Intermec 1551C tethered handheld gun (also pistol grip), variously interfaced as keyboard wedge, serial port, USB Intermec SF51 wireless gun (penlight-grip), Bluetooth-interfaced, configurable as a virtual serial port or virtual keyboard wedge The SF51 is the newest and least expensive solution of the three (about 700USD IIRC), andworks well over long distances when paired with either the Intermec-supplied BT USB dongle or the BT radio built in to my laptop. I chose to support it by using VISA to read its virtual serial interface - very straightforward. For decoded handheld scanners which typically return a string of scanned characters with perhaps a preamble and/or termination sequence, there's not much 'driver' involved - most of the work of interpreting the string is task-specific. My .02USD, and worth all you paid for it :laugh: Best regards, Dave

QUOTE(Aristos Queue @ Nov 30 2007, 05:59 PM) As Tomi suggested in his post, perhaps this is about semantics; the name of the event suggests something that isn't actually happening. True, an action was invoked on the control, but there's no change on the wire. If changing the behavior would break any existing code, then of course I wouldn't push for it. But I think this subtlety calls for some sort of clarification. I certainly hadn't expected all my boolean buttons to 'fire' from a menu-invoked reint to default. Dave

If I invoke Edit->Reinitialize Values to Default on the runtime menu of a running VI, every control which has a Value Change event registered fires an event, even if no actual value change occurs. If I test OldVal and NewVal within the event case for equality, yep, they're equal. This is especially unwelcome when dealing with latching boolean buttons which trigger some code when the user presses them - they ALL fire when the user does the Reinit to Default. I'm surprised I hadn't noticed this behavior before. If there's a rationale for this, could someone explain it to me? The workaround would be to compare OldVal and NewVal and conditionalize the code within each event case. Also behaves this way in 8.2.1. Dave

QUOTE(LV Punk @ Nov 2 2007, 06:47 AM) Oooh, I just noticed I'm about to experience a rollover event... into 8-bit territory. Is it OK for me to feel all tingle-y?Dave

QUOTE(Sparky @ Oct 19 2007, 09:08 AM) This problem looks suspiciously like one that was discussed at length http://forums.lavag.org/Table-scrollbar-customizations-not-saved-with-VI-t4098.html' target="_blank">here, though the item was a table rather than an MCL. But as others have posted, it wouldn't hurt to file the bug report with NI to remind them that someone else needs 'fat' scrollbars. Dave

QUOTE(crelf @ Oct 6 2007, 09:23 AM) Pretty surreal... I'll freely admit that I'm not familiar with Fatboy Slim. But I did find one interesting reference in the lyrics... "If you walk without rhythm, you won't attract the worm." Straight out of Frank herbert's http://en.wikipedia.org/wiki/Dune_(novel)' target="_blank">Dune.

John, I've never attempted to use the SR portion of Microsoft's Speech API - just the TTS part - but I'll agree with the others that it's fundamentally much more complex. The only suggestion I would immediately make is to look for shipping examples written for Visual Basic rather than C++. I think the Automation interface steps required to build a working VB example map much closer to on-to-one to LabVIEW. Best of success to you, Dave

QUOTE(dsaunders @ Sep 14 2007, 04:58 PM) Ah. For that, you may want the VI property 'Set Close If Lonely' to be set TRUE. This is a scripting property which must be set by the tool VI on itself each time it is invoked (it doesn't persist through a save on the tool VI). This is what allows the tool to be closed whenever LV detects that it's the last VI open. I used it on the Tunnel Wiring Wizard. Also, there are scripting properties to set a VI as a 'system' VI, which is a mod that does persist when the VI is saved. This is a VI flag that causes the tool VI to be invisible to the hierarchy window (I think it has other effects, but I can't recall). Also set on the TWW, at least my original version. Hope this helps. Best regards, Dave

QUOTE(dsaunders @ Sep 14 2007, 12:48 PM) There's an application scripting method 'New LabVIEW Document' which takes a numeric parameter and creates any one of the following: standard VI, global, control, polyVI, runtime menu, project, plus some templates of these types (I didn't try an exhaustive set of values). Unfortunately, it doesn't return a refnum to the created object.I'm pretty sure there was also a 'New VI' primitive which created a new VI with various options for what kind, and returned a refnum for the created object. But it no longer appears in my Application Control palette. Must need a ReallySuperSecret... token (or legendary scripting license activation) to get to it now Since none of this works in runtime, you were, of course, referring to creating a new VI while running the development environment, right? Why is the menubar of the calling VI necessarily hidden? Dave

QUOTE(Hacti @ Sep 13 2007, 05:25 AM) I know their meaning, but I'm not sure it will help. The indication -1.#QNAN is a string formatted output of an IEEE-754 floating-point value of Quiet NaN (not-a-number). Broadly speaking, it's the floating-point value that IEEE-754 compliant floating point libraries (or silicon) will output when performing certain operations, like dividing zero by zero, or computing the square root of a negative number, where there is no numerical answer. The IEEE standard guarantees that NaNs are propagated through further processing, so NaN plus, times, divided by, etc anything also returns NaN. Also of note, all numeric comparisons involving NaN return FALSE, even "does NaN equal NaN?". NaN doesn't "equal" anything, though there is an "IsNaN?" test. LabVIEW, I believe, is fully compliant to the IEEE-754 standard. Whenever displayed by a numeric indicator or converted to string, the output appears as NaN. There's some encoding magic I don't understand in the standard that classifies NaNs as either "quiet" or "signalling" - I think LabVIEW only generates "quiet" NaNs.The -1.#IND is another IEEE-754 value that represents "indeterminate", though I'm less sure about how that's generated. I believe it is the string conversion of a floating-point "denormalized" number, which I believe signals a limits-of-precision condition in a calculation. I'm not a computer science major - so you'll have to look that one up for more information. I know that LabVIEW never displays indeterminates in the way that it does NaNs, so they may just be quietly converting underflows into zero. There are also flag values for positive and negative infinities in the standard, which LabVIEW does implement (as +Inf and -Inf). Again, the encoding you're seeing in the shared variable monitor is from some standard C library and uses the formatting -1.#xxx, so you'd see that as -1.#INF. Where your initial values are coming from, though, I couldn't say. Sorry for the long ramble... Dave

QUOTE(Aristos Queue @ Sep 12 2007, 10:13 PM) Doggonit, Stephen, now that one (the Shift+Enter on string constant entry) I really never heard before anywhere. :thumbup: Most of the others I've seen here are the ones that I either use already, or would if I could remember which modifier to hold down while dragging, etc, but this one is new to me, and immediately useful.Can you tell us in which version of LV it made its debut? Dave

QUOTE(dsaunders @ Sep 12 2007, 05:52 PM) I think that the increment/decrement operations are appropriate when designing enum-driven state machines and the intended behavior is 'go to the next defined state'. While I'm completely in agreement with jpdrolet that one should never infer a numeric value from an enum, I think that it is valid to consider them as an ordered set of values. An advantage to using increment here is that changing the enumeration to include a new value between two existing values can often be done without revisitng the code, if the intention is still to step through the states.QUOTE(dsaunders @ Sep 12 2007, 05:52 PM) I knew something was bothering me about this. It works since, as Dave pointed out, it is really just casting an enum to the same enum. But I had tried to typecast a numeric to an enum before and it doesn't work. There is no error, and it compiles. But for some reason the enum output always goes to the default value (the first element). Possibly what you're being bitten by is the length of the numeric vs. the length of the enum. The square-peg-round-hole cast node preserves bit pattern, not numeric value, so if there's a size mismatch (say, an I32 number cast to a U16 enum), you'll get perhaps only the high-order two bytes of the numeric (depending on endianness). This is why casting to/from enums is so perilous. Try casting a U16 number to a U16 enum and see if you get the various values you'd expect. Best regards, Dave And Jeffrey beat me to it... Just for completeness' sake, the bullet casts DO preserve numeric value where possible. Only the SPRH cast behaves as described above.

QUOTE(young grasshopper @ Sep 12 2007, 03:28 PM) Your example VI has a case output tunnel which outputs a plain I32 from all its cases except one, which outputs the wire coming in. So, the tunnel is typed as a plain I32, which then is summed with another I32. So the enum wiretype never propagates past the left side shift register. What I didn't see in the other answers so far is that all your tunnel assignments should be from constants of the same enumeration. If you do this, you'll preserve the enum type in the shift register terminals. Additionally, you need to understand that arithmetic operations like add and subtract can't really be properly performed on enums, so the editor coerces the enum to its numeric value to perform the math. There is one exception to this (OK, two, technically): the increment and decrement primitives on the numeric palette. For enums, these behave as you'd expect. (Sorry, I think dsaunders post is incorrect in this regard.) Also, the enum value will "wrap" between its first and last values. These are the only "numeric" operations allowed on enums. I think they're really what you intended to do from your original posting. If you stick to these guidelines, you should never need to perform any re-casting to get your wire type "back". And the advice you already got about typedef'ing an enum is very important. It allows you to add values to the enum later and ensure that they type-propagate to all those constants (if you dropped them as typedef instances). Create the typedef before you begin coding, and use it, otherwise you'll spend hours chasing coercion dots and running down out-of-date enum constants. Best of luck! Dave

Does anyone else find this help text a little daunting to read through? Allow User to Open Diagram Property (Not in Base Package) Property of SubPanel. If TRUE, displays an Open Block Diagram item on the shortcut menu when the user right-clicks on the border of a subpanel control in a running VI or within the border of a subpanel control but not on a control or indicator on the front panel loaded in a subpanel control in a running VI. If FALSE, the Open Block Diagram menu item does not appear. This property is similar to the Allow User to Open Diagram item on the shortcut menu of a subpanel control. I was wondering if it's just me that got lost during that "If TRUE..." text. Dave

QUOTE(Justin Goeres @ Sep 11 2007, 03:23 PM) Jeez, I saw the topic title and almost fell out of my chair. I thought for a moment that it was an image tucked away in LV 8.5 along with the LAVA logo. Silly me. Dave

QUOTE(ragglefrock @ Sep 12 2007, 11:23 AM) Oooh, now that's so "clever" it's downright scary. I would have NEVER thunka' that as an alternative. Dave

I recall one problem in my multiple-choice CLD recertification where I was convinced there was no correct answer (but exactly one answer which seemed close). When I got back to the office I even re-sketched the BD snippet and the list of answers (from memory) and sent it in to the certification folks. Never got a reply. But hey - I tried. Apart from that, I had no complaints about either the original CLD test or the recertification. Dave

QUOTE(yen @ Aug 31 2007, 08:17 AM) I hadn't heard about the 'two versions' limitation for driver support - is this quoted anywhere? Somehow I have come to believe that NI's driver support generally strives to support farther back, but perhaps I'm limiting my thoughts to VISA. I also have a few apps still in use running under the 7.1 RTE and I'd hate to think that updating DAQmx would break them. With VISA, my impression was that support is dropped for older Windows OSes, not for LV versions. The VISA 4.2 readme sez:QUOTE NI-VISA 4.2 does not support Windows 9x/NT. To run your VISA application on Windows 95, you must install NI-VISA 2.6.1 or lower. To run your VISA application on Windows 98/Me, you must install NI-VISA 3.0.1 or lower. To run your VISA application on Windows NT, you must install NI-VISA 3.3.1 or lower. The readme on DAQmx 8.6 (latest release) sez:QUOTE NI-DAQmx is the latest NI-DAQ driver with new VIs and functions and development tools for programming measurement devices. You should install and use NI-DAQmx if you are using devices supported by NI-DAQmx; refer to http://file:///C:/Program%20Files/National%20Instruments/NI-DAQ/readme.html#devSupport' target="_blank">Device Support. If you are using a TEDS sensor, you can use only NI-DAQmx. If you are using NI application software with NI-DAQmx, you must use LabVIEW, LabWindows/CVI, or Measurement Studio version 7.1 and later, LabVIEW SignalExpress 2.x, or the LabVIEW Real-Time Module 7.1 or later. Elsewhere it looks like the oldest Windows OS supported by DAQmx 8.6 is Win2000. I know less about support for FieldPoint, even though I've got some FP-RT hardware running. With FP RealTime, I think of the LabVIEW version upgrade as more of a risk to compatibility - since you have to update the RT module in your development environment and also the LabVIEW engine in the hardware. And don't make me guess about GPIB support - I've got one GPIB-connected instrument in the whole facility. OK, I'll guess - that architecture is very mature and probably doesn't change much (if at all) with new driver releases. Hope this is useful - good luck, Dan. Dave

(Apropos of nothing, really...) Dyslexics of the world, untie! Regards, Dave (Unrepentant lefty who happens to use the mouse with the right hand anyway.)