Jim Kring

I wouldn't say that using templates is needless. I hope NI leaves the usage of templates the way they are. I like them. One major benefit of using templates is you can debug your code while it's running. Reentrant VI's have annoying limitations. You cannot probe data on wires and you cannot view the front panel data.

Has anyone benchmarked the performance difference between instanciating a VIT vs. a reentrant VI?

Alex,

I recommend using OpenGOOP. It will probably work (its pure G + no variants), and if it doesn't work you can fix or strip out the parts that don't.

-Jim

The "Prepare for reentrant run" option (0x08) of "Open VI Reference" was adding in LV 6.1, as was the "Auto Dispose Ref" argument of the "VI.Run" method. But, templates are still a good solution for cloning GUIs.

Yes, LabVIEW can call shared libraries on Linux. They are called shared object files and usually (if not always) have a .so file extension.

A while ago, I looked at the possibility of a GPG toolkit for LabVIEW as a way of signing OpenG Package Files. Maybe this will happen some day...

Hello RT and TCP fans. I am currently working on an RT system and I had to create a custom TCP server. I decided to make it very general and allow registering call-back VIs to handle client connection. This design allows for multiple client connections and is super-clean :thumbup: . The call-back framework handles all the management (spawing and cleanup). Please take a look and feel free to comment and discuss in the forum (see hyperlink, below).

:!: My only disclaimer is that I've only spent a couple days on it and it has not been tested for memory leaks, reliability, etc. Please report these back to me, if you would be so kind.

Example - TCP Server, An OpenGOOP TCP Server

Cheers,

-Jim

This is an example of using OpenGOOP to manage TCP client connection handlers which are spawed dynamically. Essentially you register a callback VI that will be run each time a client connects to the port that you have registered for. And, if your callback is reentrant, then you can handle multiple client connections!

More info and download:

EXAMPLE - TCP Server page at OpenG.org

Enjoy,

-Jim

Craig,

Ooo, such modesty there.

Well, I wasn't referring to myself

After all the messing, I have the interactive stuff working for commands like "ping". However, the one I'm trying to get control of is Gnu's PGP equivalent. Although it's a command line interface, catching its standard input, output and error streams do absolutely nothing. Evidently there are several ways of conversing via a text terminal and whatever GPG is using isn't well liked by .NET

Calling SSH from a system command pipe, requires passing the -T option so that it does not generate a TTY terminal shell. I don't know if GPG has anything but you might want to take a look at all of its command-line arguments and see if anything looks similar.

So it's a case of sleeping on it and seeing if inspiration hits :/

Have you tried calling GPG from a system command pipe on Linux?

Cheers,

-Jim

Craig,

The developers at OpenG are working on a pipes package for Windows which will include an "Open System Command Pipe" VI. I am not sure when this will be finished, but I can tell you that we have some very talented folks working on it.

-Jim

Just did a quick test and it does support the case selector terminal on my LV7.0 installation.  What does the status box say when you select the case selector and an output terminal?

OK, it does work. In my test the output tunnel's type was not defined -- it didn't have a source, from at least one frame of the case structure.

David,

Nice :thumbup:

It would also be nice if this supported the case "Selector Terminal" in addition to "regular" tunnel sources.

Cheers,

-Jim

The formatting on that email archive is hard to read. Here is the same info, reformatted.

Cheers,

-Jim

Properties and Methods

App:App.UnattendedMode: ..\National Instruments\LabVIEW 7.0\project\Source Code Control\_utils\SCC Revert safe.vi

VI:SetTag: ..\National Instruments\LabVIEW 7.0\vi.lib\express\express signal manip\ConvertfromDDTConfig.llb\subSetVIProperties.vi

Posible use: Create Express VI ?

VI:ConPane (The read version of it): ..\National Instruments\LabVIEW 7.0\vi.lib\express\express output\ExFileWriteConfig.llb\Configure Write LabVIEW Measurement File.vi

VERY usefull. I have made an utility using this property very similar to the call by reference but it is non blocking (using the conpane to pass data to the target VI)

VI:FP isdialog: ..\National Instruments\LabVIEW 7.0\examples\viserver\mltsetup.llb\Save Setups.vi

VI:Is Instance ?: ..\National Instruments\LabVIEW 7.0\vi.lib\express\express signal manip\TriggerBlock.llb\Ex_Inst_Trigger and Gate.vi

