Jim Kring

Craig, Well, I wasn't referring to myself 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. 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

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

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, 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, Has Tom emailed you back? 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

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

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

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

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

Try it with a Cluster instead of Tab Control: Put a SubPanel in a cluster and replace the SubPanel with another SubPanel. Then, delete the Cluster, and the SubPanel terminal will remain on the BD. Now, press the RUN button to crash LabVIEW... Yup, Norm, I think a CAR is in order. Michael, if you are in the current LabVIEW beta program, maybe you want to submit this, so that it'll be fixed in the next release.

:thumbup: Cool detective work. It sounds like you found a bug (not a feature). Actually, the SubPanel must have a terminal since it inherits from the control GObj. NI is just being sneaky and hiding it. This reminds me of how you could get RufNum constants onto the block diagram (pre-7.0) by adding them to a cluster typedef that had and instance already on a BD. Yup, that crashed LabVIEW a lot...

Michael, I agree with you that both the CBR node and the Run method have thier place. Same thing with synchronous vs asynchronous SubPanelled VI calls (Run method can be either blocking or non-blocking depending on the "Wait until done" argument). However, I was simply referring to the fact that the two primitives (CBR node and SubPanel method) should not be called in parallel, since this causes a race condition that LabVIEW has already choked on (at least in Beta). I looked at your example, and you are forcing these primitives to execute sequentially (via data flow), so you're OK :thumbup: Cheers, -Jim

Norm and Clara, :!: I discovered a bug during beta testing, which is caused by calling the CRB and SubPanel methods in parallel (as done in your example, Norm). This has been fixed (I hope), but it is probably better to 1st call the SubPanel method and then invoke the CBR node. You can take a look at the attached example to see what I'm talking about and to test whether the bug is really fixed. Regards, -Jim Download File:post-15-1075853833.zip

Use the Flatten to String function. Then get the length of the flattened string.

Whew... that was a long one... almost a week (Nov 18th - 24th). Again, Jack (or Michael), any word back from the Info-LV folks? -Jim