驱动全频段扫描的问题

嗨Hlodwig，显然正在进行三段扫描，以避免81600B-201用于将扫描扩展到超过1475和1620nm的自动模式选择。
如果运行分段扫描所需的额外秒数非常关键，那么最好运行完全扫描并让程序忽略或纠正与模式选择相关的任何“毛刺”。
对于大多数应用来说，这种影响很小，特别是在使用记录的波长数据时，这总是一个好主意。
另一方面，使用分段扫描可以让您在激光较强的扫描的大中间部分使用更高的功率，这通常有利于激光性能（SMSR，SSE和稳定性）。
我没有在命令中看到这里设置了什么功率级别。
在任何情况下，当运行这样的段时，尝试使用sweep：flag没有真正的优势吗？
查询，用于在为多次扫描设置cycles参数时加速相同扫描的重复。
由于每次使用一个循环，因此使用查询SOUR0：WAV：SWE：STAT检查扫描完成是否足够？
这将需要循环以轮询激光直到完成。
其他一些建议： - 您可以将TLS触发输入模式置于忽略状态，以便在发送扫描启动命令时直接启动扫描。
这应该消除1s暂停。
但是如果你想用触发命令启动扫描，那么最好使用软触发命令，这样就不会同时触发功率计。
sour0：wav：sweep：soft - sens：funct：状态记录，应该在扫描启动命令之前发送启动命令，这样功率计就可以被触发了。
另请注意，功率计的平均时间不到250us。
它可以设置为200us。
也许这足以消除停顿的必要性。
否则我也不明白他们为什么需要它们。
但是在每个段的开始处将涉及一些开销时间，其中激光首先移动到起始位置，该起始位置总是略低于所选择的起始波长以允许加速。
- *真的*我强烈建议使用免费816x即插即用驱动器的MFlambdascan功能对扫描波长测量进行编程，这有助于处理这些触发细节，保持扫描参数如速度和平均时间一致，并简化上传
波长和功率的二进制数据。
一些小细节：两个命令SOURCE0：POWER：STATE 1和OUTPUT0：STATE 1可能做同样的事情，第二个可以删除。
我猜也是步骤1中的激光命令真的发送到Slot 1而不是Slot 0？
问候，迈克



     以下为原文

  Hi Hlodwig,
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
SOUR0:WAV:SWE:STAT?
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.
sour0:wav:sweep:soft
-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?


Regards,
Mike

嗨mkelly，谢谢你的帮助。
我会尝试使用816x驱动程序。
关于两个命令OUTPUT0：STATE和SOURCE0：POWER：STATE，程序员指南告诉第一个打开/关闭快门，第二个打开/关闭激光器。
这是一回事吗？
第二个命令是否可以关闭激光源以保护其寿命？
问候。
Hlodwig编辑：hlodwig于2012年8月28日10:04 AM



     以下为原文

  Hi mkelly,

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 ? 

Regards.
Hlodwig

Edited by: hlodwig on Aug 28, 2012 10:04 AM

嗨Hlodwig，在我看来，这两个命令的功能与这些可调谐激光器相同。
我认为这两种形式的命令不同于使用带有百叶窗和法布里 - 珀罗激光器的衰减器，这些激光器没有快门，只能用激光电流控制。
如果要在开始编程之前使用816x PnP驱动程序检查扫描性能，可以尝试使用N7700A IL引擎包。
该程序是一个免费的GUI，也使用PnP MFlambdascan功能。
最好的问候，迈克



     以下为原文

  Hi Hlodwig,
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.

Best regards,
Mike

嗨Hlodwig，这是否意味着您可以通过单次扫描使用全范围测量而不是分成3段？
那会很好。
驱动程序通过使用来自激光扫描的λ记录数据并通过考虑平均时间的持续时间内插每个样本的波长位置来协助这一点。
您可以使用更简单的“lambdascan”功能而不是“MFlambdascan”来完成测量。
但后者在设置参数（如功率范围）和选择功率计模块方面提供了一些额外的灵活性。
通常结果证明是有用的，所以我认为从一开始就用这种更灵活的功能设置程序是件好事。
我不知道在套接字连接上使用816x即插即用驱动程序有什么问题。
也许你有一个旧版本？
当前版本是4.4.1并且能够以这种方式运行MFlambdascan。
用于PnP驱动程序的N7700A IL GUI无法通过套接字连接识别仪器，但这不是驱动程序本身的问题，只是配置向导。
最好的问候，迈克



     以下为原文

  Hi Hlodwig,

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.