VI:Diagram: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwCopySrcVIContentsIntoDstVI.vi

The Building Block to access the Block Diagram

VI:Mods.User Changes: ..\National Instruments\LabVIEW 7.0\project\Source Code Control\_utils\SCC Save safe.vi

Ctl:Terminal.Owner: ..\National Instruments\LabVIEW 7.0\project\_NewProbeWizard.llb\MoveTermInsideStruct.vi

Very usefull to quickly get to the block diagram counterpart of a control

Ctl:Terminal.Position: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwScript_ClusterConnector.vi

Ctl:Terminal.Wire.Terms[]: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwScript_ClusterConnector.vi

Ctl:Move: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwScript_ClusterConnector.vi

Clust:Terminal: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwScript_ClusterConnector.vi

Pnl:Select All: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwScript_ClusterCopy.vi

Pnl:Paste Selection: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwScript_ClusterCopy.vi

Pnl:Copy Selection: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwScript_ClusterCopy.vi

BDiag:Select All: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwCopySrcVIContentsIntoDstVI.vi

Bdiag:Copy Selection: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwCopySrcVIContentsIntoDstVI.vi

Diag:Paste Selection: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwCopySrcVIContentsIntoDstVI.vi

All these copy and paste utility are EXTREMELY usefull (I had wish for these for so long...)

SubVI:VI Ref: ..\National Instruments\LabVIEW 7.0\vi.lib\express\express signal manip\ConvertfromDDTConfig.llb\subUpdateConversionTitle.vi

ConPane:DiscTerm: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwScript_ClusterConnector.vi

Term:Name: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwConnectObjToLeadingSubVI.vi

Primitives

New VI Object: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwScript_ClusterConnector.vi

One of the most interesting primitive, open a whole new realm of possibilities

Open VI Object Reference: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwScript_ClusterCopy.vi

Hmmm, makes me wonder if we need an OpenG Toolkit VI that will "Force Empty Array Lengths to Zero". Attached is an implementation of this idea (that I threw together from some existing OpenG LabVIEW Data Tools Vis). Obviously it will be much faster to do this using strict data types instead of Variants.

You will need the OpenG Toolkit 2.x and specifically the LabVIEW Data Tools package (lib_lvdata) in order to use this example.

Cheers,

-Jim

Download File:post-16-1079981323.zip

I found this one today. Looks like it is "expected" behaviour because it is present in LabVIEW 5.11 too. Sigh could have saved me 2 hours of pain.

Connect an empty 1 D array out through a FOR loop (indexing), thus creating a 2D array at the output. Create an indicator and get the "Array Sizes" of the array. Wire "N" of the loop with any number and run the VI. Note that the first element of the sizes matches "N" of the FOR loop, but the array in fact is empty!

I can understand this in terms of the logic (ie the FOR loop does execute N times), but still reckon it should return 0 for the size of the array OUTSIDE the for loop. Imagine what happens when instead of an array constant, it's a subvi that only returns data some of the time.

cheers, Alex.

Alex,

I'm no computer scientist or mathemagician, but I agree that this is the "expected" behavior -- in fact, this is the same behavior as the build array function. Try buiilding a 2D array from two empty 1D arrays and the length will be [2,0]. I guess the moral of the story is to always test for an empty array, if it matters (good luck guessing when it will matter). The OpenG Toolkit has a VI called "Empty Array?", which tests if the Array Product == 0.

Another interesting behavior is that if you wire an empty 2D array with dimensions [2,0] into a two nested For Loops with indexing enabled, the outer For Loop will iterate twice, outputing an empty 1D array on each itteration.

Cheers,

-Jim

Craig,

It's not the abort, I think- it's the "Open". The window temporarily loses focus when opening the sub VI, then regains focus. This is what triggers the mouse leave and mouse enter events. I fixed it by only opening the VI once at the start and not autodisposing the reference.

Nice fix.

I would think that losing focus should not (in principle) fire the Mouse Enter/Leave events, unless the VI that is opened actually has its front panel opened and it is directly beneath the mouse when it opens. Also, I believe that focus should not (in principle) fire the event, since Mouse Enter/Leave will work even if the VI is not frontmost.

Cheers,

-Jim

Another last minute thought...

