Wish list for PI features

[Gareth D Hatton]

Might be a good idea to have a list of wishes for PI as we have for PfE 

I will start:

Could we have in the event log the date as well as the time for acquired images?  It would be useful to know how long it was running, say over a weekend.

[John Donovan]

Might be a good idea to have a list of wishes for PI as we have for PfE 

I will start:

Could we have in the event log the date as well as the time for acquired images?  It would be useful to know how long it was running, say over a weekend.

Hi Gareth,
I think this is an excellent idea.   

You already have access to our Mantis bug reporting site, and as you know, we've been using that for new features, but that site isn't accessible to all, so this will be very helpful I think. In fact, I'll make it sticky.

As for your specific request, just FYI, this before and after date-time information is already stored in the ProbeImage .PrbImg files, but it makes sense to me to have it in the Conditions tab as you suggest, maybe along with a total acquisition time field for the "subtraction".

Here is the date-time info in one PrbImg file (along with the before and after beam current):

[Measured/BeamCurrent]
Start=9.995e-009
End=9.999e-009
[Measured/Time]
Start=2013-12-03T14:53:10
End=2013-12-03T15:02:13

[Philipp Poeml]

I would like to have PI doing a stage backlash when it is going to a new map position, just like PfE also does.

[John Donovan]

I would like to have PI doing a stage backlash when it is going to a new map position, just like PfE also does.

We could do that.  Or you could get your stage properly repaired as we've been telling you for over a year now...

Please stop blaming the software for your stage problems.  I know we are a very responsive company, but we sell software, not hardware!

Please note that there are zero errors in the PI log file you sent us.   You do know that once we start a scan on the instrument, we no longer control the instrument, we just store the data returned?  That is all we can do; that or halt the scan. 

If the instrument firmware macro stops moving the stage or the beam during a scan and doesn't send back any errors, what exactly are we supposed to do?

In the meantime I will add a request for a stage backlash in Probe Image. It's a good idea, though not needed for JEOL instruments that have a firmware backlash and Cameca stages equipped with linear encoders.

[Philipp Poeml]

John, I am not talking about stage problems here and that your software does not work, I was just asking for this. The thread is called: "Wish list for PI features". So, I just put a line in, a simple wish.

[John Donovan]

John, I am not talking about stage problems here and that your software does not work, I was just asking for this. The thread is called: "Wish list for PI features". So, I just put a line in, a simple wish.

I am pleased to hear that the software is running well.  I am working this weekend on a new feature in PFE that I am calling a "Stage Reproducibility Correction".  It is similar to what Cameca and JEOL do in their "stage drift correction" features, in that in PFE the user will acquire an image, and then digitize points on it using the mouse.  Then during automation, after the software drives to the stage position of the digitized area and just before the "Use Beam Deflection for Acquisition" begins, the software takes another image using the same scan parameters as previously, compares that to the original image used for digitizing the points, and calculates the amount the stage is off by, and adjusts the column image shift to compensate.

I added your stage backlash wish to the PI request list.

Just for my own curiosity, if one does not perform a stage backlash correction on your SX100R stage (which is apparently very heavy and does not have linear encoders), roughly how much is the stage off from the intended stage position?  On average?

[Dan R]

I'd like to see an easier way/interface to import a 2nd or 3rd set of elements for a 6+ element map. There does not appear to be an easy way to set this up currently. Using PFE to move to a new element peak position in the MOVE window results in default peak settings, NOT the peaked element position. Is there an easier way than typing in the peak and pha settings for a second set OR creating a whole new unknown setup in PFE?
-Dan

[Probeman]

I'd like to see an easier way/interface to import a 2nd or 3rd set of elements for a 6+ element map. There does not appear to be an easy way to set this up currently. Using PFE to move to a new element peak position in the MOVE window results in default peak settings, NOT the peaked element position. Is there an easier way than typing in the peak and pha settings for a second set OR creating a whole new unknown setup in PFE?
-Dan