Best regards,
Mike

嗨mkelly，谢谢精确。
套接字连接的问题在于驱动程序等待直到每个查询的超时，就像从不识别字符一样。
我遇到VXI连接问题的原因是我需要与应用程序建立连接而不是真正的设备。
这是可能的，当我直接使用命令时，这只适用于套接字连接。
因此，如果我无法在套接字模式下使用驱动程序，我必须继续使用命令。
对于我的应用，全波段扫描中的“毛刺”真正影响，因此结果没有意义。
我可以想象纠正它们的唯一方法涉及准确性失败。
我在使用C＃制作的应用程序的早期版本中使用驱动程序时遇到问题。
准备扫描功能完成，扫描运行，但最后，应用程序崩溃。
调试告诉我崩溃发生在扫描结束时和lambda扫描函数结束之前，然后是驱动程序函数函数。
按照以下过程：hp816x_cmd（m_session，“TRIGGER：CONFIGURATION LOOPBACK”）;
hp816x_set_TLS_triggerConfiguration（m_session，sourceModule，0,2）;
// sourceModule = 1 hp816x_set_PWM_triggerConfiguration（m_session，senseModule，1,0）;
// senseModule = 2 hp816x_prepareLambdaScan（m_session，0,6,0,0,1,1525,1600,0.01，ref m_nbPoints，ref nbChan）;
hp816x_executeLambdaScan（m_session，ref wavelength_array，ref power_array，0,0,0,0,0,0）;
使用的配置是8163B，配备插槽1中的81940A源和插槽2中的81636B功率计。您对这次崩溃了解吗？
我是否滥用驱动程序或配置错误？



     以下为原文

  Hi mkelly,

Thanks for precisions.

The problem with the socket connexion is that the driver wait untill the timeout for each query, like it never identify the  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 :

hp816x_cmd(m_session, "TRIGGER:CONFIGURATION LOOPBACK");

hp816x_set_TLS_triggerConfiguration(m_session, sourceModule, 0, 2);    //    sourceModule = 1

hp816x_set_PWM_triggerConfiguration(m_session, senseModule, 1, 0);    //    senseModule = 2

hp816x_prepareLambdaScan(m_session, 0, 6, 0, 0, 1, 1525, 1600, 0.01, ref m_nbPoints, ref nbChan);

hp816x_executeLambdaScan(m_session, ref wavelength_array, ref power_array, 0, 0, 0, 0, 0, 0, 0);

The configuration used is a 8163B equiped by a 81940A source in slot 1 and a 81636B powermeter in slot 2. Have you an idea about this crash ? Am I misusing the driver or making a bad configuration ?

您好Hlodwig，你检查了你正在使用的816x驱动程序的版本吗？
在4.2之后有一个更改来支持套接字连接，它现在应该可以正常使用当前的4.4.1版本。
有时我看到它在程序第一次启动时超时，好像第一次连接时间花了更长时间，但是第二次启动程序没问题。
在下面显示的程序位中，我想在执行命令中的大多数参数发送'0'时会出现问题，即使这些通道未被使用，也需要数组。
MFlambdascan例程也更灵活。
您也不需要配置触发器的命令，因为这是由prepare lambdascan函数处理的。
但我不认为这会导致问题。



     以下为原文

  Hi Hlodwig,
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.

嗨mkelly，感谢以前的帮助，我现在使用套接字模式的驱动程序（版本4.4.1）。
但似乎不可靠。
当扫描生成超过79 200个数据点时，函数hp816x_executeMfLambdaScan会抛出分段故障异常，但功率计支持直到100 000个数据点。
有时，当我处理一个更小的扫描时，它对于某些扫描正常工作，并且突然，驱动程序返回错误，指示日志记录不准确，并且参数没有任何变化。
这些不合时宜的错误对我来说确实是一个问题，因为我的程序必须尽可能可靠。
我也想知道扫描程序。
我使用驱动器以80 nm / s扫描170 nm边缘带，但每次扫描需要12秒。
我猜驾驶员做的事情不仅仅是扫描，而是比扫描的2.5理论秒更多的时间。
这不是减少这段时间的方法，例如避免对我没用的步骤吗？
提前致谢。
看待。
Hlodwig



     以下为原文

  Hi mkelly,

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 ?

