BrokenArrow

Hello all, NI has an open ticket on a known bug in LabVIEW 8.5 with Shared Variables causing memory leaks. Specifically, String type, Network Published (I'm not sure if Single Process has the leak). The problem supposedly does not exist on 8.2, it came with 8.5. There's talk of this on the NI forums as well, just wanted to mention it here. The advice is: 1) Don't use string type Shared Variables in 8.5 2) If you must use strings to communicate from a target to a host, convert the strings to U8 arrays (and back again). I've lost a few days of my life due to this bug. The workarounds do appear to fix it. -Richard

QUOTE(Neville D @ Jan 23 2008, 01:46 PM) Thanks Neville. It's a 2576 Mux. I actually misspoke in my post. Running that Wait 'til Debounced VI every time IS adding to the time (as you'd expect). I moved that VI outside the for loop, and shaved off 20mS. Like you said, I'd like to have a method of telling the device to remember a known sequence and treat it like one relay closure rather than 8 sequential ones. I guess I'm wanting this thing to run as fast as it can, electrically, without the VI's adding more than the typical mS or two. The datasheet says it takes 3.4mS to switch a relay, so 8 in sequence, I'm almost spot on. However, I'd much rather have it be 3.4mS TOTAL, which should be acheivable, if all 8 relays were actuated at the same time. I haven't investigated lower level methods of talking to the mux. It's crunch time, and I may have to settle with the extra time. Thanks again Richard

Hello all, I'm using niSwitch to actuate relays on a 2576 MUX, via the method in the attached picture. I was dissapointed that niSwitch doesn't have a way to feed multiple relay actuations at one time, unless I'm missing something. The attached method takes about 50mS to switch the relays. Oddly, the Wait for Debounce is NOT causing the bulk of the wait. I think it's just the fact that the VI (an API call I think) has to run 8 times to switch 8 relays. Is there a better way to do this? A relay should be able to actuate and debounce in just about 10mS tops, and there's no reason why you shouldn't be able to actuate 8 at one time (IMO). Thanks, Richard

QUOTE(Kyuubi™ @ Jan 17 2008, 08:30 PM) The way I've done this has been to write a date stamp to a binary file, which can be deeply embedded in other binary "junk" so that the file is quasi-encrypted. This file is the date of installation + n time. Then just have the program look at that file and compare it to the current date to see if the "trial" period (n time) has elapsed.

QUOTE(TobyD @ Jan 8 2008, 11:42 AM) Dang, everybody's computer is faster than mine, which is a Dell desktop, XP, Pentium 4, 2.8 GHz, but only 512MB ram. I'm not a computer expert, but 512MB of ram on a P4 2.8GHz seems like putting Bose speakers on a Conrad Johson tube amp. (and by Bose I mean bad and by Conrad Johson I mean very very good).

QUOTE(ned @ Jan 8 2008, 08:30 AM) Exactly the reason to include it, and excatly the lament I have whenever someone edits my code and gets rid of the timer because "it was wired to 0 anyway!" :headbang:QUOTE(rolfk @ Jan 8 2008, 06:37 AM) Vi Analyzer is some LabVIEW versions old now.......... Thanks for that info Rolf, good to know. I do know that the Analyzer has a bad case of OCD, or anal retentiveness.QUOTE(rolfk @ Jan 8 2008, 06:37 AM) But it [build array in a loop] should always be checked and double checked if you do not want an application that gives you way to much coffee time when it is run. Coffee time is a huge no-no in this ap. But, as long as it's a set number of indecies, it shouldn't be an issue. I ran the loop 10-million times and it never "slowed down" as the VI Analyzer warned it might. Thanks for the responses! =============== OK... I got 27 downloads of the VI so far and only Ned has reponded with a time test.

QUOTE(ned @ Jan 7 2008, 05:11 PM) Thanks for the test Ned. The speed might also have something to do with Windows running junk in the background, virus-this and nanny-that. True regarding the Build Array in loop, but VI Analyzer said it was a no-no, whereas the attached VI had no issues. Seems like VI Analyzer would be smart enough to see that it's a set number of elements and not wag the finger at me. If you had this VI running, say 50 times a second, would you use the "zero" timer or not?

While experimenting with methods to update an array, I intended to check the speed difference when initializing outside the loop vs. inside. While it wasn't surprising that that made no difference, I was surprised at the difference the "zero" timer makes. Is there a faster way to do this? Oddly, I found using Build Array in the loop (a LabVIEW no-no, I thought) is just as fast as this method, and a little cleaner looking. Check this VI if you get a chance. My results are written on the BD. Thanks, Richard

... and if the called VI runs in a separate loop, all you need is a global boolean OR'd to the Stop of the callee, fired by the caller.

QUOTE(TobyD @ Dec 20 2007, 06:23 PM) <Homer Simpson> D'Oh! </Homer Simpson> I knew that... Thanks Toby!

Check out the attached VI. Why doesn't LabVIEW find the "[". ??? My slogan for this month has been "nothing is easy". Thanks! Richard

QUOTE(njg @ Dec 18 2007, 03:04 PM) Yep, myself and others have lamented the decision to not use cRio / FPGA for this project, but there IS a major portion of the data that needs to be real time. What I'm dealing with now is, all the other PXI devices in the same chassis as the RT target that don't need to be there (should be controlled by the host IMO) - I have to write two VI's to access those cards. I was just wondering how other people might go about getting data from the RT. I guess there's no "easy" way -- Shared Variables or TPC/IP. Again with the head on wall thing >>> :headbang:

When speed if not a concern, it seems to me there should be an easier way for the host to "ask" the RT system for data. Such as DAQmx Tasks, running on the Host, with explicit MAC Address + Task name! Just a thought. Take the example of an RT system with eight slots, and a DMM resides in one slot. You want to get the voltage reading and you could care less if it's in "real time". I'm currently using Shared Variables, but it seems like a lot of smoke and mirrors for just a tiny piece of data that could take 500mS to get back to me for all I care. (notwithstanding the argument that the DMM does not belong in the RT chassis if you don't need RT data from it :headbang: ). Richard

QUOTE(Yen @ Dec 5 2007, 10:45 AM) That's where the Tab is, at the end. The incomming text from a barcode scanner has a Tab at the end. And I agree that it's a bug, or at least an oversight on NI's part that it can't be done. The tangent I was investigating is that you can't type a Tab at the end of a string and have it "stay".My work-around has been to reprogram the barcode scanner to not have a Tab at the end. That's a pain, because I have to ensure the end user also does that, or deliver the scanner as part of the product.RichardQUOTE(Yen @ Dec 5 2007, 10:45 AM) In any case, here's one (bad) way of how this can be done (8.0)..... Bravo Yen! That's excellent. And it's a pity that we'd have to do these tricks to have the Tab "stay" in the control. Seems like we could turn off tabbing so the loss of focus wouldn't happen in the first place.Richard

So I guess the fact remains, you can not type a tab into a LabVIEW string control without causing issues. Hence, my #2 question, (and lament) that you can not (?) turn off tabbing. (?) Excellent responses, thank you! Richard

Both of those are good ideas for firing an event based on a tab being present, but one thing persists, you still can't type a Tab into a string control (set to show '\' Codes Display) and see the Tab (\t) it in the control - LabVIEW will pop out of the control when Tab is hit. Richard

Both of those are good ideas for firing an event based on a tab being present, but one thing persists, you still can't type a Tab into a string control (set to show '\' Codes Display) and see the Tab (\t) it in the control - LabVIEW will pop out of the control when Tab is hit. Richard

Hello all, 1) How do you look for a tab constant comming in on a String control? The tab is causing LabVIEW to just "tab" to the next control, which looses focus, and the tab's "not there". I've tried turing off tab navigation on that control, to no avail, it still looses focus when the tab comes in. My work around is to look for the loss of focus (property node) but I was wondering how you'd do the tab search thing. (string comming in is from a data scanner, i've verified (using Word) that there's no other characters besides the tab after the data). 2) Can you turn off tab navigation overall? I can't do that on this panel (user needs to tab through lots of fields) but I was wondering if it's even a possibility. Many thanks, Richard

QUOTE(Aristos Queue @ Nov 29 2007, 06:12 PM) In my case I literally forgot that my VI had sub-VI's so I just replied to my post and added them. Very squid of me. The wagging finger was tounge-n-cheek, but we don't have an emotocon for a tounge in a cheek! Had I been truly miffed at mario64, I certainly wouldn't have taken the time to clean up his VI so well! (even though he's probably gone by now). Here's one for all of you >>>> :beer: (non-drinkers pretend it's Ginger Beer). Richard

