Michael Aivaliotis

The dialog label in the controls palette is very special. You can use this label to label wires on the diagram instead of using your own colors. What makes the dialog label different from the default label is that the background color inherits the color properties of whatever object or background you place it on. Normaly, this label is used on front panels because it allows you to label dialog frames properly. Windows XP color themes contain various shades and textures which cannot be represented by a single color. However a nice bonus is the benefit of labeling wires without having to play with the colors. You must select this label from the controls palette to drop it since it's not available on the functions palette.

http://www.sunspotworld.com/

There seems to be a misunderstanding since we probably didn't clarify this point. Our fault not yours .You will still, as always, continue to attach code and files to your forum posts. This hasn't changed and will not change in the future. Sometimes however, a reply to a support topic may trigger you to come up with a tool or a complete set of VI's that are cleaned up for the general public. If you were to post it to the same thread then it would get buried in the noise. The LAVAcr helps organize those gems so people can find them and ask for support when they download it and have problems. Don't be afraid to submit code to the LAVAcr we aren't as strict as you might think.As far as emailing the person the code, this seems backwards. The whole point of the forums is to educate, and hiding the discussions and code exchange defeats this. So, YES attach your code to your reply AND post an image (for those that don't have LV:8.0.1)

I've moved this topic to the wish list because I think NI's integration with password protected VI's and the search function completely sucks. Actually, there is NO consideration of password protected VI's in LabVIEW's search function. I would like the following: A flag in the search options that allows you to ignore protected VI's If the flag is not set and a password dialog pops up during the search, there should be a checkbox asking if you want to: "ignore future searches in protected VI's (for this search)". #2 is important because when the password dialog pops up, you only have the option to Cancel. This only cancels the current VI. If you have hundreds of password protected VI's then you will get hundreds of pop-ups. Perhaps an ABORT of the search in this dialog is better. Otherwise you have to play a game of: escape+click, escape+click, escape+click in order to abort the search.

Double-Click of VI after "create subvi" action doesn't open VI. If you use the "Edit >> Create SubVI" function from menu's and then double-click the new VI icon that was created, the front panel doesn't open. However, if you nudge the icon 1 pixel, it now works. It seems to be related to editing the VI and saving it or changing the connector pane. You must do this before trying the double-click. I haven't had time to narow this down. Can others confirm this?

No one will be able to answer these questions on a public forum because of the NDA agreements they have signed. Your best bet is to come to NIWeek and talk to a developer.

C'mon guys, what do you think this is, the NI discussion forums?

I agree, Bastards! :thumbdown:

Well yes, if you could develop using OO A&D techniques and not worry about programming the framework code required to support it, then would you not do that? Are you arguing against OO design in general, or against OO design in LabVIEW?

I think that's the wrong way of looking at it. You either use GOOP or you don't. In this case size doesn't matter. If you are creating throw-away code, then sure, GOOP is overkill, but in any other instance it should be used. The reason people are afraid of it is because LabVIEW has never provided a good fully functional native implemetation of GOOP. Of course, the next release of LabVIEW should change all that. :thumbup:

Of course... If Mark, Michael, Philippe, Ashish, Jim and Norm are there, you have to be there too...

There's not much I can do for you in regard to this. It's too bad you didn't leave better documentation. Hmm, this is new information, your original post didn't indicate that, in fact it sounded like it was all you. If you are not a programmer and cannot decifer the GWBASIC code then there lies the proble. Perhaps others can help, unfortunatly this is above and beyond where I draw the line on my help. If you are in the northern California area, you can contact my employer: http://jameskring.com and we can arrange an on-site visit. Again, new information not given before. If you can't communicate to the test set using Procomm then of course, LabVIEW will not either. I guess you better roll-up your sleeves, you gotta lot of work to do. I have no clue, without seeing your setup what might be the problem. It also sounds like there is little to no documentation. Again, I'm sorry I can't be more help but there are 4000 other registered board members that may have some idea.

http://www.measurementcomputing.com/mstudio.html

Grab handle and hotspot is missing on resizable panels.

Would this inlining tool be run before you execute the VI, or is this something you would run before building an executable?The problem with creating an inlining tool is that the result would not be reversable unless you could use a rollback mechanism of some sort. So it would probably only be used for a final executable build where you wouldn't care about reversing this action.

This was written about 2 years ago in the context of LV7 so it is not wrong. Also, more people than NI wants to admit are still using LV7 so this is still a very usefull article. It would be great if you could write an addendum describing your experiences with this new feature addition in LV8 and I will include it in the original article.

You cannot change the control with scripting of an executing VI. Scripting only operates on idle VI's (not running or reserved for running). There are many other ways to do this without using scripting. I'm moving this post to the UI forum.

Ok, so I'm not so hip. Can someone tell me what jpdrolet's avatar is suppose to be?

This seems like a pretty straight forward project. The fact that you are the original designer should make things a lot easier. I could probably solve this problem for you and write all the software and design\build your hardware interfaces, but I assume you want to do all that yourself right? If that's the case then I would suggest you do some Googling around. There are some ethernet and usb "interfaces on a chip" that you could probably purchase that would do the trick. If you want to make it easier you could probably use a USB to serial dongle. As far as the LabVIEW, try opening up your examples. There are several serial examples that could get you started. I would suggest you try to communicate with your exisitng hardware through the rs232 first and make sure that works before you upgrade to USB or ethernet. So... please try a few things out and if you get stuck come on over and we'll try and help you out.

is it ok if I beat you to it?

I wish you could upload an image of your diagram.

TERRY?!! Ti kanies megale? How are you? Long time no hear. Are you gonna be at NIWeek this year?

I do...

If you place a 1msec wait function inside the loop, does this change the frequency? Does it go faster or slower?

What would be the benefit? Why not just buy a card or some other PC hardware that talks 1553? What are you trying to do with this device? Test it?