BrokenArrow

QUOTE(crelf @ Nov 9 2007, 11:26 AM) Excellent hypothosis. No one there (where I used to work) was savy about the LabVIEW.ini file. I had to show them how to put the text in the exe's INI file so that the EXE will show 14-point fonts, so knowing that, you could be spot on. Germany is like that too, using the comma. Wish I lived there... I'd make $5,125 and hour rather than the $5.125 that I make here.

QUOTE(Yen @ Nov 9 2007, 06:58 AM) Ya, same here. I friend of mine took his laptop and perfectly functioning VI's to France. Upon getting there and doing the last minute changes at the customer site, his EXE didn't work but Dev mode was fine. He ended up giving his copy of LabVIEW to the customer, and the customer ran in Dev mode. He never found out why it didn't work in the EXE. It had something to do with a Strings property node - format into sting via an enum or something like that. It was ver 5.1.1. Thanks for the response Yen. :beer: Richard

Hello all, 1) When do you know that a RMB selection check marked will work in an EXE? 2) There a RMB setting for Limit to Single Line, and also the Property Node, LimitSgLine. Set that to True. Same thing. ... but which one is "safer"? The Property Node's help says it's avalable in the RunTime Engine. So there, I feel safer it'll get set and stay that way. Plus it's more explicit when reading the code. 3) When the help for a given function/node/invoke etc. says it's "Available in Run-Time Engine", does that ALWAYS mean it will work in an EXE? Thanks! Richard (RMB = Right Mouse Button)

QUOTE(tcplomp @ Oct 27 2007, 02:54 PM) Saturday afternoon here, another exciting weekend in Parenthood. Yen, I have noticed that Merge VI is now called Place VI Contents. I posted that on the NI nugget. Richard

QUOTE(Yen @ Oct 27 2007, 02:36 PM) Yen, Regarding the cluster vs. flat data, it's a bias on my part, having been told 6 or 7 years ago in some LabVIEW book somewhere to "keep data as flat as possible". Putting the data in a cluster has the advantage of just one wire "passin' through", which is an obvious advantage. When you unbundle it, there's your label. I probably should rethink some of my biases. But I still want me wire lables!

QUOTE(tcplomp @ Oct 27 2007, 01:19 PM) Right Ton, but it ain't the same. One, because you have to "hover over" the wire to see it. Plus, it doesn't have the intelligence to know that the entire wire node is the same name. For example, you can name pieces of the same wire (i.e data) different things, within different cases/sequences/loops. For that one reason, I've found that "describing" a wire is next to useless. My habit of using free labels is also problematic, because the labels aren't attached to the wires, and can get moved or lost. I spent most of the 90's doing schematic capture and PCB design, and got used to having wire labels (net labels) showing wherever I wanted them. Net Ports were also nice, but in LV, those are Local Variables RichardQUOTE(Yen @ Oct 27 2007, 02:20 PM) A few additional relevant options for the present: Use a cluster for your state machine SR. This allows you to pass multiple values on a single wire and makes it easier if you need to add new states. Handling the value is simply a matter of unbundling and bundling by name. Use the label available in the system controls palette. Drop one on your FP and then drag it to the BD. It has the advantage of having its background adapt to whatever is under it, so you can place it on the wire itself and it looks nice. Create some merge VIs with the relevant labels. This will probably speed up your process somewhat. 1. I beleive that if you have flat data, it should stay flat. 2. Neat, but as I said in my last entry, this type of label could "get lost" couldn't it? I'll try it. 3. Good idea. I've actually left my "WireLabels.vi", where I go to copy and paste labels, in the digram by accident! Richard p.s. Yen, I never knew the System Controls label was transparent by default -- that saves a step when you want a transparent label. Cool, thanks! :thumbup:

