regisphilbin

Thanks for all the great solutions and ideas! Hmmm...A little twist seems to be that you can't "click" on a cluster element thats Strict Type Def. So what I ended up doing (correct or not) was disconnecting the cluster from the Strict Type Def, select the control within and creating its property node, then replace the cluster back to its original Strict Type Def. form. This seems to work although a slight workaround....

Just curious, I'm creating a UI that will modify elements in a cluster and was wondering if the following picture depicts the best solution. I have a boolean button that, when pressed, will trigger a corresponding boolean within the cluster to change its state. I'm using Value Signaling. I guess I was interested to see if this could be done without using a FOR loop to determine which element in the cluster I'd like to reference.

pallen, if you have any specific questions/problems on parsing strings, post them here. Heck, you can probably even attach a copy of the text file you'd like to parse.... Regis

Thanks David! Comes in real handy....

For Clarification, The ActiveX container can be obtained (in LV7.0) by the picture below. Once you drop a container in your program, Right-click on the container, then "Insert ActiveX Object". This will allow you to select the appropriate ActiveX control (if you have installed the DVT ActiveX enabling software)

Thanks mike...I learn something new every day! regis

adavid, i believe the key for making the "for loop" work is using the "array size" function to determine how many array elements (clusters in this case) are in your array. Once you do this, the for loop will know exactly how many iterations to do. I created a VI that retrieved the "name" element of the cluster via iterating through the array and wrote the names to a file. Does this help?

Thanks Jim, I'll have to check tomorrow but you're probably right about me using the Variant to flattened String Vi's. Michael, in the VI that Jim put together (and the difference from mine that i posted) is that the you don't need to specify the incoming data's datatype. This exercise did bring out the benefits of using Strict Type def controls....Anytime i changed the cluster, I didn't have to go around changing all the vi's where the cluster occurred..... Regis

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

Hi, This topic just came up at the SD Lava Usergroup meeting last week but I still have some questions regarding passing the "Type" of data through TCP and how to re-assemble the data on the "other side". Currently, I'm "copying" over the datatype as a constant to the VI receiving the data. Then using this constant, I can rebuild the cluster either via XML or Variants. What I'd like to do is send the data type through so that constants don't need to be used, I can wire in the datatype so that the receiving VII doesn't need to know the exact type of Cluster that is being sent to it.... I'm also opened to suggestions as to better methods of packaging data so that it can be sent via TCP/IP Regis

Here's picture #2. This is the BD of the SubVI. You have to place the Event Refnum control on the front panel and wire from the Main VI into this Subvi.

I've attached 2 pictures of how you can interact with a Sub VI from a top level VI using Dynamic Events. This first picture is of the Main VI. The 5 elements attached to the "register for events" node can be utilized on the Main VI and the respective actions dynamically sent to the Sub VI. [edited:] Only have have 1 picture attached. How can I attach 2 pictures to this post? I can only select one...

one nice thing about having a timer with the pass through Error cluster is that you can introduce wait times in specific parts of the program without using the sequence structure. I've attached an identical solution to the one posted above but just using NI controls (with the sequence structure)

is there any useful functionality of this BD control?

JohnRH & Mr. Bailey, Thanks for taking your time in educating us regarding this lawsuit. Although a long read, its been very educational! Mr Bailey, I'm still wondering, if your company were to 'win' this court case, would Softwire actively pursue "prohibiting NI from continuing to sell LabView"? just another Labview user, Regis

is this a feature of LV7? or something even newer?

Thanks Michael, That seems to have fixed the problem....I guess I've just gotten so used to wiring to the dynamic events structure that I forgot that it wasn't being used.... Now, if i did want to use dynamically registered events within this top VI, then I'd have to have 2 register for events twice? Regis

