Michael Aivaliotis

Is there a way for you to verify that the VISA constant is populated with the values you assume are there in an EXE? I would make that contant a control and bring it up to the GUI. Build an EXE with it like this and then you know %100 that the VISA control has this populated properly.

I like your avatar. What did they call those things? curiously large rodents? Don't remember but it was funny. One of my many favorite movies. Getting to the LLB stuff now. I would say ditch them... However it seems like your employer is stuck in the stone ages for some reason. I'm curious, do they use source code control? I bet not. Otherwise they would not be using LLB's. How can you do source code control on individual files when they're wrapped in an LLB. Don't forget the dangers of LLB corruption! This is the biggest gotcha in LLB's. When VI's are saved into LLB's the file must be kept open and if there is a glitch during the save, the entire LLB is toast. There go all your VI's. NI support can fix this but who needs the hassle?

So LV takes this time to close... so? What's the problem?

Have you tried running the close datasocket server VI?

I see you've been using OpenG Commander. In your attached llb, there are some missing strict-type controls. Can you re-save it with those?

No, I didn't like it for Burt Reynolds. I liked it as a movie in general. Yes the sex scenes were enjoyable, but the rest of the movie was great too. As far as my wife, actually her favorite part was the final scene. Her eyes were bulging while I was looking down trying to figure out what was wrong with me... hehe...

Well I'll be a monkey's uncle! We have a bonafide bug...

Thanks for the contribution to the forums... this type of generosity makes me feel all warm and fuzzy inside...

This is fishy. If there is a breakpoint then LV will find it. Can you send the VI or a picture of it? I have a hard time believing this.

Interesting concept but impractical I think. Reducing complexity into a subvi is not a mechanical task isolated from its surroundings. It has to make sense. The VI must encapsulate specific functionality.

If you start from scratch then it's totally unnecesary. You must have standards to confine your diagram size. If you don't then you're asking for diagram chaos. The standards should evolve based on screen hardware developments but they still should be in place.

uhum... you tried to hide it in the image, but I can still tell what version of LV you're running... :ninja:

I guess the NI based bot lost? The NI marketing folks are mourning...

Lots of good suggestions here. I would lean towards replacing the button images with imported *.png images (for transparency). Easy enough to do in the control editor.

Burt, right? Actually, he had a surprisingly good performance in Boogie nights. I liked that movie.

I see now... what a wack job! Hinckley's Obsession -- Jodie Foster

You took the words right out of my mouth. :thumbup:

I don't get the joke... was this suppose to be funny?

I hope you got paid by the wiring node...

Congratulation!! :thumbup:

I think I'm secretly in love with Murata Boy

My bad. I'm still getting used to the fact that I'm in the US now. Since 3/4 of my family is still in Canada (I miss them very much), there's a strong pull in that direction... As far as the LabVIEW domain in other countries, I think the biggest issue would be the LabVIEW trademark rights. NI's lawyers would love that. The laws pertaining to domain registration differ from country to country. Some countries require you to be a citizen of that country (for personal domains) or have a business that operates in that country. I know this is true for some (read the fine print).

nice one :thumbup: However don't you need to have some affiliation with that country?

Me too. It seems like remote debugging will work similer to RT debugging where you run your VI's in the development environment but target the application.

I would agree with mballa. He probably knows me a little better since NIWeek and understands how picky I am when it comes to coding style. I've been fortunate throughout my early career in LabVIEW to have experienced developers around me that I could discuss ideas and techniques with. They would also challenge my design decisions which would force me to evolve my style. That's how I've reached the level I am today. I always try to push people to explain their thought process when they code a certain way. Often time we just do things "just because". Often time this has evolved due to a few late nights of debugging customer code, only to discover that it was caused by a certain boolean button starting off as pressed. This however is the exception and shouldn't dictate how you program all applications. When we have a clear head, we should go back and evaluate, why that happened. I'd like to add one thing on the use of bundle\unbundle. Adding a new datatype to the shift register only requires the addition of the datatype to a strict-type cluster and you don't need to wire new wires through all the cases. Of course the tunnel wiring wizard would solve this problem but that is no excuse really. LabVIEW now provides the Navigation Window, but this doesn't mean we should all start creating wiring diagrams that span the width of 10 monitors... As far as your revised application using bundle\unbundle by name, I would give it an A. The reason I didn't give it an A+ is for 2 reasons. One reason is the use of array of strings. I used to program using array of strings and evolved over time to using standard strings with linefeed delimiter. I just recently had this discussion with a colleague and asked them to try using delimited strings instead of array of strings. He was reluctant at first but after he tried it, he was totally converted to this new method. Delimited strings allow easier editing of your state sequence lists because you can just double-click in the textbox and start typing. You can also quickly select text copy past etc. Another item of note in your revised code is the use of wiring a TRUE though every output to your conditional terminal of the while loop. Again, it works but it's a lot easier to just use the "stop if true" option on it. This means you only really have to wire a constant out on the frame that terminates the while loop. In your case it would be the "finished" and "default". All other cases can just use the "use default if unwired" option. This means if you add a new case, you can just ignore this terminal. A Minor thing but it's nice not to worry about those pesky little constants. From your profile it looks like you are local to my area (Livermore) so perhaps we can get together at the next LAVA meeting to discuss these coding techniques some more in person. I think the next meeting should be sometime in November. :thumbup: