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)

What MUX are you using? ....

Neville.

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)

Good Day!

Can someone give me a sample code on how to make a trial period for my program?. My Idea is i want to read the processor number or board number of the cpu that the program has been installed. Then from that i want to generate a corresponding serial for it. Any idea for a trial period time will be greatly appreciated. thanks in advance and more power to LAVA :worship: .

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)

I get 565ms-585ms without the zero timer

I get 745ms-760ms with th zero timer

This is running on a Core 2 Duo Laptop @ 2.00GHz (667MHz FSB) with 2GB RAM and Windows Vista.

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)

...I remember seeing somewhere that a zero wait allows LabVIEW to yield processor time.....

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)

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)

Looks like my computer is faster than yours - I get 595ms without the "zero" timer and 795ms with the timer.

Build Array should be acceptable in this case because the array is the same size on every iteration, so the memory for it only needs to be allocated once and then it can be reused each time through the loop. You should avoid using Build Array in a loop when you are adding elements to the array on each loop iteration and speed is critical, because adding new elements grows the array. Resizing the array may force LabVIEW to allocate a new, larger segment of memory and then copy all values into that space, which is a time-consuming operation.

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)

The left bracket is used in forming regularexpressions, so you have to use the regular expression for left bracket "\[" (or "\\[" if you are using slash codes).

<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)

Actually, if you're using a RIO device (LabVIEW FPGA) it IS as easy as you've asked for.

Local Device: RIO0

Remote Device: rio://[target name | IP address]/RIO0

It's even remarkabley fast. (though not real-time)

-Noah

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

.....it works fine except for the case where the tab is at the end of the string...... I'm not sure, but this seems like a bug.

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)

It looks to me like what may have happened with mario64's post is that he kept hitting Add Reply with the same text, and the forum software just appended all the replies together (and removed the linebreaks, which is a known problem). A flaky internet connection could cause that, if he wasn't getting confirmation back that each post went through.

:laugh: Careful about wagging the finger, BrokenArrow. Looks like similar thing http://forums.lavag.org/index.php?showtopic=8737&view=findpost&p=39195' target="_blank">happened to you...

The LAVA site burns all of us occassionally with this feature when we reply to our own posts.

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)

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. Richard

QUOTE(mario64 @ Nov 29 2007, 02:46 PM)

Hello osvaldo.I have completed the program as you said.I have found a solution to my problem. Thank you.Excuse me again osvaldo.I have found a new problem.I want to block the vi even when the boolean is not pushed.Excuse me again osvaldo.I have found a new problem.I want to block the vi even when the boolean is not pushed.Excuse me again osvaldo.I have found a new problem.I want to block the vi even when the boolean is not pushed.Excuse me again osvaldo.I have found a new problem.I want to block the vi even when the boolean is not pushed.

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)

hi...i have some problem when write multiple register using modbus library. I realize that when I send more that 1 data ther will be error out and no receive frame from device. my LV is ok when i only send 1 data. plz view my attchments files. tq

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)

Hi all,

I'm a novice Labview user. I have a class project: controlling a USB device with Labview. I've configured NI-VISA to list my digital camera (Panasonic DMC-LC33) as a resource, and I've even written a little VI to write a string to the device and read from it. The problem is that I don't know any USB commands that I can send to my device. Does anyone know any basic commands that work (something simple like IDN? which is a GPIB command) through USB? Thanks.

aarpay

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)

http://www.youtube.com/watch?v=qItugh-fFgg' target="_blank">the Table Control display is foul-up

Just a quick diversion.

~,~

The Captain

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