Using Deadtime.xls to measure JEOL WDS detector dead times

[Probe321]

When trying to run the dead time spread sheet using Excel 365 I am getting this error.

"Active X component can't create object"

The Microprobe is a JEOL 8350F-Plus

Not sure what object Active X can't create

[John Donovan]

When trying to run the dead time spread sheet using Excel 365 I am getting this error.

"Active X component can't create object"

The Microprobe is a JEOL 8350F-Plus

Not sure what object Active X can't create

Hi Keith,
I've never tested Excel 365, but I do know that we need to modify how the Remote Server app is installed because Microsoft is really starting to lock things down in the SysWOW64 folder.  I'm assuming that you installed the Remote Server app using the latest Remote.msi installer?  See the Update page on our web site. 

Since you have a JEOL 8230/8530 you will also need to copy the JEOL EIKS files from your PFE app folder to the same folder as the Remote.exe server executable which (for the time being) is C:\Windows\SysWOW64. The list of files you need to copy are described in this post:

http://probesoftware.com/smf/index.php?topic=263.msg6658#msg6658

Also did you try running the TestRemote.exe app in the Remote application folder?  That is a good way to make sure everything is working first before trying Excel. For example you might need to right click on the Remote.exe app in the SysWOW64 folder, click the Properties menu and click the Compatibility tab and check the box to "Run this program as an administrator".  You might also need to do the same for the TestRemote.exe app but probably not.

So as a sanity check I ran TestRemote.exe on my installation (Win 7 64) and it worked fine.  Then I tried running the DeadTime.xls spreadsheet from the Remote application folder and I got the error "This operation requires elevation". 

That means Windows is detecting someone trying to run an app in the SysWOW64 folder, which it doesn't like. So I found that I had to find the Excel app which is Excel.exe (I'm running Office 2010 or v14), which is in the Program Files (x86)\Microsoft Office folder and as above right click it, then click the Properties menu and then click the Compatibility tab and check the box to "Run this program as an administrator".   That fixed it for me.

Again, we need to re-write the installer so all these Remote server files go into a different folder that Microsoft isn't being so protective about.  I'll let you know when we have the new installer working, but in the meantime you should be able to get it working following these instructions.

[Probe321]

Tried your recommendations still get error.  I suspect it is Microsoft excel 2016.  Thanks for the help waiting for the new improved installer.

Keith

[John Donovan]

Hi Keith,
Did you try the TestRemote app?   That should tell us if it's Excel or not.
john

[John Donovan]

We're working on updating our Remote automation installer to install the Remote server files to a shared folder that won't trigger the Windows UAC, but in the meantime we wanted to share new Excel files with Microsoft's more modern extensions (see attached below) for calibration of the deadtime constants on your instrument.

The pdf is an old document from Paul Carpenter that should probably get updated eventually...

[Probe321]

The problem is User Account Control.  Changed it to never notify.  Testremote.exe and testdeadtime.xls worked.  Once the computer scientist looked at the response thought it was either a missing dll or UAC

[John Donovan]

The problem is User Account Control.  Changed it to never notify.  Testremote.exe and testdeadtime.xls worked.  Once the computer scientist looked at the response thought it was either a missing dll or UAC

Hi Keith,
That is good to know.   I had been suggesting people try running the remote server in compatibility mode, but this might be a better short term solution for some.

The Remote server works fine under Windows XP and earlier, but now that Microsoft has really "tightened down the screws" of executables running from the system folders, we are currently modifying the Remote server installer to copy the Remote server executable to a "shared" Windows folder, so other apps (e.g., Excel) can easily find the Remote server, but Windows won't get angry. 

Thanks for figuring this out.
john

[John Donovan]

We have posted an updated description of the steps necessary to allow the Remote automation server to register itself the first time it is run, here:

https://probesoftware.com/smf/index.php?topic=129.msg7917#msg7917