jgcode

Allow Drag and Drop of Polymorphic VI to Block Diagram From Icon

[Cross-posted to JKI] I have posted this before I think but here is how I do it: Start with a LabVIEW Project Create a top level Project Library that is used to namespace my distribution Add a virtual folder to the LabVIEW Project called support Add all the reuse VIs that will be made private to it, normally done by dragging and dropping from the dependencies item in the LabVIEW Project NI Builder assign the support folder to a Project Library during the build process Run my build script that adds the support Project Library to top level Project Library Then makes the support Project Library a private member of its parent (top level Project Library) Now all the VIs in the support folder are private to the distribution and namespaced so they won't collide with the actual reuse VIs under <LabVIEW> Currently this workflow is for NI Builder + OGPB, but I am wanting to move it to VIPM 2010. I think it shouldn't be an issue, all I have to do is handle adding the support VIs to a Project Library as part of a script - all the rest I already have code for. But I am interested in anyones else's thoughts

LabVIEW's ability to be extended. There is nothing I like more then creating reuse code and have it appearing in the palettes or writing tools that I can access natively.

TDMS in a binary format, that I have found weirdly enough to be quite large compared to other formats and thats not taking into account the index file it creates. If disk space is a major concern then why not just use binary using the LabVIEW primitives?

Hey Madhav NI have a bunch of example presentations for User Groups here. Depending on what you end up doing, you may be able to save some time and pull a bunch of stuff out and create a mashup (even for part of your presentation)? Cheers -JG

RE: Speed - Darren recommends it - need more be said Well, I won't argue the above as I believe the DSC could do with a bit more polish too. But I think Shared Variables are a powerful addition to LabVIEW. The evolution of all these related products - DataSocket, Tags, NI Scan Engine, RSI, Alias IO, streaming, IO Servers, support for type-defs etc... has really impressed me. I looked forward to its continued growth.

That's really cool!! We had a however, the guy was not looking at LabVIEW!

Hi SuperS_5 The issue is with R&D however, I followed up with NI AE to get the actual CAR Number - #257325. I have been chasing it up periodically over the last 6 weeks, but there is nothing new to post. (I have no clue really) but I don't imagine there would be a simple fix? Also, I am hoping that an X-Control polish will be part of the 2011 stability release. That would be sweet.

Hi Fred Here is a sample snippet to get you started that you can use to change the Label Text of a Front Panel Control. Cheers -JG

Yer, it all makes sense now. Well, apparently Beyond Compare works well, but my trial is running out and its prompting me to buy a key. Its 30-50 bucks, so its not a ball-breaker, but I look forward to seeing if you come up with an alternative.

FWIW - VIPM uses a VIP format for packages (which is the 'new' OGP format if you like). VIPC is a file that contains packages (VIP or OGP files). Seeing that the VIP format is an extension of the OGP I would say is better - i.e. in VIPM 2010 supports non-symbolic installation locations using sub-packages. I just downloaded Beyond Compare as it can be configured to handle diff's of packages, but it seems you have to pay for it

One way is to keep a circular buffer of the latest data in memory for display.

Great post. Is it Konstantin Shifershteyn?

Gotcha!

5000 and as witty as ever! Congrats too!

You're ok - it was me who has been running my mouth requesting a useless feature and creating workarounds for the last x months!

If you don't have VIPM installed then what are you doing with the extracted packages?

I have - I wrote reuse VIs (for VIPM 3.0) that I use in my build scripts for OGPB packages that parse the VIPC for dependencies (i.e. create list) so I could programmatically update the OGPB file's dependencies etc... So by joke I am guessing you mean simple then?

Hi Michael - welcome to LAVA I agree with Matt - the first is preferred over the second as you have a copy of the time data in all arrays. The answer may depend on the what you are doing with the data as well: Will the arrays be in memory at the same time? Do you need that format to be created i.e. to write to separate files? Are the arrays massive or really small? What platform will you run on (desktop or Real Time)? LabVIEW is good in that, in general, it handles calls to the memory manager. You may find the second does not make a big difference and might be easier depending on what you are doing etc... If you are ever unsure its easy to run quick performance tests in LabVIEW too. Cheers -JG

Starting off the week slow - I didn't understand the above posts Can you explain in more detail?

Snapshotting your entire user.lib is not as efficient as only including the packages which your code actually calls (VIPM can scan for these). Especially as your reuse library grows. Additionally you may have calls to VIs outside user.lib from third party packages (e.g. in vi.lib) or your own in different locations (e.g. drivers in instr.lib) etc.... Anyways, probably also worth mentioning is that VIPC's have a cool feature that allows you to create a VIPC as a list only (remove packages). This removes the footprint of copying all packages into SCC, whilst still maintaining the benefits of SCC (given you never release the same package number twice - which you can't really do in VIPM 2010). As long as you have a backed-up repository of all packages (internal and external) that are easy to get to - then this could be desirable.

I don't recommend this for distributing reusable code. This was a feature I thought I wanted for ages - but the VIs/Classes then don't recompile when you install in a future version of LabVIEW. On the flip side, if you could install, unlock, mass-compile, save all, lock - then that may be desirable.

For now its manual, but no more manual or discipline like than getting your developer to follow a workflow that uses SCC or comment code etc... Yes - but more correctly at the start of opening the project. In LabVIEW 8.x this would correspond to just before opening the LabVIEW Project file. No, on change to dependencies (this VIPC file is part of the project) update the VIPC file. Then Commit (on change) just like any other modified file. Well thats your call - but with a callout like that you know we are all expecting you to post the tool to LAVA within 24 hrs (I have started the countdown already)