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://smf.probesoftware.com/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://smf.probesoftware.com/index.php?topic=129.msg7917#msg7917

[Probeman]

I would just like to point out that although the Remote server is very useful for creating custom applications for your JEOL or Cameca instrument, for example see the sample Excel spreadsheets in the Remote.msi installer, e.g.,

TestRemote.xls              - simple example of how to connect, and control your microprobe from Excel
TestReproduce.xls         - example of calls to test the spectrometer reproducibility on your microprobe
TestStability.xls              - example of calls to test your instrument stability over time
TestColumn.xls              - example to control the column functions on your microprobe

The above Excel files will probably need to be changed to Excel "macro" files with the extension .xlsm because the Remote interface utilizes the macro feature in Excel.  You can get started writing your own Excel macros to control your microprobe instrument by downloading the Remote server installer Remote.msi here:

https://smf.probesoftware.com/index.php?topic=88.msg315#msg315

One can also develop custom image acquisition applications as described here:

https://smf.probesoftware.com/index.php?topic=754.0

Finally I should note (the purpose of this post is), that although there is also a Deadtime_Acquire.xlsm Excel macro file that can be used to calibrate one's dead time constants, which utilizes the Deadtime_Calc.xlsx Excel spreadsheet designed by Paul Carpenter, I no longer recommend the use of these spreadsheets for the calibration of dead times on EPMA instruments.

The reason is that we now have a much more accurate dead time method which can handle the non-linear response of our counting electronics at much higher count rates as described here in this topic:

https://smf.probesoftware.com/index.php?topic=1466.msg11102#msg11102

This new logarithmic dead time method published last year in Microscopy & Microanalysis allows one to exceed the linear response model that previously limited us to ~50 kcps and allows one to obtain stable count rates to ~300 to 400 kcps using the new constant k-ratio method as shown in our M&M paper

https://academic.oup.com/mam/article-abstract/29/3/1096/7165464

If you do not have Probe for EPMA, the link above describes how to acquire the intensity data for this new dead time calibration, but if you do have Probe for EPMA, this new dead time calibration is very easy and fully automated, as described in the pdf file available from the Help menu in Probe for EPMA: