RI Title
RI logo

This document hopes to demystify how Cassini operates when using a Test Exec to run production and how each step interacts with Guru, identifying where the configuration or calibration data is stored and when it is updated from the Guru server. This technical document references the internal operations of Cassini and is not required to operate Cassini but it could be helpful for troubleshooting and risk management for Administrators.

This typical process does not include all implementation variations. Within each stage, many of the steps can be completed in any order and specific workflow implementations may require additional procedural steps. If a Prober with wafer parts are used, substitute the word "Prober" for "Handler." Objects that store configuration or calibration data in the text below are identified by their Object Type that is listed as the ri.sys.ObjClass attribute's value in parentheses, like this: (ObjClass). All configurations are typically loaded based on the Guru ID or Serial Number which is stored in the ri.sys.Owner attribute. So when browsing Guru, one would select the ObjClass and Owner to look at or modify the configuration of that object.

Guru applications, including Cassini, interact entirely with the local Guru which requests and retrieves specific updates from the server and saves any changes locally before being backed up. This is true for every user interaction that presents a list of latest choices including Short Cuts, User Apps, Test Execs, Test Plans, Cal Data, etc. For example, when the Apps button is pressed, Guru queries the server for a list of all RiApplication objects. Once the specific Application is selected from the list, the local Guru retrieves the latest version from the server if an update is available and saves it to the local repository before opening. If the Guru Server is unavailable, after a short time as it waits for the Guru server connection attempt to fail, the system will open the latest local version of the object. This provides the applications with robust ability to operate while offline as long as nothing changes with the setup requiring an update from the server. If nothing changes, the tester can operate indefinitely offline with all changes automatically being backed up as soon as the server connection is resumed. When an application saves a Test plan or calibration data, it is always stored locally with a "local.ri.sys.COPY1=guruConnectionName" attribute until Guru copies it the Guru server configured as the backup and the local.sys.COPY1 attribute is removed.. If a Datalog Server connection is configured, only "STDF" RiDatalog objects are sent to that guru server. The RiLotSummary and all other objects are copied to the Backup connection. For more information, please reference the Database 'Product Docs', View 'All Documents', Document 'RI System Software Network and Data Integration Guide'RI System Software Network and Data Integration Guide.

1. Dock Cassini to Handler/Prober
2. Select Test Exec
3. Test DUTs
4. Troubleshooting

Dock to Handler/Prober (see Figure 1)
  1. Attach AC power and Air to the facility supplies. Dual redundant power supplies in the rack convert AC to DC when the AC breaker is in the ON position. Up/Down buttons become active after the first time the START switch is rotated to ON. If a AC power fault is encountered the breakers will switch to the OFF position. The DC side is connected to the internal infrastructure EMO and START switch when Green light on each power supply is on. If the light on the DC power supply is off or not green, it can be swapped while the tester is powered on, however we recommend stopping testing and powering off the AC to perform the swap. Air is regulated to 90 PSI (supports 65-120 PSI) and enables the testhead to latch/unlatch the Fixture. Production touchscreen is powered directly from within the infrastructure's DC power supply and is powered as soon as the switch is in the ON position.
  2. The EPC powers up and starts the embedded OS (ArcaOS) uses network configuration and any customization like mounting shared network folders and printers. Time is synced with NTP configured servers to keep the OS time in sync (ntp.company.com host should be on-site). If the tester is disconnected from AC power, a battery on the mother board keeps accurate time, this battery may need to replaced if the time is wrong when powered on. The RIFL Master includes a calibrated 10 MHz clock that is assigned to the EPC, saved to the local disk and also backed up in Guru.
  3. Guru launches from the OS Startup folder by unzipping the GuruServer.zip and launching startup.cmd with default command options. The startup script unzips and executes Guru if the local Guru process is shutdown or crashes. Guru can be temporarily disconnected by closing the startup script and launching it from a command window. Any guru server error logs are imported into Guru at startup.
  4. Guru loads it's preferences (RiSystem) and connections (RiGuruConnection) based on the GuruID present in the D:\RiGuru\GuruKey folder matching the ri.sys.Owner attribute. After a slight delay, Guru launches DB Manager (again, the application is unzipped and executed) to handle the generation of RITdb and worksheet UI. Guru gets updates for any Agents (AutoStart) configured based on the Guru ID and executes them some time after startup.
    Note: Some versions of Guru require the operator to physically stop DB Manager and quickly launch it from the Apps button to update the version to the latest, otherwise DbManager will auto restart without updating. This is to coordinate any Guru server dependancies, if required.
  5. Operator attaches Handler POD and green ground wire to the handler (not facilities ground). If the tester and handler do not share a common power outlet (i.e. 120 vs 220), the ground differential between the two circuits can be significant and cause serial communication issues. This ground point is intended to eliminate that differential between the two circuits. Operator prepares Handler for processing the lot.
  6. Operator attaches the DIB and latches the Fixture to the handler, then docks the Cassini testhead using the UP/Down buttons, monitoring the Fixture Align light. When the Align light turns from Red to Green, the operator rotates the Fixture switch to Latch and confirms the Latch light turns from Red to Green, signifying a the Fixture is docked. If setup verification is required, this can be done with the Fixture attached directly to the testhead. When docking, unlatch the Fixture, mount it to the Handler, then dock the testhead to the handler mounted Fixture.