Hi Dan,
Not a problem.  See this post from Karsten Goemann (about halfway down):

http://probesoftware.com/smf/index.php?topic=141.msg570#msg570

In PFE, create a new unknown sample and load the Sample Setup for the second five elements. Again go to Acquire! | Peaking Options and click "Move To On Peak (start analysis) Positions". Wait until the move is completed then click "Read ELM" again for the WDS channels in Probe Image

The above method works for the first element on each spectrometer.  For subsequent order elements, use the same dialog (from the Probe for EPMA Acquire! Peaking Options button), and follow the steps shown below to select the spectrometer order or simply <ctrl> click the elements for custom selections and then click the Move Selected Elements To On-Peak Positions button

[Anette von der Handt]

I would like to be able to ONLY acquire off peak maps.

I usually run MAPS with MAN anyway (before you ask) but I had now a situation where making the maps was an afterthought and then for the necessary interference corrections to be applied I realized I also needed background maps. So for future moments of poorly thought out workflow, being able to add off peak maps to the mix after the peak maps have been already acquired would be great.

Thanks!

[Probeman]

I would like to be able to ONLY acquire off peak maps.

I usually run MAPS with MAN anyway (before you ask) but I had now a situation where making the maps was an afterthought and then for the necessary interference corrections to be applied I realized I also needed background maps. So for future moments of poorly thought out workflow, being able to add off peak maps to the mix after the peak maps have been already acquired would be great.

Hey, we can deal with who-man error!   

I would just set the on-peak acquisition time for a minimum dwell time per pixel and acquire the off-peak maps for the desired off-peak dwell time.  Note that you will need to delete the new (low precision) on-peak maps and rename the off-peak maps to match the acquisition numbers of your original on-peak maps before loading them into CalcImage for quant.

[Anette von der Handt]

Hi,

would it be possible to add a feature to PictureSnap to define and evaluate map dimensions in ProbeImage? For large maps, it can be a little bit trial and error when figuring out the absolute positions, dimensions and dwell times for a map and their costs/benefit.

I understand that there is already the two point set-up option in ProbeImage and so it is not really a pressing need. However I could see it being a very nice visual feature in aiding setting up X-ray maps (and I think the other programs don't offer a comparable feature but I may be wrong here).

What I envision is a dialog very similar to the "calibrate image" dialog in picture snap that can be launched out of ProbeImage. We can load in a calibrated SE/BSE image of the to-be-mapped region and either

(1) draw an area (square/rectangle) on the image by hand. The dialog would then give the center point of this area plus either the #pixels or pixel sizes (comparable to the traverse options dialog). Maybe also the calculated acquisition times if a dwell time is defined

and/or

2) I define a center point for my map. Depending on the entered pixels and pixel sizes, the mapped area will be shown on the image. Again bonus points if the total time for map acquisitions is shown.

A feature like this would have the added benefit that it make offline strategic planning of overnight maps easier (when I already have calibrated images from a previous PFE run and just want to see how long maps would run me).

Thanks for listening

Anette

[John Donovan]

would it be possible to add a feature to PictureSnap to define and evaluate map dimensions in ProbeImage? For large maps, it can be a little bit trial and error when figuring out the absolute positions, dimensions and dwell times for a map and their costs/benefit.

Hi Anette,
I think this is a great idea and I think I can do this by adding a dialog in PictureSnap that loops on a read of the current acquisition setup in Probe Image.  I'll have to have Brian add a timer event that triggers a save of the current acquisition setup to a static name such as ProbeImage.acq or something, and then this new "Mapping Assistant" (or whatever we call it) in PictureSnap, reads that file and displays the current mapping setups currently loaded in Probe Image.

It's a bit of work, so let me think about it a little more, but I think it's entirely doable (and a great idea!).
john

[Ben Buse]

Hi John,

I have a suggestion - when you click ok on the message that says the maps are complete -