Thanks in advance.
Regard.
Hlodwig

要迁移，sourceId：104189



     以下为原文

  to be migrated, sourceId: 104189

嗨mkelly，在情况下，步长决定了我的应用程序的准确性，所以越小越好。
所以我试图禁用等距数据。
但这并不能避免这个问题：记录错误有时会附加，现在有毛刺。
关于dataPoint的数量，我试图使用VXI连接，但没有改变任何东西。
我会尝试使用PFL来减少扫描时间。
最好的方法是使用与使用命令的方法相同的扫描时间，这只需要6秒，并避免毛刺。
问候。
Hlodwig



     以下为原文

  Hi mkelly,

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.

Regards.
Hlodwig

嗨mkelly，我现在使用PFL的fastSweep功能来驱动仪器，这会产生很好的效果。
扫描时间不超过9秒，并且不存在记录数据点数量的问题。
但这会让人回到最初的问题：毛刺。
为此，我会尝试以另一种方式避免它们。
PFL文档说明了fastScan的功能，激光源每4000个循环进行一次润滑循环。
我有两个问题：只有在使用PFL时才进行润滑循环，还是有其他方法可以做到这一点？
我知道仪器的寿命是几小时，但循环次数的寿命如何？
问候。
Hlodwig



     以下为原文

  Hi mkelly,

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 ?

Regards.
Hlodwig

还有一点指向PnP驱动程序中使用MFlambdascan的数据点数量的早期问题。
我查了一下，这不是司机的限制。
我想这是由于编程环境中默认数组大小的限制而发生的。
需要为MFlambdascan和PFL_FastSweep例程分配所需大小的波长和功率阵列。
由于你没有PFL的问题，你必须正确地这样做。
我在使用MFlambdascan时看到的唯一区别是，数组与两个命令一起传递：executeMFLambdScan getLambdaScanResult，而在FastSweep例程的相应命令中：doFastSweep getFastSweepResult只有第二个命令传递数组。



     以下为原文

  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:
executeMFLambdScan
getLambdaScanResult

while in the corresponding commands of the FastSweep routine:
doFastSweep
getFastSweepResult

only the second command passes arrays.

嗨mkelly，我配置了环境变量，就是这样！
我现在只需要扫描所需的时间：整个波段的10秒以内的时间，以及毛刺的校正。
还有一些罕见的毛刺（下午50点）随机出现。
为了测试，我在几天内尝试了连续扫描。
并且，在开始后2天，我有一个关于触发的内部错误：816x：驱动程序interbal错误;
未能重新触发扫描1错误号-1073807360您是否知道导致此错误的原因以及我该怎么做才能再次使用它？
问候。
Hlodwig



     以下为原文

  Hi mkelly,

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 ?

Regards.
Hlodwig

嗨Hlodwig，很好，它的工作方式就是你想要的。
很难说出导致错误消息的原因，但这应该意味着该程序无法触发成功扫描。
如果你连续几天运行可能是一个好主意的偶尔（可能每天一次）从你的程序运行lambda归零校准。
这可以通过PnP功能来完成：hp816x_TLS_zeroing这有助于防止激光在扫描期间在预期波长和测量波长之间累积偏移。
当激光器的温度漂移超过4度时，这是自动完成的，但是在稳定的环境和可能不会发生的预热系统中，然后可以由您的程序明确地调出。
在此之前，FastSweep应该关闭，然后再做好准备。
偶尔的故障可能仍然是由于模式跳跃，因为与指定的模式跳跃自由扫描范围相比，您的扫描相当长。
感谢更新。
麦克风



     以下为原文

  Hi Hlodwig,

Good that it's working the way you want this way.
It's hard to tell what caused the error message, but it should mean that the program was not able to trigger a successful sweep.
Something that might be a good idea if you are running for days consecutively is to occasionally (maybe once per day) run a lambda zeroing calibration from your program. That can be done with the PnP function: hp816x_TLS_zeroing
That can help to keep the laser from accumulating offset between the intended wavelength and the measured wavelength during sweeps. This is done automatically when the temperature of the laser has drifted more that 4 degrees, but in a stable environment and warmed-up system that might not occur and it can be then called out by your program explicitly.
Before that the FastSweep should be closed and then prepared again afterwards.
The occasional glitches may still be due to mode-hops, since your sweeps are pretty long compared to the specified mode-hop free sweep range.

Thanks for the update.
Mike