When result >= 2 :
SENSE1:CHANNEL1:FUNCTION:RESULT:BLOC? 0 ,18000
pause 3 seconds
And after that, going to the step 3 for the next section. When all sections are scanned, a new sweep is done (step 2).
That works, but the problem is that take a long time. As you can see, I have to force the program to takes pauses in the procedure for every section, else there is a problem with the flag. If the pauses are not respected, the flag starts at 0, increments to 1 and never increments again and the program waits infinitely.
Is there something wrong on the procedure ? Or is this a physical constraint I can't avoid ?
Running the sweep in three segments is apparently being done to avoid the automatic mode-selection that the 81600B-201 uses to extend the sweeps beyond 1475 and 1620nm. If the additional seconds needed to run the segmented sweep are critical, then it might be better to run the full sweep and have your program ignore or correct any "glitches" related to the mode-selection. This impact is small for most applications, especially when using the logged wavelength data as is always a good idea. On the other hand, using the segmented sweep does allow you to use higher power for the large middle part of the sweep where the laser is stronger, which is generally good for laser performance (SMSR, SSE, and stability). I don't see in the commands what power level is being set here.
In any case, when running the segments like this, there is no real advantage to trying to use the sweep:flag? query, which is intended to speed repetitions of identical sweeps when the cycles parameter is set for multiple sweeps. Since you are using a single cycle each time, it will be enough to check for sweep completion with the query
This will need to be in a loop to poll the laser until finished.
Some other suggestions:
-You could leave the TLS trigger input mode on ignore, so that the sweep would be started directly when you send the sweep start command. That should eliminate the 1s pause. But if you want to start the sweeps with a trigger command then it would be better to use the soft trigger command so that the power meter is not triggered at the same time.
-The sens:funct:state logging,start command should be sent before the sweep start command, so that the power meter is ready to be triggered. Note also that the power meter does not have a 250us averaging time available. It could be set to 200us here.
Maybe that is enough to eliminate the need for the pauses. Otherwise I also don't see why they are needed. But there will be some overhead time involved at the start of each segment, where the laser moves first to the starting position, which is always somewhat lower than the chosen start wavelength to allow for acceleration.
-*Really* I would strongly recommend to program the swept-wavelength measurements using the MFlambdascan functions of the free 816x Plug&Play driver, which help to handle these triggering details, keep the sweep parameters like speed and averaging time consistent and simplify uploading the binary data for wavelength and power.
A couple of minor details: the two commands SOURCE0:POWER:STATE 1 and OUTPUT0:STATE 1 are probably doing the same thing and the 2nd one can be removed. I guess also that the laser command in step 1 is really sent to Slot 1 and not Slot 0?
Thanks for your help. I'll try to use the 816x driver.
About the two commands OUTPUT0:STATE and SOURCE0:POWER:STATE, the programmer's guide tells that the first open/close the shutter and the second switches on/off the laser.
Is it the same thing ? Doesn't the second command alow to power down the laser source to protect its life span ?
It looks to me like the function of the two commands is identical with these tunable lasers. I think the two forms of commands originated separately from use in attenuators with shutters and Fabry-Perot lasers that do not have shutters but are controlled only with the laser current.
If you want to check the performance of sweeps using the 816x PnP driver before you start to program with it, you could try using the N7700A IL engine package. This program is a free GUI that also uses the PnP MFlambdascan functions.
This driver appears respond to my problem of glitches.
I test it with the lambdascan function. I don't understand why should I use MFLambdascan function. This function is to the Multi-frame systems, and I use only one frame, equiped by one TLS and one powermeter. Do the MFLambdasan function offer something more than simple lambdascan function when it is used for a single frame ?
But it seems that the 816x Pnp driver don't supports the socket mode connexion. This is a problem for me because, to communicate with another application, I need a socket connexion (with an adress like TCPIP0::xxx.xxx.xxx.xxx::5025::SOCKET). Moreover, a Socket connexion is told faster by the manual. Is there a driver like the 816x Pnp which supports it ?
Does that mean you are able to use the measurements made over your full range with a single scan instead of broken into 3 segments? That would be good. The driver is assisting this by using the lambda logging data from the laser sweep and by interpolating the wavelengh position of each sample considering the duration of the averaging time.
You are right that the measurements can be done with the simpler "lambdascan" function instead of the "MFlambdascan". But the latter offers some additional flexibility in setting parameters, like power ranges, and selecting power meter modules. Often that turns out to be useful so I think it is good to set up the program with this more flexible functionality from the start.
I'm not aware of an issue using the 816x Plug&Play driver over a sockets connection. Maybe you have an older version? The current version is 4.4.1 and is able to run the MFlambdascan this way.
The N7700A IL GUI for the PnP driver does not recognize instruments over the sockets connection, but that is not an issue of the driver itself, just the Configuration Wizard.
The problem with the socket connexion is that the driver wait untill the timeout for each query, like it never identify the <END> character.
The reason of my problem with the VXI connexion is that I need to establish a connexion with an application instead of a real equipment. This is possible, and that works, only with a socket connexion, when I use directly the commands. So, if I can't use the driver in socket mode, I have to continue to use the commands.
For my application, the "glitches" in a full band sweep are realy impacting, so that the results not make sense. The only way I can imagine to correct them involves accuracy looses.
I have a problem to use the driver in a previous version of the application, made in C#. The prepare sweep function is done, the sweep runs, but at the end of it, the application crashs. The debug tell me that the crash occurs at the end of the scan and before the lambda scan function ends, then in the driver function function. Following the process :
Did you check the version of 816x driver that you are using? There was a change after 4.2 to support the sockets connection and it should work ok now with the current 4.4.1 version. Sometimes I've seen it time out when the program is first started, as if the first connection time took longer, but then starting the program a second time was ok.
In the program bit that you show below, I guess there is an issue with sending '0' for most of the parameters in the execute command, where arrays are expected, even if these channels are not in use. This point is also more flexible with the MFlambdascan routines. You would also not need the commands that are configuring the triggers, since this is handled by the prepare lambdascan function. But I don't expect that this is causing a problem.
Thanks for previously helping, I use now the driver in socket mode (ver 4.4.1).
But it seems unreliable. When the sweep generates over 79 200 datapoints, the function hp816x_executeMfLambdaScan throw a segmentation fault exception, however the powermeter supports until 100 000 datapoints. And sometimes, when I process a more little sweep, it works normaly for some sweeps and suddenly, the driver return the error that indicates the logging is not exact enougth, without any change in parameters.
These inoportune errors are realy a problem for me because my program have to be as reliable as possible.
I also wonder about the scan procedure. I use the driver to sweep a 170 nm edge band, at 80 nm/s but each sweep takes over 12 second. I guess the driver does more things than only scanning, but 10 more second than the 2.5 theoric seconds of scan is very much. Is it not a way to reduce this time, for example avoiding the steps which are not usefull for me ?
Probably the driver error referring to logging accuracy is happening when very small steps are used and maybe caused at the mode-selection points in the long scans, referred to above. In some cases this causes problems for the interpolation routines used to return the data with equally spaced wavelength values.
The message probably suggests increasing the step size and that might be an option. Or if you don't want to change that you could try just disabling the interpolation and then the lambda-logging values are returned as measured.
You can use the driver command:
hp816x_returnEquidistantData(ViSession ihandle, ViBoolean equallySpacedDatapoints);
to disable this.
The MFlambdascan functions do have some overhead time, because the scan is set up each time, and of course the laser has to return to the starting point as well. If you are trying to reduce the time for repeating identical sweeps, then the next level for your equipment setup could be reached by using the FastSweep function in the N4150A PFL software library. N4150A PFL link
This uses some advanced programming for faster repetition including uploading the data during the back-sweeps and setting the next sweep to be started with a single software trigger. Depending on the amount of data points and the speed of the transfer, this can be used to do repetitions with very little time that the laser is not tuning.
On the other point, I don't have any information at present about why the number of points allowed is smaller with the sockets connection, but there is some additional complication in controlling the length of binary data transmission this way, and this was not originally a feature when the 8164B was designed.
In situation, the step size determines the accuracy of my application, so the smaller the better. So I tried to disable the equidistant data. But that not avoid the problem : the logging error conitnue to append sometimes and there are now glitches.
About the number of dataPoint, I tried to use the VXI connection but that not changed anything.
I'll try to use the PFL to reduce the sweep time. The best would be to have the same sweep time as the method using commands, which take only 6 seconds, and avoiding the glitches.
I use now the fastSweep funcitons of the PFL to drive the instrument and that gives good results. The sweep time don't exceed 9 seconds and there is no more problems of logging of number of datapoints.
But that makes go back the initial problem : the glitches. For that, I'll try to avoid them by another way.
The PFL documentation tell that whith the fastScan functions, the laser source does a lubrication cycle each 4000 cycles. I have two question about that :
Is the lubraction cycle performed only when using the PFL or there is another way to do it ?
And I know the instrument's life span is hours, but how is the life span in number of cycles ?
Thanks for the update.
For using the PFL fastsweep like you are doing, there is a setting available that may help deal with your "glitches".
These are apparently do to the mode-selection points in the long sweeps and were apparently being handled nicely by the lambdascan functions, which use the lambda-logging data.
The PFL fastsweep routines also use the lambda-logging data, but in order to increase the repetition rate, they are uploaded only every 100 sweeps by default. This is acceptable for many applications where only repeatable wavelength variations need to be used, but the mode steps are apparently not so repeatable.
So you can set an environmental variable so that the lambdascan data is read with every sweep. Since you are looking for accuracy at the pm level, I recommend to use this setting.
You will need to create a Windows environmental variable with the name
and give it the value 1 (rather than the default 100).
In Win XP that looks like this:
The "lubrication sweep" is a special process in the PFL fastsweep since that was designed for letting the laser repeat scans continuously. But you can accomplish the same thing by periodically having the laser sweep over its maximum range. This is of most value when the laser is always scanning the same short range and helps to keep the laser scanning smoothly over the full range. In your case you seem to be using about the full range anyway, Note that the automatic wavelength zeroing ("settling") process also serves a similar purpose.
One more point to the earlier issue with the number of data points using MFlambdascan in the PnP driver.
I checked and this is not a limitation of the driver. I guess this was happening due to a limitation of the default array size in the programming environment.
The arrays for wavelength and power need to be allocated with the required size for both the MFlambdascan and the PFL_FastSweep routines.
Since you don't have the problem with PFL, you must be doing this correctly.
The only difference about this that I see when using MFlambdascan is that arrays are passed with both the commands:
while in the corresponding commands of the FastSweep routine:
I configured the environmental variable and this is it! I have now all I need to the sweep : a time under 10 seconds on the whole wavelength band, and a correction of the glitches. There is still some rare glitches (50 pm) whitch appeared randomly.
For test, I've tryed a continuous sweep during a few days. And, 2 days after the begining, I had an internal error about the triggering :
816x : driver interbal error; failed to retrigger sweep 1
Error number -1073807360
Do you know what caused this error and what can I do to doesn't have it again ?