NDT Analysis Workstations: Test the Software and Real Files
The best workstation for an inspection team is one that supports its approved software and completes its real review tasks reliably. Build the purchase decision around supported versions and representative files rather than a generic gaming-computer specification.
For: U.S. NDT equipment coordinators, quality staff and inspection business owners
Define the workstation's actual job
Separate acquisition control, post-acquisition analysis, report preparation and general office work. A computer used to control an instrument can have different interface and support requirements from one used only to review delivered files. A report workstation may need another application or template environment. Identify which roles the proposed computer will serve before asking for a hardware quotation, and keep any instrument-control acceptance work under the organization's approved technical process.
List the inspection applications, editions and versions the team intends to use. Include necessary report tools, viewers and interfaces rather than only the primary analysis program. A powerful computer can still be unsuitable if a required application or entitlement is unsupported. The buyer should understand the complete software environment that must work together and who is responsible for maintaining each part after delivery.
Define a few concrete tasks that represent success. Examples include opening an approved sample dataset, navigating the required views, completing a defined review action and generating the agreed report. The technical reviewer determines what a correct result looks like. Purchasing and IT can then evaluate performance and supportability without treating a hardware benchmark unrelated to inspection work as proof of suitability.
Use requirements for the intended software release
Manufacturer requirements are tied to particular releases and products. Eddyfi's UltraVision 3.12R27 notes and TubePro 6.1 notes provide historical examples of published system requirements and compatibility information. They demonstrate why version matters; they are not a recommendation to install an older operating system or use those requirements for every current release.
Obtain the applicable requirements from the supplier for the exact software being purchased or retained. Record the document date and version in the evaluation file. If a product page, release note and sales response disagree, request clarification rather than selecting the most convenient value. The organization needs a supportable configuration, not merely a computer that appears to launch the application during a brief demonstration.
Distinguish minimum requirements, recommended requirements and any application-specific restrictions. Ask what each statement establishes and which workload it assumes. A minimum may describe the ability to run the program while leaving the team's larger files or more demanding tasks untested. The buyer should use representative work to assess practical performance while respecting the supplier's supported configuration boundary.
Build a representative dataset set
Select authorized sample files that exercise the real review tasks without exposing unrelated customer information. Include an ordinary file, a more demanding file and any legacy format the organization must continue to access. The technical team should identify what makes each case relevant. A very small vendor demonstration file may be useful for learning the interface but cannot establish performance for a substantially different workload.
Record a stable identifier, source software version, size and intended task for each sample. Keep the source unchanged and use working copies for the evaluation. This allows two candidate computers to be compared on the same inputs. If a file is replaced or modified during the trial, record the change so that a faster result is not mistakenly attributed to hardware when the workload itself became smaller or simpler.
Include the supporting objects needed by the workflow, such as a permitted template or configuration reference. A file that opens without its expected context may not support the task the reviewer needs to perform. The dataset set should therefore represent a complete usable sample package, not an isolated file chosen solely because it is large. Correctness and completeness matter before speed is compared.
Compare complete environments rather than processor labels
Record the actual computer configuration used in each trial, including processor, memory, graphics arrangement, storage, operating system and relevant application versions. The purpose is reproducibility, not a universal shopping list. Two computers with the same processor family name can differ in memory, storage behavior or deployment configuration. A useful evaluation identifies the tested machine well enough to compare it with the model being ordered.
Ask the application supplier which hardware characteristics matter for the intended tasks. Some workflows may depend on a supported graphics capability or network interface, while others are constrained differently. Do not assume that a high-priced graphics card accelerates every analysis function. The buyer should obtain product-specific support information and test the actual workload instead of applying generic advice from unrelated software categories.
Keep portability and deployment needs visible. A field laptop may need to fit an approved working arrangement, while an office workstation may benefit from a different display and storage setup. The organization should evaluate those practical needs alongside performance. A desktop that completes a task quickly may still be the wrong choice for a role that requires an approved portable environment at the inspection location.
Measure useful tasks with agreed acceptance criteria
Create a trial sheet with the sample identifier, task, expected result, observed result and reviewer. Include time observations where they matter to the business, but define the start and finish of each task consistently. Opening a file, loading all required views and becoming ready for review can be different milestones. A vague claim that a computer feels fast is less useful than a reproducible observation tied to a specific task.
Have the technical reviewer confirm the output before treating the performance result as acceptable. A quick export that omits an image or a required identifier is not a successful task. Likewise, an application that opens a legacy file in a limited viewing mode may not support the intended analysis. The trial should record the function available, not simply whether the program displayed something without an error message.
Repeat a case only when there is a reason, such as an inconsistent result, configuration change or suspected dependency. Avoid turning the purchasing exercise into an open-ended benchmark project. The goal is enough evidence to choose a suitable supported environment. Once the agreed cases pass and meaningful concerns are resolved, retain the results and proceed with the procurement decision.
Evaluate memory and storage as workflow resources
Ask how the intended application uses memory and temporary storage for the chosen tasks. The supplier may identify relevant constraints, and the trial can reveal whether the candidate environment handles the representative package without unacceptable interruption. Do not calculate a universal memory requirement from file size alone. The relationship depends on the application, processing and objects loaded during the review.
Separate application installation space, active project storage and retained archives in the ownership plan. Include the organization's approved recovery copies and any working space required by the workflow. A computer may have enough nominal capacity at delivery while leaving little room for the first substantial project. Record the planning assumptions and the person responsible for managing storage growth rather than treating the advertised drive size as the complete answer.
Test the intended storage location. A sample opened from a local drive may behave differently from one accessed through the organization's network or approved external storage. Use the actual planned environment where feasible and record any limitation. The buyer should know whether a performance result depends on copying files locally first and whether that additional step fits the organization's record and access process.
Inspect displays and exported reports with the intended reviewer
Have the reviewer use the proposed display arrangement for the required tasks. Check that relevant views, labels and controls are accessible and that the workflow remains practical at the intended scaling and layout. Follow the application's applicable display requirements and the organization's review process. This article does not establish technical image evaluation criteria or approve a monitor for a regulated radiographic interpretation task.
Include external displays or docking equipment if they are part of the purchase. A laptop demonstration on the supplier's monitor does not establish the behavior of the buyer's planned setup. Record the tested arrangement and any required configuration. The objective is to avoid a workflow that becomes awkward or loses required interface elements when the delivered computer is connected in the way staff will actually use it.
Generate the agreed report and inspect the delivered representation. Templates, fonts, office applications and export components can affect presentation. A report that looks correct within the analysis program may differ after export or printing. The acceptance exercise should verify identifiers, figures and revision information in the actual output, with the technical reviewer deciding whether the result communicates the required evidence appropriately.
Verify licenses and permissions before final acceptance
Confirm the application edition and entitlement used during the trial. A supplier demonstration may use a broader license than the buyer plans to purchase. The accepted workstation should support the required functions under the actual entitlement, including any separate acquisition, analysis or reporting rights. Evident's WeldSight product information illustrates distinct acquisition and analysis functions that should be clarified in a quotation.
Ask IT and the supplier to resolve installation and operating permission requirements through the organization's approved process. Do not assume that granting every user administrator access is the correct response to a software dependency. The buyer needs an agreed supported deployment model. If the application requires conditions that conflict with the organization's normal environment, record the issue and obtain an authorized resolution before declaring the workstation ready.
Test the intended user role after installation. A program may work for the person who installed it while another user cannot reach a template, license or storage location. Use a controlled sample and the permissions planned for production. This check connects the purchasing evidence to the actual staff workflow without requiring access to unrelated confidential projects or changing the organization's policies during the demonstration.
Preserve legacy access without assuming full compatibility
Identify which historical datasets the organization must continue to use and what tasks they must support. Opening an older file for visualization can be different from enabling all current analysis functions. Ask the supplier for release-specific compatibility information and demonstrate the required legacy task. The purchase decision should not equate a successful file-open action with complete functional compatibility across every historical format.
Keep the earlier source evidence and approved software relationships identifiable. If the new environment requires conversion, document the conversion and its limitations, and retain the original according to the organization's requirements. Do not replace the only retained source file with an unreviewed converted version simply to make the new workstation convenient. The technical and records owners should decide what evidence must remain available.
Plan how a necessary legacy environment will be maintained through the organization's IT and support process. This guide does not recommend unsupported operating systems or indefinite use of obsolete software. The practical task is to identify the dependency, evaluate supported options and assign responsibility for a controlled transition. A new computer purchase should expose the issue rather than silently remove access to records the organization still needs.
Prepare for recovery and replacement
Ask whether the accepted environment can be recreated on a replacement computer through the approved support process. Identify the installation source, entitlement records, templates, configuration and data locations needed. The recovery plan should distinguish the application environment from the inspection archive. Reinstalling software does not restore missing source data, and restoring data does not guarantee that the required license or viewer is available.
Use an appropriate controlled recovery exercise when the workflow is important enough to justify it. The objective is to confirm the essential dependencies, not to disrupt the only production workstation. A spare or approved test environment can demonstrate that a representative package is usable after restoration. Record the evidence and any unresolved step so the organization knows what assistance would be needed during an actual equipment failure.
Assign ownership of later updates. Operating system, application, graphics and other changes may affect a supported configuration. The responsible IT and technical personnel should decide what review is proportionate to a proposed change. Retain the accepted trial cases as a reusable reference, so the team can check the affected functions without repeating unrelated purchasing work every time a routine update is considered.
Compare two hypothetical workstation offers
A fictional inspection company compares a portable computer with a higher advertised processor tier and a less expensive office workstation. Both meet the supplier's stated requirements for the intended application, but the field team needs portability while the office reviewer needs to handle the larger sample package. The company evaluates each against its actual role instead of declaring a single winner from the processor labels.
In the hypothetical trial, one computer opens the sample quickly but the planned user account cannot access the report template. The team records the file-opening task as successful and the reporting task as unresolved. IT and the supplier correct the deployment issue through the approved process, then repeat the affected case. This example shows why a computer's performance and its complete usable environment should be assessed together.
The final decision identifies the tested configuration, accepted tasks, software entitlement and support owner. The downloadable worksheet can hold those observations outside NDT Connect. The equipment tracker can reference the associated instrument and external acceptance record, but it does not benchmark computers, manage analysis licenses or store inspection datasets. The workstation purchase is ready when the intended users can perform the agreed tasks correctly in a supported, maintainable environment.
Frequently Asked Questions
Is the manufacturer’s minimum specification enough to choose a computer?
It establishes a starting support boundary, but evaluate the actual software release and representative workload before deciding whether the environment meets the team’s needs.
Does a fast file-open test prove an NDT workstation is ready?
No. Include the required review, reporting, permissions, license and data-access tasks, and verify their outputs.
Should an older release note be used as a current operating-system recommendation?
No. Use it as a versioned historical reference and obtain current support information for the software and environment you intend to deploy.
References & Standards Cited
- Eddyfi: UltraVision 3.12R27 release notes, August 2024, historical requirement example View source ↗
- Eddyfi: TubePro 6.1 release notes, December 2025 View source ↗
- Evident: WeldSight acquisition, analysis and compatibility information View source ↗
Related on NDT Connect
Join NDT Connect — free
The free marketplace for the NDT industry — connect inspectors and the companies that need them.
Free to join · Compare provider qualifications and confirm availability directly · Browse providers
By NDT Connect Editorial · Updated
Source-based editorial guidance. Read our editorial policy and disclosures.