Selecting Test Exec (see Figure 2)
  1. Log On to Guru - Use chooses Log On from Guru and enters a case sensitive username and password. If the RiUser object (updated from server) matches the password, the Log On button changes to System and other buttons are enabled. This is used to limit visibility (access) to features and some objects based on Permission/Category. Logout and Logon can be performed at any time, the objects and features will become visible or disappear the next time they are requested. Some administrative applications like Guru Explorer and Sync Util always have full access to all guru objects.
  2. Launch Short Cut or User App - Cassini software is updated from server. The application is copied from the local Guru repository as a .zip archive then unpacked and executed. Any patches are loaded out of the local Guru if it is not a fast loading short Cut, otherwise the application loads without needing to recompile any patches. Unlocked Short Cuts that are allowed to update patches to their latest versions are updated as the patches are loaded.
  3. Cassini initializes the RIFL Master in the EPC by loading 10 MHz clock cal data off the hard drive, loads the last saved Tester definition (RiTesterDef) associated with this Guru ID (Options > Save State) and then proceeds to check in each instrument by performing a System Startup. If a Tester def (configuration) has not been associated with Save State, Cassini will choose the latest configurationin Guru. If the EPC was swapped, the Tester's Serial Number stored in the 3 RIFL Hubs located in the testhead may not match the EPC's Guru ID, so the system will prompt the user to change the EPC serial number and reboot. (See EPC Exchange procedure)
  4. For each TIM, the system powers on and initializes the instruments, initiating the warm up period. Some instruments require 20 minutes to warm up before use and 2 hours before calibration. If the instruments are powered off, always start the Short Cut early in the process before finishing the rest of the tester setup. Cassini loads updated calibration data based on the Instrument's Serial Number (TIM S/N matches the ri.sys.NodeID attribute), which loads the latest BaseInstDef (by model number), which loads the InstumentDefs for each Instrument in the TIM. All of these Defs are packaged with the RiPatch object. The Cassini software, based on patch levels, loads the TIM's firmware into the TIM (Rbf) and identifies the Instruments added to the Configuration. The latest cal data and defs are updated from the server if a new version is available. If multiple identical TIMs contain the same instrument name, the Tester configuration (RiTesterDef) is used to assign names based on Serial Numbers last time the Tester definition was saved (Tester > Save). This is why it is important to save the Tester every time a TIM with a different serial number is swapped. A Self Cal is performed at Startup and becomes the reference for future self cal offset for temperature variation.
  5. Cassini reads the serial number of the Handler POD via the AUX RIFL ports, loads appropriate GPIB/Parallel/Serial handler drivers based on the BaseInstDef and switches to "physical" Handler mode. The Handler only appears in the Equipment Pool (System > Equip > Pool) because it is not an Instrument that can be controlled by the testplan. It's configuration can be edited from the equipment pool and saved to EEPROM in the POD. The operator can change handler modes before starting the Exec by choosing System > Handler > physical | manual | simulated.
  6. Cassini reads the serial number of the Fixture, loads the latest calibration data that references the Fixture Def (ri.sys.Esn attribute) and then if the calPerTester=true flag is found in the Def, the latest calibration data that matches both the Tester's Guru ID (ri.sys.Teseter) and the Fixture's Serial Number (or ESN). If the Fixture Def calls out a RIFL carrier, the tester loads the firmware (Rbf) and adds the Fixture Instrument to the Tester's Configuration with "Transient" at the end indicating it will not be stored in the configuration when the Tester is saved.
  7. Cassini reads the serial number of the DIB, loads the latest calibration data that references the DIB Def and then if the calPerTester=true and/or calPerFixture=true features are implemented, reloads the calibration data appropriate to those features and then adds the DeviceInterface to the Tester's configuration with "Transient" label.
  8. Operator launches the Test Exec. The Test Exec will load the latest Testplan configured based on Title or CID if "Do not update testplan revision automatically" is selected, assign the configured limits and softbin and hardbin configurations. Any Views are opened and options/features (like Bias Offsets, About on Save settings, etc.) implemented. Alternatively, an operator can choose a User App which pairs a Short Cut + Test Exec and is accessible via Bar code scanner because of the text input filter on the User Apps button. If the Short Cut version is already running, it will only load the Exec. If a different Short Cut is required, the User App will close the currently running Cassini software and launch the appropriate Short Cut, perform a startup to identify and load all the TIMs, Handler POD, Fixture and DIB.
  9. Cassini compiles the testplan with all the calibration data from the TIMs, Fixture and DIB and generates RIFL packets specific to each Instrument model based on the RiBaseInstDef. If any errors are encountered, a user prompt is presented requesting the operator fix and then choose OK to continue. Once it compiles successfully, the tester will display a green START button. Any displays specified in the Test Exec editor open.

