Importance of Standardized State Files in Production Based Environments
- connorpaine038
- Jul 15
- 2 min read
In any sizable production based environment, there’s usually more than one RF test station and that station usually has a dedicated VNA. For low mix high volume labs, incoming product is almost always slated to run on more than one station since there’s quite a handful (sometimes hundreds) of units per lot/purchase order.
Each VNA has a dedicated state file (sometimes a set of state files) to test that specific part number and the difficulty of managing these state files scales especially when:
1. Each state file is saved locally on the VNA drive
2. The VNA’s aren’t connected to a local network therefore restricting access to the state files unless physically in front of the analyzer
3. The state file is out dated or there are unmanaged duplicates (RevA, RevB, Rev_Final, I’ve seen it all)
4. There are multiple VNAs and drives to manage
5. Folder rights aren’t managed - meaning anyone can change a state file parameter either by accident or on purpose
6. The VNA state file folder itself is unmanaged and includes production state files and engineering state files
This is a big problem for many reasons, but to describe it in one sentence - the same part number was not tested with the same parameters and both of those units are slated to ship. So, how do you prevent this problem and lock in state file management?
1. Save the VNA state files on a network drive and recall the state file from that network drive. VNA state files should not be stored locally if possible. Even better if you can call the same, singular state file from any VNA.
2. Lock down the folder the VNA’s state files are stored in via some administrative rights. This can be difficult with older VNAs but newer VNAs from 2010 to present should be able to handle it.
3. If the state file is old, search for the customer test specification or contact them directly for clarification on the parameters per the contract. Might take them a while to find it if the program is old but they’re more than happy to help most of the time especially if it means getting reliable data for their product.
4. Separate engineering and production state files. They shouldn’t be in the same folder.
5. Create a file management system for these state files (signoffs, naming conventions, parameter sheets). Just document the hell out of your state files.
6. Parameter checks either on a monthly or bi-weekly cadence at minimum.
Even if you do just 1 out of 6 of the above suggestions, your lab and data acquisition/analysis will be much more accurate and less painful from a quality and production perspective.




Comments