showed his VGs

vgs will be on the web, send to bryan allen

no questions

LEO is in communication speed with the microscope and leading...

shack "idea"

NZ - when thinking about day to day archiving.. have permanent and throw-away data (archival info vs. scratchpad)

EV - when save image.. gets a number tag, etc... on-line for several mo... server changes the owner of file within 10 min (to protect from changes)

NZ - so currently have no scratchpad... once save as... it is saved

JAR - if other people want to use that image.. no info about what it is about... no metadata

but, are people going to use and need to search for images

Ginny - how store from various instruments

EV - a folder exists for each instrument.. 50GB system.. fully backed-up...

Reza - why not make the archive the responsibility of the client side

EV - ensures that everything is secure, etc.

TAN - as user center feel it is their duty to provide this capability

Reza - sounds like a headache

EV - only the saving to CD

MOK - back-ups are on tape.. what he is describing is local to ORNL... are you proposing this for the MMC

EV- not clear if need to have centralized storage across MMC

MOK - perhaps a distributed system

JAR - we need to maybe design a system and agree on it... will need lots of metadata if plan on a centralized system for searching

JHunt - can purchase databases

Hans - archiving is still not a problem... need to have the ability to associate lots of information with an experiment.. there is no problem on the market that can do that... there are also many kinds of data... need to get all this info together and a means to search it.. has this been discussed at all...

JHunt - maybe we can blow $50K as a group to do this... go and buy it.. Documentum (for drug qualification)

Hans - can it be customizable

JHunt - our needs are not unique.. Documentum has a package to handle this.. start at the $100K

Hans- does this allow Java plug-ins to hook into this data

NZ - what about notebooks and Habanero toolset... these are beginning to develop into this manner.. there is a location... it is not working yet

JHunt - Hans and he have different concerns.. providing storage for customers with far less $$ than the collaboratory... direct appln of money may fix it for us

breakdown: enabling functions, collaboration functions, device interaction, persistence

ORB- an applet...

Hans - where would core software sit on the next generation architecture..

DBA - on real-time command and control software level

NZ - needs to be through JAVA.

Hans - this is a very good architeture to design expts

Jhunt - why not use the next generation architecture now?

DBA - have heard primarily about the cruder API architecture since became involved in MMC

NZ - embedded processor does not need to be in the instrument... if asked microscope companies to include an embedded processor... they would not do it

Jhunt - whole purpose of all of this is that implementation is a detail... processor need not be on the microscope

Ray - all can be done on JAVA

How much persistence do we really need? Do we need to be able to re-trace our footsteps? How do we search these entities? what about metadata and/or metadata encapsulation? relational databases help with searching...

Need to integrate the electronic notebooks more...

JAR - there is another box... what about specimens?

Security issues

Entrust - canadian company going public soon; labs use it; use two key-pairs; escrowed key is an advantage with foreign users; under your control, not the governments; can replace the netscape security with the entrust; can use entrust-aware applns

MMC applns would need to keep track of public key

Entrust certificates are expensive - $157 each... but can be re-issued to new users (can revoke first users certificate)... had a deal to buy $50 each up until June, but no applns could use them

within the architecture.. need a call to the security service to allow that call

user only needs to keep track of private key

will use authority certificates being generated by LBNL... this will bind things like training, reservations, etc. - the security engine will check keys as well as the certificate to see what that user has the authority to do

Ray - design the architecture so that security is a plug-in and that as things change can modify readily

NZ - couldn’t use simplify it by using DBA’s model... and check it as come into it... then the APIs don’t need to check

JAR - don’t agree..need to check on every appln

NZ - don’t agree... don’t need so many checks

Ray - need to minimize and/or optimize the number of places that you check security

JAR - set of security functions that are turned on depends on the role of the user

concentrate on the instrument services aspects... think in terms of properties, actions and results

from user point of view... there is a directory of instruments with an associated list of location, description, etc as well as a list of properties (functions) which can be utilized by that instrument

use a set of general commands... that use a shell to be used by a particular instrument

in multiple user environment... need this to be multicast

NZ - a lot of info... need to examine more and decide which functionalities are being used

BP - need to decide what the best strategy is from the user standpoint

NZ - two ways of viewing it... what is everything you can control. vs. what do you actually need

BP- user profile is a different issue... that is, what functions can a user actually access

in the long-term each instrument will have it’s own individual interface

JHunt - the web-based description that BP and he have developed is also useful... need a plan for common control for instruments

