David Boyd

Not to hijack the thread back to its original subject :laugh: , but... Box came in the mail today - identified as the new copy of LV 8.20 FDS (we have a volume license for both PDS and FDS). Not that it really matters - the CD contents are whatever you have activation codes for. An identical box with PDS labelling will probably show up in a few more days. But definitely no fancy zippered cases for us Mostly I'm just happy to have the disks for the August 2006 driver release. Dave

Probably the wrong forum, and I'm almost embarassed to ask, but: If you've got an SSP, have you received your LV 8.20 distribution CDs by now? I got the impression from others on this forum that they've received theirs a few weeks ago, but I still haven't seen mine show up. I emailed my rep last week, who promised that they'd be shipping 'in a week or two'. Are you guys all working off the installer you FTP'd? Dave

:headbang: Y'know, I STILL can't get this to work under LV8 - I've moved the code into a project (a step long overdue anyway), created a .ctl file w/in the project, &c., and gone back over your steps, and no joy. Did I mention that the containing object for the table is not the FP directly, but one of the pages of a tab control? You don't suppose this has anything to do with the behavior? It's just a little wish - just one of those UI dress-ups you turn your attention to when the project has reached the 90%+ functional mark. Thanks again for all the experimentation on my behalf. Dave

So far I'm unable to get this to work - I recreated the customized control w/in a LV 8.0 project, along with a VI which uses it, but it still seems to show the default scrollbar appearance once reloaded. Sorry, but can you give me a step-by-step of how you did this workaround? Thanks so much to you and to Scott for knocking this around - this is why I love the online LabVIEW community so much. Best, Dave

Thanks, Scott, for confirming this... I neglected to add that I did observe this behavior when I checked a LV version *ahem* between 8 and 8.20. And just now I opened my typedef file and Hey Presto! there's my 'fat' scrollbar... so your observations about the order of opening TD vs. VI seem to be confirmed. If only there were a way to trick LV into using all the custom control's attributes when on the FP.... Dave

To demonstrate, do the following: 1) On a new VI, drop a table control from the 'List & Table' palette. 2) Popup and invoke the control editor on the table. 3) Show Parts Window. Change the width of the Y scrollbar from default (17) to 32 pixels. 4) Change the width of the frame from default (250) to 265 (to match the scrollbar change). 5) Apply changes, then dispose the control editor window. 6) Observe that the table has the 'fat' vertical scrollbar. Save and close the VI. 7) Reopen the VI - the scrollbar reverts to default width. I also tried saving the control as a strict typedef. The typedef retains the change when reopened, but instances of it on VI FPs don't reflect the modification. EDIT: The typedef does not retain the change either - I may have had it lurking on my clipboard when I tried it earlier. I wanted a 'fat' scrollbar for my touchscreen UI... My guess, FWIW: this is a bug related to the 'BigSavings' introduced in LV8 to reduce VI footprint on disk. What I'd really like is for someone to check whether this behavior remains in 8.20 - I haven't received my 'official' SSP CDs, so I don't have it installed. Best regards, Dave

(Insert head-smack noise here.) Doh! Michael, sometimes the obvious solution just doesn't occur to me... This method looks to be clean and 100% reliable - after all, NaN always gets converted to the string "NaN", so it's a cinch to do the fixup in the string. Thanks a bunch! Dave

Hello all- Was having this discussion with my coworker today, and he swears he saw a clever example of this somewhere - the task at hand is to convert doubles to strings for eventual display in a table. I regularly use NaN to indicate lack of a measured value, and I was lamenting all the extra nodes it takes, to test for isNaN?, then a select node, and an empty string constant, just to suppress the 'NaN' text, which is meaningless to my end users. Plus, while I want to format multiple doubles into a row of the table, I can't use an expandable Format Into String node if I need to do this testing and selecting. So, is there some undocumented format code to conditionally format an NaN? Or is he confusing this with Excel's conditional formatting? Best regards, Dave

Not an inexpensive solution, but if you need a true GPIB analyzer (a non-participating device that captures bus activity between other devices), NI has the PCI-GPIB+ board. (The '+' denotes the analysis capabilities).If you only want to trace GPIB activity between your own LV code and one or more GPIB devices, you can do this with the NI-Spy application which comes standard with an installation of NI-VISA, NI-GPIB, MAX, etc. You can set it to capture different levels of calls and returns. Hope this helps. Dave

Dominic,Just off the top of my head : Many or most of the functions in kernel32 have both widechar and ANSI versions (like GetVolumeInformationW and GetVolumeInformationA). The prototyping in the .h file has some fancy #ifdef directives which get you to one or the other version, if you're a C compiler, since the C programmer just uses the syntax GetVolumeInformation, which is platform-independent. I think that the wizard is able to parse more straightforward header files, but loses all hope when presented with one of the Windows core components headers. You can look up all the kernel32, advapi, winspool, etc. function documentation using the online MSDN references, then do all the CLN configuration yourself. It's a drag, but I just don't think the new wizard is capable of following all the preprocessor #ifdefs and nested #includes found in the header files you have. Sorry this isn't the answer you sought. Best regards, Dave

