Run remote application with ActiveX

[lmattiso]

I'm currently trying to  launch a session of MATLAB on a remote computer from a client computer with Labview.  I can start the program via ActiveX on the local machine but when I change the machine ID to the remote computer, I get a -2147467238 error (The server process could not be started because the configured identity is incorrect.  Check the username and password).  I believe this is a setup issue with DCOM on the remote computer.  I've gone through a couple of tutorials and adjusted everything that was recommended but I still get this error.  Both machines are running XP SP2 and I'm logged in as the same user on both.  They are direct connected though via a crossover cable.  Could this be the problem?  They aren't a member of a domain but they are a member of the same workgroup and I can see them in explorer.

I added the Everyone group in the Com Security limits and defaults tabs and added MATLAB to the exceptions list on windows firewall.  I've disabled the firewall also with no change.

Any ideas?

Thanks,

Larry

[smercurio_fc]

DCOM is a pain in the a**. We had the same situation here in trying to get the Agilent VSA Software remotely controlled, as it runs off of a laptop. I don't know if this will work for you, but our configuration is as follows (based on the tab names)

• General: Authentication Level set to "None"
• Location: Only "Run Application on this computer" is checked
• Security: 
  • Launch and Activation Permissions: Use Default
  • Access Permission: Use Default
  • Configuration Permissions: Customize (in the ACL add the user/group and set it to "Full Contrl"
• Endpoint: left it alone
• Identity: Set to "The interactive user".

I have no idea why it works. I just know it does, and I pray that it continues working.

[lmattiso]

Yeah, I'm starting to realize how frustrating DCOM is.  Ridiculous fighting with XP security settings.  I'm going to see if putting the machines on a domain will fix the problem.  It's definitely an authentication problem and I've got the DCOM settings as open as possible so I'm not sure what else I can change.

I may also try to put a Labview executable on the remote machine and try to use ActiveX calls with it to do what I need instead of talking to MATLAB directly.

Larry

[SunshineDesign]

I've been working with the VSA Dcom for over 18 months now and the DCOM connection is rather fickle at times. The MS Dcom security model is primative and requires both server and client to be loged in same and same password. another setting is "Simple File Sharing" must be enabled. I also included one of the connection documents Agilent shares with the DCOM security settings. One last thing is the security settings can occasionally reset and needs to be checked if you have problems. Sometimes to solve a DCOM connection problem you have to be using a later version. Versions prior to 7.2 have several known connection issues. Also make sure the firewall is turned off. Setting the VSA Vector or Spectrum applications as exceptions does not always take care of the connection issue. I don't have to other DCOM connection document from Agilent on me and will post later when I have access to it.

[smercurio_fc]

We haven't had issues with the VSA software once I got the DCOM configured, and I thought the settings might help the original poster who was trying to get Matlab to work remotely. It just seemed like a lot of hocus-pocus to me.

I'll keep your information handy should I run into any problems.  Thanks.

[lmattiso]

Sunshine,

Thanks for the info.  I'll look over the Agilent notes today.  After destroying a COM+ installation on the laptop I was using (which is a frustrating experience trying to reinstall), I started new on a different machine.  Surprisingly everything works except when I launch my apps remotely they seem to run in the background so I don't see the front panel.  If I do a test with IE, I can see the process running in the server's background but no window (even if the property is set to visible).  If I have another instance of IE running, then I do see the additional window.  Any insights?

To get the COM working I had both computers on the same workgroup with the same user and password (null pwd not allowed).  I read that simple file sharing should be turned OFF so that's what I did.  I had some exceptions setup in Windows firewall but in the end I had to disable it all together.  I also had to modify the DCOM settings to allow my user Launch and Activation privileges. 

Larry

[SunshineDesign]

Larry,

I ran into the problem of the VSA application running in background and not displaying on the screen properly once at my last client. I resolved the problem by, killing all the extreneous instances called to try and get it working and then resetting all the DCom settings and re-enabling the Simple File sharing and rebooting. It seemed the DCOM settings can be reset somehow. I was using VB6 as my development platform at the time. I am now using Labview got everything working fine with version 10.01. I was tasked to use version 6.3 to free up the v10 license. I was not able to connect to 6.3 (several automation problems reported on line by others) I upgraded 6.3 to 7.0 and then to 7.2. I was still seeing the automation error 3008 when I tried to use the measurement handle. I could open the app and get a measurment object handle, but got the error trying to use the measurement handle. Other reported 7.2 worked OK with labview, but I have not been able to resolve the error. I had to go back to version 10.01.

[SunshineDesign]

I have some new information I wanted to share. I discovered working with the versions of the VSA Dcom that Labview has a nasty habit of keeping it's handle to the old VSA DCom object, if it is still on the computer. I had all the DCOM version files archived on my test machine and even though I uninstalled the v7.01 and then cleaned the registry with VsaRegClean.bat, as long as the file was still on the computer, Labview kept coomming back to that version in the Type Library browser when I tried to rehook with the "Automation Open". I had to close Labview and reboot to break the handle and remove all the other DCOM files and directories, then load the DCOM version desired, Install it and reboot, then bring up Labview and connect to the DCOM object. Labview will now be able to work with it properly. Note that the Agilent VsaVector.tlb does not show up as version 10.0. Labview will display in in the Type Library Browser as Agilent 89600 Vector Signal Analyzer 9.00 version 1.15. So this is a bit confusing as the Agilent VSA help and splash screen at start up shows it to be version 10.01.

So just to reiterate, if you are having DCOM connection issues due to DCOM version, kill Labview, reboot, delete all old DCOM file versions, Load the new DCOM version files, install them and reboot to make sure they register properly and then bring up Labview to connect to them.

I was able to finally retest the version 7.2 connection and it did still show the automation error 3008 as the older version 7.01 did. 7.01 gave the error when I tried to use the measurment object handle. 7.2 gave the error when I used the measurement object to open the frequency object. So I can now say v7.2 has a Labview automation connection issue.

[SunshineDesign]

Here is the other document I got from Agilent some time ago that goes into the details of setting up the DCOM connection on the two computers. I finally dug it up.

[lmattiso]

Thanks Sunshine, that's great information to have.  I found out what I was doing wrong to cause the remote application not to be visible.  I didn't have the interactive user selected to run the app.  I had the launching user selected instead.  Now when I call MATLAB from my remote machine, I see the command window appear on the other one.  I still don't see any echo of what Labview is writing to MATLAB on the remote machine and I'm not sure if that's something I can change on MATLAB's side or not but I can send and receive data.

Now the problem is that the current MATLAB code that I'm launching remotely has a bunch of user input and dialogs that hang up Labview.  There's input at the beginning of the MATLAB routine for test info and there's input at the end prompting the operator for comments or to run again.  I can get around the user input in the beginning by populating variables in the MATLAB workspace then loading them in the script program instead of the keyboard.  I need to find a way to allow Labview to interact with MATLAB while the script is running so I can deal with the dialogs at the end of the test.  Does anyone know of a way to set up a two way link between the two such as a DDE connection that would allow Labview to pass data while the script is running?  The execute method that I'm using to launch the script expects a string return variable and Labview sits and waits until the script is complete before relenquishing control.

Ideally I would have some way of programatically simulating an operator sitting at the other end entering in data and closing dialog boxes without using a Remote Desktop (any function calls in a MATLAB dll that I can use or ActiveX objects?)

Thanks,

Larry