Wire Warrior

Just a quick read on wikipedia makes me think that you should be able to access this via the .Net framework. I don't know enough about .Net to be of more assistance than that but I imagine that if you look on the lync developer pages there will be better details on that. As for using .Net with LabVIEW if you search for .Net on the developer's network there are a number of examples that pop up. I hope this at least gives you a direction to look. Thanks Jason

Omar, Your session was great. I am really looking forward to your blog post on the topic. I think this kind of information on the "software engineering" support for LabVIEW projects is important. Thanks for sharing!

Mark, Yes I would like to have the quick drop integration. Please post the VIs

ah thanks

That's it Thanks! How did you search for things under his name? I couldn't do this....

No it wasn't the Icon editor....maybe it was part of that but this was a smaller, VI manipulation piece. It centered VIs arranged connector panes, etc. Good for cleanup of old code.

During a presentation at NI Week, sorry can't remember which one exactly, the presenter suggested that the "Mark Balla Tool" was a great piece of IDE support code to have. This code was a utility VI or VIs that was said to be available on the code repository. I can't seem to find it. Can anyone point me in the correct direction? Thanks WireWarrior

Got my ticket and ready to go!!!

Okay let me see if I have this straight. The 'Application Directory' will give me my .lvproj file directory path in the IDE and the .exe file directory path in the Run Time Environment (RTE). Did I state that correctly?

I think "Get Terminal Name" is a better name for the VI. It more correctly references what the VI does. My first thought on reading the VI name in this thread was that data doesn't have a name it has an address in memory. I guess the context the word 'data' refers is the confusing point. Terminal referring to its use within the LabVIEW environment drives the context to the correct space.

Phillip's post makes me think that what we are discussing here are two options. One read the file with the computers localization information and the other read my file with the localization it was saved with previously. Determining the localization for the computer loading the file is easy. Determining the state of the file previously requires, as Phillip rightly pointed out, a field in the INI to report the information from the last save. Of course, that still would not allow for us to support the work of a user with a text editor easily.

Thanks for the note Kombela. I will have a look at the VI this evening.

LAVA has a Twitter? What is it? I had not heard this (I think).

Okay here is a screenshot of the modification that Mads made to work around the problem of matching the decimal point indicator. Looking at this the first concern I have is that this assumes that the first period or comma encountered is the decimal point. This means that 100,000.00 would be interpreted as one hundred instead of one hundred thousand. It seems like a method that examines the input string for the existence of both commas and periods then makes a decision based on quantity would be a work around for that issue. Of course this approach does limit the user to only two choices. I suppose we could include an optional input to the Read Key VI that would allow the user to assign any string as the decimal point indicator. I would propose that such a solution choose the first character of the string as the indicator. There is also the implicit requirement that the string be printable if humans want to read the character in a text editor. What do people think about the cases where someone would want to use something other than a period or comma? I can't think of any localization types beyond those two but I will admit my experience is limited. Your thoughts folks? Jason

Okay since I spent a while today fighting with the font size type issues between Windows XP and Windows 7 machines I really believe in the standardization between Windows OS's. Check out the link for an idea exchange for this. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Font-size-standardization/idi-p/1405022 In the long run this issue will vanish as the xp computers fade in to nothing but it sure would be nice if there was an easy way to manage fonts between OS's.

Well since Mads was interested enough to post we will start with the ID:3004519 issue. Mads, I saw on the old OpenG forums that you had linked a VI with a solution to the issue you were using. Would you mind posting that here again? The old forums don't let guests, like me :-), view the files. TonP, You had linked an image of your solution. Do you still have that? Could you link here if so? Thanks Jason

I was researching the OpenG variantconfig issue 3005419 about decimal point localization and tried to view some of the files linked to the original discussion on the old OpenG forums. (http://forums.openg.org/index.php?showtopic=1117&pid=3034&st=0entry3034) The problem is whenever I try to access the VI that MADS linked or TonP's png image I get a file access not allowed because I am a guest. Is there a way of getting access to these? I was thinking that they had been linked over to the LAVA forums but I couldn't find it. Thanks Jason

Sounds like you need a Hardware Abstraction Layer (HAL). See the white paper or the webcast for more details. Searching for "hal" on the NI website will get you tons more info. As for the method your describing you could simply use the build in visa commands and then you can easily accomodate either or both solutions (USB or traditional Serial) from a programming standpoint. As for USB being more reliable, I don't really think the USB would affect the reliability as much as the autosampler itself would. Two things you might want to consider.....Why are people not buying the USB version? The underlying reason may help your decision. and two.....................................................I don't know about you but at my company we have to go through extra effort to get a computer with a serial port. They are all coming with USB's instead now. Jason

Have you ever noticed that you come up with the strangest poetry AKA limericks? You know that point where you're at the end of a big push right before the holidays on that R&D item that was low priority the rest of the year....you and the team have put in lots of extra hours and at last you're waiting on that last or near to last FPGA compile that takes a while and you begin making up limericks...... Things like: The LEDs blink and flash, Around the wires the datum dash My sbRIO has the datum lost The custom board has circuits crossed &@#$% watch my RT program crash or There once was a CLD, Who went one day on a LabVIEW spree, He wired, dropped, and right clicked with cheer While keeping at hand an ice cold beer Now his code looks like spaghetti Wirewarrior

Hi bab, Let's see if I understand the issue correctly. As I understand it, when you use the Read Key(Variant)__ogtk.vi the name of the input typing cluster does not propagate. By this I mean the name of the cluster control/constant that envelopes the sub-keys. It is not the names of the sub-keys themselves you are talking about but of the collective entity. Just wanting to make sure I trap the stated issue with my test. Thanks Jason

Check out Darren Natingers blog. http://labviewartisan.blogspot.com/ The LabVIEW coding challenge 2012 is about to begin. I really enjoyed last years. Click "Coding Challenge 2012" to go directly to the user's group. Jason

I will check tonight that this has a bug ID against it. If not I will create one. Thanks Jason

So........What other thoughts does anyone have concerning the variant config library? Any thing? Jason

Okay what is the "allocation dot" I have not heard of that before. Sounds like a good thing to know. Thanks jason

LOL...I suppose you can Aristos. Never thought of that as a feature. Jason