BrokenArrow

QUOTE (Gary Rubin @ May 15 2008, 10:48 AM) Yep, or so old that they use the old serial driver interface! I just re-wrote a handful of turd balls from [popular signal generator company] into one VI. (note I said one "VI" not one "driver")

QUOTE (rolfk @ May 14 2008, 04:25 AM) Agreed! I wonder if it's the benchmarking rouine that could be to blame? Maybe "Tick Count" works differently in EXE than Dev, and what I'm seeing is the burden of the Tick Count as opposed to any real time differences in the code between the ticks. (?)

Thanks for all the responses. Great stuff. I've come to three conclusions: I've concluded that this topic is "entirely arbitrary and subjective" to borrow a phrase from Rolf. :worship: When the Quality Department asks me to divide my Software Release Document into the VI's that are drivers and the VI's that are not, I will just make a best guess and that'll be that. It may be up to non-LabVIEW programmers to make my mind up for me. :laugh: I know that when I add "EasyDAQ.dll" alongside my VI's, there's going to be heck to pay. Richard

QUOTE (Daklu @ May 13 2008, 07:14 PM) Well, I think that's true to the extent of complexity of the "thing" you're driving. I've used devices that just do one simple thing and the VI can fit on 1/3 of a screen, such as a high-current relay output board with just two relays. So to your point (or against it) I guess that would be an example of one VI being a well written driver. But I assert that it isn't a driver, but is a LabVIEW VI. QUOTE (crelf @ May 13 2008, 06:25 PM) I'd say A that is also a B with some C Well, since I wrote it, I can assure you it is a C (Turd Ball). :beer: Richard :beer:

QUOTE (crelf @ May 13 2008, 03:56 PM) Argh! OK. WHAT is THIS?... A VI A Driver A Turd Ball All of the above

I agree with the points that Gary and Paul have brought up. To take it a step further, a driver (to me) is something that a piece of hardware *can't* work without (think printer driver), whereas if you've written a LabVIEW VI that controls a device, the device may still stand on its own with something written in (god forbid) C or VB or Cobol or Fortran or Pascal or JAVA or HPV.... ... ... Thanks for the input, I've been trying to get people to stop calling LabVIEW VI's "drivers" because I think that terminology can confuse a customer/user. OK, back to my hand full of turd balls. These arrays aren't going to index themselves. Richard

QUOTE (Michael_Aivaliotis @ May 13 2008, 01:36 PM) First time I ever LOL'd reading a LAVA post! Richard

QUOTE (Dan Press @ May 13 2008, 09:12 AM) So Dan, you have experience seeing TCP being faster than Shared Variables? I have seen the somewhat counter-intuitive behaviour of the TCP routines being a lot faster than Shared Variables in Development Mode, but once an EXE was made, the TCP approach only yielded a modest speed advantage. There's a lot going on under the hood of Shared Variables (variant VI's and whatnot), but maybe once it is compiled.... ? QUOTE (vestman @ May 13 2008, 09:04 AM) ....when using a smaller array this time increases to a whopping 31ms. Spot-on my observations. Richard

When is a VI a "driver" ? It never is It always is, if it talks to hardware When the VI works only on a specific brand/model/part number of device When its main purpose is to make API calls When your manager, vendor, or girlfriend referes to it as such Thanks!

QUOTE (rolfk @ May 13 2008, 03:20 AM) Rolf, Indeed they are different, I didn't mean to imply that they were similar, but does it make sense to create an event and immediately discarding it as this example is doing? The reason I suggested the Flush was, if the hardware were filling the buffer with "stuff" by the time he got around to doing the next Read/Write there would be trash in the buffer, so a tabula rasa would make the reads clean. I thought maybe whatever the Discard is asserting on the line might be analogous to clearing the line, but it isn't - thanks for the clarification

All of these serial devices have idiosyncrasies that often just have to be shotgunned. Still looks odd to me, the Discard. Maybe Flush Buffer would work? But hey, if it works it works! :thumbup: If you can't string together your commands with ";" or CR/LF (the typical method), you could still combine your Serial Writes with a For Loop. Congrats on the success, thanks for checking back in.

QUOTE (fuzzyspot @ May 5 2008, 12:53 PM) and thank YOU for not being a "One hit Wonder!" :thumbup: Richard

QUOTE (fuzzyspot @ May 4 2008, 11:59 PM) You need to leave the String input "Normal", not HEX and definitely not DEC. Those are plain ASCII characters you're sending. You need to send a CR with the string to satisify the <enter> that you'd normally do in HyperTerm. Concatenate a CR or a CR/LF combo with your string when you send it. See attached JPG. Richard

QUOTE (Götz Becker @ May 5 2008, 04:13 AM) That's great news. NI said the next release (after 8.5) would fix some of the leaks. I'm glad to see that ugrading may be worth the trouble. Thanks for checking back in.