Just for completeness' sake, I'll add a slight variation on Mike's reply - perform the test for > 19, then feed that to the boolean terminal of a 'Select' primitive. This is the triangular-shaped node on the 'Comparison' palette which is the LV equivalent of the C syntax: s ? t : f Wire the shift register leftside to the 'f' input, your constant zero to the 't' input, and the output to the shift register rightside. Same result as the case structure, but a little more readable - you don't have to flip the case structure to see its alternate-case code. Hope this helps! Dave

This is really oh-so-easy under Windows. All Windows XP installations have the ActiveX support for the Microsoft Speech API (SAPI 5.1). The VIs in the zipfile posted by Jacendom have most all the functionality you'll typically need, though on quick inspection, the 'Speak' VI seems a bit cumbersome to me - every time it's called, it also goes through all the voice/volume/speechrate stuff as well. This should be broken out into separate VIs which pass the ActiveX refnum through. For some reason I can't fathom, WinXP only ships with the 'Microsoft Sam' voice, which is pretty tedious to listen to - 'Sam' has a few 'speech impediments'. If you do some digging around MS's developer site, you should be able to find the free downloads for 'Mary' and 'Mike' - Mary is (IMO) the clearest of the bunch, and (under SAPI 4) was the default shipping voice with Windows 2000. If you want more voices, you can purchase other SAPI 5 compliant voices from AT&T, IBM ViaVoice, Cepstral, and others - Google on "SAPI5 compliant TTS voice". This is where you'll also find support for other languages, too. Forget about Agent. Last I knew, it still depended on SAPI4 for its TTS abilities, and comes with a lot of extraneous baggage - little animated genies and such - if all you really want is TTS. Happy mechanical talking! Dave

Aaack, ptui! I agree with Philippe - I just took a peek at the BD of the 146chart.vi, without all its support subVIs, and it's hideous. Too bad you're not using the MKS 179A/1179A massflow controllers - I have a classic, pure-G set of VIs for controlling the serial RS-485 version of this series. Wrote 'em myself in, 5.1, I think, and I keep reusing them over and over. You'll definitely be looking for outside help if you're on a deadline. Probably anyone you contract with will need to code at least a minimal set of VIs for controlling the 146. Properly planned, they'll be easily expanded and form a great reuse library. Sorry I can't offer anything up on this device. Dave

Perhaps the attached will be of some use to you. These little data manipulation problems can be solved in so many ways, since LV has a pretty complete set of polymorphic primitives. The VI I've attached is just one way to get there, I'm sure someone else will come along with a cleaner and/or faster approach Best regards, Dave Download File:post-195-1150951577.vi

