Integration with Surround SCM

[klessm1]

I am getting an error when trying to configure LabVIEW 8.5 to use Surround SCM version 5.0.4, and their new beta version 2008.0.25.  I also get the error when just trying to make a dll call using the call library function (after I point to the dll and the function and go to the block diagram it gives the error).  I have used two computers, and LabVIEW will load perforce and vss just fine through the options window.  I also have TestStand on the systems and it integrates fine with both versions of the Seapine Surround SCM client.  I tried a couple of different installation types (with and without the JRE) with no luck.  I get two different errors when I run the two different versions, but they are similar types of errors.

The errors are attached.

I looked into if the dlls need to be registered, but I get the error that they don't have a register entry point, so they probably are not supposed to be registered.  I do have the path for the dlls in the environment variables (put there by the installation of surround).  The only thing I could maybe think of is somthing needs to be setup in LabVIEW to recognize the dll links.  Like I said, no problem with TestStand 4.0 linking to either version (I believe it calls the same dll).

The dll in question is: Surround SCM SCCI.dll

That is the dll that is pointed to in the registry.

Thanks for any inputs.

[gmart]

I think there may be a conflict between DLLs that Surround SCM loads and what LabVIEW uses. Surround SCM seems to be loading some QT DLLs when LabVIEW tries to configure the provider. If the Surround SCM DLLs are statically linking directly to the QT libraries, then they need to be found when the Surround files load. That means unless the QT DLLs are located in a place in the PATH environment variable, the DLL may not load. Additionally, LabVIEW uses some QT DLLs as well. It may also be that there is a version conflict between the DLLs that LabVIEW uses and that which Surround SCM uses. In order to make sure the QT files are loaded in LabVIEW before Surround's files, I would do this:

1. Make sure SCC is not enabled in LabVIEW.
2. Create or open two LabVIEW projects.
3. Create a new VI in one of the projects. Drag that new VI into the other project. This should force the QT DLLs to load.
4. Try to configure Surround SCM in LabVIEW.

You may still get the same result. If not, it would be interesting to know what the new behavior is.

TestStand does not use any QT files so that might explain why it does not have a problem with Surround SCM.

[klessm1]

Thanks for the information.  It still does not work, but now it only give the second error box that the LabVIEW vi's generate.  It no longer generates the dll entry point error.  I noticed that after the first time of trying to configure the SCC provider, it would only give the second error.  I also tried to move the environment variable path to the front of the search but that did not work. I noticed that the QT dlls are different revs (duh!!!).  This is not good.  I am assuming that LabVIEW is depending on a certain version and won't work with the new version?  I will try switching the dlls for LabVIEW (old ones) to the new dlls.   Hopefully they are backward compatable.  I will know right away.

If it doesn't work, is there another work around?

[klessm1]

I tried using the new QTlib with LabVIEW and it worked.  I didn't get any errors in LabVIEW, but that doesn't mean that some function way down deep in LabVIEW is going to call something that is not compatible.  I have a support case with NI and hopefully find out soon if the 4.3.0.0 version is compatible with LabVIEW 8.5, or if there is some way to trick LabVIEW and Surround to use their own QTLibs.

Thanks again.

[gmart]

After some investigation it seems the problem is compatibility with the QT DLLs that both LabVIEW and Seapine calls. Seapine is using version 4.1.4 and LabVIEW is using a newer version. Apparently, the newer version does not have an exported function that Surround SCM needs. This is a compatibility issue with the QT DLLs.

For now, the workaround is what you found. You can replace the QT DLL's LabVIEW uses with Seapine's versions. When I tried this with their 5.04.37 version, I was able to get Surround SCM configured. While not ideal, replacing the DLLs should not adversely affect LabVIEW. There is a tool that may not run ok  - the Multi-Variable Editor. This is a LabVIEW DSC feature so if you don't use it, you should be ok.