Guten tag Markus, I don't have that Keithley driver (vi), so I can't steer you to an exact solution, but I do have a few comments: Why do you Enable the Service request then immediately Discard it? If Keithley supplied a set of VI's to you, then I doubt you even need to enable a VISA service. Check with Keithley for an example. Richard

QUOTE (rolfk @ Apr 30 2008, 02:50 AM) Then you need to update your info below Chewbaka, which reads "LV:7.1 ,8.0.1 ,6.1".

QUOTE (rolfk @ Apr 29 2008, 06:39 PM) My thoughts exactly. Many of those globals were being used as locals, and those "variables" were used to avoid shift registers. I think the customer got a lot more than he thinks from the cleanup labor, which he was initially skeptical of.

Thanks for the responses! I need some fodder to explain why a 5.1 to 8.2 conversion runs faster. Getting rid of a lot of globals, and using VISA rather than Serpderv, and the un-called panels (that used to run in the background) are the only things I can think of that programmatically sped things up. It likely has more to do with better folding / compiling since 5.1 Richard

Hello all, If a VI is set so that it does not show the FP during a call, does it still take time to update the indicators? Also, regarding this, has there been a significant change from 5.1 to 8.X regarding how indicators are updated when the panel is not shown? Thanks, Richard

QUOTE (crelf @ Mar 20 2008, 04:38 PM) Agreed! Jim Kring is the Neil Peart of LabVIEW! On a side: One thing I really like about LAVA is the diversity. All are welcome, but experts hold the fort. When I open a thread, and I see it peppered with names like crelf, Jim, Aristos, et.al., it makes me want to read further. These experts add a sense of validity to a thread. I mean, who wants to see answers from squids like me? (although I nominate myself as the Champion of the One Hit Wonder). But.. what about the guru lurkers out there? I know of several mighty LabVIEW Champion members that just don't post. Attach the ChipIn widget and get to postin' ! Richard

QUOTE (Michael_Aivaliotis @ Apr 28 2008, 05:12 PM) Dido. There have been many a test engineer manager that have been sold on the idea that you NEED TestStand in order to sequence your individual LabVIEW "tests". That, and TestStand can provide "reports". This is insipid. LabVIEW can do all of that, espaically with Toolkits. Why not just develop a LabVIEW interface that sequences the VI's? Some people think that without TestStand, you can't (for example) skip test 2 and 3, do test 13 twice, then go back and do test 1 again. Rubbish. Yes, TestStand has it's place, but it's not worth the effort JUST for sequencing already developed LabVIEW VI's. QUOTE (jhoskins @ Apr 28 2008, 05:28 PM) ...... I love the fact that I can code my tests in just about any language...... .... .....Try debugging a C dll in a LV statemachine! ..... Perfect reasons to use TS! QUOTE (Tim_S @ Apr 28 2008, 10:30 AM) LabVIEW is a programming language; Measurement Studio is a group of controls........... This is true, but I think we can infer that he meant Visual Studio, and was using Measurement Studio for the controls? QUOTE (jhoskins @ Apr 28 2008, 04:59 PM) I would agree with Michael in the fact that you do have to know som C syntax to get the things that you want from teststand. I still don't buy this, simply because if I can use it (with my limited C skills), anybody can! :laugh:

Reem, That's not a DAQ, it's a breakout board. I honestly think you're missing some high level knowledge. Is there anyone where you work that has programmed in LV that can help you? "Creating a Task" is plain LabVIEW talk. Read up on MAX (Measurement & Automation Explorer), DAQmx, and find your DAQ!

Michael, Why do you refer to TestStand as a text-based language? I have months of mouse-induced carpal pain from "programming" in TestStand, and other than being in pull-down list hell, I don't recall "typing" a whole lot.

QUOTE (SPM @ Apr 28 2008, 10:49 AM) Certainly. Load the system parameters from a text file into the the VI's that need the info. If VI's share information dynamically, a file is a easy sell-off to agencies because the data is "always there". As TestStand calls the VI, the VI will load what it needs from the file. It only takes a few mS to read several hundered lines of configuration data. When each VI exits, it reliquishes its memory (or at least it should - close your references), but that's OK because we were reading the parameters on each call. Would this scenario work? How are you doing it now? edit: .... also ask yourself.. do you really need TestStand? What is it doing in this case that LabVIEW couldn't do by itself?

SPM, You are inferring that there is something intrinsically wrong with LabVIEW insofar as how it handles memory. If this is what you truly believe, then you've answered your own question. You might need to explain your complaint more specifically in order to get help. For example, can you give an example where a VI had a hard time retaining a value? Also, how is TestStand going to tell LabVIEW to dump memory? Richard