[LVTN] Code Capture Tool

[crossrulz]

Was just trying to install a bunch of my favorite tools on a new computer last night.  VIPM would not let me install the CCT because there was a conflict.  Apparently, it conflicts with itself!  VIPM 2014.  Looking at my other systems who have upgraded to VIPM 2014 still has the CCT installed, but it is showing up as a conflict.

 

Perhaps the conflicts with Code_Capture_Tool >= 0.0.1 should be removed from the package.

[Yair]

I didn't deal with the VIPM package myself, but if I remember correctly, this was the previous incarnation of the CCT (i.e. the older version was with the underscores and the new one doesn't have them) and there was no way to tell VIPM that this is an upgrade, so it was marked as a conflict to alert the user to uninstall the old version first. I don't know if the only real change was the renaming of the package or if there were other changes which required this.

 

At least I think that's the issue. I didn't check it.

[Ravens Fan]

I didn't deal with the VIPM package myself, but if I remember correctly, this was the previous incarnation of the CCT (i.e. the older version was with the underscores and the new one doesn't have them) and there was no way to tell VIPM that this is an upgrade, so it was marked as a conflict to alert the user to uninstall the old version first. I don't know if the only real change was the renaming of the package or if there were other changes which required this.

 

At least I think that's the issue. I didn't check it.

 

I've had issues with this as well.  I'm hoping it can be fixed, because it just doesn't make sense.  I think I've been battling it for a couple years, but got by with just copying the appropriate files from the old PC to the new.  I failed to do that when I got my new laptop a couple weeks ago, and I'm trying to install it fresh.

 

I installed VIPM, then allowed it to update itself.  I try to install the CCT that shows up automatically and appears to be the latest version 3.2.1-46.  It says I can't because it conflicts with the Code_Capture_Tool 0.0.1 which I don't have installed at all because this is a fresh PCl, fresh LabVIEW, and fresh VIPM setup.

 

I was able to find an old .OGP file I had on my PC from 4 years ago, version 2.1.4-1.  It installed without any issues.  Then I was able to install the new 3.2.1-46. It says there is an auto-conflict with 2.1.4-1 and it will uninstall the old version.  It uninstalls the old version and installs the new without any errors.  However, the VIPM screen shows a warning icon for the new CCT.  But the CCT seems to work just fine in LabVIEW.

 

I think it is related to the conflict with the Code_Capture_Tool 0.0.1, but the conflict is backwards and actually does install more or less properly when you do have an old version with underscores, but fails to install if you don't have an old version of the CCT installed.

 

The CCT is by far superior to the built-in LabVIEW snippet tool.  I use it all the time and recommend it to others.  But the conflict issue on install is a huge barrier when it really shouldn't be.  And as time moves on, the chances of someone having the old CCT, and a real conflict with the old CCT should be very infrequent.

[Yair]

I don't remember seeing this at all the last few years, but I don't install the CCT too often.

 

Just now I opened LV 2014 beta 32 bit and VIPM 2014 beta on what is essentially a clean virtual machine and did the following:

1. Searched for "code capture".
2. Chose to install the first option.
3. When asked about contacting the network to get more info said yes.
4. Waited while VIPM downloaded a bunch of spec files which don't actually have anything to do with the package from NI's FTP server.
5. Saw that it says it's "Code Capture Tool v3.2.1-46 by LAVA" and "This Package Conflicts with these other packages:
   Code_Capture_Tool >= 0.0.1"
6. Clicked the install button and confirmed the license. Didn't see any problems because I don't have the conflicting package installed.

I expect that's the same experience most users have and it's the same thing I remember for most of my installs. I don't know what the difference is in your case, since you both say your PCs are also new. Maybe you have some kind of other package which has the old one linked somewhere? Like I said, I didn't deal with the package myself and my knowledge of VIPM package management is basically zero.

 

In any case, you're probably right that having the conflict is not that critical and it could be removed if it's causing problems. I'll let Ton weigh in on that.

[Jeff Bohrer]

I just did some testing of this myself.  once on a fresh laptop with a clean 2013 install.  and once on the old 8-Ball laptop after upgrade to 2014 DS2   VIPM would not allow either machine to install CCT 3.2.1-46

 

Resolved by downloading CCT 2.1.3-1 and installing that package first from the product homepage.  VIPM was scessful in installing 3.2.1-46 as an upgrade

[Yair]

Ton appears to be AWOL and I can't seem to reproduce this issue. I hate shifting the burden, but can you check with JKI  to see if there's an option to enable debugging or logging on VIPM and see exactly why this is happening on your machine? I'm seriously hoping that this is not the experience most people are having. I'm still suspecting that this has something to do with something else you installed first or something you have configured, but I have no idea what.

 

The other alternative to figuring this is out is to remove the dependency. Like I said, I haven't dealt with the VIPM part and I also haven't personally dealt with the CCT code directly in a long time (my role in recent years has been more in feedback and design. Ton did most of the actual coding), and it's currently saved in Mercurial, which I don't even have installed. I would have to read the build instructions to figure out how to build it as much as anyone else would, and I don't know if I have the tools needed to build an updated version. Anyone who wants to can have a look here - http://sourceforge.net/p/lv-cct-tool/code/ci/default/tree/

[hooovahh]