I only use the VI.Abort method in extreme situations, for the same reason that you don't stop a LabVIEW application by pressing the Abort button on the toolbar. You lose a lot of control over how things are stopped. I like to be in control. Usually, I will try to message into the running VI with a Notifier or by setting a Boolean flag to TRUE in a shared data-space (in a GOOP data store, for example). Then, if the VI is still running after some timeout period, I will kill the VI by invoking the VI.Abort method, but this is after all else has failed.

Attached is an image that shows a routine that I commonly use to perform this task.

I have been wanting to write up some documentation on the design pattern of process/daemon/agent spawning, and specifically how it relates to OpenGOOP classes. Expect to see something in the semi-near future...

Cheers,

-Jim

Hi Philippe,

This seems to be pretty serious. It appears that the VI.Abort method causes some crazy behavior related to mouse-window interaction. Notice how the all the VIs' Front Panels appear to "flash" when the Abort is called. It is like things are being "reset" behind the scenes.

:question: I wonder... What other mouse events the VI.Abort method causes to misfire?

Well, you may have already solved the real problem, which is how to exit the spawned VI. In this case a Notifier works very well. Attached is an example that shows how to do this.

Cheers,

-Jim

Download File:post-16-1079901464.zip

Craig,

Queus, Notifiers, and occurrences are all non-polling, unless you set the timeout to something other than "-1". Same thing with the event structure, which also has a timeout. The trick is to make the consumer of your event non-polling (with an infinite timeout) and then destroy the queue/notifier or send a user-defined "exit" event to the event structure get it to return/execute so that you can shutdown.

Regards,

-Jim Kring

Michael,

I sent a personal reply to Tom offering the lavausergroup server as the new home to the info-labview mailing list. I hope he responds favourably so that we can keep this institution alive.

I'm not trying to bully my way into anything. I just want to help the community. Feel free to sign-up and send messages. Time will tell of what will happen to the original info-labview list. In the meantime let's move on. If the original ever gets revived then I will shut-down my list.

It would seem (to me) that there won't be many people signing up for this new list, until Tom give it his blessing. Most people that already read this forum are happy enough using a forum instead of a mailing list. Regardless, I applaud your initiative and support this transition of info-labview to a more stable environment. So, will Tom give you the info-labview members email list so that you can do a batch import? If users have to sign up for the new list manually, I'm afraid that many of the list members will be lost forever. It seems that to be successful you will really need Tom's blessing and assistance (in getting a member list).

-Jim

In your original post you said your local NI rep claimed it wouldn't perform. What changed?

NI is really pushing the FPGA product, which is probably why they told Jack that he needed it without fully evaluating other options.

Until I read to Jack's second posting, I was going to recommend calling NI again to get a second opinion about the ARB. They are designed for exactly the task he described In fact, you can also set them up to respond to hardware triggers for *very* fast response times.

-Jim

Jim,

for some reason I get an error on the "variant to Data" VI. 

Possible reason(s):

LabVIEW:  The data type of the variant is not compatible with the data type wired to the type input.

Regis

Regis,

You can see that the attached VI works just fine. So, either...

(1) your two clusters are not the same type or

(2) there is a problem with the code.

If the problem is #2, then my guess is that you might have used "Variant to Flattened String" or "Flattened String to Variant" instead of "Flatten to String" or "Unflatten from String" (respectively).

-Jim

Download File:post-10-1078457192.zip

You can do it this way... (see attached image)

Also, you can use the OpenG Version of Flatten and Unflatten From XML, which outputs variant data.

EXAMPLE - OpenG Flatten to XML

-Jim

Hey, Mike.

I'm not sure if you've seen this, but it might be worth a look. A while back, I created an example of calling into LabVIEW from Python.

EXAMPLE - Python Client to LabVIEW Server

As always, any feedback is appreciated.

-Jim

This VI give the directory listing of files and directories, it is also able to do a recursive listing.  I was using the OpenG VI but that could not handle very large directories efficiently.

Any comments are welcome.

-Sam

Hi Sam,

I was wondering if you are interested in helping to make the OpenG version more efficient. Perhaps you would want to contribute some of your improvements.

Cheers,

-Jim Kring

is there any useful functionality of this BD control?

Impressing your friends :gathering:

Tom,

We (OpenG) are actually trying to do just what you are talking about. We are releasing packages of reuse libraries and it is very possible to download these, programatically, over the internet. In fact, I have a working prototype that does just that. If you would like to participate in the development of this infrastructure, we would love to have you on the team.

Regards,

-Jim Kring