Ticket #1629197

Hello Kyle, We have a ticket system now that will help us keep multiple eyes on the situation. I have created a ticket for SpaceX. Please in the future always include [email] in the email so it generates this automatically. I will login to FileXchange and grab those files. Thanks,

Hello Kyle, I wanted to let you know that we’ve submitted a formal inquiry to our development team in Japan regarding the issue you reported. The inquiry includes all relevant logs and screenshots from your system. Please be assured that maintaining data integrity and traceability is our top priority. We’ll provide you with progress updates as soon as additional details become available from Japan. Thank you again for your patience and cooperation while this is being reviewed. Best regards,

Hello Kyle and Sam, We are still investigating this issue and I don't have a clear resolution timeline yet. It seems like every time the wrong image is shown, the correct image will appear when reopening the inspection in RVSXRay. Is it also fair to assume that the initial NG images are seen when the operator opens the review immediately after the scan is completed? I would like the following logs from the RVSXray PC which demonstrated the issue: C:\Program Files\OMRON\RVS_APL300\RVSXRay\AppLog\ All .txt files modified on or after 10/31 C:\Program Files\OMRON\VirtualCrossSectionViewer\log\ All .txt files modified on or after 10/31 ​C:\Program Files (x86)\OMRON\VcsVService\log\ All .txt files modified on or after 10/31 It looks like these reviews always happened on 10/31, so would it be safe to assume the first time the operator opened the review is close to the time of Inspection? Regards,

Hello Sam, Can you please double check that these log files came from the RVSXray PC that demonstrated the issue, and not a different PC? I am trying to match the logs with the images that were send earlier, and none of the board serials in the photos appear in the logs at all. Regards,

Hello Kyle and Tyler, Thank you again for your continued collaboration and for sharing the latest observations from your team. We’ve developed a new PowerShell-based review tool that allows operators to scan a PCB barcode and instantly display only the NG component images linked to that specific inspection. This helps verify image-to-board relationships directly from the AXI database in a controlled, repeatable way—without needing to navigate through RVS manually. I’ve attached (and also recorded) a short demonstration video showing how the tool functions. It continuously monitors the SQL database, retrieves the latest inspection data, filters out non-NG components, and displays the relevant images inside a clean, single-window interface. This can be used to validate image integrity across multiple boards while avoiding any cached data from the review station. Additionally, we have relayed all information you and your team have provided—including logs, reproduction steps, and correlation results—to our development group in Japan for further investigation into the root cause of the cross-section viewer behavior you reported. Once we receive additional technical feedback or direction from Japan, we will update you immediately. We greatly appreciate your patience and detailed testing support while this matter is under review. Best regards,

Hello All, Jeremiah's Powershell script and instructional video have been uploaded to FileXChange. Please try this on the RVSXRay PC and let us know if it helps.

Hello Tyler, Thanks for letting me know the error. I have reuploaded a couple of files. ​1. Can you please get create_rvs_app_win_auth_FROM_AXI_SERVER.zip file, extract this onto your AXI server, and run this .bat file inside. This will create the rvs_app user on your SQL database. 2. Then download the RUN_AFTER_ON_REVIEW_STATION_AxiNgViewer.zip file from FileXchange, and extract this onto the review station. You can run this now and shouldn't have that authentication issue we had before. Let me know? I will text you as well to let you know these files are here. Thanks.

Hello Tyler, ​I have uploaded a new file for you to test. Please test and send me a screenshot if it doesn't work. We were able to validate we connected to the DB, now just need the images to come back cleanly. This had to do with the code in the powershell script and the naming convention of your REF designators. Let me know? Thanks.

Hello Kyle, We've done some testing and although the issue does not reproduce here, we have a generally good idea of the process. Can you confirm a few details here? ​Issue occurs only when RVSXRay is closed manually via the Taskbar ​Issue does not have any relation to how quickly the review is opened after scan ​When RVSXRay is manually closed by an operator, VirtualCrossSectionViewer does NOT close Issue occurs only when VirtualCrossSectionViewer is left OPEN after RVSXRay is closed manually I also have a few questions: When the image displayed is WRONG, what happens when you click a different component line item in the RVSXray menu? Does it hang on the wrong component, or change to a correct one? When the image displayed is WRONG, what happens when you click the VolumeViewer icon? Does it open the wrong volume, the wrong volume, or just crash? Please let me know. Regards,

Hello Kyle, Thank you for confirming. That lines up with the behavior that we discussed in the meeting. Basically, the impact of opening a review when the Virtual Cross Section Viewer is in the stale state is that any number of the images could be incorrect. I got some more information from Japan about the issue. Like I mentioned before, force closing is not a standard operation, so it has not been considered in-scope for the development team thus far. That being said, they were able to reproduce VirtualCrossSectionViewer NOT closing. Here is the basic situation: RVSXRay version 3.01.00S (used by SpaceX): When force closing, VirtualCrossSectionViewer does NOT close RVSXRay version 3.01.00T or later: When force closing, VirtualCrossSectionViewer closes automatically Obviously, this means an upgrade would change the behavior. Unfortunately, SpaceX is still locked out of upgrading due to being on custom software. The custom function, Fiducial Retry, was slated to become standard (allowing SpaceX to rejoin the normal upgrade path) in version 6.07. Currently, the latest software version is 6.06.00C. I have asked the development team again to confirm this roadmap item regarding Fiducial Retry. If I get a timeline on 6.07 and the standardizing of this function, I will let you know. I am thinking that most of the action for this ticket is complete, so let me summarize the current status: Issue Behavior: Part of non-standard operation, but discovered to be tied to a specific software version. No action can be done yet, we will need to wait for development of version 6.07 to return SpaceX to the normal upgrade path. Scope: Known to occur during specific operation (force close RVSX, leave open VCSViewer, reopen RVSX). While we cannot concretely prove that this is the only operation that triggers the issue, it appears to be highly likely given the troubleshooting efforts thus far. Impact: Known to occur on current software version, but it is not clear if previous software versions are affected. Jeremiah provided a script to parse through the Log files so that SpaceX can identify suspect Review operations and analyze for problems. Please let us know if more concerns arise while using the script to estimate impact. If no issues, we will close the ticket and make sure to keep you updated about the release of the next software version. Regards,

Hello Kyle, I checked with Japan and it seems like they removed the Fiducial Retry function from the future standard roadmap. Please allow some time while we negotiate with the development team. The plan is to get either a standard software update or a patch that fixes the bug. For now, a patch is likely the quickest option. Regards,

No sanitized conversation text indexed.