Schematic capture programs have had wire labels for decades. Seems like an obvious thing for LV. I'd prefer color-coded like my example here. I have a VI full of these color-coded labels, and I use it to plop down labels, but this should be an easy thing to implement with a Right-Click, Show Wire Name. I've found these labels particularly useful in state machines when the data is "just passin' through", or of course on long wires. Richard

QUOTE(ned @ Oct 26 2007, 05:20 PM) Excellent point. Luckily in this app, my "consumer loop" has all of the timeouts wired to 100mS, but you know... I'm hosting an RT session, which I didn't write the VI's for... so I think I will release the notifiers. Thanks for the incentive. Richard

QUOTE(Michael_Aivaliotis @ Oct 26 2007, 04:21 PM) ....I can't tell you how much work I do for that very reason. Sometimes 30 minutes of writing unnecessary code is less painful than the ad-hock meetings that occur due to the lack of that code. Good point. Richard

You say you have LabVIEW 7.1 "program", but do you have LabVIEW 7.1? If so, and you know how to write simple code in LabVIEW, then write your own emulator in LabVIEW. I mean, you have the computer, you have the device, so you must know what the packets of data look like that you want to "emulate", so look at the VISA serial port examples, write up a quick program, throw it on a laptop, and that becomes your emulator. Richard

Hello all, Is it really necessary to release Notifiers and Queues when you're exiting a program? By habit, I do it, but I'm thinking if LabVIEW is quiting, or the EXE is closing, what's the point? Thanks, Richard

.... If displayed in a Windows (and LabVIEW) control you can also get away with setting them to certain fonts ...... Rolf Kalbermatter Indeed. But getting everyone who may look at the data to set Notepad or Wordpad, et.al. to a certain font is a leap. I just made a text file that looks great in Courier (width defined characters), good (not great) in Arial, but switch to Times' and it's hosed up. I installed our Reports Toolkit last night with much hesitation, and I'll probably end up using Excel for the "human viewable" report. -Richard (p.s. On a side note, if you use the Excel VI's and want to make an EXE, remember to include the proper Dynamic VI's in your build! :headbang: )

Thanks for all the response. Yep, this seems like more trouble than it's worth. The customer is used to an old DOS-based text file that had those box characters. The way I got LabVIEW to do it was to send FFFE 6625 and I got ╦. BUT, when it writes the "txt" file, and you open it in notepad, sure enough it looks fine, but it says it's Unicode encoded. Try to read that file BACK into LabVIEW and it's SOL. Thanks for the education, I didn't know "extended ASCII" was so softly defined, since I've been using those alt+200 type things successfully since 1986 in DOS, I just figured it would work the same way in LV. -Richard

Hello all! I need to write, to a txt file, some of the extended ascii characters, specifically the "box drawing" type such as alt+203, alt+204, etc. How is that done in LabVIEW? I've done it with unicode (by writing FFFE 6625 for example, to get one of the characters), but as you know, the file resulting Unicode becomes useless to LV when you read it and parse for data later. Thanks, Richard (lv 8.2.1)

Your "One more thing" is a good thing to know. My issue with replacing RS232 stuff with USB is the drivers required. It just seems when RS232 stuff works, it works great and works from computer-to-computer with no issues*, whereas the USB DAQ piece may require a CD-ROM to float with it where ever it goes. *ASRL1::INSTR vs. "COM1" notwithstanding

What are some of your favorite "generic" (i.e. non-NI) DAQ instruments? DIO, AIO, etc. I like Ontrak, for reasons I can't really explain other than comfort level, and Measurement Computing, which most of you have probably heard of. -Richard

Hello! This site is great. This is the de-facto NI forum gap filler. But seriously, if you havn't tried the NI forums, they are also a great source. Different "climate" there, more conducive to the kinds of questions someone like me mught ask, like "what's a Refnum?" http://forums.ni.com/ni/board?board.id=170

knock knock, hello? lack of deoderant? stupid question?