EV - Max would like to have the microscope with an outside computer that does outside control, Hitachi does it more directly to microscope itself...

JHunt - need to write a program to access the kind of control that each vendor provides... need a high level control algorithm

JHunt - so encapsulate it so that it makes no difference, need to go to the point where can get commonality... need to think software bus implementation...

BP - object-request broker locates the service that you require.. just tells you if you can do it and then performs it

MCW - need workshop to be about architecture... need to create the APIs... BP has a 3 layer model of property, function and instrument implementation

Hans - this model should include detectors as well

MCW - where does abstraction occur

JHunt - maybe should be a fourth layer... between the function and instrumentation implementation layer... this model does not yet deal with large amounts of data coming from the detector (hidden in this model)

Hans - what we really want to do is do experiments... need to shift to expt-oriented thinking.. expter must implement the expt - must include detectors and imaging as well, does software bus thinking include detectors as well...

BP - info can come from detector, from CCD camera... have two sets of data source - control parameters for dynamic studies and information being generated

JAR - from users point of view... have several computers with various diagnostics in the actual microscope room... but if running remotely only have one screen

NZ - what does the user need in front of him? how many computers

BP - new products... Orbix manager allows you to build diagnostics systems into the ORB... can be presented to the end-user... also Orbix Talk and Orbix Event to handle broadcast... "talk" has reliable multicast and logging information

DBA - what about licenses for the Orblets... the developer’s pay the license fee

JHunt - you don’t pay for the clients... Forte has a variety of solutions as well and their clients are now free as well

NZ - what are the functions that you have -- shift, tilt, mag... what else? Need to be flexible enough to cover all instruments to be used in the collaboratory... e.g.- if know functionality can design the API to do that

JAR - need to design the set of commands for the SHACK

Pass by microscope manufacturer

Instrument Control

Hans de Ruitjer

Detector Systems

want to open Pandora’s box on how implement this... like to see our need to integrate all of this together... should have the same philosophy locally as well... should aim for one local one and one remote one

JAR - do present Pcs have enough computer power to do this?

Hans - for the most part, the answer is yes

More microscopists are thinking of doing expts, not just data... need to combine the information (metadata??)... e.g. - Z Contrast/HRPEELS

Microscope control aspects are much older... microscopes are much more adaptable to exptl modifications... but now we need to include detectors in this scenario

if want to talk to detectors... still need to break-into the detectors... need to make the detectors more open system..

two aspects - hardware and software

two ways to get one computer in the room

1) one computer talking to many signals and the computer control

or... 2) could have microscopes and detectors be TCP/IP nodes on the network (better soln.. could even combine several instruments in an expt)

every detector should have a driver

software bus idea implements this scenario

need to convince manufacturers to implement this technology (need to get these to work together)

last point - once all detectors are on-line enet and software bus in place... still need some implementation for expts.... there are timing issues where various detectors need to talk to each other - can’t always do independent... need to develop a core to design expts.as well as the "architecture"

NZ - yes, I like it, but realistically need to decide on short-term goals... this vision could be an output of the MMC (the ideal down the road)

Hans - software bus in place to talk to instruments... software needs to be developed to design expts... or do we stick with Timbuktu and run comml applns

NZ - Timbuktu is not considered a solution... only OK to start things up

JHunt - need to get everyone interacting and defining standards for communication... we have an opportunity here to allow the microscopes community to interact... we have a lot of little problems (an engineering project)... could define a common interface and have the manufacturer bring theirs up to there or could kludge things to what the manufacturers currently have supplied us with... we are working very abstractly about philosophy

Hans - need to go to open systems across the board.. open= detector with driver and e-net connection

JHunt - UNIX is "open" because people come together and define standards

Hans - but this is "open" hardware, not software that I am referring to

JHunt - is Gatan an "open" system.?..no, despite the fact the everything is controllable through a network... but it is specific to DM... there is no common standard...

Ginny - is "open" system still a useful term?

Hans - currently in EM, every vendor has hardware and software to run the instrument, the functionality of instruments is defined by the vendor-specific software...would prefer to see an "open" system that can be accessed

MCW - have many layers do we need

DBA - the user interface can be up-loaded in real-time in an intelligent way from the server

John Hunt

Imaging and Analysis

why is Timbuktu not a good soln..need to think about this before we can declare that web-based control is the right soln.

old microscopes are linked to a PC and treated as a complete system

