Jump to content
jgcode

Should OpenG Move to vi.lib?

Recommended Posts

Yer, I like to ask all the big questions... :)

The question was raised here (among other things, but I want to focus on installation directory only) and elsewhere on whether OpenG would be better suited in vi.lib as per the NI requirements for

developing third-party APIs etc...

Why is OpenG installed to user.lib? That's simple, it's a historical thing.

Now due to changes, notably NI opening up vi.lib, things have changed.

It also turns out user.lib is so 8.0's (ha! get it?) and vi.lib is now the preferred and more professional approach for installation of third-party APIs.

I tested this in LabVIEW 2009.

It seems LabVIEW handles the transition quite well, so I think this is doable.

You can test it yourself by doing the following:

  • Create a Test.vi
  • Link Test.vi to (any) reuse VI in user.lib
  • Save and close Test.vi
  • Move the user.lib reuse VI to the same level in vi.lib (do not edit any folder or file names)
  • Open Test.vi and watch LabVIEW link to the moved reuse VI

I have even played with changing folder names and LabVIEW is able to link to the correct VI.

So we could even review if we wanted to change _OpenG.lib to _OpenG or OpenG as per the NI recommendations for Company Name.

So what would a change like this mean? I envisage the following for OpenG Developers and End Users:

  • On opening a project with OpenG, the OpenG VIs will be missing, LabVIEW will conduct a search and automatically find the new VIs in vi.lib quickly and with no user interaction
  • All OpenG packages will have external dependencies upgraded to be the latest OpenG packages (so all linkages are correct for that package)
  • This update of OpenG Libraries will be atomic i.e. available to the public all at the same time (as per 4.x release)

Thoughts?

Share this post


Link to post
Share on other sites

Does it also relink as painless if you need to revert to an older OpenG-set residing in user.lib? I guess so, but I don't kown the internals how that automagic relinking takes place.

What about the rare situation someone has installed an older version manually (copy&paste) instead of using VIPM? Then we could have an old vi with the same name in user.lib. Do we get a preference on vi.lib or does it happen (even if randomly) that we get a link back to user.lib?

Had to many relinking troubles in my life...

Felix

Share this post


Link to post
Share on other sites

The way I see it, if it was done - the End User should install all the latest packages so the entire Library is in vi.lib (which would be in the current version e.g. LabVIEW 2009).

As for manually installing the code, I don't know, OpenG is designed to be installed using VIPM, if someone is doing some custom install I don't think we can handle all those use cases - I guess the End User would have to do what's necessary to maintain the installation then.

In terms of your example above, I would not recommend having two versions of any code installed under <LabVIEW> just for the possibility of linking to the wrong code. VIPM only allows one version of the code to be installed e.g. A v1 or A v2 - assuming of course that in your workflow you would never create two separate package streams (e.g. A v1 and B v1) with code of the same names etc..

Share this post


Link to post
Share on other sites

Hey JG, related to the question of location in the LabVIEW hierarchy I guess that you need to think about the palette location. National Instruments ask us to move our toolkits from custom SAPHIR palette to existing category (i.e Connectivity, Data communication...) for future LV2012 Compatible for LabVIEW program. Other possible place could be Add-ons palette if you want to keep VIs in OpenG palette.

Olivier

Share this post


Link to post
Share on other sites

Hey JG, related to the question of location in the LabVIEW hierarchy I guess that you need to think about the palette location. National Instruments ask us to move our toolkits from custom SAPHIR palette to existing category (i.e Connectivity, Data communication...) for future LV2012 Compatible for LabVIEW program. Other possible place could be Add-ons palette if you want to keep VIs in OpenG palette.

Olivier

Hi Olivier

Thanks for the hot tip - can you go into details about these changes for 2012?

I will head over to that NI Group also and see what I can find out.

At the moment VIPM handles generation of Top Level Menus using the Custom Category feature, so any changes to NI protocols I assume will be reflected in VIPM.

