BrokenArrow

QUOTE (Gary Rubin @ May 15 2008, 10:48 AM)

My experience is that these are usually so poorly written (i.e. overuse of sequence structures) that we end up rewriting them amost from scratch anyway.

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)

As to being compiled, as far as LabVIEW is concerned there should be little difference between development system and runtime system performance.

Rolf Kalbermatter

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:

1. I've concluded that this topic is "entirely arbitrary and subjective" to borrow a phrase from Rolf. :worship:
   
2. 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:
   
3. 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)

A good driver is generally a collection of vis. If your hardware has a single vi as a driver it likely needs to be broken up or rewritten.

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)

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)

... it's all a matter of your frame of reference.

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)

.....a hand full of turd balls...

First time I ever LOL'd reading a LAVA post!

Richard

QUOTE (Dan Press @ May 13 2008, 09:12 AM)

If it's throughput you seek, shared varibales may not offer the best solution. The way I see it, you have two options.

1. Pad your data such that each Write is at least 2033 elements. Just make sure your first element is equal to the number of real elements you wish to process on the other side.

2. Switch to raw TCP and make your own protocol.

I agree that your timing results are troubling. I've seen similar spooky things with network shared variables.

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)

Spot-on my observations.

Richard

When is a VI a "driver" ?

1. It never is
   
2. It always is, if it talks to hardware
   
3. When the VI works only on a specific brand/model/part number of device
   
4. When its main purpose is to make API calls
   
5. When your manager, vendor, or girlfriend referes to it as such
   

Thanks!

QUOTE (rolfk @ May 13 2008, 03:20 AM)

Flush Buffer will delate data already in either the receive or transmit buffer. Discard Event will discard any events that might have already been queued for the current refnum. That are two very different things.

Rolf Kalbermatter

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)

Thanks sooooooo much!!

and thank YOU for not being a "One hit Wonder!" :thumbup:

Richard

QUOTE (fuzzyspot @ May 4 2008, 11:59 PM)

......I onlly typed in things like "BD1", "H+", etc. Should I convert them to HEX or DEC format? .....

1. You need to leave the String input "Normal", not HEX and definitely not DEC. Those are plain ASCII characters you're sending.
   
2. 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)

Hi again ,

after the switch to 8.5.1 together with a new PXI controller the memory consumption remained stable......

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)

....I have installed every LabVIEW version since 5.1 up to 8.5 and a bit more on my development computer

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)

... getting rid of globals might have done this trick in two ways. First saving lots of data copies just for the sake of the removed global itself and the necessary changes in architecture might have given LabVIEW a chance to actually use optimization in other places too.

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)

I'd like to nominate http://forums.lavag.org/Jim-Kring-m17.html' target="_blank">Jim Kring for a (IMHO long overdue) TALM award. Jim's personal dedication to the LabVIEW community is truly wonderful:

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)

I would trade a nice LabVIEW state machine for a TestStand sequence any day.

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)

Perfect reasons to use TS!

QUOTE (Tim_S @ Apr 28 2008, 10:30 AM)

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

Can the configuration be made persistent so that it doesn't disappear between TestStand test steps?

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