Michael Aivaliotis

Yes, it would be a good start to get all the previous subscribers imported over. This, however can also happen at a later time. Right now we can just let everyone (including Tom) know the backup is there and there is a desire to continue. I've sent an email out to the list to let the existing members know and hopefully most will be willing to subscribe. Also, I think the existing members should have the choice to have their email address migrated over. We'll just have to wait and see if Tom responds. As you know, he is very busy and this list is very low on his priority list.

Yes, this is good. However since you already have auto-indexing enabled, adding the array size function is redundant. You will see that if you delete this function and the wire to the N terminal, you program will still work. In general, a for loop will iterate for every element in an indexing array input OR the number wired into the N terminal, whichever is smaller. If you have an array of size 10 and wire a 5 into the N terminal, the loop will iterate only 5 times regardless of the array size. Also, if you have an empty array then the loop will not iterate at all.

Well, I decided to put up an alternative Info-LabVIEW mailing list. Since it is a fact that many people refuse to use web based forums, I think a mailing list is essential. Right now, the original list is up and down. Here is the link to the new subscription page. Alternative Info-LabVIEW mailing list subscription 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.

Oh, now I know what feature you might have seen. This comes back to "playing" with graphics programs. You can now add animated GIF's to your controls. This will do exactly what you want. No special thing you have to do just generate 2 different animated GIF's in your graphics package and then place it in the 2 different states.

I guess my point is that, in user interfaces, your front panel objects should always "look like" how they behave. Even if you managed to code around this, you shouldn't. The "look" of the existing button conveys the following message: There are 2 buttons here. However they are covered by an icon that spreads across both. So, if you want the right side then click the right button but don't click the icon. If you want to click on both buttons then click on the icon, this will depress both buttons. Do you see my point? By splitting the icon in 2, you have suddenly changed the message you are conveying because now you have a dark "crack" between the icon. So, the operator "understands" that both buttons operate on the same factory but for 2 different purposes. There is no confusion. A better addition would be to add arrows to the 2 icons. Yes, arrows are sometime ok. One on the left -> (inbound) and one on the right -> (outbound). Hope this helps.

Well, before I give my response, I want to know the user interface purpose behind this decision. Why split it into 2 sections? Are both clickable? If so, then isn't this confusing for the operator? What message are you conveying? I would just split the image in 2, half on one and half on the other. No code changes are good. 5-10 minutes using an imaging application is better than extra programming. My opinion anyway.

I guess this should be a wish-list item. As fas I'm aware, this is not possible yet. I guess the closest thing would be to create a sub-vi with the code and feed-in a ctrl reference to the control of interest. Would this work for you? What exactly do you want to do with the custom code that can't already be done with conventional methods?

There was a post from Tom on Info-LabVIEW today regarding the future of that mailing list: 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. :thumbup: There is an ongoing debate comparing the pros and cons of a mailing list to web Forums. In my opinion, both have their place. It would be nice, in the near future, to see them both combined so that posts to the forums can be emailed out and posts to the mailing list can go to the forums. This is an idea that I have been experimenting with for some time but not fully implemented yet. Of course public opinion would steer the debate. In any case, the LAVA server is here and ready. It also has the mailing list infrastructure to handle the new list. We already host the LAVA user group mailing lists. Comments are of course always welcome.

I agree on this. So far I have been impressed by the interest this one topic has generated on our Forums. It started as a simple announcement and took on a life of its own. I appreaciate the contributions everyone has made and encourage those that are silent to participate. It just shows that it is important to have an open forum where these discussions can take place. It also helps to have the history of all comments made so it can all be put into perspective. -- I look forward to more exciting discussions like this. ...

Ok, I think the best approach for you would be to use the GPIB interface on the back of the instrument to retreive the data into LabVIEW. You will need a GPIB interface card on the PC. Here is a link to NI's website to purchase a GPIB controller: GPIB (IEEE 488) Solutions The next step would be to build a LabVIEW driver for this instrument. Thankfully, there are drivers already built for you. Here is a link to download the driver for the 8720: HP8720C LabVIEW Driver These driver VI's can be run in LabVIEW. They will allow you to communicate with the instrument and retreive the data you would like. Once you have the data in Labview, you need to then pass it to the spreadsheet. You can use ActiveX to pass data from LabVIEW to another application. I assume your application is Excel? In any case, it sounds like you don't want to use VB at all. Is this correct? Do you want to develop the entire application in LabVIEW alone? I hope this helps.

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

But on the contrary, you still do. Whether the datatype is an indicator or a constant makes no difference. How do you decide on what indicator to use? I agree that variants are more powerfull in this regard. Did you read my last post? I think this implementation is much improved in handling multiple datatypes on the same comm link.

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.