I'm a little late to the party on this one, but I found this to be an enlightening thread. Great stuff by all. I agree that clones are a pain, but I love them LV2 style globals. Attached is my demo of a classic LV2-style global VI, and it's behaviour if when reentrant and not. RichardQUOTE(BrokenArrow @ Nov 29 2007, 05:42 PM) oops. attached are sub-vi's for that demo

QUOTE(mario64 @ Nov 29 2007, 02:46 PM) OK, you want the Stop button to stop everything, even if Boolean isn't True. There was (and still is) a lot of fishy stuff going on, but the attached VI solves your question. Please don't muck up this great forum with the copy-n-paste , we know what you meant. Richard

QUOTE(gdah @ Nov 19 2007, 11:39 PM) Do you know how modbus works? Your data is heavily laden with a header and footer, address information, possibly a checksum and even a 2's compliment flux capacitor on the end. Point is, One packet expects One message, so don't send more than "1 data". I hope my answer is at least as clear as your question.

QUOTE(aarpay @ Nov 24 2007, 03:56 PM) I doubt you'll get anywhere just shotgunning commands to your camera. Your camera is just a black box, and you are talking through a UART to a microprocessor, which is running application-specific firmware which has a known set of commands, but you'll never know them. Be cool, stay in school. Richard

QUOTE(Norm Kirchner @ Nov 13 2007, 04:43 PM) I had that in my mind as the link was opening! -------- ttkx, New transparent control (boolean "double-click to find me") over erratic transparent table. Just overlap the problematic table a small fraction and Bamn! All your data are belong to table.

:thumbdown: odd. Attached is a workaround. Richard