I have a signal continuously sweeping at 25ms. I would like to read a marker after every sweep. What command can I use to know when the sweep is complete so that I may read the marker? Is it possible to get a timestamp from the PNA-X when the data is read? Thanks.
1. Take the PNA out of continuous sweep. Then simply trigger a sweep, wait for it to complete, read the marker and repeat as necessary.
2. Leave the PNA in continuous sweep and use events (or SRQ) to detect the end of sweep. Then read the marker and wait for the next event.
The problem with approach number 2 is that 25ms is fairly short and if you cannot complete everything before the next sweep, you could miss a sweep. Depending upon your needs, this may or may not be an issue.
The approach #2 seems great, but can you please help with SCPI configuration of event registers and SRQ at the analyzer side for catching it at the controller side?
Unfortunately, for me the explanation in the manual is not that obvious and I am trying to understand it for quite some time ...I just want to get that SRQ exactly when sweep (or measurement, actually, I measure S21) has finished the last point and gone to start again.
I have to say that using the SRQ method is usually not best way to handle this. Besides, it make programming much more complicated. The SRQ method is used mostly when the computer must be processing other data while waiting for the PNA to finish acquiring data. If this is not the case, then placing the PNA in single sweep mode is the most reliable way to ensure you are getting the proper data. We highly recommend doing it this way unless there are extenuating circumstances. Let me know the specifics of what you want to do, and we can go from there.
As far as I know, SRQ method allows 4 important things, besides parallel processing, of course, which is available using vi event-based function calls.
1) The controller is free for work with other GPIB devices. This improves performance of the supervising software as well, reducing delays and CPU load. Especially when using procedural programming.
2) The device issuing SRQ is free from STB polling spam from controller side.
3) This method allows NOT to kill parallel measurements execution option of the NA with *WAI. While *WAI and *OPC are easy to use, those are regressive approaches.
4) (which is a part of #3) This is just a very fast method for real-time data synch.
So, my question is still the same: how can I enable SRQ on sweep finish or measurement finish? The register map in the manual is quite complex, but the explanation is not very informative for people new to the architecture. Moreover, I found profanation in program samples explaining SRQ. I mean that fake program, which makes STB serial poll in the loop, instead of responding to SRQ.
If I had a good example, I would have posted it. I will have to search around for one, however, for the next two weeks we have people from all over the world here for training and I cannot guarantee a timely response. I do agree that we do not have any good examples of this....and we really should.
I have done what Akalei is asking about using DCOM.
I registered an callback for 'OnChannelEvent'. Once in the callback code, I filter events to only run the data-pull code if the event is ALL_SWEEPS_COMPLETED_AND_PROCESSED
I noticed a few things however:
I originally used the CHANNEL_SWEEP_COMPLETE event as my filter, but it wasn't always working correctly. That's why I switched to the other event.
I needed a minimum of 2 Channels (measurements) running, even if it was the same measurement twice. Otherwise it seemed like the data was being overwritten before I could pull it off the PNA.
Third, I had a problem with IArrayTrasfergetComplex (details can be found in other threads with my name). It boiled down to the data pointer for the wrapper function being for a single floating point variable instead of an array of floats.
I cannot post complete code, but I can help somewhat if you decide to try DCOM.
If you are going to remain in continuous sweep, then you better make sure that you read whatever data you want before the next sweep starts. If you delay too long, then the data you read may be stale. One way to give yourself more time is to add a first point delay if necessary.
Also, providing us with the programming language you are using may be helpful.
Tom's example does not exactly represent the Asynchronous sweep model. the Async use case by definition requires the client application to be multi-threaded and the above example operates on a single thread. I took the liberty of modifying it a little bit.
when you set the trigger to manual and use and INIT:IMM then you are essentially doing a single sweep. in the changed example, you will notice that the channel is in continuous sweep and a separate thread monitors the spoll results and uses a couple of global variables as thread synchronization.