Let's go even farther back. The oldest Teletypes with which I'm acquainted used a 5-bit encoding called Baudot (pronounced appropriately as the French inventor's surname). With only 32 possible combinations, this required that two bit patterns, designated 'LTRS' and 'FIGS', were used to shift the machine between two interpretations of all subsequent characters. Was widely in use during WW II - I remember my father had a rolled-up spool of punched tape which was a transcript of a letter he'd sent to his older sister, who was serving elsewhere in the armed forces at the time. In the 70's (my teen years), I had a computer instructor who wrote some PDP-8 assembler to read the tape on an 8-bit reader (anybody remember device "PTR:"?), and translate the codes for printing. Sorry for all the archeological diversion... Best regards, Dave

Wasn't there an undocumented way to select a section of BD and turn it into a so-called "inline" subVI? IIRC, what actually happened was a process similar to the 'create subVI' action, except the code got placed inside a single-frame-sequence which was then shrunk down to the size of a subVI conpane. This, of course, could be copied and pasted. Does anybody else have a clue what I'm talking about? Dave

Justin, I'm surprised that nobody followed up on your posting, though I don't know what the 'correct' behavior is for the null length match situation you described. (It's sort of a 'pathological case'.) However, I've recently been trying to use the new PCRE Match Regular Expression primitive, and I've found another behavior that I'd tentatively call a bug. It sure 'smells' like some kind of holdover from C string functions, since it involves null character matching (null, as in character value of 0x00). Basically, I can't find any way to create a regex that will match to a character pattern which has a null character within it. The pattern matching always splits the input string at the nullchar, and if I include \x00 anywhere in the regex (to try to explicitly match the nullchar), the entire matching fails. I don't have any Perl experience - can anyone else tell me if my assumptions are faulty here? Best regards, Dave P.S. I can't identify the node in the diagram below - is/was it a primitive, or was it a VI that had a yellow icon? Can you tell me where to find it?

Thanks, Darren, and I really didn't want to give the impression that I'm upset - in fact I've managed to use the RGT a little in the past few months, am getting ready to use it some more under LV8, and like AMSLLC, I'm happy with it, if just for what it can do to abstract away most of the Excel automation stuff. I just sent an email to my inside sales rep and asked him to double-check the upgrade based on your response. If there are release notes for 1.1.1, I'll peruse those when I eventually get the CD in my hands. Otherwise, I'll bug you for the gory details. Thanks again! Dave

Chris, Hijack away! Over the past several years we've amassed licenses at this facility for LV, TS, MS, plus RT, the RGT, the DCT, so by now we almost surely coulda/woulda/shoulda gone for a DevSuite. Though I'm loath to go back to my boss to ask for more $$$ for 'more LabVIEW stuff', your experience makes me wonder if we might come out ahead. Thanks for sharing your experience. Maybe it's time for our NI inside sales person to 'sharpen his pencil'. Best regards, Dave Darren, Thanks for confirming what I had hoped - that a dot-dot-1 release would be a free bugfix. My inside sales person was apologetic when quoting me the upgrade price, so I'll I'll have to check back with him. Though I probably don't care about the Express VI issue, I would like the 'proper' fix for the palette incompatibility. Take care, Dave

If anyone has a recent copy of the Report Generation for Office toolkit (at version 1.1.1), I'd appreciate it if they could describe to me, or send me, the release notes. I bought a copy less than a year ago (at release 1.1) and recently found that it's 'broken' under LV8. The NI Advisor is offering me an upgrade to 1.1.1 for only 195 USD, which I find a little offensive for a toolkit that's broken by a LV release . I think I fixed the LV8 compatibility problem (seems like it's just some issues with the palette menus), but I can't even find any updated documentation on the NI site. Thanks for reading... Dave

OK, it's been awhile since I even HAD a C compiler installed on my PC, but here goes: Did I get it right?? Hope this helps, Dave

A good free tool that I've used in the past for troubleshooting these sorts of problems is TCPview from SysInternals. If the problem really is as you've suggested, TCPview would make this evident by listing lots of connections in the 'CLOSE_WAIT' state, tying up local ports. Just my 2 cents' worth... Best regards, Dave P.S. And no, you don't want to try to use the same port number on both sides of the connection. At least for 'well-known' ports, that would be simply impossible (i.e., you couldn't likely connect to a web server's port 80 and specify port 80 for your end of the connection. Your OS would most probably disallow you from using any of the 'well-known' ports in such a way.)

If this was buried in the LV8 release notes, I missed it. Certain of the front panel indicators have had a change to their behavior with the release of LV8. It appears that, for FP objects which display a needle on an arc scale (e.g., the knob, the meter, the gauge), if the object has a value of NaN, the needle is not drawn. I actually think this is a useful enhancement, since any other indication could be construed as misleading, though I'd be interested in hearing what others think about this behavioral change. Now, why this change doesn't seem to have been applied to the FP objects with linear scales (e.g., the thermometer, the tank, the horizontal and vertical slides), I couldn't say. I think the same rationale could be used here for drawing/hiding the fill color or the 'thumb'. Anybody know more about this? Dave

I first started with the MS Agent API way back when I was first trying to incorporate TTS into my LabVIEW app. I got frustrated with it because so much of the API is concerned with drawing little floating genies, wizards, robots, etc, when all I wanted was a voice. As far as I know, Agent is still based on the version 4.0 release of the Speech API, which is at an evolutionary dead end. Bottom line - I would avoid it, and go the SAPI 5.1 route. One caveat - the SAPI 5 full SDK installation is massive, on the order of 500 megabytes. If you can get past that, the redistributables are pretty reasonable in size, and I'm pretty sure that all Windows XP installations come with TTS support and at least one English TTS voice (Microsoft 'Sam', my least-favorite... MS 'Mary' is much clearer). 'Mary' and 'Mike' are available as a freely distributable download. Of course, the original posting was about speech recognition, so all my blather about TTS is beside the point anyway. Dave

If you're content to run under Windows only, you might want to look into the Microsoft Speech API (SAPI 5.1). There is already a complete framework for creating speech-enabled applications which is exposed through a very extensive set of automation objects and interfaces. Generating text-to-speech from LabVIEW is pretty trivial. I wrote my first TTS LV application over 5 years ago. Getting speech recognition to work is a good deal more complex, I'll admit I've never tried it. A lot of the complexity depends on whether you want to implement a speaker-independent interface with a very limited vocabulary, or if you need context-free continuous recognition, which requires a training sequence where the recognizer 'learns' a particular human voice. You might start here. Good luck and best regards, Dave