if we can come up with the descriptions for how the CCD camera or xray system connects to the LAN, etc... (in an extensible manner) ... we have accomplished something

DBA - what if the computer is a Windows 3.1 machine...

JH - wouldn’t touch it...would put another machine somewhere?

there should be only one computer that the user has to touch... there can be more computers around...Hans agrees

Instrumentation evolution - bleeding, leading maturing and maturity... need to support all of it.. some of these instruments have very little built-in automation

most selling instrumentation is leading edge (level II)

despite computer automation, system complexity has increased... need to integrate more

need to provide interfaces for both basic and bleeding edge users

Gatan TEM automation - TEM autotuning, magnification calibration, TEM system control (icon control, image centric contro, context images), automated/assisted image acquisition, automated image analysis, specimen maps and digital notebooks

BP - can you give an example of automated image analysis

JH - particle size analysis... dimensionality measurements, e.g.

JH - automated image analysis will be hard with a web-browser interface... eventually you would prefer to use it locally (e.g. via a downloadable image analysis program that has a finite lifetime)

LFA - do you foresee an efficient way to show specimen maps/digital notebooks during the course of an expt? we still always go back to paper and pencil

JH - 15 hrs ago the geological researchers were using this technology...

JAR - Human Genome people have Java-based tools.

JH - we should steal what we can... wait for other things... reluctantly create what we have to (minimalistically)

Hans - digital notebooks can be integrated by querying the instrumentation for operating conditions

JH - Example: when acquire an image... get all imaging parameters (some timing problems... latency on order of 30 sec.)...use a tensor to map the stage coordinates between expts when the specimen is removed and reinserted (depends on reference parameters and calibration)... a layer manager is used to relate the "children" images (metadata)...

Hans - how do we do this on the remote side?

JH - showed for 2 reasons... to show what is available - Gatan has a high level control package that is instrument-independent... the next step is to use commodity functions (all microscopes have) and unique functions...2nd reason to show is that there are certain functions that cannot be performed on web-based browsers...

JAR - but NGI

NZ - but it will matter to the clients

Hans - Why can high level functionality not be available on web-based browser? can you give an example of BW-limited problems?

JH - implementation burden on manuf. to develop dual interfaces on all machines..

MCW - there is a difference between whether it can be done and whether it is practical (for the reasons given above)

Hans - it would be good if core software was available as building blocks for expt. and get us away from the limited, specific software available from indl. manuf. -- use Java blocks to design the appropriate expts.... why can’t the expt-er write a java script for the appropriate expt.

JH - does not believe that the manuf. will make this all available

NZ - doesn’t expect manuf. to implement every functionality of their microscope onto a web-browser... would put them out of business and no-one would want to buy the proprietary, specialized software

Razdan -ASU

Partnership for Research in Stereo Modeling - remote operation of the SPM

NSF funded - Interactive visualization in science and engineering

www site for educational thrust

started in May... first attempts are quick and dirty

goals: live viewing; create web tools to view ad analyze images; capability for remote

operation

use an SGI server wtih Micro-app, utility app, Httpd, CGI: with connections to remote operator, other clients and canned image/data storage capabilities

have embedded software in topometrix to communicate with microscope control via sockets

receive and send data from the microscope running on a SGI O2

examine 3D data

software runs on SGI in C++, acts as a go-between the web clients and microscope

creates a JPEG image which is fed to the clients as either 2D or 3D data

2D JPEG mutli-threaded CGI program using server push, 3D uses pull technology

WWW Client (2D) - web brosers... web client for remote control..

Java Applet - provides simple user interface to remotely operate the SPM

3D PLUG-IN... allows for image manipulation.. each client can control the viewing parameters... rendering is a netscape plug-in local to the client

future: measurement and characterization tools... extend technology to other instruments... conferencing feature between clients for redlining and communication.. update with new web technologies as they emerge

website: see link on workshop website: http://invsee.eas.asu.edu/remote/

Open GL libraries are available from Microsoft

simple user interface to select area of scanning... and submit... via Netscape (or any Java-enabled browser)

Hans - are you trying to implement some microscope control to set operating parameters

Rasdan- plan to move forward, will have to implement security.... as more and more controls... have to deal with real estate issues

Rasdan - similar to an embedded controller... clients don’t see how many computers, etc. are involved... interested in the core software ideas espoused by Hans... always will need a device independent layer that each instrument manufacturer will need to conform to

