Thank you for purchasing the new 53210A counter. I’m sorry the instrument is not cooperating.
There are 53210A commands that are sequence dependent; however, in the code you provided there are no such dependencies. I executed the commands in your sequence and queried the trigger source. ‘BUS was returned as expected. Sending TRIG:SOUR BUS immediately after CALC:STATE:OFF also returned the correct source:
-> *rst;:calc:state off;:trig:sour bus;:trig:sour? <- BUS
Regarding the “trigger ignored” error, the 53210A must be set to the ‘wait-for-trigger state’ before triggers are accepted. The INITiate:Immediate command does this. The commands you used to configure the counter occur while the counter is in its ‘idle state’. Sending INIT moves the counter to the ‘wait-for-trigger’ state. When a trigger is received the counter is now in the ‘triggered’ state. When the signal from the specified gate source is received, the measurement is taken.
I am concerned that the Reset function on occasion is not able to reset the counter. Can you provide more information on what is occurring before and after the reset is issued?
You mentioned writing a DLL for the 53132A counter. Were you aware of the compatibility mode feature of the 53210A? The 53200A series counters will eventually replace the 531xxA counters. To help in the migration to the new counters, the 53200A models are compatible with the 531xxA models as follows:
53210A 53181A 53220A 53131A 53230A 53132A
In compatibility mode the 53200A series counter can execute the commands of its corresponding 531xxA counter. This allows the 53200A counters to be integrated into systems currently containing 531xxA counters and leverage existing code.
with the string ""INP:PROB 1;IMP 50;COUP AC;SLOP POS;NREJ ON;LEV:ABS 1.000e-001;:INP:FILT:LPASS:STATE OFF" I dont get an error.
The measurement is started with "*TRG;DATA:REM? 1, WAIT" then I get the frequency with ibrd(...) but it only works for the first time. When I again send the command "*TRG;DATA:REM? 1, WAIT" I get -230, "Data corrupt or stale"
What is wrong here?
But I would like it mutch more when I could use ibtrg() and then the counter makes a measurement and when done sets the SRQ and then I can read the frequency.
Why I want this: On our CrystalTuners after fixing and contacting the crystal two threads are started, the first one measures the frequency of the crystal and the second is the machine vision which searches the tuning space on the crystal. So when I sent the GET (ibtrg()) then the counter starts measuring and the measure thread sleeps on WaitForSingleObject (srq) so the machine vision thread can run at least for gatetime milliseconds. Normally the machine vision thread is finished before the SRQ from the counter so we save a lot time (We produce 2'000'000 Crystals per day so 2.0e6 * 40e-3 = 80000 seconds).
As a little motivation boost for you, we have about 50 53181A counters and more than 500 53132A counter in our fab
I am not sure why the trigger source query is returning the wrong source unless a reset or preset is occurring somewhere.
As you discovered, you do not get an error with the string:
INP:PROB 1;IMP 50;COUP AC;SLOP POS;NREJ ON;LEV:ABS 1.000e-001;:INP:FILT:LPASS:STATE OFF
The reason is the command key words: PROB, IMP, COUP, SLOP, NREJ, LEV, and FILT are peers (i.e. at the same command hierarchy level). This means each is directly under the root keyword INP and are separated by a semicolon (;). The undefined header error was caused by the ‘FILT:LPASS:STAT OFF’ command because in the previous command the keywords LEV:ABS were specified. FILT is a peer of LEV and not ABS (a lower level). Therefore the “FILT” command must start at the root and be separated from the previous command by ;: (i.e. ;:INP:FILT:LPASS:STATE OFF).
If ABS had not been specified, your original string would have executed without error.
TRG;DATA:REM? 1, WAIT generates error -230, “Data corrupt or stale” the second time it is executed because there is no data to retrieve. The counter was not re-initiated after the first reading was taken, thus the trigger (TRG) was ignored. Sending a trigger will not start an actual measurement unless the counter is previously initiated by sending INITiate:IMMediate or the trigger count is set to a value > 1 (assuming the gate source is IMMediate). The attached figure from the 53210A user guide illustrates this:
For trigger counts > 1, the counter will remain in the ‘wait for trigger state’ until the specified number of triggers have been accepted. The counter does not have to be re-initiated prior to each trigger in the trigger count.
To have the counter generate an SRQ when the reading is complete a process similar to the following can be used:
CONF:FREQ // configure measurement TRIG:SOUR <source> // set the trigger source TRIG:COUN <count> // set the trigger count: 1 or ‘n’ number of readings DATA:POINts:EVENt:THReshold <count> // set the reading threshold to generate SRQ: same as trigger count STATus:OPERation:ENABle 4096 // unmask reading threshold bit (12) in standard operation register *SRE 128 // unmask standard operation summary bit (7) in status byte register INIT // initiate counter TRG // trigger the counter SPOLL // poll the status byte for reading threshold reached FETC? // fetch (read) the reading(s) from the output buffer STATus:OPERation:EVENt // read the event register to clear bit 12 for the next threshold event
TRG // trigger the counter SPOLL FETC? //fetch the next reading or set of readings STATus:OPERation:EVENt // read event register to clear bit
When sending the programming strings to the counter, before sending the display command strings "DISP:WIND:STAT ON" or "DISP:WIND:STAT OFF" I have to do a Sleep (500)! Without this Sleep() the counter is dead! Only switching off and on brings it back to life.