at present it drives to the map (presumably the center)

In my experience of using it - I would would prefer it not to drive anywhere. For often I don't click ok until I'm half way through a different job in PFE and it catches me out by moving the stage

Thanks

Ben

ps I'm really liking probe image now - last week i was setting up batches of 9 maps and the Read XYZ and read z for each of the corners is very easy to use.

One thing I did wonder - but this would be complex and for the future. Sometimes when putting in the coordinates for a map and running the map 20 hours later - i.e. for the 9th map the z has gone slightly out of focus presumably as the vacuum has improved. I wondered if we could do something clever with the autofocus. So when it drives to a sample - there is a position which it autofocuses on and corrects all the corners by the same amount. The complexity is this would not be the center - as when the corners are set the center is not always in sharp focus. Nor would it always be the same corner - for if you have a step from the sample onto expoxy - and you have set the focus for the sample height - when it drove to the corner it would autofocus on the expoxy. I'm not sure it's worth doing - it would only be worth doing for quant mapping and I have not checked the effect on totals - is it significant - I guess that's the thing to check - how much it has to be out of focus to be a problem.

[John Donovan]

I have a suggestion - when you click ok on the message that says the maps are complete -  at present it drives to the map (presumably the center)

In my experience of using it - I would would prefer it not to drive anywhere. For often I don't click ok until I'm half way through a different job in PFE and it catches me out by moving the stage

Hi Ben,
Note that the position PI drives to after mapping is complete, is wherever the stage was when you started the automated map acquisitions.  So one solution would be to put up the modal dialog (that the maps are complete), *after* it moves the stage back to this start position? 

ps I'm really liking probe image now - last week i was setting up batches of 9 maps and the Read XYZ and read z for each of the corners is very easy to use.

One thing I did wonder - but this would be complex and for the future. Sometimes when putting in the coordinates for a map and running the map 20 hours later - i.e. for the 9th map the z has gone slightly out of focus presumably as the vacuum has improved. I wondered if we could do something clever with the autofocus. So when it drives to a sample - there is a position which it autofocuses on and corrects all the corners by the same amount. The complexity is this would not be the center - as when the corners are set the center is not always in sharp focus. Nor would it always be the same corner - for if you have a step from the sample onto expoxy - and you have set the focus for the sample height - when it drove to the corner it would autofocus on the expoxy. I'm not sure it's worth doing - it would only be worth doing for quant mapping and I have not checked the effect on totals - is it significant - I guess that's the thing to check - how much it has to be out of focus to be a problem.

Would it be ok, to have an option for PI to perform an autofocus on each map, just before it starts the map acquisition?  Perhaps it should just utilize the center of the map for this optional auto-focus? In other words, (if an auto-focus option is specified), drive to the center of the current automated map, based on a fit to the corner Z positions, perform the auto-focus, then adjust the corner Z positions based on the auto-focus offset, then start the map acquisition using the newly adjusted corner positions.  How does that sound?
john

[Ben Buse]

Hi John,

Note that the position PI drives to after mapping is complete, is wherever the stage was when you started the automated map acquisitions.  So one solution would be to put up the modal dialog (that the maps are complete), *after* it moves the stage back to this start position? 

Yes that would work well.

Would it be ok, to have an option for PI to perform an autofocus on each map, just before it starts the map acquisition?  Perhaps it should just utilize the center of the map for this optional auto-focus? In other words, (if an auto-focus option is specified), drive to the center of the current automated map, based on a fit to the corner Z positions, perform the auto-focus, then adjust the corner Z positions based on the auto-focus offset, then start the map acquisition using the newly adjusted corner positions.  How does that sound?
john

I don't think this would work - because sometimes when the corners are in focus - the center is not in focus - it could be on a spot of epoxy. I'm not sure how important this is - I need to check on acquired data to see the effect on intensity of it being slightly out of focus

Thanks

Ben