Christopher Morgan - California State, Hayward (MOK connection)

Microscope and Graphic Imaging Center (Magic)

home site of a network of microscopes within the CSU system...

provide local and remote access for optical and electron microscopes

Philips XL-40 EM (primary instrument)... there are others involved

IP over modem...

using PC Anywhere and Timbuktu to some extend

custom, in-house software (IRSA)

outreach program with high schools (distributed learning resources program for education outreach)

Basic model - an instrument is controlled over SCSI bus.. controlled by a SEM-PC

use PC Anywhere on SEM-PC (several problems with that)... now use a direct custom control through a library...have an API supplied by Philips... use intermediary or proxy software in-between..

now going to a central server model... capture video separately through campus cable and/or VC network (like one of the instruments) - also captured through Sun workstation... trying to do a modular approach where things just plug-in

Networking (internet, ATM, modem, Internet 2 proposals)... GUI.. software development (object-oriented, tool-based)... distributed systems

NZ - IRSA sends what kind of protocols? it is JAVA, so it is multi-platform...

CM - RPC protocols like Sun protocols

have a push technology for JPEG images.... runs as a separate process.. that is the nice thing about UNIX machines

wants to work with us to make sure that what we develop is applicable across many fields

Cam Hubbard -beamlines

see VG

KBA - videoconferencing

what are the requirements and how flexible do we have to be...do we want to electronically mimic how we currently operate microscopes or create a new electronic way that is more optimized to use BW

Ray Bair - PNNL

DOE2000 ... Collaborative Session Management (PNNL/ANL)

There are several classes of tools that share an infrastructure... real time tools for 2-->> n people working together... and anyone an act on that tool and everybody sees it at once... pass events and pass data requires a framework so operate on

Cross-platform is necessary

Wanted a flexible framework that you could add onto as needed

NCSA Habanero - Univ. of Illinois, Champaign-Urbana... provides a user environment from which you can join a collaborative session...with it’s own session control interface... operates with a client/server architecture...you get a pallette with a selection of tools you might use in your collaborations... everyone sees what you see and/or open up...all written in JAVA...

features: collaborative framework, supports a wide variety of tools, cross-platform with JAVA development kit, provides routing, synchronization, arbitration; shared events; provides sharing of state data; applns leverage new framework developments such as CORBA

DOE2000 Habanero additions - security API, improved floor control, multiple modes including 3D virtual rooms, additional tools - shared screens (televiewer), audio/video (Mbone, CUSeeME), shared netscape browser (Webtour), shared editors, instruments, etc.

EMSL Televiewer - only screen display tool that is platform-independent... not remote... share anything on your screen with anyone, anywhere, & print, save, copy shared screen regions. Server provides translations for the platforms, screens in use. Sends compressed difference data (which is fast). Not fast for video screens where lots of things are changing.

Multi-pane Whiteboard - with thumbnails, parallel work within distributed groups, draw text, lines, shapes, etc... came out of summer project- a Habanero tool

Finished a software distribution agreement... next release date is Oct. 31...beta release on the website...http://www.emsl.pnl.gov/docs/collab (has better installation procedures)

Windows NT testing starts in Nov... works on W’95, IRIX, Sun Solaris, Macs now

Exhibit at SC’97 in San Jose, CA -- November 17-20.

Nestor -ANL

MMC User Interface...

Not going to talk about what I’m doing, because that is irrelevant...Would like to have us define the functionality contained within the user interface.

Starting functionality list:

• platform independent,

• intuitive GUI,

• responsive to the user,

• adaptable to lots of instruments,

• provides what the user needs to do the expt.

communication & control: user interface (www/rcp)... server... communication API... instrument driver appln... microscope --- what about data? what about intelligent agents?

SUN and GTS have donated about $250K in equipment to us - 300Hz with software and hardware to do video serving as well as video conferencing (two complete video boards)... gives us a baseline for comparison...same baseline across the laboratories

APIs command structure "in" to API (translator) which sends control syntex (defined by the microscope manufacturer) to the microscope... question is whether the info goes directly to the microscope or through another

we can create the command structure at this workshop

Design Criteria:

• client platform (CPU speed, desktop area)

• connectivity of user

• variable user level

• instrument safety

• instrument data format

• API/instrument communication speed

Basic Functions to be implemented (novice level - indt of system)

• translate/tilt... do we specify a distance?

• focus image

• adjust prove

• magnify image... do we just increase and decrease?