Hi, I'm wondering if using a "Wait" Function within an event prevents the event structure from "seeing" incoming events? I seem to have this issue and am wondering what type of work arounds can be used.... BTW, my application requires the use of various timeouts. I'm running a sequence of time-based fieldpoint tasks. Instructions: Open both VI's. Run "Caller_simplified.vi". Click on "Start" - This will start a sequence in the "called_Simplified.vi". Occasionally, switching the "Start" to its False state will stop the Sequence, other times not.... **** On the side, please feel free to comment / criticize on the structure of the VI. If there is something that I'm doing obviously incorrectly, please let me know... Thanks, Regis Download File:post-15-1073112019.zip

must....get......my.....fix :shock:

With the help of Nicola Chiari, I was able to get it to work...here are some of the details as well as a basic diagram. 1) It was mentioned to use an ActiveX container as my ActiveX Reference. instead of just creating an ActiveX Control on the wiring diagram. This allowed me to change some of the properties prior to running the program. 2) Not only did i need to specify the RemoteHost IP Address in the "connect" invoke mode, but also in the properties of the ActiveX Container. 3) I was trying to talk directly to the winsocket DLL's but that got way too complicated too quickly. Pictures below: 1) I put 2 objects on the front panel, a ActiveX Container, and an ActiveX control. 2) The wiring diagram shows pretty much identical coding with the container vs. the control. I was always getting Winsock errors with the control. I'd also have to wire some sort of picture indicator for displaying the cameras image. 3) The property of the ActiveX Container and where I had to "hard-code" the actual IP address. I'm finding out now that i can set up the properties programatically prior to wiring the "Connect" invoke node.

I've been playing around with a DVT Ethernet based B&W Camera and trying to get it to communicate with LV using ActiveX. First off, has anyone put together VI's for this product? DTV provides ActiveX components and I'm using the "connect" method after opening a reference to the device. I get an error msg "Socket DLL Error: WSANOTINITIALISED:10093 A successful WSAStartup() call must occur before using this function" looking this up in MSKB, i found that WSAStartup() is a function call within wsock32.dll. When trying to "Browse" for the "Select ActiveX class" input, I'm unable to call this function... just FYI, my only real activeX experience is utilizing ActiveX to control Excel functionality for reading/writing to spreadsheets.... In any case, would someone know the process in "initializing" Winsock in LV so that I can proceed with linking LV to the camera? Thanks, regis

JRA on 7/14/2003 answered: "NI is actually aware of this issue. And you're right. It is an issue with LabVIEW 7.0. They are working on providing a fix in a future release..."

So i've created a workaround in LV7 by using a dynamic User Event. In the event "Numeric - Mouse UP", I generate a user event which then sets the Keyfocus value. I'm still not sure why setting the Keyfocus property node doesn't work but.... Download File:post-16-1073112494.vi

I've attached to following files for testing: in Labview 6.1: I've created a snippet of code that shows what i'm looking to accomplish. LV61_test.vi and LV61_keypad.vi Then i re-compiled both the VI's (identical to above) and renamed them LV70_test.vi and LV70_Keypad.vi If you try both versions out in their respective labview versions, you'll find that the keyfocus feature seems to not function in 7. This is not to say that there might be something i'm missing but I'm assuming that code that works with 6.1 should work with 7.0. I've skimmed through the upgrade notes and haven't been able to find anything of relevance.... Regis Download File:post-16-1073112391.zip

I have created a vi that works properly in Labview 6.1 but not in Labview 7. The VI in question is pictured below. it waits for user to click on the Numeric control. When this event occurs, a keypad VI pops up and allows the user to enter a value. The User presses enter on this keypad VI and the value entered is inserted into the Numeric control on the main VI. After this occurs, I'd like to keep the keyfocus on the numeric control. I have been unable to do this in LV7 although i've been doing this for months in LV6.1 I've attached the code sample code that i've created and compiled in both LV6.1 and LV7. I believe the keypad vi was one found on the NI website. It is an event based keypad.vi so its rather new.... I'll forward you the sample code if you'd like....