Put me down as another who has issues with this.  So I make a VIPC with all the OpenG, internal, and some other packages for easy install for other developers.  I started getting complaints that they couldn't install the VIPC with VIPM 2014.  So when I got some time I installed each package one at a time until I found one that wouldn't install and the CCT was the culprit. 

 

It was a little weirder than that too.  If a user double clicked the VIPC file that contained the CCT in 2014, then the Tools Network dialog would show up.  Instead of the dialog asking about installing the VIPC.  The same thing happened if I double clicked the 3.2.1-46.ogp file.  The only way I could attempt to install it was to go to File >> Open Package File(s) and select the file.  At this point I got the error saying there was a conflict.

 

So I extracted the package, edited the spec file to not have any conflicts, then re-zipped it into a 3.2.2-46, and then I was able to install it by going to File >> Open again, but not if I double clicked the file.  I don't mind attaching my version but I feel it would confuse people.  Looking at the repository it looks like a version 3.2.2 was planned but never built.

 

At the time of all of this confusion the developer had no packages previously installed.

[Mellroth]

I've had issues with VIPM 2014 not resolving items paths correctly. To be more precise, I rebuilt an old package with VIPM 2014, and all additional installation directories would not install properly. In this case the problem was that previous versions of VIPM used '\' as a separator, but the 2014 version had switched to '/'.

 

http://forums.jki.net/topic/2406-frustrated-by-vipm-2014/page__view__findpost__p__5830

 

You could check the OpenG spec file and have a look at the different paths.

 

/J

 

 

[hooovahh]

In this case the problem was that previous versions of VIPM used '\' as a separator, but the 2014 version had switched to '/'.

Thanks for the info, but this issue is not related to this package.  No where in the spec file does "<Path>" appear or any "\" in respect to a path.

[eberaud]

Resolved by downloading CCT 2.1.3-1 and installing that package first from the product homepage.  VIPM was scessful in installing 3.2.1-46 as an upgrade

 

I ran into the same conflict issue, so I tried to find version 2.1.3-1 and let VIPM upgrade it but I can't find this version. The earliest version 3.x I can find is 3.2.0-41 which led to the same conflict error...

[Yair]

Like I said, I never dealt with VIPM myself and Ton isn't responding to emails (championship went to his head? Blood went to his head on account of being upside down?).

 

I tend to agree that it's likely that the conflict is the issue - looking at version 2.1.3.1, it doesn't have a conflict listed, so it would explain why it can be installed. I would guess that for some reason VIPM is ignoring the underscores in the name in some places and treating it as the same package, so it thinks it conflicts with itself. What's not clear to me is why this is happening only to some people. Maybe it is something else you have installed? Maybe it has to do with the version number of VIPM (although it was said here that this has been happening for a couple of years)? Maybe it has to do with the VIPM license, which runs additional code for different licenses?

 

In any case, I think that it should be safe enough to remove the conflict now. I took the OGP files I had on my computer and manually removed the conflict line from the spec file and from the spec file inside the OGP file. I didn't change the version number and I didn't test that this works properly. I'm attaching these files here and they should be unzipped to <Users>\All Users\JKI\VIPM\cache. I would like to someone who knows where this can be reproduced to test it there and see if it's no longer happening. If it doesn't, we'll figure out a way to build a new package.

 

Also, if someone has contact with Ton (e.g. on Facebook or Twitter), maybe you should contact him separately and nudge him towards this.

lv-cct.zip

Edited December 7, 2014 by Yair

[infinitenothing]

Thanks for fixing the conflicts. The new package works for me.

[Ton Plomp]

Like I said, I never dealt with VIPM myself and Ton isn't responding to emails (championship went to his head? Blood went to his head on account of being upside down?).

.......

 

Also, if someone has contact with Ton (e.g. on Facebook or Twitter), maybe you should contact him separately and nudge him towards this.

Sorry guys.

 

I had a chat with JKI about this, and there is a fix available for VIPM, or the OGP that Yair posted. I'll see if I can get the version updated soon.

 

Yes the move to New Zealand had been of quite an impact and I moved out of the LabVIEW world, moving to PLCs and SCADAs at an Aluminium Smelter. Working with different technologies has shown me the strengths of LabVIEW and weaknesses. However I can tell that the programming language LabVIEW is far superior to any of the PLC languages i've been working with so far.

 

Cheers,

 

Ton

[hooovahh]

Working with different technologies has shown me the strengths of LabVIEW and weaknesses. 

I'd be really interested in your opinions on this.  I'd encourage you to make a blog post, or post on LAVA.

[Joseph LDIT]

Just wondering, can I make an LabVIEW exe file that uses the CCT VIs?  Will I need anything extra to make it work?

 

thanks,

Joseph

[Yair]

I'm pretty sure all the functionality should work, but I don't remember testing specifically. You can look at the documentation for each method or make a small test app.

 

Some potential caveats:

1. LV strips the BD of all VIs that go into an EXE unless you explicitly tell it not to. Without a BD there's nothing to capture.
2. LV strips the FP of most VIs which go into an EXE. For both, this isn't relevant if you're looking at external VIs.
3. At some point, LV lost the ability to read an image from the clipboard in an EXE. The method just doesn't work. I don't think this affects writing an image to the clipboard, but it might.