• change modes

• change acquisition rates

• change resolution

• change detectors

• read/write instrument parameters

• recall/store data (images, spectra, text)

Expert Level Functions
• instrument alignments

• full e-o adjustments

• expert modes (HREM, holography, HADF/STEM, EFI, Spectral images)

Local Level Functions

• gun operations

• specimen exchange

• calibrations

• start up

• vacuum

Screen turf is an issue... what do you put on the screen at any given point in time... users might have small screens... use tabbed interfaces

DBA- user interfaces from NASA/AMES... use a drag and drop interface for control like LabView... fully customizable on the fly... can see that this could be called up for specific instruments .. when sign onto an instrument get a specific control panel

Hans - like EMiSPEC system... you get the pages and controls you need for the expt. you are running... customizable workspaces

BP - do you match expts to the instruments? could do this easily

Hans - basic microscope control API...who produces these customizable workspaces... can we probe a little bit at this point?

NZ - sees us leaving with idea of control algorithms... what should baseline be for the translate command, for example? Is it move 1 micron? Then who is in charge of the translator? ... Philips (Max would like to see)--- us to say that he wants this operation done-- and he will write it for us...But, the XL30 people give us an RS232 port and they want us to write the API... so the scenario varies. But nonetheless, we have to sit down and decide what the command structure looks like... we have to live with the control syntax (the manuf. limit us here in the current instrumentation).

NZ - we need to decide on the command structure first... then the rest will come.

Command Structure -->> Translators (API) -->> Control Syntax

we do this here do this once manuf. dictate this for now

Jim Mabon - U of I

Training and teaching aspects...

how to use collaboratory...how to use instrument interface

classroom use issues needs to be addressed

JAR- wants to issue training certificates

Agenda for rest of the meeting:

Define the process for the remainder of the workshop

Hans - what is the goal? Control the microscope...what functionalities do we want? Do we want images, microanalysis?

EV - what about the SHACK on a secure link?

JH- as a functionality test? this would be a subset of the larger picture that we could create... at the levels we are at... it doesn’t matter what kind of data we are dealing with...(CCD cameras, video signal, eds, eels..)

JH - this is pretty simple asynchronous control, but Hans brought up some other issues that need to be considered down the line that would need to be done synchronously... we need to put together a first-level spec document

Hans - will Gatan include our spec vision for a CCD camera

John - if it is good, it will be an open std Gatan will adhere to...otherwise will be a tack-on for the MMC

Hans - so we will come up with a std of how to talk to instruments... on an API level... without really worrying about how to do expt. ...doesn’t think we can do this like this

NZ - need to comm. between clients and data (detector, CCD camera, SPM image)... need the user interface to say that it needs x,y,z done... we need to list these and then specify how to do these...

data layer...instrument layer...client layer ... expt layer

different levels of functionality are required for different users

JH - differentiated between CCD cameras, xray systems, etc..... because sometimes there really is only one major manufacturer... could be extensible and added-on to

JH- need to create specifications on larger projects like this...

MCW: let’s do a 1D layer model...

Experiment Layer

Device Dependent Layer

Specific Layer

Device Independent Layer

Device Dependent Layer

Device Device Device

source: adjust HT, filament adjust, emission, alignment,

display or data transfer (rate, size, format, compression)

store/recall (rate, size, format)

vacuum

active (novice, expert, admin) /passive (lurker, collaborator) modes

red = novice

Tilt/rotate... units of degrees

Focus... medium and fine increments/decrements... show a delta window/zero

Stigmators... medium and fine increments/decrements

Position Probe...x/y shifts

Morning Discussion:

server performs conversion to GIF/JPEG... no burden on client-side

those who write browser interfaces will decide how the data is to be display...wilth server performing the necessary conversions... JAVA applets can perform this

looks like there will be a west coast and a east coast contingent... east more on the user interface, west on the software bus

NZ - need to make sure that everything talks to each other... what client throws up must be interpretable... not everything will be a JAVA-based browser

BP - CGI v IOP

NZ - will have to allow both CGI and IOP communications

DBA - CGI is a gateway through http

NZ - doesn’t understand protocols for IOP...

BP - need a bridge/translator to read client command and translate to IOP

Chris - advantage of centralized server is that you can use a variety of streams/commands

JH - if someoone decides to use CGI.. they are just using another access route, don’t need to specify standards... maybe fastest way for testing and implementation