The good thing is, palette and disk hierarchy are not always related, which is the case with OpenG, so palette location would not affect a move to vi.lib (as long as everything is configured to point to the new location etc... of course).

Share this post


Link to post
Share on other sites
At the moment VIPM handles generation of Top Level Menus using the Custom Category feature, so any changes to NI protocols I assume will be reflected in VIPM. The good thing is, palette and disk hierarchy are not always related, which is the case with OpenG, so palette location would not affect a move to vi.lib (as long as everything is configured to point to the new location etc... of course).

I agree, it's not a technical issue, but it could be philosophic debate or more simple a big change in our usual day to day OpenG usage :)

Share this post


Link to post
Share on other sites

Hi All,

I'm very friendly to moving OpenG into vi.lib in order to conform with NI's new standards for add-ons (and I don't see any obvious show stoppers). There are various reasons to do this (in terms of how LabVIEW gives vi.lib some special treatment not given to user.lib), in addition to the fact that it's a standard (which are probably the reasons for the standard). That said, we should consider all the possible negative impacts of the move to vi.lib and figure out their significance and ways to mitigate the problems. One possible negative impact I can think of is: any VIs that might have a hard-coded path to call these VIs by reference (low probability).

Regarding adding tools into the existing palette categories, this is an idea that JKI is currently (in the early stages of) discussing with NI, since it will involve the adoption of some new standards. The JKI team has some ideas that need to be put down onto (electronic) paper as a functional spec proposal. I'm just mentioning this, since I think that OpenG (and others like SAPHIR) would benefit from this, so I want you all to bug me/JKI about it later/often :)

Share this post


Link to post
Share on other sites

The following is NOT my area of expertise. I am raising something that is possibly FUD -- it's something I've heard about that you should research further before deciding the "move to vi.lib" question.

I would be concerned about future versions of Windows. Vista and Winy both ratcheted up security for applications, and they encourage app authors to go well beyond the requirements. You can find Microsoft's current recommendations here: http://msdn.microsoft.com/en-us/library/aa368769%28v=vs.85%29.aspx

But they keep moving up, and finding that these are requirements one day soon isn't unreasonable. I can easily imagine Windows requiring that any app that modifies a directory created by an installer must itself be signed by the same original authority. That would mean OpenG's installer wouldn't be able to write to vi.lib unless NI signed the installer. Probably not desirable.

Now, on the flip side, NI might decide to move vi.lib out of Program Files under such a scenario. There's lots of possibilities here. So, it's not necessarily a showstopper, but I'd suggest you investigate MS' Windows 8 plans before deciding this issue.

Share this post


Link to post
Share on other sites

AQ,

Great points. Windows/OS permissions are a very important consideration.

My thoughts are that OpenG should probably follow suite with the official standard, since I believe that both NI and JKI will be working hard to solve this problem for everyone. For example, stuff that is installed by VIPM could be done so with special permissions (signature) granted by NI.

Share this post


Link to post
Share on other sites

Side-note. If MS lock up program files (which I can understand), and NI moves vi.lib to the the user profile (or All-user profiles) They should make sure that there are seperate folders for each installation of LabVIEW.

Ton

Share this post


Link to post
Share on other sites

Side-note. If MS lock up program files (which I can understand), and NI moves vi.lib to the the user profile (or All-user profiles) They should make sure that there are seperate folders for each installation of LabVIEW.

Taking a look at my Public Documents folder, it appears this is already an observed practice - but a good point nonetheless.

Share this post


Link to post
Share on other sites

Yes, please, move it. IMHO, user.lib should be for *user* developed code, not add-ons, which is what OpenG really is.

As a practical matter, it would also make my life a little easier. I develop on anywhere from 3 - 6 machines at one time. They are usually not networked, or not networked to each other. Therefore I have to manually xfer my user.lib between machines when I make any changes/updates. While I have a couple hundred functions I've developed myself over the years, about half of my user.lib is OpenG. So it gets copied back and forth along with the rest of my user.lib, doubling the transfer time. If OpenG were in the add-ons directory, I wouldn't have to touch it except when an actual update was available.

Share this post


Link to post
Share on other sites

Yes, please, move it. IMHO, user.lib should be for *user* developed code, not add-ons, which is what OpenG really is.

...If OpenG were in the add-ons directory, I wouldn't have to touch it except when an actual update was available.

Precisely so. And then, if for some reason you (a user) did make a "local" modification to some underlying OpenG VI, you would put the modified code into user.lib, leaving the original OpenG untouched in vi.lib.

Share this post


Link to post
Share on other sites

I'm all for doing things right, but let's look at the economy of doing this: NI is suggesting that plugins have thier code in vi.lib, but are they requiring it? What is the impact if we keep OpenG in user.lib? What are the risks of the migration - what might break, on different OSes, different versions of LabVIEW, etc? What is the time impact of moving everything over to vi.lib and testing it thoroughly on different OSes and versions of LabVIEW (keeping in mind that every minute it takes is a minute taken away from OpenG code development)? We haven't seen much new stuff come from OpenG in a long time, and I know that we're working hard (ie: mostly JGCode) to get all our ducks in a row so that we can have a good platform to grow going forward, but is this idea worth spending time on if it means pushing out new features even further?

PS: I have no philosophical issue with OpenG being in vi.lib.

Share this post


Link to post
Share on other sites

It's been awhile since I've done a fresh install of OpenG -- does it currently have the option of installing to somewhere other than user.lib?

Share this post


Link to post
Share on other sites

It's been awhile since I've done a fresh install of OpenG -- does it currently have the option of installing to somewhere other than user.lib?

Nope, simply because there is no <OpenG> symbolic path in LabVIEW. So any code you develop using OpenG, can open up on any computer with OpenG installed without needing to search for the OpenG stuff. By placing OpenG code in <vi.lib> or <user.lib> we can guarantee a smooth experience for the OpenG user (that might not even know it's using OpenG libraries).

Share this post


Link to post
Share on other sites
I'm all for doing things right..

Good, then the short answer is: yes. Doing things right from the beginning (or as soon as possible for retroactive situations) ALWAYS pays off in the long run. If not then we all ought to just be jusing shifts and FGVs, typedef clusters....

Share this post


Link to post
Share on other sites
Nope, simply because there is no <OpenG> symbolic path in LabVIEW. So any code you develop using OpenG, can open up on any computer with OpenG installed without needing to search for the OpenG stuff. By placing OpenG code in <vi.lib> or <user.lib> we can guarantee a smooth experience for the OpenG user (that might not even know it's using OpenG libraries).

I should have asked a clearer question. Is there an option during install of OpenG that would allow me to put it in vi.lib now, or does it have to install to user.lib? Just wondering if in the short term, while those of you who decide these issues are deciding, I can go ahead and reinstall OpenG to vi.lib where it seems most logical (to me!) for it to be. My guess is the answer is still "no"...

Share this post


Link to post
Share on other sites

I've had a few calls into NI tech support lately and had to send them my entire user.lib, including (and mainly because of) the OpenG libraries. Zipping up something in the vi.lib as well as the user.lib is not a big deal to me, however it may be for a more novice LabVIEW user trying to get tech support.

Share this post


Link to post
Share on other sites

I didn't here a reason why not to move to vi.lib (except for Chris's reasoning about manpower), so I guess it's save to go for the move. However we should go package by package, is there anybody that has a dependency map of OpenG packages?

Ton

Share this post


Link to post
Share on other sites

I didn't here a reason why not to move to vi.lib (except for Chris's reasoning about manpower), so I guess it's save to go for the move. However we should go package by package, is there anybody that has a dependency map of OpenG packages?

I disagree - I think it would be easier for end users and OpenG developers if all packages are rolled out at once (like we did for v4.0).

  • Like 1

Share this post


Link to post
Share on other sites

,,,I think it would be easier for end users and OpenG developers if all packages are rolled out at once (like we did for v4.0).

I think so too, FWIW.

Share this post


Link to post
Share on other sites

...a dependency map of OpenG packages?

This is something I have played with in the past with my reuse library in LabVIEW where VIs represent packages and I link them and then use the VI Heirarchy window to view it.

If VIPM had that feature it would be really cool. But it's probably heaps of work for a little used feature.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By Bas de Jong
      Hello, I'm trying to display an animated GIF on the front panel. This gif should be loaded programmatically based on some user event. My google search led me to use the OpenG Read GIF File (Animated)__ogtk.vi file. However, loading a GIF is extremely slow. It takes almost 20 seconds to execute the vi when I load the attached GIF (I found randomly on the internet). Is this normal? And if so, is there a way to load a gif faster? Because I need to load several and I cannot afford to load maybe 2 minutes only for the gifs.

    • By fennectp
      Hi all,
       
      I've got a customer that wants to zip/unzip files on their cRIO-9035, so I had them playing with the OpenG Zip tools to see if it would fit their needs. Although they've found that they can zip files on their cRIO just fine, they find that they get disconnected from their RT target and the shell shows the following error message:
      LabVIEW caught a fatal signal 15.0 - Recieved SIGSEGV Reason: address not mapped to object Attempt to reference address: 0x0x10000000 stdin: is not a tty  
      The zip file they're testing with includes two simple .txt files with short strings in them ("booya" and "booya2"). This file unzips just fine on the host PC with the "ZLIB Extract All Files To Dir" VI, but when copied over to the cRIO and unzipped via the same VI, it only unzips the first text file and the resulting file doesn't have any text in it.
      I've attached a copy of the project and the zip file I used to reproduce this behavior using a cRIO-9033 that I had on hand. (The only thing I can't provide is the cRIO >_<)
      Could anybody tell me what I'm doing wrong? Any suggestions as to what other workarounds I could take to zip/unzip files on a LinuxRT target would also be very much appreciated!
       
      Regards,

      Tamon
      Unzip on cRIO-9033.zip
    • By ASalcedo
      Hello to all.
      I have an application wich use; imaqdx (displays...), sliders, many controls and many indicators, and everything in a tab control of 3 pages and 2 subVI.
      I am trying to use "write and read panel to/from ini . vi".
      The first thing that my program does is to read panel from ini.
      Here there is the first problem because it gives the next error: "Error 91 "The data type of the variant is not compatible with the data type wired to the type input. Set control value"
      Here is my piece of code in image attached (boolean input in open.vi is True).
      I notticed that it gives me an error if the .ini file does not exist (but it should work even .ini file does not exist).
      Well, my next step was to create a .ini file before to use "read panel from INI.vi".
      So I use "write panel from INI.vi" and it works fine. It does not give me any error. and the ini file is the next:
      [medir.vi] Boca = "0,000000" Camara 1 Configuracion = "\00\00\00\1Dremote image 0000000013F9C704\00\00\00\0Anivissvc.*\00\00\00\13LV_ImageDTClassInfo\00\00\00\01\00\13)É\00\00\10\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\10\00¬\00\00\00\00\00\00\00\1D)\13\00\00\00\00\00\00\00\00\00<\04\00\00\00\00\00\00<\04\00\00\00\00\00\00\03\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00€\04\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00DÊù\13\00\00\00\00LÌj\0F<\1E\00\00ø\08\00\00\00\00\00\00\00\00\00\00\01\00\00\00\01\00\00\00\00\00\00\00\1D\00\00\00\00)\13\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00remote image 0000000013F9C704\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\0ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿúïêôÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿËž“Š„€z€}{zzwx|{wwxswyvttquvrtqpprqsrpvppsquqqusputquxusswwssttvwtwt}yqvuxuzvvuwtwvvtvrwrqpupgc\\XYZX\\XW[[UVVWUXTRTRURUQQSPNQNNOKKLKLJLJFEDEEBBC?B??=:>@CDHGHHIJGJEGDFEHJGFDBADDCCEDBCFILS^ao€–³Òñÿÿÿÿÿÿÿÿÿÿÿÿ\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00ÿÿÿÿÿÿÿÿÿÿÿÿÿÿìÛËÚ̾¶³³³¼³Àìÿãϸ¬ª£¤œ‘‘‹Ž‰Œ‡…€†~z~}x{||}z~xx}}v{syx{vwwwzyywxxxxwwuruwzyvwszvzt{z{yv{wy|{vyw{zzwy~y}xzz}y{|€†€‚€€‚ƒƒ†}‡ƒ…‡‡†‹ŠŒŒŽ‹‹•š’–”›žœ›  ¡¢©©©±²µ¶º½ËÒåÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿýëä÷ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ Ž‹…†|ƒ}~xv~z{zu{wvvvuutvssqssusotqrwruxtrpqrrotusrvuwywrsuusyxvywxtvsvwuuwvwywquvvuvswtvqpplge^\\VYWYXWYXSWVUZUVQSUTSRTTUNONMKMMKKMJLLLJGEDC@CA?@@@??=CBDGGJLJIJGGIGHEFGFHHCBCBADCAADDIOWZiq„œ·Ôïÿÿÿÿÿÿÿÿÿÿÿÿ\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00ÿÿÿÿÿÿÿÿÿÿÿÿÿÿåÙ×âɺµ®¶¶³·ÍýÿßDz¨¤¢¥š–“‰ˆ‰…‚‚‚~~z}x}}~xxxwyy}xwzwzvywuvxyuxtvyxvvwtyqvpzv|zvzzy{xzzzxx{yxyzyzxw}{y~{}|~€{{|‚‚„ƒ‚…‡€{‚‚„‚‡Š‰‡‰Š‹ŠŒ‰ŒŽ‘Ž’••’“š™žš™›Ÿ¡§ž£ªª®²´»½ÂÉÚïÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿøàéÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿô»žŒˆƒ€~}~}||w{yzxuwwuxvrtvtvtrqpuotqppttvtxsstqqtrtpswtwwvsusuvwxxxxvxuxxvvtx{ux{uuvttxtsssspoja\\Z\\YYZXWYWSSWXWWUSRPTUQSRNQPQNOLNLLKJJIHFFHECA?A?><@?=?ADHFELIHHJIIGEHFGJJDEFBCBECEACDGJPX_fs‡¢»Úóÿÿÿÿÿÿÿÿÿÿÿÿ\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00ÿÿÿÿÿÿÿÿÿÿÿÿÿÿé×Ýã¾·®´´Âº»Ò Camara 2 = "0,000000" led_boca = "FALSE" Buena_boca = "0,000000" mala_boca = "0,000000" Espiga = "0,000000" led_espiga = "FALSE" buena_espiga = "0,000000" Bulbo = "0,000000" led_bulbo = "FALSE" buena_bulbo = "0,000000" Cuello = "0,000000" led_cuello = "FALSE" buena_cuello = "0,000000" mala_cuello = "0,000000" Cuerpo = "0,000000" led_cuerpo = "FALSE" buena_cuerpo = "0,000000" mala_cuerpo = "0,000000" Excentricidad = "0,000000" Buenas = "0,000000" Malas = "0,000000" led_excen = "FALSE" EXCENT = "0,000000" Camara 2 Configuracion = "\00\00\00\15Threshold Destination\00\00\00\0Anivissvc.*\00\00\00\13LV_ImageDTClassInfo\00\00\00\01\00\00\00Á\00\00\10\0000\00\00\03\00\00\00\00\00\00\00\\00\00\00\00\00\00\00Threshold Destination" Excentricidad.<size(s)> = "6" Excentricidad 0. = "<size(s)=0> " Excentricidad 1. = "<size(s)=0> " Excentricidad 2. = "<size(s)=30> 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000" Excentricidad 3. = "<size(s)=30> 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000" Excentricidad 4. = "<size(s)=30> 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000" Excentricidad 5. = "<size(s)=30> 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000" Nivel de luminosidad = "157,666672" led_luminosidad = "TRUE" Distancia promedio = "46,131313" Bordes encontrados = "33" Camara2_grafica = "0,000000" Dist_Cuerpo_Cnfig = "0,000000" Dist_Boca_Cnfig = "0,000000" Dist_Espiga_Cnfig = "0,000000" Dist_Bulbo_Cnfig = "0,000000" Largo total = "0,000000" led_largoTotal = "FALSE" cuello_config_cluster.Left = "0" cuello_config_cluster.Top = "0" cuello_config_cluster.Right = "0" cuello_config_cluster.Bottom = "0" cuello_config_cluster.Rotation = "0,000000" top_cuello_prod = "0" botton_cuello_prod = "0" PLC_Valor_Cuello = "0" ampolla_ok_prod = "FALSE" num_disparo_cam1 = "0,000000" PLC_Valor_Espiga = "0" PLC_Valor_Cam2 = "0" lim_min_ambar_boca = "0,000000" lim_max_ambar_boca = "0,000000" Largo Total.<size(s)> = "1" Largo Total 0. = "<size(s)=0> " Tab Control = "Camara 2" Cluster.Numeric = "0,000000" Cluster.Numeric 2 = "0,000000" Cluster.Numeric 3 = "0,000000" Cluster.Numeric 4 = "0,000000" Cluster.Numeric 5 = "0,000000" I resume "camara 1 configuration" because the rare symbols are about x10 more.
      Well, next step is to read this .ini file and now it does not give me any error but it stacks in "read panel from ini.vi" (maybe it takes about minutes for reading .ini).
      How can I do to write and read panel to/from ini well?
      It is very important for my application. Maybe there is another library that I can use?
      Thanks a lot!

    • By liskped
      Hi.
      Im working on this prosjekt where I have a TCP communication between two computers (Server & Klient). I have managed to get communication between those two. (Sending and reciving one cluster.) But I want to send and recive more than one. I looked at det Topic "Passing Cluster and Datatype Through TCP" on how to use the OpenG, but I have a problem with "the Variant to Data". 
      What am I doing wrong? Or is there another way to send more data?
       
      The Klient side:


       
       
       
      The Server side: 


       
       
    • By bbean
      After reading this LabVIEW Idea exchange request:
      http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Provide-a-better-way-to-implement-a-polymorphic-VI/idi-p/920487
       
      I was inspired to create VI macro(s) to attempt to address the problem mentioned in the request.  Attached is my first attempt and I'm looking for feedback since I know people here have strong opinions.   The benefit of this method is that a single vim (or 2 could replace a polymorphic VI with over 48 separate VIs....unless I'm missing something.  I know that VI macros are not officially supported by NI, but that hasn't stopped us from using unsupported features before.  Some people have probably already done something like this, but I couldn't find an example.
       
      To use the files, unzip them and copy them all to your \LabVIEW (version)\user.lib\macros\ directory.  
      Create the directory if it does not exist.  For example: C:\Program Files (x86)\National Instruments\LabVIEW 2014\user.lib\macros\   And as described in the wait-ms-with pass through post below, modify your LabVIEW.ini file to have the following     ExternalNodesEnabled=True and Optionally     XNodeWizardMode=True   http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Wait-ms-with-error-pass-through/idc-p/3178218#M31820
       
      Open the Example Changed.vi and review.
      Changed Example.zip
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.