I would contact Seapine and let them know that there is a compatibility issue with another application that uses QT. They may want to change how they load their code or write their DLL.

[rolfk]

---

@gmart wrote:

I would contact Seapine and let them know that there is a compatibility issue with another application that uses QT. They may want to change how they load their code or write their DLL.

---

Ok so it is a shared variable thing for DSC. Thanks for that information. But your suggestion to talk to Seapine is a bit .... well. Why would they have to change things and not LabVIEW?

A Windows development environment that uses some common libraries originating from Unix is basically simply asking for troubles since the method to prevent version conflicts under Unix is to give each new shared library version a new unique name that is constructed from the version numbers and use links for compatible versions, something not frequently done under Windows (and links are an almost unknown feature under Windows) and being a major reason for the frequently mentioned DLL hell, which we see in action here too.

However I wonder why LabVIEW would even attempt to load those QTlibs when DSC isn't even installed on a system or does klessm have DSC installed too on that system? I know for sure I haven't for LabVIEW 8.5 and still have those QTlibs in my main LabVIEW directory.

Rolf Kalbermatter

[gmart]

The suggestion for contacting Seapine was to let them know that perhaps Seapine's assumption that the QT DLLs they load would only be the ones their program ships with may not be correct. In this case, another app (LabVIEW) has their own copies of QT DLLs which cause problems for their app. That does not mean that LabVIEW should (or won't) do something to prevent this behavior from happening, but the suggestion was just to provide feedback to Seapine not to propose that Seapine is responsible to fix the problem.

LabVIEW isn't loading the DLLs until it needs them. The problem is that the search routine for locating the QT DLLs is probably a "look next to the running EXE" algorithm and hence Seapine's software loads LabVIEW's newer set of QT DLLs which are missing functions it needs.

[klessm1]

I am not sure what they are using the dlls for, but I am not using DSC and I do not have it loaded.  I called NI again today in today and they said they would get back to me by Friday on if the new dll versions will work.  Hopefully they have good news.  I did contact Seapine, and they have a patch for the 2008 version to look like the 5.x version of surround for compatibility with the 7.4.x version of TestTrack.  It has the same issue with LabVIEW though.  They mentioned something about maybe working on a patch that would go onto 2008 since they are releasing it today or tomorrow. 

My luck would be that I go through all this and end up using VSS for cost reasons (we already have license for it).  At least I would have helped out any other users that want to go to Surround.  It is the best product by far for LabVIEW development (even with the dll bug) that I have looked at if you are looking for an SCM solution and not just somewhere to store your code.  It is really good when integrated with TestTrack.  That is probably why it is so expensive.

[gmart]

This issues has been reported to LabVIEW R&D and documented in ID 4E9A8DP2.

Surround 5.04.37 uses QT DLLs that requires an exported function that is not present in the QT DLLs LabVIEW uses.

Surround 2008.0 uses QT DLLs that use new exported functions that is not present in the QT DLLs LabVIEW uses.

So, out of the box, the above versions of Surround SCM will not work with LabVIEW 8.5. The above Surround SCM versions should work with LabVIEW 8.0 or 8.2 since those LabVIEW versions do not use QT (which is also why TestStand works).

The current workaround is to replace the QT DLLs in the LabVIEW directory with the Seapine DLLs or to move the LabVIEW QT DLLs to a subdirectory. The workaround has not been extensively tested, but LabVIEW seems to function ok in both scenarios. There will be a problem, though, with the Multi-Variable Editor (which is enabled as part of the DSC module). It will not run with the workarounds listed above.

Message Edited by gmart on 10-10-2007 11:36 AM

Message Edited by gmart on 10-10-2007 11:37 AM

[klessm1]

Thanks for checking this out.  Seapine has a guy working on a dll update.  I guess he just went to a Trolltech conference where this type of conflict came up and I guess they went through how to get around the issue.  I will let you know if they come up with a solution and what it is.