NZ - how do I wraite something that I can test now quickly... and still allow for modifications later

BP - IOP... internet interoperable protocol... attempt to let multiple CORBA vendors to allow their stuff to talk to each other... another new thing - sickyIOP

MCW - IOP is a freebie

MCW - are emerging with two different drawings that are not necessarily incompatible with each other... which view is most useful depends on the details we decide on

Chris - there are both hardware and software architectures to be considered

JAR - what is it we need to do?

DBA - we are talking several different things....what are the commands/API that are appropriate for the model that we use... we haven’t really agreed on the picture

JAR - our diagram may not be drawable

JH - aim for getting something together within a month... it is unreasonable to come with all the answers today...

JAR - need to make sure that what we do is extensible and flexible...may have to change the hardware interfaces, but the basic architecture will be the same.

JH - need to understand bridge technology between DCON and CORBA

JAR - what about firewalls

JH - Microsoft will probably take care of that

DBA - have to use DCON if writing to Microsoft Explorer

JAR - will we require Explorer or both Netscape/Explorer

MCW - there are other issues being explorer for monopolies.. whether Explorer should be free and so pervasive

Jan- it is not easy to delete Explorer

Ray - need to leave it and disable it

JAR - we need to make some of these decisions now.. will we support both Explorer and Netscape... could go with only Netscape, but not only Explorer....then we don’t have to worry about DCON if we choose Netscape

MCW - must support all 3 platforms...Netscape allows that

JH - since the bridges exist to go into DCON can probably accommodate this...

MCW - community wil eventually resolve DCON/Corba issues

BP - believes that a bridge for these already exist... security is not clear

DBA - even at the html level... need to accommodate multiple browsers....bridges may not be enough at the appropriate level...if support both, must be done all the way down the tree

JAR - sounds like we have decided to use Netscape

BP - not true... mutlicasting capability is an issue... we just use a JAVA applet

JAR - do we need multicasting for these applns?

Chris - yes

JAR - no.. streaming A/V to many may be enough... but these collaboratories may be 3 participants for multicasting... can do lurking with streaming alone

NZ - a reflector may be sufficient

Chris - intelligent MC only uses links that you require... no flooding of the network

Ray - router issue... those that won’t program routers to do MC are waiting for the routers codes to settle down to be reliable.. . it is not that they don’t want to do MC in general

Chris - need an architecture that needs a hook into MC

Jim - should command set be fully extensible

MCW - EV wants us to define a minimum scenario.... define a exptl scenario that is simple and would be useful to all sites

Ginny - this interface assumes that everyone is a microscopist... we are not dealing with total amateurs... how general is the interface... should this be a beginning step in their training...

NZ - we assume that these people have used a microscope... we don’t want something that serves for training per se

MCW - need to design at high enough level that we can accommodate many viewers for distance learning as well as high level research collaborations.... extensible architectures require similar sorts of syntax for commands... need to distinguish architecture design from implementation

RJLEE has a copy of this...

User Interface -->> server ---> microscope -->> slow-scanTV

SUN + video cards l

l<<------------------------------------------------l

web/remote serial/PC on-board computer

httpd asciii/api today

the presence of the PC between server/microscope allows data, spectroscopy data to be sent

BP uses IOP/Java on the httpd communcation point... could run httpd and IIOP scenarios in parallel (need a switch)

two video cards with SUN - one for High rate, one for low rate... each with two plugs

Our Philips at ORNL.... not a slow scan camera... need a TV signal

server will need to know what kind of microscope it is talking to....

can we in the short term use the SUN server to create this for: Philips Hitachi (VG&IBM LEEM headaches) Kratos Zeiss JEOL?

have server send ASCII to microscope and have it "expect" a specific ASCII string back (program is called EXPECT and it is from NIST)...a CGI extension (common gateway interface... an interface outside the web browser)

have appropriate ASCII control codes for JEOL, Hitachi and Philips and Zeiss

can then create a matrix for command codes/microscope/DAS(Emispec).... can compile this rapidly - a kludge... gray-out inappropriate buttons

cycle colors red/green to let you know that command is sent/received/acted on

JAR - what NZ is proposing works... can this be modified to a more sophisticated architecture

Hans - need a computer in this scenario to acquire data

Jan - what format does spectroscopy data come out in

Hans - we are heading for a home-grown solution...

NZ - need something up and running... check it for how well it works...

