Michael Aivaliotis

I think a more usefull implementation would be able to adapt to multiple datatypes passed along the tcp-ip link. Of course theis implementation can be used wherever communications is limited to string data. The attached images show how you can add some smarts to your data so that it can be decoded properly on the receiving end. Of course you can improve upon this implementation by having the receiver call the appropriate data decoder dynamically when needed instead of feeding to a case structure. Personally I use the variant method. The VI's shown are included in the OpenG LabVIEW Data Tools library that can be downloaded from the OpenG site. I don't use this for TCP\IP rather to pass data between VI modules using queues in LabVIEW.

Why use variants. What advantage do you get? Why not use this method?: Even with the implementation Jim mentioned, you still need to know the datatype of the final output. The question is, how do you pass the datatype across.

You need to use dynamic events and the Dynamic Event terminal on the left of the event structure. All the events of the calling VI must be registered this way in the sub-vi event structure. Can you describe what you are doing right now that is giving you problems?

I don't have Windows 2000 anymore but I believe that the dial-up connections reference specific configuration files. It's possible, I suspect, to call those configuration files through the LV system exec and in-turn they would make the connection. However if a specific file is not available then prehaps you can create a short-cut for the specific connection then call the short-cut. Probably a better method would be to access the Remote Access Services (RAS) directly through a Windows API call. Go onto the Microsoft MSDN site and see what you can find. You need to call the C:\WINDOWS\system32\rasapi32.dll. The function you need is RasDial: The RasDial function Some more research reveals a toolkit that will do RAS dialing in LabVIEW: RAS-Toolkit LV

What Language is this concerning? LabVIEW will use French, German or Japanese menus if you use the application builder for that language. The other alternative as Randall mentioned is only available in LV7.0... sorry.

Hmmm, Can you be more specific? What exactly do you want to do with your ethernet connection? There are many methods of connecting two LabVIEW applications to communicate with each other. More details please.

There is a way to do this but you have to trick LabVIEW. The implementation attached is in LV60. It accomplishes the paste by simulating the keypress combination "ctrl+V". You should also make the string field have the keyfocus. Let me know if you have problems running it. It ran fine in LV6.1 and I did a "save to previous" to 6.0 but I cannot try it in that version. Download File:post-10-1078017732.llb

To start, I'd like to thank you for the image you provided. This help a lot in explaining your problem. :thumbup: One thing to consider in solving your problem is why was it working before and why is it not working now? It looks like this code is communicating with COM1 on your computer. Is the cable unplugged? Looking at the code indicates that it is possible that you could check bytes at port before you issue the 1R command. However since this is a loop, at some point during the iterations you should read bytes at port. If you probe this and ALWAYS get 0 as a byte count then this means the hardware is NOT responding to your command. If you are getting some bytes at the port >0 then the next thing to check is what is the response string comming from the serial port read vi. Your suggestion that it looks for <anything>R is false. The (=) function looks for an absolute match so if the response is anyhting but *R, it will never match. I would use a different function here. have two suggestions for you. I have attached an image that shows these two approaches. 1. The top loop in the image is a quick fix. This is coded in a more predictable fashion and i've replaced the (=) function with the "match pattern". 2. The second approach is more robust since if there is a problem with the communications somewhere along the line then the code will not "hang". To do this i've created a timeout check in monitoring the bytes at port and an overall timeout for the function. I've also done some error checking at the start. If there is an error sending the command then the loop will stop. You can change the timeout values. I used 5 seconds for the overall timeout and 1 second for the bytes at port timeout.

Hey, I just checked. You're right, it is. Well, apparently it's not so obvious, that is why I mentioned it. NI doesn't even know about it... Look at this suggestion on their website: How do I Obtain the String Selected from a Text Ring or Menu Ring

I'm not sure if many of you know about this new property that was introduced in LV7. It allows you to extract the selected text from any type of ring control. Previously you had to perform a tedious task of getting the strings[] property and then indexing this array with the selected item. Not any more! :thumbup:

It took me a while to grasp why your VI would be more efficient than other implementations. I have my own version that is more efficient than the OpenG version as well. I compared my approach to yours and noticed no performance benefit on several thousand files and directories. I noticed that you are initializing an array of filepaths to 500 items. You resize and build an array of another 500 items at a time when you require it. This seems like an excellent approach however as i said, this didn't show up in the performance comparisons I did between my version and yours. When is the benefit evident? I also noticed that Windows does some caching of directory access. This seems apparent when you run a recursive search for the first time regardless of what implementation you choose. I've attached my version (LV7). Let's compare notes... Download File:post-10-1077255628.vi