Hello all, There's a thread on NI about this, but it's not very conclusive... I have an issue where.. A computer had (and still has) LabVIEW 5.1.1 installed. I then installed the LabVIEW drivers for 8.2.1 in order to get NI-DAQ and MAX, and the Run-Time engine, so that applications built on 8.2.1 will run. At first, I just installed the 8.2.1 Run-Time engine, but I realized later I needed MAX to configure the com port aliases. So that's why I installed the NI-DAQ/MAX. The computer now gives me an error when it boots up, regarding nidevmon.exe not being able to start. Also, MAX doesn't work - it will not find the devices - tells me to restart the computer. The application built on 8.2.1 is working fine. As is the 5.1.1 development system. So it's basically an irritant - the nidevmon.exe and MAX not working. I've tried uninstalling MAX and reinstalling, to no avail. Any ideas? Thanks!

QUOTE(tcplomp @ Jul 17 2007, 02:49 PM) Great stuff, from the horse's mouth! QUOTE(Val Brown @ Jul 17 2007, 02:50 PM) .... I would STRONGLY suggest using XP and maintaining the legacy serial driver routines ..... OK, so I've got an opinion! Yes! It has been our experience that XP and serpdrv work OK together. I'm sure VISA is better*, and I'd take a reduction in pay to be able to change our old 5.1 code to 8.2.1 / VISA, but they know it would be a month-long project, and we be a tiny company. THANKS for all the suggestions.! * VISA functions also have error in/out and more easily follow LabVIEW style. They are worth it for that alone. No one mentioned that, thought I would!

Indeed, this old app uses the old serial drivers. It has to stay in 5.1 for reasons I won't go into here. Apparently, the old code does work on an XP system. On a different application, when I converted it to 8.2.1, the old serial VI's caried over, but if you open them up, it's VISA. Unfortunately, this one old program has to stay with the old serial port stuff (i.e 5.1). I could probably have a good argument for taking the time to redo this old app in 8.2.1, based on the newer drivers. What's the biggest drawback to the serial drivers of 5.1? I remember using them in 6.i, then switching over to VISA when 7.1 came out, but I don't remember the old stuff NOT working. Richard

Hi all! If you had a system that ran 9 com ports and did a lot of file I/O, with multiple parallel loops, would you choose Windows XP or 2000 Pro? The choice IS limited to those two, no Linux or MS Bob, etc. If you know of any reasons why one is better than another and can share that with me, I'd appreciate it. THANKS! p.s. this is for a built app LV 5.1.1

QUOTE(tcplomp @ Jun 20 2007, 01:53 AM) Ton, I love LV2G's, thanks for the idea.

QUOTE(Ben @ Jun 19 2007, 09:09 AM) Ben, By "use seperate "opens"" do you mean are the VI's different that do the opening? There's definately one write. QUOTE(tcplomp @ Jun 19 2007, 09:14 AM) A better solution is the fileinfo primitive: Link If I were you I'd use a messaging system, but since you are debugging most likely you inherited the code :headbang: Ton That's a great idea Ton. That way, it's not opening and closing the file just to see if it has changed. Or, if it does open it, at least it's a different open as Ben recommended. -Richard ----------------------------- p.s. Is writing to a file a common way to share a variable? (keep in mind this is 5.1)

QUOTE(LV Punk @ Jun 19 2007, 12:06 PM) Indeed. This is 5.1, which doesn't show the flow direction on terminals and lets you wire from any direction. This inherited code is full of that kind of qurky wiring. QUOTE(jpdrolet @ Jun 19 2007, 11:06 AM) The safest way to implement this is to add a shift register in the for loop and feed it with the char offset wire. Sweet. If I had a dollar for every time this code used a local rather than a shift register, I could buy this website and host porn. Nah, they'd never allow porn on the internet. QUOTE(Jim Kring @ Jun 19 2007, 10:16 AM) It is a classic example of a race condition. Thanks Jim and Ton. Every time I mention "race condition" around here they look at me like I'm making sh!t up. -Richard