Sparc

Reminds self to be more pedantic when posting.

QUOTE(Gavin Burnell @ Jul 6 2007, 02:35 PM)

Assuming you don't care too much how verbose your TCP transmissions are, why not use the (un)flatten to/from XML functions ? They (obviously) don't use a type descriptor array and with the string data being human readable it might be easier to debug if the conversion failed...

These functions are substantially slower than the raw Flatten/Unflatten. Fine for a final write out to file, but not something I'd want in a loop.

Sparc

Plain labels don't have property nodes.

Use a string indicator with a transparent background and border instead. The Classic Controls->Strings->Simple String is ideal for this.

Sparc

In somewhat never ending attempt to get some of LabVIEW's UI controls to behave more like traditional Windows controls I have long sought for 'smooth' scrolling arrays. Now, using splitters and panes I finally have an array of clusters that will scroll smoothly. Feel my joy!

Now that I have achieved this, I want to tab through the elements for data entry. I can get the focus rectangle (KeyFocus) to the controls in the cluster (in the array) and it will cycle through them, however it only cycles through the controls in one element of the array.

How can I make is so when the last control in the cluster has the focus and the user presses 'Tab' that the focus rectangle jumps to the first enabled control in the cluster in the next element of the array?

There appears to be no subtle method for setting the element the focus rectangle should be on. I can set the 'Index Values' property of the array, but that affects the visual appearance of the array as well (causes the wired index to become the element in the top of the array). The SelStart property has no effect. :headbang:

Note you can mouse click on a new element in the array and the focus rectangle will follow the mouse and not change the visual appearance of the array.

Smooth scrolling array example in LV 8.2 attached.

I'm spec'ing some hardware for a client. I need 12k (or more) discrete steps ramped in 500 uS. I find the NI PCI-5421 (100 MS/s, 16-Bit) and am quite happy. Until I read "Amplitude Resolution: 3 digits". I also read somewhere "AC accuracy: 1 mV". WTF?

I called NI and was pointed to this as an answer. I'm not sure what that answer was other than "its a floor wax AND a dessert topping".

So if you any of you guys have experience with this device can you please answer me this simple question:

If I use this device to drive a 0 to 2 V ramp with 12000 steps, will I see 0.00016 V increments in the output waveform? This signal will be driving the control input for a laser while I won't be measuring the output directly, I should be able to detect the change in wavelength with another instrument.

And, if you could answer how 16-bits = 3 digits I'd love to hear that too.

Your help is appreciated,

Sparc

QUOTE(Eugen Graf @ Mar 16 2007, 03:28 PM)

I knew of them what you wrote, but why Windows don't give a NOP functionality, how in uCs. I don't want to wait any determenistic time, but less than 1 ms without 100% CPU load.

Eugen

Should I ask Bill Gates?

:thumbup:

A NOP would still give you 100% cpu load since all it does is increment the program counter and eats up exactly one clock/instruction cycle. A loop of NOPs would indicate 100% cpu usage. It always has.

If you want NOP functionality, you need to use rafa's idea of an active wait, cause thats all NOP ever did.

What you want is a thread Sleep with more than 1 mS resolution (Want to me to break out my grouchy old man voice and tell you that not long ago the best we could hope for was 15 mS resolution?). As others have stated, Microsoft's Desktop OSs don't offer that resolution for a multitude of reasons, the most fundamental being you don't need it for an OS designed to be operated by humans.

If you only get 100% usage while talking to your hardware and you don't have it pegged for hours on end, I wouldn't worry about it too much. But if you're hung up on it here's how you can reduce it. Run your little loop without any delay for 999 iterations. And on iteration 1000, add a 1 mS delay. Rinse. Repeat. It'd be smarter to add that little delay at some non-critical moment instead of a fixed 1000 iterations, but hopefully you get the idea.

Better yet, check and see if your [wiki]DAQ[/wiki] card has any buffer memory where you can write a waveform.

To update a value of a cluster, don't do it via a reference. Unless you like slow and complicated code it is usually better just to pass the value of the cluster around.

Use references to affect how the cluster looks or behaves. Unless you have a compelling reason, don't use references to just to update a value.

If you've found that every time you change what the cluster holds that all your sub-vis break, you should turn your cluster into a type def.

Sparc

Somebody knows if all this scripting feature can be applicated to the same vi (where it is running), instead of create a new VI?

Thanks

A. V.

6020[/snapback]

Scripting features that actually modify VIs cannot be used on a running VI nor one reserved to run. New Object, for example will fail if the owner object is, or is in, a running VI.