Testing with a Test Exec (see Figure 3)
  1. Operator enters lot information either via keyboard and/or bar code scanner and presses START. The tester transitions from the tester idle state to the testplan idle settings that include the disconnect settings and global defaults.
  2. The tester generates the RITdb and displays the worksheet via messages to DB Manager and saves the STDF Header information (RiDatalog) and stores to the local Guru.
  3. Force Test can be pressed if the handler communication times out and causes the tester to re-emit Handler "SOT" command.
  4. Testing continues, where all the measurement values are compared to the limits and BIN command sent to the handler and the test data is stored RITdb and worksheet is updated. (See Figure 4)
  5. If an issue arises, and ALARM prompt will ask the operator to resolve the issue (like "More Parts") or if and instrument stops responding. See "Troubleshooting Operations" for common resolution tips. Choosing Ok, then the green RESUME button will continue the log.
  6. Operator can Pause testing and the current DUT will finish testing and will send BIN command to the handler but will not ask the handler for the next part. Operator can "Reprint Report" while testing is Paused.
  7. If power is lost or the EPC hangs during this process, the RITdb should have every result from the last DUT. (RI is working on the ability to Resume Lot from fresh start after detecting a unfinished RITdb.) For now, the lot has to be started over or can be continued in a separate datalog.
  8. Every 100 DUTs, a "detail" STDF datalog is stored to local Guru.
  9. When the lot ends, the operator presses STOP and the local RITdb is closed, a Lot Summary is generated (if the option in the exec is enabled), the STDF Summary is saved to local Guru. (The RITdb is saved for 30 days and can be opened from the Program > View RITdb menu.)
  10. Operator can enter new lot information and press START again or can close the Exec to wait for the next setup.

Troubleshooting Operations (see Figure 5)
  • If there are "Fixture missing" issues, confirm Fixture is latched properly and that the socket, DIB and Fixture connections are clean and free of damage or debris.
  • Confirm TIMs are latched and loaded and named properly in the Configuration (correct T-Location).
  • RI recommends leaving the Cassini software running while testing is idle, this allows the instruments to remain at operating temperature and allows Guru housekeeping including expiring objects. DIBs, Fixtures and TIMs can be safely removed when the tester is Idle, just perform a System > Check or System > Equip > Startup to update the live software configuration.
  • Power off the Tester by first removing the Handler POD from the handler RIFL AUX port, since RI intends the POD and RIFL cable to stay with the Handler it is configured with and to avoid damage to the RIFL cable. Unlatch and remove the Fixture. Close the Cassini software and any other Guru Apps. Choose System > Backup to force an immediate backup of any remaining Guru objects, then perform an OS shutdown, choosing Skip to force close any processes that are not closing promptly (this is safe to do). Once the screen flicks black, rotate the START switch to OFF position to disable power to the EPC. Switch the AC breaker to the OFF position and disconnect from AC power and air from facility supplies.
  • If power is lost, the Fixture can be manually unlatched from the testhead by forcing the black testhead handles once the Air supply is disconnected. It is safe to unlatch and store the TIMs on a shelf in a temperature controlled room, anti-static precautions are not required.

Figure 1: Docking & Setup

Figure 2: Choose Exec

Figure 3: Testing with Exec

Figure 4: Test Exec Flow from Idle State

Figure 5: Troubleshooting Operations

PrintEmail Link
©2020-2024 Roos Instruments, Inc. All rights reserved.