Hans - where does EMiSPEC fit it... we need a core that integrates all of this... if we go home-grown the detector manuf. will be hesitant to be involved.... their system is already integrated... just hook this in with a JAVA plug-in to get browser access... MMC cannot afford to pick a manufacturer in particular... Emispec system includes all the data to run this. .. with homegrown stuff can control the microscope... but to gather spectroscopy data, this is more difficult due to the proprietary nature of their software... do we work with all the detector manuf, or do we deal with something like EMiSPEC? Or can ask all the vendors to write a script/API so as to react to the command "start EDS".... needs to know what the MMC decisions are ...

Bill Mollon - Noran and Oxford... supply commands to talk to EDS detector via PC

NZ - believes we an do this in 3 wks... similar to the SPM work.. in time for SC’97

Focus in on the PC between the server and microscope (EV/Hans)...Hans - how does MMC view the role of the industrial persons...he envisions the "core" being similar to what EMiSPEC does with a link to a JAVA browser... they are in a position to do this well, but their soln would not be "collab"...Do we want one local computer talking to all the detectors? in principle, they can do everything (not a commercial product, yet)....go straight to the detectors (EMiSPEC) with an RS232 to the microscope...in long term want detectors to be nodes on the network (ORTECs (Billl Hardy s’ behaves like this)... but for now, communications with detectors are proprietary.... but need to buy EMiSPec’s hardware soln which includes MCA and pulse processor...

JAR - we shouldn’t reinvent the wheel, should use comml solns if available...we are going to have to use a manuf. soln to talk to these

NZ - question comes down to $$ and how???

NZ - do we require to MMC members to go and buy what we have....

right now a faster route is to use DM and camera to talk to microscope... JH has the hooks to do this... if not complete, not a fast solution...CM200 has DM on it... just need to connect for instrument control

what is a practical thing to do for SC97... webcast from NZ, Timbuktu Pro, dedicated machine from LBNL..but was hoping to get SUNs up and broadcast on one page from all the sites.. maybe only have control over one of the them...the other trick is to post the DM page on the web page

Jan - could just send channel by channel spectroscopy data to users and they use DTSA.. do you want users to do EDS analysis through web browsers...

EV - for spectroscopy , if talk directly to the hardware, you are throwing out the software that the vendors provide

Hans - what we are planning to do is very similar to what ES has already done...maybe it is ambitious to just bring any old EDS system on-line... maybe MMC should invite industry to create MMS spec’d products... let the indy compete...

EV - can we run ES stuff through Netscape...(within 1 yr should be available)

Hans - need to do it as an open bid... need our data acquisition systems to do the following...GATAN and ES are already on this route...

• a short-term model to bring us up and running

• list of functions/operations for the basic user interface... first-cut design

• ID need for integration of detectors/microscopes...need to write a spec for what comml acquisition systems should provide in the future...in the short-term need to integrate legacy systems (either ourselves or through comml. systems).

Experimental Modules:

through focal series

auto alignment

JH: begin all MMC mail traffic with "MMC:"

audio issues in VC.... not much drop-out, seems to be more machine-dependent on the audio card being used

JAR: Stu Loken was with group watching Mbone feed, in general they didn’t need talking heads... they really needed chat, whiteboards and shared screens, etc.... but they didn’t believe that they needed to see people. They were using things like NetMeeting.

NZ: out CUSeeME interactions have been OK

NZ : the key thing is that we already know each toher.. but, if you are working with somebody that you do not know well, talking heads allow better interactions.

MCW: the meeting minutes have been sent out by email, DBA and MCW will put these on the websites.

DBA is working on a form to allow easy uplinks to the website

MCW: the electronic notebook... what should we do about it.

NZ: there are 3 notebooks up and running... a public one, a private one, and his personal one at the microscope for logging expts.

NZ: can use on a day to day basis, if it were on the VG computer, but that is an OS/2 box that cannot be modified. So currently has to run notebookj on a separate machine from his microscope control computer (inconvenient).

MCW: should we create a notebook for the software development per se? Is that a reasonable thing to do?

BP: the toolkit that he uses has an underlying database, but that is only for local people... ...will put code on an ftp site (prefers not to put in the electronic notebook)

MCW: nestor has the webpages for doe2000... meeting minutes, etc. will go on the website that DBA is handling.. materials science research info will be go nestor’s webpage

BP: there is an MMC site at LBNL.... they can put stuff on there and we can link to it.

NZ: add the link to BPs site to the NCEM site

NZ: need to migrate the home page to a more collaboratory-centric rather than a collection-centric...

MCW: what do we do now? we don’t have a diagram that we have all agreed to. but we can set up some tasks and timeframes...there seems to be a west coast crew that we create a template format for other to test... the question is "how general is the west coast solution"... who is going to specify the device drivers... how do we proceed.. how do we define the role of industry in this effort? ...

NZ: what we need to define at the end of the day is a list of items that need to be implemented... and put it down in some detail... and then a) implement it ourselves of b) put it out to our indy partners for review/comments.... then we have a generic specification decided upon by the MMC group (including indy)... need to do this for both our current systems as well as for the future systems that we are envisioning... this comes down writing specifications....

