News:

:) We depend on your feedback and ideas!

Main Menu

Faraday utility

Started by John Donovan, November 21, 2024, 11:24:07 AM

Previous topic - Next topic

John Donovan

I recently posted about the need to adjust the Faraday wait in and wait out times for JEOL instruments here:

https://smf.probesoftware.com/index.php?topic=1260.msg12974#msg12974

Especially for newer JEOL (8230/8530/iSP100/iHP200F) instruments which seem to require up to 2.5 to 3 seconds wait times for the picoammeter for reproducible accuracy of the beam (and absorbed) currents.

One can edit these values in the Probewin.ini file:

[faraday]
FaradayWaitInTime=2.4        ; delay after insertion
FaradayWaitOutTime=2.2        ; delay after removal

and re-start Probe for EPMA to check the accuracy of the beam current measurements, but there exists a small utility called Faraday which comes with PFE and is much quicker to test with.



To test the beam current measurement, select the Faraday option, then click the Remove Faraday button, then click Measure and the app will insert the Faraday cup, wait for the specified time and print out the measured beam current.

To test the absorbed beam current, select the Absorbed option, then click the Insert Faraday button and again click the Measure button. The app will remove the Faraday cup, wait the specified time and measure the absorbed current.

One can decrease these wait in and wait out times by editing these entries in the Probewin.ini file, saving it, then re-starting the Faraday application. Repeat as desired to see the minimum wait times that are required to obtain an accurate reading.
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

John Donovan

I want to emphasize how important it is to have a sufficient delay after inserting the Faraday cup to get an accurate beam current reading on the newer JEOL EPMA instruments (8230, 8530, iSP100, iHP200F).

This is because Probe for EPMA measures the beam current both at the beginning of the analysis and also at the end of the analysis.  The reason for this is to check for beam stability over the course of the x-ray measurement.  This may not matter for analyses only lasting a few minutes, but it could be important for analyses that take longer. By averaging the two beam current measurements, PFE can "correct" for any beam current drift during the measurement (assuming the drift is linear).

This has always worked well on Cameca EPMA and older JEOL 8900, 8200 and 8500 instruments.  But starting with the 8230/8530 instruments, the JEOL picoammeter is gotten much slower, requiring longer settling times. This may sometimes be caused by a "sticky" Faraday cup, but we have found that even a normally operating Faraday cup on a newer JEOL EPMA requires 2.5 to 3 seconds of delay after the cup is inserted to get an accurate reading.

Note that the first beam current reading performed by Probe for EPMA is always fine, because the cup is already inserted and therefore the beam current has already stabilized, but the 2nd Faraday cup measurement requires that the cup be inserted after the x-ray measurements have finished, and that is where the FaradayWaitInTime delay value in the Probewin.ini file becomes critical.  You can see what the values are for these for your instrument in the Count Times dialog:

https://smf.probesoftware.com/index.php?topic=1260.msg12974#msg12974

Recently I noticed a user had these results for their beam current readings:

Off-Peak Corrected or MAN On-Peak X-ray Counts (cps/1nA) (and Faraday/Absorbed Currents):
ELEM:    BEAM1   BEAM2
    2G  19.986  18.323

AVER:   19.986  18.323
SDEV:     .000    .000

This shows an ~8% variance between the two beam current measurements. Again, the first beam current reading is fine, but the second one requires a longer FaradayWaitInTime delay. Anette von der Handt sent me a plot of her JEOL iHP200F instrument and this shows how reproducible her beam currents are when this value is properly set:



Here are the ProbeWin.ini values for these keywords on her instrument:

FaradayWaitInTime=3.0             
FaradayWaitOutTime=1.0

Note that for absorbed current measurements it is the FaradayWaitOutTime that may need to be adjusted.
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

sem-geologist

As hardware-aware person I just wonder why it is like that (technical reason). Maybe to large capacitance in the measurement line? Poor outdated PCB design emitting enormous amounts of EM noise, and thus added capacitors to filter out the noise of tiny current measurement?

coredump