However, scripting Properties like "Is Indicator" can be used on a running VI.

Sparc

What I am looking to do is make somthing that operates as the end user would expect.

In this case the addition needs to happen at the bottom.

The user is going to expect a scroll bar rather than a slider for the fixed number of elements workaround, because the scrollbar gives feedback to the number of elements out of view.

I've given into the fact that there is no way to easily accomplish this and have moved down another path.

Thanks for all the help! :thumbup:

5559[/snapback]

Provided its pretty simple data, how about displaying the data in a listbox/multi-column listbox instead? Sure, you'd have to convert it all to strings and then be limited to ~32k entries, but the scollbar works like it should.

Sparc

The guts of the integral are just to add one number after another after another until everything in the data set is added to a single value (which is then multiplied by the dt value for correct time units).

What he said. To integrate the values from a DAQ board just sum all the samples and multiply by how long the acquistion took. To do it "continuously" keep the last sum around, add the new DAQ samples to it and multiply by the time since the DAQ started (or whenever you have defined to be t0). Rinse. Repeat.

Sparc

I second the Beyond Comare nomination.

Sparc

The example wasn't meant to be a perfect implementation of your Action Engine, just an example that a VI could be loaded in to memory, without a Front Panel and you could access it remotely. No, it doesn't truely terminate and given the constraints of LabVIEW, it never will and keep the behaviour you want.

Do note that a VI ca run to termination and not unload as long as something has an open reference to it.

Also, a loop that is waiting on a queue element, notification, or an occurance consumes almost no CPU cycles.

Maybe, with a little revision, you can use these ideas to make your Action Engine.

Sparc

dear Sparc,

That doesn't really work.

Beware when you reference the VI!

If you use a "Static VI Reference" from the Application Control Palette

that is just the same as if you had laid down the icon to the VI itself.

That is a static reference. It loads the target vi when the caller loads.

What you probably miss is the true dynamic nature of what we have been attempting,

and that is to choose which of several similar Action Engine vis with the same type to use.

Instead of the static vi reference, use just a "type specifier VI Refnum (for type only)"

as shown in the attached .jpg clip.

You will find it won't work. Nice try though.

Paul

4900[/snapback]

Show me where I said "Use a 'Static VI Reference'" and I'll show you your mistake.

Take the example .zip, only open "exe.vi" and run it. You'll see the counter increment. Close the VI. Re-open it and re-run it, you find that the counter is still incrementing.

It's left as a task to the reader to implement a clean way of shutting down the tsr.vi.

Sparc

Hi All,

I have an LED indicator to test  for a pass/fail condition on a voltage level received from a datalogger. I would like to be able to click on the LED to get the current reading from the data logger. Is there a way to do this? I eventually will have many channels and do not want to clutter the front panel by displaying the data at all times.

Cheers,

Steve

4873[/snapback]

Slap an old style flat boolean on the top of your existing indicator, color it 'transparent' (both states) and use that control to trigger you additional displays.

Sparc

:headbang:

dear mesmith.

I tried making a reference to the called vi from within the called vi. LV complains about doing recursive calls. I don't think making the VI reentrant will work as a LV2 style global. I tried passing in the reference from the calling vi and stashing that in an unitialized shift register, but that doesn't work either.

:headbang:

dear cb,

I tried that too but when the calling VI stops its execution (stops running), the called VI is dynamically, immediately  and most decidedly unloaded. The uninitialized shift registers in it instantly forget that they ever had anything in them.

Any other suggestions?  Anybody want me to post a simple example of what doesn't work?

ConawayNY

4733[/snapback]

Create a reference to itself by using 'Open VI Reference" with 'Current VI's Path' wired into the 'VI Path' terminal. Store the generated reference in a shift register until you're ready to close it.

Sparc

Thanks for the info. I contacted NI Belgium and this is indeed an example of functionality that cannot be used in an executable since the new default values cannot be saved to the vi because it is embedded in the exe. I have to do it using a configuration file (an ini-file).

Don't you think the application builder should give a warning in such cases?

Greetings,

Manu.

2321[/snapback]

Its not that "make current value default" isn't working, its the VI you're trying to operate on.

When you use "make current value default" you have to save the VI to make it stick. The VI you want to change is inside the .exe. The .exe is being executed by the operating system. Generally speaking OS's lock the .exes before running them so they can't be deleted, renamed, overwritten, etc while they are running (saving the VI would overwrite the .exe). The exe is locked, and by extention so is your VI, hence the error.

"Make current value default" should work fine from an .exe, just not on a VI inside the .exe.

Sparc