MCW: so you guys are going to create a functional specification in sufficient detail that the computer scientists can then write what needs to be written?

NZ: need to make sure that it is clear in our minds what we want to do and then get information from JH and Hans, etc...need to be able to produce the document and clarify these issues before we put it out to the rest of the world.. want to avoid reinventing the wheel... how do we make use of their expertise... how do we use them in our MMC and get their input?

Architecture Working Group:

see Bryan’s drawings esp. of JHs structure

server controls the component through an ORB, but also restricts access and performs some expt integration

clients interact via CORBA, HTTP/CGI, DCOM

hardware vs. software models... software architecture (DBAs drawing absent the layers)

Ray: how would you integrate these kinds of concepts (DBA drawing) with Habanero... i.e. set up collaborative clients... just look at the conceptual level

embedded web server concepts seem to be expanding... web servers in ROM.. on a chip

Hans: real-time acquisition and servers need to be separate systems

everyone agres

JAR: how send real-time data to the web server

JH: the web server talks to components which sends data in real time... which then propagates upwards to the clients...

DBA: can be done through the ORB, through a JAVA applet...

JH: implementation can be however you would want it

Tasks/Timelines

John, Bahram, Chris and Mike will take what they are already doing, make it more general and supply the info to us as a template

meanwhile:

• others will get up to speed on CORBA, IOP

• other will be working on a user interface

• implementing the short-term solution (http-based)

JAR: what other collaboratory tools are required for us to collaborate....other than instrument control,

MCW: look into Habanero after October 31 re-release

NZ: original Habanero was a bunch of little applns.. games, etc... it was basically a chat window with a history to it... when you logged in, it would update you as to what you missed.

JAR: could envision a chat window where you post archived images... draw on them...etc. suspects that Habnero may not included this capability

NZ: Habanero.. has archival retrieval as well as annotation capability as well as whiteboard capabilities that everyone an view at once

MCW: VC tools are incorporating more and more communication tools such as whiteboard

JAR: what about the reception area/information center for the collaboratory?

NZ: difficult to do...a black art; better done through organic entity

JAR: what about the reservation desk...issuing certificates

MCW: bureaucratic paperwork process across the sites

KBA: what about definitions about capabilities with links to appropriate sites

TIMELINE/SCHEDULE:

BPl,BP,Chris - will be getting together every 2 wks and generating a white paper/IDL and create a working set of stub layers... will know in one mo. if it can be done.... after second mo... would be looking for comments from others

"Component Server Transport Layer White Paper" - John Hunt, 11/22/97;

"Component server draft RFC" - John Hunt, 12/22/97

Publish/communicate results

Build a prototype system

SC’97 short term expt - Nestor 11/17/97

bring multiple facilities on-line: DBA,

document process into the notebook

Basic User Interface

command description draft- Nestor 11/17/97

RFC - Nestor & others -

CCD output to the web: EV, John Hunt, NZ

Issue certificates to collaboratory members: JAR

Set-up Secure Servers and Certificate servers: JAR

Publish security architecture: JAR

Develop Prototype MMC Collaborative webspace: NZ, DBA

Publish talks, minutes, results from workshop: DBA

Plan for public workshop for next year: LFA

MM98 Symposium: EV, NZ, MOK

Investigate Notebook instantiation/shelf concept: DBA

michael wright

kba

hans de ruitjer

ray bair

gary casuchio

nancy

christopher morgan

mike o’keefe

jim bentley

ringnalda

carl mcdonald?

arvid

ted

cam

larry

asu

ginny

jim

steve ... anl

matt ... anl

nestor

john hunt

edgar

bill mollon

bryan allen

bahram pavram

charlie neilson

Bryan: link to the Virtual SEM/Virtual TEM sites