Are those wait time values in second? If so, they are approx. twice as high as 733 - 8800/8900 gen.
As far as I remember, P/N of the beam shutter for 8530 is the same as that of 733 - 8800/8900.
Design change in the solenoid (that is, mechanical change) or electrical circuit?

John Donovan

#4
Quote from: coredump on December 21, 2024, 07:53:48 PMAre those wait time values in second? If so, they are approx. twice as high as 733 - 8800/8900 gen.
As far as I remember, P/N of the beam shutter for 8530 is the same as that of 733 - 8800/8900.
Design change in the solenoid (that is, mechanical change) or electrical circuit?

Yes, in seconds. And yes, the required "settling" time for the 8900 was around 1 second, for the 8200/8500 around 1.5 second, for the 8230/8530 around 2 seconds and for the iSP100/iHP200F around 3 seconds.

As to why, that is what SEM Geologist asks above. I can only imagine that JEOL is trying to improve the accuracy of the picoammeter and therefore using an electronic circuit that requires a longer integration time (higher value capacitors).
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

John Donovan

#5
I should add that this is not a problem for the JEOL software as it only measures the Faraday cup once at the beginning of an analysis when the cup is already inserted and therefore stabilized.  But because Probe for EPMA measures the beam current both at the beginning and the end of the acquisition, the Faraday cup needs to be inserted before the 2nd beam current measurement. Therefore the Faraday cup insertion requires whatever settling time is necessary for a stable beam current measurement.

A similar consideration applies to the absorbed current measurement, because, again, Probe for EPMA measures the absorbed current (if specified) at both the beginning and the end of the acquisition. So because the absorbed current must be measured after the Faraday cup is removed, a similar settling time is required for a stable 1st absorbed current measurement.

Therefore if your Faraday cup requires a full 3 seconds to stabilize, your Faraday wait times might look like this:

[faraday]
FaradayCupPresent=1        ; non-zero = faraday cup interface present
FaradayCountTime=1.0        ; number of faraday integrations for Cameca and JEOL
FaradayCupType=0        ; 0 = automated, 1 = manual
FaradayWaitInTime=3.0        ; delay after insertion (important for accurate 2nd beam current readings)
FaradayWaitOutTime=3.0        ; delay after removal (important for accurate 1st absorbed current readings)
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

coredump

I suspect there are other factors, such as the reading algorithm in JEOL firmware or main software.

Delay caused by capacitor is difficult to imagine. It requires extremely large capacitor must be installed in the signal line to produce 2 - 3 sec delay. But I cannot imagine any reason to do so.

Long time constant also makes spectrometer adjustment very difficult. Furthermore, long time constant may hide certain troubles that occur in short period, such as sparks.

Mechanical delay of 733 is less than 500ms. So, I think the firmware contains an unwanted bug.


sem-geologist

#7
Quote from: coredump on February 25, 2025, 12:56:42 AMI suspect there are other factors, such as the reading algorithm in JEOL firmware or main software.

Delay caused by capacitor is difficult to imagine. It requires extremely large capacitor must be installed in the signal line to produce 2 - 3 sec delay. But I cannot imagine any reason to do so.

Long time constant also makes spectrometer adjustment very difficult. Furthermore, long time constant may hide certain troubles that occur in short period, such as sparks.

Mechanical delay of 733 is less than 500ms. So, I think the firmware contains an unwanted bug.



Sorry, but your presented circuit simulation to this situation is inadequate: First of all, replace voltage source with current source (that what the Faraday cup is) and I would also eperiment with different resistor values (100k, 1M, 10M...) (i.e. on SX100 there are 5 different feedback loops for different current ranges; I guess as Jeol is more a budget probe it would have single or just a few). Anyway, even leaving the resistor values of 1k and 100k (which is a bit a questionable chose IMHO) and replacing voltage source with current source, lets say 10nA, the stabilization of voltage at capacitor gets in about 2 seconds with 100 times smaller capacitor of 4.7µF than in your simulation - that is not huge capacitance as for sensitive line RC filter. (huge would be 10000µF; I seen 47uF and 4.7uF caps used all over where RC filters are used to filter sensitive signals, and in some case 470µF would also make sense. Not that Cameca probes would be equipped with any capacitors at all at this particular circuit.) The drain resistor could be 1M, or 10M (typical input-GND resistance for some of precission OPAMPS is even larger, more like 10Tohm) and then capacitor value to fit into 2 sec of full load can drop to 470nF or even 47nF... or even in picofarad range, where longer coaxial cable would start showing effect of its capacitance.