With the advent of LV Real-Time and the increasing use of reentrant VI's in NI toolkits, it's becomming more and more frustrating to debug your LabVIEW code. You cannot see live data on the front panel of a reentrant VI. You also cannot debug it using the conventional probing methods. I guess my wish would be to have the ability to do ALL of these things. When you double-click a reentrant VI icon on the diagram, THAT instance of the VI would open for viewing or debugging. This would have the potential to have multiple panels of the same VI open, each referencing to a specific version in memory. The title-bar of the VI could be labeled to reflect this.

I would recommend that you read-up on FOR loops... The loop will iterate for the number wired inthe the N terminal. All you need to do is +1 to that number and it will iterate one more time. If you need to reset any control, you can use a local variable. You can use them to write 0's to the controls. Put the reset code outside, before you enter the loop.

I'd like to remind everyone that Measurement Computing and SoftWire is charging National Instruments not the other way around. http://forums.lavausergroup.org/index.php?...=findpost&p=290 It is also possible that Mr. Bailey is using this LabVIEW forum to sway public opinion his way. The fact that NI remains silent just means that they probably don't want these comments to effect their litigation. So let's not get our panties in a bunch. Also, if the courts and the legal system are irrelavent then what is the point of getting a patent? Why not have a free-for-all of ideas an inventions? Of course this could be another thread altogether. NO, I don't want to see LabVIEW dissapear from the market. Doing so would mean I would be out of a job, but more so I would lose one of the most exciting and fun software tools on the market. If Measurement Computing and SoftWire think they are getting some brownie points (freedom and the American Dream) then they should think again. Besides... I'm Canadian... eh?

No there is not. You can start one if you like!

I brought up this issue last December on info-labview and people from NI responded: I agree that the free support is a huge help to newbies and to students. I teach LabVIEW at a community college here. I used to always say: "hey, if you have any problems just call 1800-IEEE488 and NI can help". I used to say this to many of my customers as well. I sort of felt proud of this in a peculiar way since it was a huge contrast to the "pay by the minute" philosophy of Microsoft.

Yes, this information is all in the public domain. I just spent a few hours perusing the United States patent and trademark office website. What a treasuretrove of fascinating information :!: I found the original NI patent in question: United States Patent: 4,901,221 It's interesting to view the original screenshots of the MAC version of LabVIEW. Images. The Fluke patent is here: United States Patent: 4,849,880 Images Of course there are dozens of other patents that have come out since then that are somehow related both from NI and SoftWIRE. As I was going through the various patents I noticed that there were other companies with patents describing similer graphical technologies. I guess the decision on who sues who is decided based on certain criteria such as, can the case be won or not. There must be lawyers out there who's sole purpose in life is to read patents and consult there clients on who they should sue next. We'll have to keep monitoring this topic...

oops, I just discovered something else... . You can't delete the subpanel control either! . Thank god for undo.

I accidentaly discovered how to reveal the subpanel terminal. This terminal is usually hidden from view. Only certain methods and properties are allowed on it. Place a subpanel frame inside a tab control. Right-click on the subpanel frame and replace it with a sub-panel. Goto the digram. You will see a black terminal which is the subpanel. Another spooky thing is that if you then drag the front panel (subPanel) outside the tab control then you have lost it. It dissapears from the front panel but the diagram terminal remains...

Well, I tried it out and it seems to be fixed. :thumbup: However there is a place for both implementation methods. I usually use sub-panels as part of a larger user interface approach. I prefer my sub-panel call to be non-blocking so my caller can go about it's business. This is why I prefer the VIServer implementation. However from an ease of use standpoint the call by reference is much better.

I am curious to know how you are passing data to the sub-paneled VI right now? In any case, to pass data to a VI control before launch you can use the VI Server Method Set Control Value. I have attached an image that shows how to do this before running and embedding the VI.

Jack, welcome to the wacky world of real-time. I have programmed several real-time applications using PXI and Fieldpoint so I know exactly what you're going through. Your post is so timely for me since I am right in the middle of another RT system and have my own recent gripes. I didn't realize how much of a paradigm shift I had to make from standard LabVIEW coding practices. My first RT project was under quoted by about five-fold. Needless to say, I lost money on that first one. :2cents:

You can use the "lexical class" function on the comparison pallette. Be carefull, this operates on only the first character so you need to parse through each character.

You can try here: http://forums.lavausergroup.org/index.php?showtopic=46 It is a link to a codeless radio button. However, if you want to program this in code, you are better to use an event structure. You can make an event case for every boolean. When the event fires for that boolean make the others false with a local variable.