History of EPMA

[Anette von der Handt]

Hi,

the Camebax Microbeam came out in 1982. It was the microprocessor-controlled version of the Camebax (released in 1974).

[Karsten Goemann]

I don't think the Cameca SX100 came out as early as 1987 ?

The SX50 here in Tasmania was installed in 1989 and in Clausthal in Germany we had an "early" SX100 (#654, with Unix system) installed in 1995.

[Probeman]

I don't think the Cameca SX100 came out as early as 1987 ?

The SX50 here in Tasmania was installed in 1989 and in Clausthal in Germany we had an "early" SX100 (#654, with Unix system) installed in 1995.

That's right.  Our Berkeley SX-51 was installed in 1992 or so, so the SX100 was after that.

[Anette von der Handt]

Cameca SX100 was officially launched in 1994 according to de Chambost (2011), History of Cameca. This paper also states that "..the SX100, the study of which started in 1987, had a new electronics system.." which is confusing wording IMO.

Cameca SX50 came out in 1984.

[rickard]

For the record, officially confirmed by Kim Epps from JEOL that the  JXA-50A was introduced in 1971.

[rickard]

Revised listing after inputs from Forum:
                   Year introduced
SEMQ-II   ARL          1978
SX-100   CAMECA   1994
JXA-50A   JEOL           1971
EMX-SM   ARL           1960
CAMEBAX MICROBEAM   CAMECA   1982

[sem-geologist]

Cameca SX100 was officially launched in 1994 according to de Chambost (2011), History of Cameca. This paper also states that "..the SX100, the study of which started in 1987, had a new electronics system.." which is confusing wording IMO.

Cameca SX50 came out in 1984.

As operator of SX100 (manuf. 1998) and SXFiveFE (manuf. 2014) I had also found that sentence absolutely confusing, but not by the quoted part, but the part which follows after.
Actually I am not confused by dates. Contrary, I think that reveals really interesting developement (and excellent practice of company behind). SX50 came out in 84 (officially) probably similarly to SX100 Cameca it was being developed many years prior. Indeed I find this incredible that only three years after launching SX50 they started to look to the future and started developing SX100. It is interesting that it took 7 years to get the SX100 stable enough to launch as a new product, However it gets even more interesting when tracking the introduction dates of used components in finally launched product - it reveals some flexibility and adaptability to the changing market opportunities and advancing technology, something which existed then in Cameca.

Anyway as I mentioned the real confusion is actually not "having a new electronics system from 1987", but actually further in that paragraph when considering FPGA's:

The SX100, the study of which started in 1987, had a new electronics system that used programmable logic devices known as field-programmable gate arrays (FPGAs), which can often replace an entire printed circuit board (PCB) by a single circuit.

I think de Chambost got confused himself as SX100's in 2011 were being rolled out from factory with newer hardware than the hardware in prototypes from 1987 or at launch in 1994. Indeed in 2011 FPGAs were replacing lots of large circuit boards and SX100 was being sold with such new boards (the same hardware as later launched SXFive, which then probably was already in development). Actually modern implementation in FPGA-based solutions could achieve even more impressive effect than what De Chambost stated: i.e. 3 fully populated VME boards (6U extended size eurocards) (that is a Scanning Board, an Aquisition board and a Visualisation board) and squeeze that logic into a single board! three - into one!. This also eliminated lots of complications as logic of these three boards need tightly to work together, and previously signaling had to cross over VME motherboard - lots of delay and timing issues. In a single FPGA chip it is much easier to synchronize all of three logics, and it also consumes much less power and produce less heat. The similar FPGA-introduced improvements are present for stage and WDS boards, where stage board got twice smaller, and WDS got extremely un-cluttered and streamlined. The thing is this huge improvement come only with late SX100 or as an upgrade option for older SX100.

Now the confusion at my side originated from the fact that exact model of FPGA's on these new boards is Altera Cyclone (the I-st generation), which hit the market only in mid 2003! However, while this particular FPGA hit the market 2003, the first kind of mass-produced FPGA device was manufactured in 1984 (Altera EP300). Thus the experimentation with these kind of devices really could realistically start at Cameca R&D in 1987. Albeit these first FPGA was much less capable, and  claim of "replace an entire printed circuit board" from POV of capabilities of FPGA's up to mid 90'ies is very huge overstatement for SX100 officially launched in 1994. However the initially launched SX100 (with old hardware boards, thus also including our manufactured in 1998) had few FPGA's already replacing some very limited part of circuits. The only place where it was introduced was the WDS board. There the two FPGA's (Actel A1280A) in parallel was controlling counting of pulses from 5 spectrometers. Actels A1280A hit the market in 1990 and was one of highest density FPGA's available then, thus it actually only 4 (not 7) years of SX100 from final prototype to final product.

Old WDS board. Single FPGA could not replace whole PCB, densities and I/O pins of FPGA's in early 90'es was so limited that actually more than one FPGA's were needed to do something like that. These FPGA's probably allowed to evade the need for (additional) piggy-back card, something which is seen on other older VME boards:

Note that it is picture only of half of old WDS board. Please note the stickers with FPGA gateware at v1.01 dating to 12th January 1995, while board was produced at 1998. Does it means that they managed to write proper Gateware and required only a single fix half year after launch, and needed no more fixes after? - that indeed is impressive.

Anyway, the detailed analysis of electronics evolution reveals very interesting healthy development environment in Cameca. De Chambost clearly oversimplified the historical description (introduced some mental-shortcuts) introducing some confusion - the most important aspect of his message is actully not introduction of SX100, but that Cameca was early adopters of FPGA technology and they mastered usage of FPGA. I personally think Cameca was closely tracking the FPGA improvements and adopting the relevant advantages in the design. Thus because they started with simple FPGA from 1987, the R&D of Cameca could easily keep up and adapt the advantages of changing FPGA landscape for own advantage (getting in nowadays FPGA's is extremely steep learning-curve, but tracking FPGA evolution from 80's on company level would give a much more shallow learning curve to master FPGA usage). So currently large parts of most complicated logic on latest SXFive(FE) is indeed Gateware*, and if Cameca would decide to get back to production of non-shielded EPMA, they could pull that very easily, despite changing landscape of availability of electronic components used in current generation of boards. I guess they apply experience with FPGA to different instrumentation (SIMS, LEAP) where tight timing and integration is even more important than on EPMA. Probably Cameca could start moving to Gateware on different FPGA models on some of prototype iterations which we had never seen. I find it mind-blowing that Cameca had the mentioned Acquisition-Scanning-Visualization board ready only a single year from Altera Cyclon (I) being released to the market! Adopting to FPGA is extremely competitive advantage, hopefully Cameca will not waste this potential.

P.S. actually mind-blowing is only the 3 months for stage board FPGA adaptation, which they got the same year as Altera Cyclon FPGA got released. So Cameca had indeed achieved mastering in FPGA and I think they could one day surprise us with a new EPMA.

P.S.S. but even bigger mind-blowing is that the new type WDS board was developed before Altera Cyclone officially hit the market, which means it had to be started developed earlier and thus very likely Cameca was not just using mature FPGA available on shelf, they were clearly actively probing different pre-market source for these FPGA - now that is absolutely different level of engineering (in absolutely positive way).

*Gateware. We know more less what is hardware and software. There is also some word as "firmware" which partially could be used instead of gateware. But firmware is more the software which runs on the hardware, while gateware can return just intermediate products (bits) of processing and could be not exposed to any software ready I/O interfaces, but to other intermediate hardware. One is clear - gateware as software can be coded and digitally analysed and simulated before instantiated as combination of gate connections inside FPGA. Other important aspect is that it can be modified and FPGA can be reflashed with newer version. The FPGA can be switched to different model of different vendor and if FPGA has enough of capability the manifestation of gate connection from gateware code can be achieved on this other FPGA with very little of modifications.

[Probeman]

Ed Vicenzi calls this the "unearthed image the government doesn't want you to see":



Because he has such a beautiful baby face from 1993 in front of his PGT UNIX system...

[qEd]

That lab did have some paranormal activity, mainly confined to one spectrometer.

[Probeman]

That lab did have some paranormal activity, mainly confined to one spectrometer.

You mean the "Ed" spectrometer?   

[John Donovan]

As many of you know, we at Probe Software have released many updates to Probe for EPMA over the years, the current version being 14.0.2.

In fact version 1.0 (originally called Probe for Windows) was released in March 1996. This was when we went from the DOS version, then called Probe (which was written in FORTRAN!), to Windows (written in Visual Basic). But let's talk about backwards compatibility for a moment, because I think people don't talk about the importance of backwards compatibility enough.

In science we'd like to be able to access our old data and re-process it again if necessary. Ideally without the bother of keeping an ancient computer around with an ancient application, running on an ancient operating system . There are three main aspects to backwards compatibility:

1. The data file.

Our raw data files (for all fields in science) should be able to be opened by every subsequent version of the applications which created them.  This is a key aspect of data compatibility going forward. I personally can't speak about other commercial software applications, but below we will look at the data file backwards compatibility in Probe for EPMA, which is going back for almost 30 years!

2. The operating system.

The application should run on all current (and future) operating systems. Fortunately Microsoft has done an excellent job maintaining the Win32 API and allowing 32 applications that stay within the Win32 "sandbox" to keep running on all OS updates.

3. The API (application programming interface).

In addition to keeping operating system calls backward compatible, it is important to maintain backwards compatibility with application API extensions. For example the Thermo, Bruker, JEOL, Cameca instrument and software APIs. Unfortunately the various vendors have not always maintained backwards compatibility with new API releases.

One key to this is having a "version number" function call within the API (and data files!). This call would be made initially to determine what older functions may no longer be supported and also what new functions may be available.  Unfortunately this is rarely (if ever) done.

In fact because Thermo kept adding so many new functions to their API, we had to keep a NSS/PathFinder version number keyword in our Probewin.ini file!

Anyway, here's the first few updates from the version.txt file from when Probe (for Windows) was created:

PROBE for Windows Version Changes
                            Last Updated 3/2000


3/2/96          Initial beta version
v. 1.0

3/10/96        Add sample setup feature to allow user to save and load
v. 1.01        analytical sample setups to their database. See new
                "Load Sample Setup" buttons in FormNEW, FormGETELM and
                "Sample Setups" button in FormDIGITIZE. New code module
                SETUPSAM.BAS. Setup number in FormDIGITIZE will be used
                to automatically load sample setups during automated
                sample acquisition. Modify FormDIGITIZE and FormAUTOMATE
                to display position sample setup number.

                Remove beep from MiscDelay routine and add beep to Real-
                Time GetProbeStatus routine if motor position is out of
                bounds and different from previous position.

3/14/96        Add Published values to Analyze grid. Add Set PHA button
                to FormPHA (Startwin). Disable FormNEW options if sample
                setup from another source is loaded.


3/16/96        Add option buttons for selecting automation default for
v. 1.02        starting new samples in FormAUTOMATE. Add check box in
                FormPLOT to select analyzed or analyzed and specified
                element list loading. Fix spectrometer peak center bug
                when backlash is used. Improve automation loop performance
                in AcquireDoAutomateNext. Add warning if user selects peak
                center pre-scan and runs automation. Add option to append
                or overwrite existing save log to disk file. Add function
                return help context ID for future context sensitive help.

And here, I found a v. 2.1.1 Probe (for Windows) MDB file (created in October, 1996), and was able to open it with version 13.9.8 of Probe (for EPMA) running in Windows 11, and was able to view the raw data and even analyzed a sample:



That's almost 30 years ago my friends!  Pretty cool for a 29 year old relational database of EPMA intensities! I will have to give credit to Microsoft for maintaining the Win32 (and Access MDB file format) backwards compatibility in every new version of the Windows operating system since then... in fact I think we started with Windows NT.  Remember that OS?

[JonF]

In science we'd like to be able to access our old data and re-process it again if necessary. Ideally without the bother of keeping an ancient computer around with an ancient application, running on an ancient operating system . There are three main aspects to backwards compatibility:

1. The data file.

Our raw data files (for all fields in science) should be able to be opened by every subsequent version of the applications which created them.  This is a key aspect of data compatibility going forward. I personally can't speak about other commercial software applications, but below we will look at the data file backwards compatibility in Probe for EPMA, which is going back for almost 30 years!

I've wondered why Probe for EPMA was still using .MDB files, but agree the backwards compatibility makes sense.

It does create a slight headache for programming in the newer .NET platform as Microsoft doesn't seem to have included JET compatibility, meaning we're either limited to using either .NET Framework 4.8 or a third party plugin* for .NET if we want to access the PfE MDB databases via code.

*See EntityFrameworkCore.JET Github or NuGet

[John Donovan]

In science we'd like to be able to access our old data and re-process it again if necessary. Ideally without the bother of keeping an ancient computer around with an ancient application, running on an ancient operating system . There are three main aspects to backwards compatibility:

1. The data file.

Our raw data files (for all fields in science) should be able to be opened by every subsequent version of the applications which created them.  This is a key aspect of data compatibility going forward. I personally can't speak about other commercial software applications, but below we will look at the data file backwards compatibility in Probe for EPMA, which is going back for almost 30 years!

I've wondered why Probe for EPMA was still using .MDB files, but agree the backwards compatibility makes sense.

It does create a slight headache for programming in the newer .NET platform as Microsoft doesn't seem to have included JET compatibility, meaning we're either limited to using either .NET Framework 4.8 or a third party plugin* for .NET if we want to access the PfE MDB databases via code.

*See EntityFrameworkCore.JET Github or NuGet

Yes, backwards compatibility does have a cost, but most of our users aren't writing software to access their MDB files, so being able to read ones 30 year old databases with the current software is probably the best thing for most people.

I had not known of the EntityFrameworkCore.JET package previously.  Have you tried using it yourself?

I do know that some people have used Microsoft Access to view/edit their MDB files (always make a backup copy of your MDB files before editing them in Access as it's easy to break things!), though not sure how long Microsoft will support this in the latest versions of Access.

And of course one can always install the Visual Basic 6.0 development environment as it is distributed for free now.  Then one will have the JET database API.

[JonF]

I had not known of the EntityFrameworkCore.JET package previously.  Have you tried using it yourself?

No, not yet - whenever I'm writing something that will interact with the MDB file directly, I'll revert back to the last .NET Framework (4.8.1) as its still (as of writing!) supported, and then use System.Data.OleDb namespace to access the MDB using the ACE rather than JET.

We could do with some more acronyms...