sem-geologist

#8
While looking to your 2nd graph, I got quite confused. Is that some real measurements? Are the time units correct (maybe should be ns (nano), not ms (milli)?; 15ms ringing period suggest the 50ohm coaxial cable from faraday cup to run for about thousand of km. Even with correct units of ns, that still looks wrong. Maybe there is too long cable which is tied into few rounds making kind of inductor. I guess picoamperometer is situated unnecessarily far from faraday cup. As for contrast, on properly designed Cameca SX probes, faraday cup is connected with very short cable to picoamperometer, where picoamperometer is situated just below the chamber. with only 1m of coaxial cable beam current change at FC would produced ringing with unterminated coaxial, but would be dampened down within 1ms. Another thing is that terribly huge noise. That is not a surprise whole 3 seconds are needed to average out the noise. Again, placing picoamperometer far away from digital noise as close as possible to the faraday cup will have less noise introduced, thus can be measured much faster.

sem-geologist

#9
and here my simulation (interactive):
the simulation in circuitjs

It is simplified essence of circuit used on SX, with addition of noise (slidebar from 1mV to 50mV injected into signal through resistor of 100k - kinda simplified simulation of noise introduction by nearby noisy electronics) and additional optional capacitor ,which demonstrates the very easy way to minimize such noise (the most lazy way, answering "why anyone would add a cap there"). SX instruments has no such cap as it is not needed (noise is not introduced, as system of FC-transmision line-picoamperometer are held within clean analog domain with no digital signals anywhere nearby or crossing its path. A cap is a physical way to filter out the signal from noise. The multi measurement and getting median is another way - without a cap. In any case, presented 2nd graph clearly demonstrates p-to-p noise in some cases reaching 50% of the median value. 3 seconds of integration of multi measurements even without cap is absolutely necessary.

Probeman

#10
Quote from: coredump on February 25, 2025, 12:56:42 AMI suspect there are other factors, such as the reading algorithm in JEOL firmware or main software.

Delay caused by capacitor is difficult to imagine. It requires extremely large capacitor must be installed in the signal line to produce 2 - 3 sec delay. But I cannot imagine any reason to do so.

Long time constant also makes spectrometer adjustment very difficult. Furthermore, long time constant may hide certain troubles that occur in short period, such as sparks.

Mechanical delay of 733 is less than 500ms. So, I think the firmware contains an unwanted bug.

I agree that something isn't right.

And yes, the early JEOL instruments required a much shorter delay. Less than a second as you say.

But each newer JEOL instrument model seemed to require a somewhat longer delay to obtain a stable beam current reading.

I would be interested obtaining a packet capture of the command used to read the instrument beam/sample current on a modern (8x30 or later) JEOL instrument, as the EIKS command may be part of the problem...
The only stupid question is the one not asked!

coredump

Quote from: sem-geologist on February 25, 2025, 02:03:15 AMSorry, but your presented circuit simulation to this situation is inadequate: First of all, replace voltage source with current source (that what the Faraday cup is) and I would also eperiment with different resistor values (100k, 1M, 10M...) (i.e. on SX100 there are 5 different feedback loops for different current ranges; I guess as Jeol is more a budget probe it would have single or just a few). Anyway, even leaving the resistor values of 1k and 100k (which is a bit a questionable chose IMHO) and replacing voltage source with current source, lets say 10nA, the stabilization of voltage at capacitor gets in about 2 seconds with 100 times smaller capacitor of 4.7µF than in your simulation - that is not huge capacitance as for sensitive line RC filter. (huge would be 10000µF; I seen 47uF and 4.7uF caps used all over where RC filters are used to filter sensitive signals, and in some case 470µF would also make sense. Not that Cameca probes would be equipped with any capacitors at all at this particular circuit.) The drain resistor could be 1M, or 10M (typical input-GND resistance for some of precission OPAMPS is even larger, more like 10Tohm) and then capacitor value to fit into 2 sec of full load can drop to 470nF or even 47nF... or even in picofarad range, where longer coaxial cable would start showing effect of its capacitance.
I simulated I-V circuite. I added 1k reg because Opamps generally cause problems with capacitive load. It still requires large capacitors to produce 2s delay. The diagram shows the output pin of OP77.

coredump

Quote from: sem-geologist on February 25, 2025, 05:25:40 AMWhile looking to your 2nd graph, I got quite confused. Is that some real measurements? Are the time units correct (maybe should be ns (nano), not ms (milli)?; 15ms ringing period suggest the 50ohm coaxial cable from faraday cup to run for about thousand of km. Even with correct units of ns, that still looks wrong. Maybe there is too long cable which is tied into few rounds making kind of inductor. I guess picoamperometer is situated unnecessarily far from faraday cup. As for contrast, on properly designed Cameca SX probes, faraday cup is connected with very short cable to picoamperometer, where picoamperometer is situated just below the chamber. with only 1m of coaxial cable beam current change at FC would produced ringing with unterminated coaxial, but would be dampened down within 1ms. Another thing is that terribly huge noise. That is not a surprise whole 3 seconds are needed to average out the noise. Again, placing picoamperometer far away from digital noise as close as possible to the faraday cup will have less noise introduced, thus can be measured much faster.
Yes, it is the real measurement. The unit of the horizontal axis is milliseconds. I guess the rising time of opamp used in 733-AEM is very slow. My probing is really bad. I used low-quality cable, not coaxial cable, to obtain output signal of I-V converter. So, the result has large noise.

Theoretically 733/8600 gens should have larger noise than later models. Those models use long coaxial cables to I-V converter. Then, the output of the I-V converter is connected to ADC via coaxial cable. However, the acquistion time of ADC is 30ms, so 3-digits reading value looks stable.

The ADC of 8800 is driven by 250kHz clock, so it can be sensitive to noise. I guess later models also use similar or faster ADC.

sem-geologist

Quote from: coredump on February 25, 2025, 08:35:55 PM
Quote from: sem-geologist on February 25, 2025, 05:25:40 AMWhile looking to your 2nd graph...
Yes, it is the real measurement. The unit of the horizontal axis is milliseconds. I guess the rising time of opamp used in 733-AEM is very slow. My probing is really bad. I used low-quality cable, not coaxial cable, to obtain output signal of I-V converter. So, the result has large noise.

Theoretically 733/8600 gens should have larger noise than later models. Those models use long coaxial cables to I-V converter. Then, the output of the I-V converter is connected to ADC via coaxial cable. However, the acquistion time of ADC is 30ms, so 3-digits reading value looks stable.

The ADC of 8800 is driven by 250kHz clock, so it can be sensitive to noise. I guess later models also use similar or faster ADC.

Ahh.. so this oscilloscope measurement is done after I-V conversion with some OPAMP, plus not perfect measurement setup. That explains the observed ringing which most likely then is just a oscilloscope measurement setup artifact, and thus also the observed noise could be introduced by oscilloscope measurement. Any ADC is driven with clocks and if PCB is designed correctly (no obtrusion of return currents) it should not cause any problems. I would not think that problem of ringing is in slowness of OPAMP - slower slew rate normally means less ringing and less overshot when capacitive load (i.e. probe cables for oscilloscope) is added. It is rather that precision OPAMP (which coincidentally normally have slow slew rate) has low capacitive load capability, and that cause ringing when oscilloscope probe is added to the circuit. Normally if signal after amplification needs to be transmitted to other unit (thus by cable) or exposed parallel to some external device (i.e. external oscilloscope), the output from precission OPAMP should be buffered with driver OPAMP with high capacitive load driving capability (Which precision OPAMPs has not).

To clarify, long coaxial cable (up to few meters) won't cause trouble if it is properly 360 degree grounded at both ends (to same earth), not through funky decoupling of capacitors, resistors, inductors - just plainly to the metal casing. Normally also coaxial cables with AC signals are terminated at the receivers end with resistor matching the cable impedance and matching resistor in series at transmitters end. The drawback of such termination is introduction of voltage divide (thus twice lower p-b ratio) or attenuation of current (in our case). And thus considering cable length of only up to few meters and that we measure basically slow DC signals, and that FC insertion and retraction rather won't create very steep nano seconds like signal edges - that means coaxial cable in FC to I-V OPAMP connection can work without any termination absolutely fine. As it got clarified the observed ringing is caused by oscilloscope probing setup, so my raised concern about the length of cable can be discarded here.

250kHz clock maters not and it is quite slow as for ADC. What matters is the rising edge of clock and PCB layout matching impedance for digital fast changing (where state flip happens in few ns) signals. There is very cheap way to check it out with any budget oscilloscope. connecting ground clip to probe of oscilloscope cable some about 5cm loop can be made. The loop can be used to troubleshoot for electromagnetic interference (EMI) problems or reveal potential problems. It works by bringing the loop near to PCB to suspect-able parts. Sometimes EMI is directional (i.e. can be seen in X-Y, but wont be seen in Y-Z, or X-Z direction). If You won't see any fields created around ADC, then there is rather no problem there.

All this brings me to believe that your blame on software is rather the right shot. Discarding all those oscilloscope measurement artifacts it is clear that measurement should be possible within 1s or even much less. As for SX case it is a bit different, as it use 5 precision OPAMP feed back loops, and needs time to switch to the right one. Also on these SX instruments... the same ADC (same single chip) is used to measure the FC and also is used to measure about 20 other slow signals from different parts of the instrument (kinda of unnecessary centralization) so probably FC measurement needs to wait in queue for its turn. Now this is kind a "...but Why?" moment.

John Donovan

I am not sure what exactly is going on with the newer JEOL instruments but as mentioned previously, on the older 8900/8200/8500 JEOL instruments, we read the probe current directly from the instrument itself.

While on the newer (8230/8530/iSP100/iHP200F) instruments, we read the beam current from the JEOL EIKS interface, which means talking to the JEOL software on the JEOL computer.  Why the "settling time" for newer JEOL instrument is longer than for the older instruments, is a mystery to us.

On the other hand, for the Cameca SX100/SXFive instruments we read directly from the instrument through the MachLib interface, and only require a 200 millisec delay after insertion before reading a stable beam current.

Another note, we looked at the code to read the beam current and found that we utilize a loop to wait for two stable beam current readings in a row before accepting the value:

' Check for valid handle
If Jeolhandle& = 0 Then GoTo JeolGetFaraday2NoHandle
beamcurrent! = MAXMINIMUM!     ' force loop entry

' Avoid JEOL garbage number (positive and negative) that JEOL 8200 sometimes returns
numtries% = 0
Do Until beamcurrent! > 0# And beamcurrent! < 16383# And beamcurrent! <> 1638.3 And beamcurrent! <> 163.83 And beamcurrent! <> 16.383 And beamcurrent! <> 1.6383

itest& = J8K_ReadCurrent(Jeolhandle&, tbeamcurrent!)
Call JeolGetError(itest&, "JeolGetFaraday2")
If ierror Then Exit Function

beamcurrent! = tbeamcurrent! * NAPA#   ' convert from amps to nA
numtries% = numtries% + 1
If numtries% > MAXTRIES% Then Exit Do     ' give up and return whatever

If numtries% > 1 Then   ' only delay if first time failed
Sleep 10
End If
Loop

JeolGetFaraday2! = beamcurrent!

Apparently we saw problems reading the JEOL beam current back in the day for the 8200 instrument and have utilized this code loop ever since. The symptom was that the JEOL instrument would return a floating point value that had the digits "16383" (with a variable decimal point), until the beam current was stable...

However, this is a separate issue from the FaradayWaitInTime delay required for newer JEOL instruments to obtain a stable beam current reading.
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"