In the absence of the source code, if you want to understand the specific protocol between the program and the device that communicates through the gps, the following method can be used to infer the specific protocol by analysing the communication process。
Method 1: use gpib to monitor communication hardware connections
Use the existing gpib card to install it into the second computer and connect it to the gpib bus. Ensure that the connection on the gpib bus is correct, i. E. That the second computer can be involved in the communication at the same time through a branch or repeater。
Configure listening devices
Sets the gpib card to the listener mode to ensure that it does not proactively send data. Use software (e. G. Ni max or labview) to initialize gpib cards and set them to passive listening status。
Capture communication data
In ni max, select the gpib device and use its own debugging tool to monitor the traffic stream. Or use labview to create a simple program to read bus data continuously through gpib read vi。
Recording of communications
Record commands and responses captured and analyse communication content formats such as:
Whether to use scpi (standard instrument command). Data structure (e. G. Command keywords, parameter separator). Returns data type (e. G. String, binary data)。
Method 2: hardware requirements using logical analyser or protocol tools
Use a logical analyser or a dedicated gps protocol analysis tool (e. G. Keysight 16850). Connect analysers to gpib bus, capture signals on data lines (dio1-dio8) and control lines (atn, dav, etc.)。
Capture communication
Sets the trigger condition (e. G. Atn line low level indicates a command sent). Commence collection of communication data and keep it as a document。
Protocol parsing
The data collected are analysed using protocol analysis tools. Analyses the command format, the package structure and the format of the returned data。
Method 3: an experiment to speculate that if the data heard by the inspectors cannot be fully interpreted, an attempt can be made to send the order manually, and the observation device will respond:
Preliminary guess type of agreement
Check the equipment manual or related document to see if it supports scpi or other standard protocols. If there is no clear document, try sending some common commands:
Query device identifier: *idn?
Experimental command sent
Use the second computer to send captured commands through the gpib card and labview writer to confirm that the equipment response is consistent. If format cannot be confirmed, gradually modify the command content (e. G. Changing parameters or command keywords), the return value of the observation device。
Iterations
Test all possible features of the device on a case-by-case basis, record the corresponding commands and responses, and build up a complete protocol document。
Method 4: data analysis in a combination of catch and reverse reasoning
Use method 1 or method 2 to capture complete communication data. The mechanism of operation of the agreement is presumed on the basis of known communication logic (e. G. Initialization, reading and writing parameters, closure operations, etc.)。
Reverse reasoning
Based on the equipment response content and command model, a set of hypothetical protocols is developed. Verify if the agreement is correct and adjust the order format。
Attention to avoid conflict
Make sure the second computer's gps card doesn't interfere with the main computer's communications. While listening, keep the mainframe still being coNtrol in charge. Compatibility issues
Some equipment may use a manufacturer-defined agreement and may require additional experiments to fully extrapolate the agreement. Legal compliance
If the equipment agreement is protected by copyright or patent, ensure that it is operated in accordance with local legal requirements。
Through the above method, communication protocols for equipment can be developed to provide a reference for subsequent development or maintenance。
