Ошибка кластера что это

From Wikipedia, the free encyclopedia

Clustered standard errors (or Liang-Zeger standard errors)^[1] are measurements that estimate the standard error of a regression parameter in settings where observations may be subdivided into smaller-sized groups («clusters») and where the sampling and/or treatment assignment is correlated within each group.^[2][3] Clustered standard errors are widely used in a variety of applied econometric settings, including difference-in-differences^[4] or experiments.^[5]

Analogous to how Huber-White standard errors are consistent in the presence of heteroscedasticity and Newey–West standard errors are consistent in the presence of accurately-modeled autocorrelation, clustered standard errors are consistent in the presence of cluster-based sampling or treatment assignment. Clustered standard errors are often justified by possible correlation in modeling residuals within each cluster; while recent work suggests that this is not the precise justification behind clustering,^[6] it may be pedagogically useful.

Intuitive motivation[edit]

Clustered standard errors are often useful when treatment is assigned at the level of a cluster instead of at the individual level. For example, suppose that an educational researcher wants to discover whether a new teaching technique improves student test scores. She therefore assigns teachers in «treated» classrooms to try this new technique, while leaving «control» classrooms unaffected. When analyzing her results, she may want to keep the data at the student level (for example, to control for student-level observable characteristics). However, when estimating the standard error or confidence interval of her statistical model, she realizes that classical or even heteroscedasticity-robust standard errors are inappropriate because student test scores within each class are not independently distributed. Instead, students in classes with better teachers have especially high test scores (regardless of whether they receive the experimental treatment) while students in classes with worse teachers have especially low test scores. The researcher can cluster her standard errors at the level of a classroom to account for this aspect of her experiment.^[7]

While this example is very specific, similar issues arise in a wide variety of settings. For example, in many panel data settings (such as difference-in-differences) clustering often offers a simple and effective way to account for non-independence between periods within each unit (sometimes referred to as «autocorrelation in residuals»).^[4] Another common and logically distinct justification for clustering arises when a full population cannot be randomly sampled, and so instead clusters are sampled and then units are randomized within cluster. In this case, clustered standard errors account for the uncertainty driven by the fact that the researcher does not observe large parts of the population of interest.^[8]

Mathematical motivation[edit]

A useful mathematical illustration comes from the case of one-way clustering in an ordinary least squares (OLS) model. Consider a simple model with N observations that are subdivided in C clusters. Let be an vector of outcomes, a matrix of covariates, an vector of unknown parameters, and an vector of unexplained residuals:

As is standard with OLS models, we minimize the sum of squared residuals to get an estimate :

From there, we can derive the classic «sandwich» estimator:

Denoting yields a potentially more familiar form

While one can develop a plug-in estimator by defining and letting , this completely flexible estimator will not converge to as . Given the assumptions that a practitioner deems as reasonable, different types of standard errors solve this problem in different ways. For example, classic homoskedastic standard errors assume that is diagonal with identical elements , which simplifies the expression for . Huber-White standard errors assume is diagonal but that the diagonal value varies, while other types of standard errors (e.g. Newey–West, Moulton SEs, Conley spatial SEs) make other restrictions on the form of this matrix to reduce the number of parameters that the practitioner needs to estimate.

Clustered standard errors assume that is block-diagonal according to the clusters in the sample, with unrestricted values in each block but zeros elsewhere. In this case, one can define and as the within-block analogues of and and derive the following mathematical fact:

By constructing plug-in matrices , one can form an estimator for that is consistent as the number of clusters becomes large. While no specific number of clusters is statistically proven to be sufficient, practitioners often cite a number in the range of 30-50 and are comfortable using clustered standard errors when the number of clusters exceeds that threshold.

Further reading[edit]

• Alberto Abadie, Susan Athey, Guido W Imbens, and Jeffrey M Wooldridge. 2022. «When Should You Adjust Standard Errors for Clustering?» Quarterly Journal of Economics.

References[edit]

Clustered standard errors (or Liang-Zeger standard errors)^[1] are measurements that estimate the standard error of a regression parameter in settings where observations may be subdivided into smaller-sized groups («clusters») and where the sampling and/or treatment assignment is correlated within each group.^[2][3] Clustered standard errors are widely used in a variety of applied econometric settings, including difference-in-differences^[4] or experiments.^[5]

Analogous to how Huber-White standard errors are consistent in the presence of heteroscedasticity and Newey–West standard errors are consistent in the presence of accurately-modeled autocorrelation, clustered standard errors are consistent in the presence of cluster-based sampling or treatment assignment. Clustered standard errors are often justified by possible correlation in modeling residuals within each cluster; while recent work suggests that this is not the precise justification behind clustering,^[6] it may be pedagogically useful.

Intuitive motivation[edit]

Clustered standard errors are often useful when treatment is assigned at the level of a cluster instead of at the individual level. For example, suppose that an educational researcher wants to discover whether a new teaching technique improves student test scores. She therefore assigns teachers in «treated» classrooms to try this new technique, while leaving «control» classrooms unaffected. When analyzing her results, she may want to keep the data at the student level (for example, to control for student-level observable characteristics). However, when estimating the standard error or confidence interval of her statistical model, she realizes that classical or even heteroscedasticity-robust standard errors are inappropriate because student test scores within each class are not independently distributed. Instead, students in classes with better teachers have especially high test scores (regardless of whether they receive the experimental treatment) while students in classes with worse teachers have especially low test scores. The researcher can cluster her standard errors at the level of a classroom to account for this aspect of her experiment.^[7]

While this example is very specific, similar issues arise in a wide variety of settings. For example, in many panel data settings (such as difference-in-differences) clustering often offers a simple and effective way to account for non-independence between periods within each unit (sometimes referred to as «autocorrelation in residuals»).^[4] Another common and logically distinct justification for clustering arises when a full population cannot be randomly sampled, and so instead clusters are sampled and then units are randomized within cluster. In this case, clustered standard errors account for the uncertainty driven by the fact that the researcher does not observe large parts of the population of interest.^[8]

Mathematical motivation[edit]

A useful mathematical illustration comes from the case of one-way clustering in an ordinary least squares (OLS) model. Consider a simple model with N observations that are subdivided in C clusters. Let be an vector of outcomes, a matrix of covariates, an vector of unknown parameters, and an vector of unexplained residuals:

As is standard with OLS models, we minimize the sum of squared residuals to get an estimate :

From there, we can derive the classic «sandwich» estimator:

Denoting yields a potentially more familiar form

While one can develop a plug-in estimator by defining and letting , this completely flexible estimator will not converge to as . Given the assumptions that a practitioner deems as reasonable, different types of standard errors solve this problem in different ways. For example, classic homoskedastic standard errors assume that is diagonal with identical elements , which simplifies the expression for . Huber-White standard errors assume is diagonal but that the diagonal value varies, while other types of standard errors (e.g. Newey–West, Moulton SEs, Conley spatial SEs) make other restrictions on the form of this matrix to reduce the number of parameters that the practitioner needs to estimate.

Clustered standard errors assume that is block-diagonal according to the clusters in the sample, with unrestricted values in each block but zeros elsewhere. In this case, one can define and as the within-block analogues of and and derive the following mathematical fact:

By constructing plug-in matrices , one can form an estimator for that is consistent as the number of clusters becomes large. While no specific number of clusters is statistically proven to be sufficient, practitioners often cite a number in the range of 30-50 and are comfortable using clustered standard errors when the number of clusters exceeds that threshold.

Further reading[edit]

• Alberto Abadie, Susan Athey, Guido W Imbens, and Jeffrey M Wooldridge. 2022. «When Should You Adjust Standard Errors for Clustering?» Quarterly Journal of Economics.

References[edit]

.

Проблема 1

Служба кластеров при запуске обнаруживает сети, в которые входит узел, и для каждой сети определяет сетевые адаптеры. Одна из типичных неполадок связана с тем, что отказоустойчивая кластеризация Windows Server (WSFC) допускает использование для одной сети только одного сетевого адаптера. Все прочие адаптеры этой сети игнорируются.

Предположим, что администратор настроил узел с двумя сетевыми адаптерами для одной сети:

Card1
IP Address: 10.10.10.1
Subnet Mask: 255.0.0.0
Card2
IP Address: 10.10.10.2
Subnet Mask: 255.0.0.0

Сетевой драйвер кластера (Netft.sys) для каждой сети будет использовать только один сетевой адаптер (или группу). Поэтому при данной конфигурации сеть кластера Cluster Network 1 (10.10.10.0/16) будет задействовать только сетевой адаптер Card1, тогда как сетевой адаптер Card2 будет игнорироваться, то есть не будет применяться для связи между узлами. Поскольку работает только одна сеть, при выходе Card1 из строя или утрате сетевого соединения узел не сможет взаимодействовать с другими узлами. Это единственная точка отказа. Чтобы избежать подобной ситуации, кластер следует настраивать так, чтобы между узлами существовало, как минимум, два сетевых пути. В этом случае при отказе одного из сетевых адаптеров связь между узлами будет осуществляться через другой сетевой адаптер.

Проблема 2

Вторую типичную проблему проще всего раскрыть с помощью сценариев. Опишем ее на примере двух различных конфигураций кластера: односайтовой и многосайтовой.

Односайтовый кластер. Предположим, что администратор решил изменить конфигурацию кластера, установив две сети между узлами Node1 и Node2. На узле Node1 он поменял IP-адреса и маски подсети сетевых адаптеров:

Card1
IP Address: 192.168.0.1 (Cluster Network 1)
Subnet Mask: 255.255.255.0
Card2
IP Address: 10.10.10.1 (Cluster Network 2)
Subnet Mask: 255.0.0.0

Кроме того, администратор поменял IP-адреса узла Node2 (192.168.0.2 и 10.10.10.2). При этом на узле Node1 в кластере он добавил группу файлового сервера, назначив ей IP-адрес 192.168.0.15.

Затем администратор протестировал кластер, чтобы убедиться в успешном переходе группы файлового сервера на узел Node2 при отработке отказа. Однако IP-адрес группы файлового сервера не виден в сети, то есть группа находится в автономном состоянии. В журнале событий системы регистрируется событие 1069, описание которого указывает на отказ ресурса с этим IP-адресом.

Причина отказа становится очевидной, если воспользоваться командой PowerShell Get-ClusterLog для вывода журнала кластера. Для этого достаточно ввести следующий набор символов:

Get-ClusterLog

Команда инициирует создание журнала кластера на каждом узле. Для построения журнала кластера только на одном узле можно добавить параметр -Node и указать имя узла. Можно также добавить параметр -TimeSpan для создания журнала только за последние x минут. Например, приведенная ниже команда предписывает построить журнал кластера на узле Node2 за последние 15 минут:

Get-ClusterLog –Node Node2 –TimeSpan 15

В результатах, представленных на экране 1, указано состояние «status 5035.».

Экран 1. Информация о состоянии 5035 в файле журнала кластера

Это сообщение об ошибке указывает на неработоспособное состояние сети кластера. Если администратор перейдет в диспетчер отказоустойчивости кластеров, то в разделе «Сети» он увидит, что сеть 192.168.0.0/24 содержит только один сетевой адаптер для узла Node1. Однако имеется новая сеть 192.0.0.0/8, обслуживаемая сетевым адаптером узла Node2. Администратор, поменяв IP-адрес сетевого адаптера на узле Node2, не поменял маску подсети. Таким образом, ошибка 5035 возникла из-за неверной настройки сетевого адаптера.

Создавая ресурс с IP-адресом, можно указать сеть, которая будет использоваться для него. Если эта сеть не будет существовать на узле, куда данный ресурс перейдет при отработке отказа, то WSFC не поменяет сеть, используемую ресурсом. В данном примере, при том IP-адресе, который указал администратор, и маске подсети, применяемой этим IP-адресом, группа файлового сервера сможет работать только по сети Cluster Network 1 (192.168.0.0/24).

Многосайтовый кластер. В случае многосайтового кластера каждый узел обычно имеет собственную сеть со своим IP-адресом. При первоначальном создании кластера и его ролей с помощью мастера создания ресурсов вам предлагается указать IP-адрес для сетей каждого из узлов, настроенных для клиентского доступа (см. экран 2).

Экран 2. Создание многосайтового кластера

Мастер создания ресурсов, создавая IP-адреса и назначая имя сети, автоматически присваивает параметру зависимости этого имени сети значение «или». Это означает, что если один из IP-адресов в сети, имя также видно в сети. Создавая группы или ресурсы перед добавлением узлов из других сетей, необходимо вручную создавать эти вторичные IP-адреса и добавлять зависимость «или».

Проблема 3

Для формирования кластера необязательно быть администратором домена, но создание объектов в Active Directory (AD) требует наличия соответствующих прав. Как минимум, необходимо обладать правами на просмотр и создание объектов (Read and Create) в том подразделении (OU), где создается данный объект имени кластера (CNO). CNO – это объект-компьютер, связанный с ресурсом-кластером «Имя кластера». При создании кластера служба WSFC использует учетную запись, с которой вы регистрировались в системе, чтобы создать объект CNO в том же OU, которому принадлежат узлы. Если вы не обладаете достаточными правами в отношении данного OU, кластер не будет создан, и система выдаст ошибку, как показано на экране 3.

Экран 3. Ошибка процесса создания кластера

В статье «Диагностика проблем отказоустойчивых кластеров Windows Server 2012» (№ 10 за 2013 г.) я рассказывал об использовании мастера проверки конфигурации в диспетчере отказоустойчивости кластеров для выявления причин возникающих проблем. Мастер позволяет выполнять различные тесты, включая проверку настроек Active Directory. В ответ на попытку запуска этого теста без достаточных прав в отношении данного OU будет выдана ошибка, как показано на экране 4. Соответствующая настройка прав позволит вам создать кластер.

Экран 4. Ошибка проверки настроек Active Directory

Все другие ресурсы с сетевыми именами в кластере ассоциированы с объектами виртуальных компьютеров (VCO), создаваемыми в том же OU, что и CNO. Следовательно, при назначении ролей в кластере необходимо указать CNO с соответствующими правами (просмотр и создание) в отношении OU, поскольку CNO формирует все VCO в кластере. В противном случае новая роль будет находиться в состоянии сбоя. Тогда в журнале появится событие 1194 (см. экран 5).

Экран 5. Событие 1194 в журнале событий системы

Есть и другие установки локального компьютера, способные вызвать ошибки (включая ошибки отказа в доступе) при создании VCO в AD.

1. В составе локальной группы «Пользователи» больше нет группы «Прошедшие проверку пользователи». Обычно она удаляется объектами групповой политики (GPO) или шаблонами безопасности.

2. В локальной политике безопасности разрешение Access this computer from the network («Доступ к этому компьютеру по сети») или Add workstations to the domain («Добавление рабочих станций к домену») больше не включает группу «Прошедшие проверку пользователи». Обычно она удаляется объектами групповой политики (GPO) или шаблонами безопасности.

3. Включены следующие права доступа:

• сетевой доступ (не разрешать перечисление учетных записей SAM анонимными пользователями);
• сетевой доступ (не разрешать перечисление учетных записей SAM и общих ресурсов анонимными пользователями).

4. Ресурс имени кластера в состоянии сбоя.

Проблема 4

CNO и VCO – учетные записи компьютера и, подобно учетным записям пользователей, они имеют пароли, генерируемые AD случайным образом. По умолчанию политика домена предусматривает сброс пароля учетной записи компьютера каждые 60 дней.

СNO используется для таких операций, как добавление новых узлов к кластеру, создание новых объектов в домене и выполнение динамической миграции виртуальных машин с узла на узел. Для выполнения этих операций пароль CNO в домене должен быть актуальным. Для верности служба кластера делает попытку сброса паролей этих объектов по истечении половины срока (через 30 дней). Если пароль не сброшен на 60-дневной отметке, имя кластера не видно в сети.

Для сброса пароля необходимо выполнить восстановление в диспетчере отказоустойчивости кластеров. Как показано на экране 6, щелкните правой кнопкой имя проблемного ресурса и выберите «Дополнительные действия» и «Восстановить».

Экран 6. Сброс пароля вручную в диспетчере отказоустойчивости кластеров

При обращении к AD для сброса пароля диспетчер отказоустойчивости кластеров задействует учетную запись пользователя, под которой вы зарегистрировались в системе, поэтому вашей учетной записи должно быть предоставлено право на изменение пароля CNO; в противном случае восстановление не будет выполнено. Необходимо также убедиться, что включено разрешение на сброс пароля CNO и VCO, чтобы служба WSFC могла выполнять сброс при необходимости.

Проблема 5

Чтобы узел был осведомлен о том, какие узлы являются активными участниками кластера (то есть о текущем членстве), применяется ряд периодических контрольных сигналов, передаваемых между узлами по сети. Эти пакеты сигналов представляют собой UDP-датаграммы, следующие через порт 3343.

Каждый пакет включает регистрационный номер, по которому отслеживается факт приема пакета. Это работает следующим образом: узел Node1, отправляющий регистрационный номер 1111, ожидает ответного пакета, включающего 1111. Эти действия совершаются между всеми узлами каждую секунду. Если узел Node1 не получает ответного пакета, он отправляет следующий по порядку регистрационный номер (1112), и т.д.

По умолчанию, если узел не получает пять контрольных сигналов в течение пяти секунд, WSFC устанавливает факт отказа узла. Активный узел в кластере отправляет пакет на узел, где установлен отказ, чтобы завершить работу службы кластера, и регистрирует событие 1135 в журнале событий системы (см. экран 7).

Экран 7. Событие 1135 в журнале событий системы

Такое событие может быть вызвано несколькими причинами, многие из которых связаны с блокировкой связи через порт 3343:

1. Отказ сетевого оборудования.

2. Устаревший драйвер или устаревшая прошивка сетевого адаптера.

3. Сетевая задержка.

4. Протокол IPv6 разрешен на серверах, но параметры брандмауэра Windows выключают следующие разрешения для входящего и исходящего трафика:

• основы сетей – объявление поиска соседей;
• основы сетей – запрос поиска соседей.

5. Настройка коммутаторов, брандмауэров или маршрутизаторов не допускает прохождения трафика данных UDP-датаграмм.

6. Проблемы производительности (зависания, задержки и прочее).

7. Неправильно настроенные параметры буфера приема у драйвера сетевого адаптера.

Первым делом я всегда проверяю счетчик отброшенных принятых пакетов в составе объекта производительности сетевого интерфейса в окне системного монитора. Этот счетчик отслеживает число входящих пакетов, которые были отброшены, хотя и не было зафиксировано каких-либо ошибок, препятствующих их передаче протоколу верхнего уровня. Одна из возможных причин – необходимость освободить место в буфере.

Для добавления счетчика отброшенных принятых пакетов в окне системного монитора щелкните правой кнопкой на дисплее и выберите «Добавить счетчики». В открывшемся окне добавления счетчиков укажите нужный компьютер, выполните прокрутку и выберите счетчик «Отброшено принятых пакетов». В выпадающем списке «Экземпляры выбранного объекта» выберите нужный сетевой адаптер и нажмите «Добавить» (см. экран 8).

Экран 8. Добавление счетчика отброшенных принятых пакетов в системный монитор

Добавив счетчик, проверьте его среднее, минимальное и максимальное значения. Если есть значения больше нуля, это указывает на необходимость настройки буфера приема для сетевого адаптера. Проконсультируйтесь с производителем сетевого адаптера по поводу рекомендуемых параметров. Может потребоваться перезагрузка.

В отказоустойчивом кластере Windows Server 2012 R2 можно воспользоваться мастером проверки конфигурации для выполнения проверки сетевого взаимодействия. Этот тест позволяет проверить возможность информационного обмена между узлами через порт 3343. Если есть проблемы связи, то будет выдана соответствующая ошибка с указанием возможной причины.

Проблема 6

Иногда диспетчер отказоустойчивости кластеров не открывается, выдавая сообщение об ошибке (см. экран 9). В процессе открытия диспетчер отказоустойчивости кластеров устанавливает WMI-соединение с каждым узлом кластера. Сообщение об ошибке, приведенное на экране 9, указывает на то, что один из узлов имеет недопустимое пространство имен, то есть с узла был удален экземпляр Cluster WMI (Cluswmi.mof). Остается выяснить, на котором из узлов он удален, поскольку в сообщении об ошибке эта информация отсутствует.

Экран 9. Сообщение о недопустимом пространстве имен

В листинге приведен сценарий Windows PowerShell, позволяющий выявить узел, утративший экземпляр Cluster WMI.

Установив проблемный узел, можно ввести команду

Set-Location C:WindowsSystem32Wbem
Mofcomp.exe Cluswmi.mof

Наиболее распространенной причиной утраты Cluswmi.mof узлом является устаревший способ решения проблем WMI. Для устранения неполадок WMI администраторы обычно используют команду Mofcomp.exe *.mof, позволяющую скомпилировать все файлы Managed Object Format (MOF) в репозиторий WMI. Однако дело в том, что существует довольно много файлов удаления для различных ролей и компонентов Windows, включая Cluster WMI. Поэтому файл Cluswmi.mof, устанавливаемый с помощью этой команды, впоследствии удаляется. Правильный способ восстановления репозитория WMI – с использованием команды Winmgmt.exe.

Ошибку легче предупредить

Как известно, предупредить ошибку легче, чем исправлять ее последствия. Поэтому в заключение повторю простое правило: регулярно актуализируйте состояние своих систем, применяя все обновления и исправления, касающиеся безопасности. Команда разработчиков отказоустойчивой кластеризации в Microsoft опубликовала материалы с перечнями исправлений, которые рекомендуется применить на всех кластерах. Каждой версии Windows посвящена отдельная публикация:

• «Рекомендуемые исправления и обновления для отказоустойчивых кластеров на базе Windows Server 2012 R2» (support.microsoft.com/kb/2920151/EN-US);
• «Рекомендуемые исправления и обновления для отказоустойчивых кластеров на базе Windows Server 2012» (support.microsoft.com/kb/2784261/EN-US);
• «Рекомендуемые исправления и обновления для отказоустойчивых кластеров на базе Windows Server 2008 R2» (support.microsoft.com/kb/980054/EN-US).

Материалы обновляются по мере необходимости, поэтому всегда актуальны. Замечу, что в них перечислены не все исправления, а лишь самые критичные для обеспечения стабильной работы и наиболее востребованные, исходя из числа обращений в службу поддержки Microsoft.

$NodeNames = Get-ClusterNode
ForEach ($ClusterName in $NodeNames)
{
Write-Host -NoNewline «Testing $ClusterName»
Try
{
$result = (Get-WmiObject -Class «MSCluster_CLUSTER» `
-namespace «rootMSCluster» `
-authentication PacketPrivacy `
-computername $ClusterName -erroraction stop).__SERVER
Write-host «: Successfully queried cluster node»
}
Catch
{
Write-host -NoNewline «: Failed to query cluster node»
Write-host -ForegroundColor Red -BackgroundColor Black `
$_.Exception.Message
}
}

Загрузка конфигурации в ПЛИС через USB или разбираем FTDI MPSSE
Пишем загрузчик ПЛИС в LabVIEW. Часть 1

В первой статье мы обкатали алгоритм загрузки на старом добром Си, во второй статье разобрались, как в LabVIEW можно организовать программу и реализовать простой интерфейс пользователя. В этот раз мы познакомимся с новыми приемами работы в LabVIEW, разберем особенности обработки ошибок и завершим проект: реализуем протокол загрузки файла конфигурации в ПЛИС.

Обработка ошибок

Открываем сишный исходник, анализируем функцию MPSSE_open. Несмотря на алгоритмическую простоту (функции вызываются друг за дружкой) требуется импортировать довольно много элементов API D2XX: FT_OpenEx, FT_ResetDevice, FT_Purge, FT_SetUSBParameters, FT_SetChars, FT_SetTimeouts, FT_SetLatencyTimer, FT_SetFlowControl, FT_SetBitMode. Как было показано в предыдущей статье, импорт функций осуществляется с помощью узла Call library Function. Этот узел имеет выделенные терминалы для контроля ошибок. В LabVIEW есть одно простое правило: все ВП должны отслеживать ошибки и сообщать об ошибках, возвращаемых терминалами ошибок. Большинство встроенных ВП неукоснительно следует ему. Надеюсь всем понятно, насколько важно контролировать и обрабатывать ошибки особенно на этапе отладки, однако есть еще одна причина, почему это так важно, неочевидная «классическим» программистам. В LabVIEW нет строгой последовательности выполнения приборов на блок-диаграмме: прибор выполняется, когда на его входах будут готовы данные. Если с выхода одного ВП данные передаются на вход другого ВП, то понятно, что в начале отработает первый ВП, только после него второй. А как быть, если нет передачи данных, а ВП выполняют независимые действия? Конечно можно воспользоваться громоздкой «Flat Sequence Structure», но гораздо удобнее соединить приборы между собой потоком ошибок.

При импорте функций D2XX мы сталкиваемся с двумя типами ошибок. Первый — это ошибка непосредственно импорта — возвращает сам блок Call library Function. Второй — ошибка самой библиотеки, возвращается почти каждой функцией через FT_STATUS. Все возможные значения описаны в виде enum’а в заголовочном файле ftd2xx.h. Хотя достаточно знать, что значение FT_OK — отсутствие ошибки, а все остальные значения — коды ошибок, хотелось бы отследить не только сам факт ошибки, но и какая ошибка произошла и где именно она произошла.

В LabVIEW данные об ошибке распространяются через кластеры error. Это такой специальный выделенный тип данных, в LabVIEW есть множество ВП и функций для работы с ним. Кластер ошибок состоит из трех элементов: логическая переменная — отображает статус, целое знаковое число — код ошибки, строка — источник ошибки. Статус показывает, произошла ли ошибка, код ошибки определяет ее тип и используется специальными ВП для формирования отчета. Строка дает более развернутое представление о том, где именно произошла ошибка. В LabVIEW принято, если статус равен TRUE, то это ошибка, если статус равен FALSE, но код не равен нулю и строка описания не пустая, то это предупреждение, если же статус FALSE, код равен нулю и строка пустая — нет ошибки.

LabVIEW содержит внутреннюю базу данных, в которой код каждой ошибки связан с ее описанием. Для каждого типа ошибок выделен специальный диапазон значений кодов. Например, для ошибок связанных с работой сети выделено несколько диапазонов: от –2147467263 до –1967390460, от 61 до 65, от 116 до 118 и 122, 1101, 1114, 1115, 1132 до 1134, от 1139 до 1143 и от 1178 до 1185. Для ошибок, определяемых пользователем зарезервировано два диапазона от –8999 до –8000 и от 5000 до 9999. Из этих диапазонов мы можем выбрать значения для кодов ошибок библиотеки D2XX.

Создадим ВП, принимающий на вход статус функции D2XX и конвертирующий этот статус в кластер ошибки LabVIEW. Большинство функций и ВП в LabVIEW, получив на вход Error In статус TRUE, не выполняют свой код, а передают информацию об ошибке на терминал Error Out. Это позволяет эффективно передать информацию о источнике через всю цепочку до обработчика ошибок, исключив выполнение кода в аварийном режиме. Желательно, чтобы и наши ВП вели себя аналогично.

Оформим список статусов D2XX в виде enum и вынесем его в отдельный тип (в предыдущей статье мы так поступили с типами FTDI).

Новый ВП сохраняем под именем FT_error.vi. На переднюю панель добавляем два кластера Error In и Error Out, найти их можно в палитре «Array, Matrix & Cluster». Подсоединяем их к терминалам на панели соединений в нижнем левом и нижнем правом углах соответственно, как уже говорилось в прошлой статье, это принятое в LabVIEW расположение терминалов потока ошибок. На блок-диаграмму добавляем структуру Case, на вход Case selector подаем кластер Error In, после чего структура Case меняет цвет и делиться две поддиаграммы: «No Error» — зеленый цвет, и «Error» — красный цвет. Внутри случая Error передаем кластер ошибок от терминала селектора напрямую к выходному туннелю на правой границе. А в зеленом случае добавляем еще один Case, он в зависимости от статуса будет определять, следует ли создавать ошибку (статус не равен FT_OK), или оставить все как есть: пропустить входной кластер ошибки на выход без изменения.

Для того, чтобы технично преобразовать код ошибки в кластер, можно использовать ВП Error Cluster From Error Code VI. Этот SubVI в описание ошибки добавляет цепочку вызова, благодаря чему мы сможем определить не только что произошло, но еще и где это случилось.

Чтобы выделить текст, соответствующий входному статусу (FT_Status), используем блок свойств: выбираем «RingText.Text». Текст ошибки передаем на вход error message ВП Error Cluster From Error Code VI.
Не забываем нарисовать «говорящую» иконку.

Для испытания FT_error можно создать пустой ВП, добавить туда созданный ВП и посмотреть, как будет меняться значение при запуске, если подавать различные статусы.

Теперь, после любого вызова функции из API D2XX, мы будем использовать SubVI FT_error.vi. А кластер ошибок будет проходить через все ВП по всей иерархии вызова.

В ВП верхнего уровня мы должны определиться, что делать с обнаруженной ошибкой: можно вывести сообщение в диалоговом окне, записать его в файл отчета, проигнорировать или просто «тихо» завершить приложение. Диалоговое окно — самый простой и наиболее популярный способ отчета об ошибках. А еще он удобен для начинающего программиста, так как делать ничего не надо. В каждом ВП по умолчанию активирован режим автоматической обработки ошибок (Enable automatic error handling, находится в категории Execution меню ВП Properties). Работает он так: если в каком-то узле выходной терминал Error Out никуда не подключен, и в этом узле происходит ошибка, то LabVIEW приостанавливает выполнение приложения и выдает диалоговое окно. Если терминал Error Out узла соединен, то поток ошибки распространяется, как запрограммировано, и никаких дополнительных действий не происходит. Однако окно сообщения можно вызвать программно, для этого нужно воспользоваться ВП General Error Handler и Simple Error Handler (находятся в палитре «Dialog&User Interface»). При этом информацию об ошибке мы можем использовать для завершения программы. На блок-диаграмме это выглядит примерно так:

Картинка кликабельная

Когда произойдет ошибка, программа будет приостановлена, появится окно с отчетом, после закрытия окна программа корректно завершиться.

Открыть и закрыть FTDI

Итак, возвращаемся к функции MPSSE_open. Создаем новый VI. Первым делом, добавляем терминалы для потока ошибок. Добавляем структуру выбора и на селектор подаем вход Error In. В зеленом кейсе делаем импорт функций в порядке и с параметрами как в Сишном прототипе. Все узлы Call Library Function Node соединяем в цепочку потоком ошибок. В красном кейсе через тунель соединяем Error In с выходным терминалом ошибки.

Картинка кликабельная

ВП MPSSE_open.vi

На вход SubVI подается строка с описанием FTDI (Description), на выходе — Handle и инициализированный чип FTDI в режиме MPSSE.

Создадим ВП, завершающий работу с FTDI и можно уже проверить работоспособность на железе.

В предыдущей статье для отладки интерфейса мы сделали ВП заглушку SP_FT_MPSSE_FPGA.vi, сейчас настало время наполнить его. Добавляем на его блок-диаграмму MPSSE_open.vi и FT_Close.vi. На данном этапе достаточно сложно оценить, верно ли прошла инициализация, однако ненулевое значение Handle на выходе MPSSE_open.vi и отсутствие ошибки нам уже о многом скажет.

Блок-диаграмма SP_FT_MPSSE_FPGA.vi

Для того, чтобы посмотреть значение Handle можно воспользоваться окном «Probe Watch Window». Это удобный инструмент отладки, позволяющий вывести значение данных на любом (почти любом) проводе в процессе выполнения прибора. Для того чтобы установить пробу на линию, нужно в контекстном меню этой самой линии выбрать пункт «Probe». Откроется окно «Probe Watch Window», а на линии появится циферка с номером пробы. На рисунке выше это «3».

Отлично! Запускаем ВП верхнего уровня, подключаем к компьютеру отладочную плату. В списке «Выберите устройство» появляется описание подключенной микросхемы FTDI, нажимаем кнопку «Программировать» и… ничего не происходит. Только в окне «Probe Watch» появилось значение Handle. И это хорошо.

Отключаем плату, список устройств очищается. Нажимаем «Программировать». Вот тут-то выскакивает окно с отчетом об ошибке.

После нажатия кнопки «Continue», ВП завершает свою работу.

Стоит запретить нажимать кнопку, если не найдено ни одного устройства. Модифицируем кейс «Timeout» обработчика событий. Напомню, два раза в секунду сканируются подключенные к ПК чипы FTDI, если таковые обнаружены и могут быть использованы для программирования ПЛИС, то через свойство Strings[] их дескрипторы добавляются в Devices list. Создаем для «Программировать» свойство Disabled, и, если годных устройств не обнаружено, то отключаем и затемняем кнопку.

Осваиваем GPIO

После того, как MPSSE активирован, работа с ним осуществляется через так называемые «op-code», а из функций API D2XX используется только FT_Write, FT_Read и FT_Queue (чтобы узнать статус буфера приемника). По наторенной дорожке создаем соответствующие VI: FT_Write.vi, FT_Read.vi, FT_Queue.vi.

Теперь из этих трех кирпичиков выкладываем ВП для чтения параллельного порта и записи в него. Значение удобно представить в виде массива булевых переменных.

Как говорилось в самой первой статье протокол загрузки ПЛИС «Passive Serial» есть ничто иное как SPI с дополнительной манипуляцией флагами. Всего используется пять ножек: линии DCLK, DATA[0], nCONFIG должны быть сконфигурированы как выхода, линии nSTATUS, CONF_DONE — как входы.

Нам понадобится ВП, который сможет менять значение на выбранной ножке не затрагивая все остальные. Первым делом создаем Enum с порядковыми номерами ножек в порту, сохраняем в виде «Strict Type Def» в файл SP_LBYTE_BITS.ctl. Создаем новый ВП, добавляем привычные терминалы потока ошибок. Считываем текущее значение параллельного порта с помощью MPSSE_Get_LByte.vi, с помощью функции Replace Array Subset модифицируем нужный бит и записываем значение обратно в порт (MPSSE_Set_LByte.vi).

Для начала конфигурации контроллер MPSSE должен генерировать переход из низкого уровня в высокий на линии nCONFIG. Как только ПЛИС будет готова к приему данных, она сформирует высокий уровень на линии nSTATUS. На данном этапе у нас все готово для эксперимента в железе. На блок-диаграмму SP_FT_MPSSE_FPGA.v добавляем управление линией nCONFIG — после инициализации MPSSE подаем низкий уровень, а затем высокий. После каждой операции (для отладки) считываем состояние ножек порта.

В целом, во время запуска VI видно, что ПЛИС реагирует на переход на линии nCONFIG — на ножке nSTATUS устанавливается ноль, а затем единица. Но не будет лишним проконтролировать это с помощью осциллографа. Годится почти любой двуканальный осциллограф с возможностью запуска по триггеру (ждущий режим). Канал А (синий трек) я ставлю в контрольную точку цепи nCONFIG, канал B (красный трек) — цепь nSTATUS. Триггер настроен на спадающий фронт канала A.

Картинка кликабельна. С подробностями!

Работа с файлом

ПЛИС готова принять файл конфигурации. А готовы ли мы передать файл в ПЛИС?

LabVIEW содержит обширный набор инструментов для работы с файлами. Не скажу, что функционала хватает на абсолютно весь спектр задач, однако базовые операции типа чтение и запись выполняются легко и приятно. Основной набор VI для работы с файлами можно найти в палитре «File I/O». Для решаемой задачи требуется открыть файл конфигурации, оценить его размер (нам нужно знать, сколько байт отправлять ПЛИС), прочесть его и закрыть. Все просто и друг за другом. Используем ВП Open/Create/Replace File, Get File Size, Read from Binary File, Close File, объединяем их цепочкой потока ошибок и refnum — число, типа файлового дескриптора, создается при открытии файла и должно быть передано на вход другим ВП, работающим с этим файлом.

Пока нам некуда утилизировать считанные данные, но если очень хочется проверить работоспособность цепочки, то можно создать индикатор типа String и немножко настроить его. В контекстном меню активируем опцию «Hex Display», включаем вертикальный скроллбар (Visible Items -> Vertical Scrollbar) и после запуска наблюдаем содержимое бинарного файла конфигурации.

На блок-диаграмме ВП образовалось две независимые параллельные линии кода, поэтому для них используются раздельные цепочки ошибок. Для того, чтобы свести параллельные потоки в один терминал Error Out, используется функция Merge Errors. Эта функция просматривает ошибки на входе сверху вниз (да, там может более двух входных терминалов, растягивается мышкой) и возвращает первую, которую найдет. Если ошибок нет, то возвращает первое попавшееся предупреждение. Если и предупреждений не обнаружено, то на выходе ошибка отсутствует. Важно отметить, что порядок подключения входов Merge Errors определяет приоритет ошибок, и если ошибка возникнет сразу в двух цепочках, то нижняя ошибка будет проигнорирована. К этому нужно относиться внимательно.

Если мы попытаемся в ВП верхнего уровня нажать кнопку «Программировать» не выбрав файл, то на вход SP_FT_MPSSE_FPGA.vi поступит пустой путь, что вызовет ошибку «Error 1430. LabVIEW: (Hex 0x596) The path is empty or relative. You must use an absolute path.» Как говорит мой друг детства: «Пустяки, дело-то житейское!». И ошибка эта — вовсе не ошибка, а так, невнимательность пользователя. Останавливать программу и ругаться на него окном с красным крестиком мы не будем, просто удалим ошибку с этим кодом из потока и в диалоговом окне порекомендуем пользователю определиться с файлом. Для фильтрации ошибки используем ВП «Clear Errors» из палитры «Dialog&User Interface». Для вывода сообщения — «One Button Dialog».

Загрузка конфигурации

Для последовательной передачи данных процессору MPSSE нужно послать op-code 0x18, аргументами команды будет длина передаваемой последовательности (два байта, начиная с младшего), и сама последовательность данных. Длина кодируется за вычетом единицы. Отправку блока данных оформим в виде ВП MPSSE_send.

Размер входного буфера (Array Size) преобразовываем к двухбайтовому типу U16, отнимаем единицу, меняем местами младший и старший байт (Swap Bytes) — отправлять длину нужно начиная с младшего, и преобразовываем двухбайтовое число в однобайтный массив (Type Cast).

Функция Type Cast заслуживает отдельного внимания. Это такой универсальный преобразователь типов, сообразительность которого порою сильно удивляет. Если коротко, то:

Наглядно для програмиста

Однако это не просто приведение данных к другому типу, это еще и эвристическая интерпретация. Эта функция позволяет выполнять преобразование между несовместимыми типами данных, при этом функция не брезгует выравниванием входных данных и даже удалением «лишних» частей. Если запрошенный тип данных требует памяти больше, чем у входных данных, то функция выделит недостающий объем. Для начинающего разработчика LabVIEW Type Cast может стать палочкой-выручалочкой, но с взрослением, лучше от такого преобразователя отказаться — сильно много скрыто от глаз и может стать источником непредвиденных ошибок. Лучше использовать более явные методы преобразования, например, Coerce To Type.

При инициализации процессора MPSSE, мы задали максимально допустимый размер буфера для передачи данных в 65536 байт, следовательно файл конфигурации мы должны разделить на фрагменты, размер которых не превышает указанный размер. Воспользуемся функцией Array Subset, эта функция выделяет из массива подмассив начиная с элемента index и длинною length. Разбивать будем в цикле While, каждую итерацию индекс будем увеличивать на 65536, между итерациями значение передадим через сдвиговый регистр. Как только не удастся от основного массива отщипнуть 65536 байта, берем все, что осталось, отправляем и останавливаем цикл.

Согласно протоколу загрузки, после того, как все данные были переданы, нужно подать еще два тактовых импульса, чтобы началась инициализация ПЛИС. Для этого после цикла выполняем отправку еще одного «пустого» байта.

Для того, чтобы понять успех прошивки, считаем флаги, и, если CONF_DONE установлен в единицу, рапортуем ВП верхнему уровня, что все ОК.

Программа завершена. Осталось убедиться, что ПЛИС успешно прошивается, а плата счастливо мигает светодиодиками.

Про именование ВП

Ни для кого не секрет, что в классическом программировании всем пользовательским объектам и функциям нужно давать осмысленные имена, то же можно сказать и о LabVIEW, особенно, если в роли объектов выступает SubVI. Я привык имена файлам ВП давать на основе их места в иерархии разрабатываемого ПО. В текущем приложении можно выделить четыре уровня абстракции:

• Самый низкий уровень — это ВП, выполняющие непосредственное взаимодействие с FTDI, в большинстве своем они сводятся к вызову соответствующей функции из API D2XX. В своем проекте имена ВП этого уровня я начинал с префикса «FT», например FT_Close.vi или FT_Read.vi.
• Второй уровень — это взаимодействие с процессором MPSSE. Имена ВП этого уровня начинаются с префикса «MPSSE». Пример: MPSSE_open.vi, MPSSE_Set_LByte.vi, MPSSE_Get_LByte.vi.
• Третий уровень — это реализация протокола «Passive Serial» поверх MPSSE. Все файлы имеют префикс «SР». Например, SP_FT_MPSSE_FPGA.vi (жуткое имя, состоящее из аббревиатур) и SP_LBYTE_BITS.ctl.
• Уровень приложения. ВП верхнего уровня. Имя может быть произвольным, человекоориентированным.

Если проект достаточно большой (десятки ВП), то для каждого уровня файлы лучше хранить в отдельных директориях с соответствующим названием. В нашем проекте все ВП разместились в одной папке subVI.

Заключение

Может показаться, что описание процесса излишне подробно, но уж очень не хотелось создать очередное пособие по рисованию совы.

Я не пытался сделать справочник или учебник по языку, я хотел показать процесс создания приложения на LabVIEW, показать как строится логика разработки в этой среде. Человек со стороны поймет, нужно ли это ему вообще, начинающий разработчик несомненно почерпнет для себя много нового, профессионал снисходительно улыбнется и вспомнит себя в молодости (либо кинет в меня помидором). А мне будет куда направить моих студентов и дипломников.

Материалы по теме

1. Блюм П. LabVIEW: стиль программирования. Пер. с англ. под ред. Михеева П.– М.:
   ДМК Пресс, 2008 – 400 с.: ил.
2. labview_mpsse. Репозиторий с проектом.
3. Учебный стенд для ЦОС. Железо для опыта
4. Software Application Development D2XX Programmer’s Guide. Руководство по API D2XX.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Интересна ли тема LabVIEW

Проголосовали 23 пользователя.

Воздержались 5 пользователей.

Урок 5 Отладка ВП

Как бы вы ни были уверены в создаваемом ВП, невозможно предусмотреть все проблемы, с которыми может столкнуться пользователь. Без механизма определения ошибок будет понятно только то, что ВП работает неправильно. Проверка на наличие ошибок позволит узнать, где именно и почему произошла ошибка.

Автоматическая обработка ошибок

Каждой ошибке соответствует числовой код и текстовое сообщение.

По умолчанию LabVIEW обрабатывает все ошибки, произошедшие во время выполнения ВП, следующим образом: ВП переводится в состояние ожидания, подВП или функция, где произошла ошибка, подсвечивается, а на экран выводится диалог ошибки.

Чтобы запретить автоматическую обработку ошибок для текущего ВП, выберите пункт меню File>>VI Properties, а затем Execution в

раскрывающемся меню Category. Чтобы запретить автоматическую обработку для всех вновь создаваемых ВП, выберите

Tools>>Options, а затем Block Diagram в списке Category. Чтобы запретить автоматическую обработку ошибок для подВП или функции, соедините выход error out с входом error in другого подВП или функции, либо с индикатором error out.

Ручная обработка ошибок

Можно выбирать другие методы обработки ошибок. Например, если для ВП ввода-вывода истекло время ожидания, не всегда нужно останавливать приложение и выводить диалог ошибки. Возможно, вы захотите, чтобы ВП повторял попытки в течение некоторого времени. Решения, связанные с обработкой ошибок, можно принимать на блок-диаграмме ВП.

Для управления ошибками предназначены ВП и функции обработки ошибок на палитре Dialog & User Interface, а также параметры error in и error out, присутствующие у большинства ВП и функций. Например, можно выводить сообщение об ошибке в диалогах различных видов. Используйте обработку ошибок совместно с инструментами отладки, чтобы эффективно находить и устранять ошибки в программе.

ВП и функции сообщают об ошибках либо при помощи числового кода, либо при помощи кластера ошибки. Как правило, числовые коды используются в функциях, а кластеры — в ВП, которые имеют для этого специальные входы и выходы.

При любых операциях ввода-вывода следует учитывать возможность ошибки. Почти все функции ввода-вывода возвращают информацию об ошибках. Наличие ошибок особенно важно проверять при работе с файлами, внешними приборами, устройствами сбора данных и при организации связи между компьютерами. Помимо проверки, следует реализовать механизм, адекватно обрабатывающий ошибки.

Урок 5 Отладка ВП

Обработкой ошибок можно управлять при помощи встроенных ВП, функций и параметров. Например, если LabVIEW обнаружит ошибку, вы можете сообщить о ней в окне диалога. Можно устранить ошибку программным способом, а затем удалить информацию о ней, соединив выход error out с входом error in ВП

Clear Errors. Компания National Instruments настоятельно рекомендует использовать обработку ошибок.

Кластеры ошибок

Элементы управления и индикаторы, представляющие кластеры ошибок, используются для передачи информации об ошибках между подВП.

Кластеры error in и error out содержат следующую информацию:

•status — логическое значение, в случае ошибки равно TRUE.

•code — 32-битовое знаковое целое, идентифицирующее ошибку. Ненулевой код и status = FALSE означают предупреждение.

•source — строка, идентифицирующая источник ошибки.

Обработка ошибок в LabVIEW соответствует модели потока данных. Информация об ошибках распространяется по ВП аналогично другим данным. Передавайте информацию об ошибках от начала до конца ВП, а в самом конце установите обработчик ошибок, чтобы определить, было ли выполнение безошибочным. Для передачи информации об ошибках используйте кластеры error in и error out. Их следует включать и в те ВП, которые вы строите самостоятельно.

Перед выполнением каждого узла блок-диаграммы LabVIEW проверяет наличие ошибок на его входе. Если ошибок нет, узел выполняется в нормальном режиме. Если ошибка обнаружена, она передается следующему узлу без выполнения текущей части кода. Следующий узел делает то же самое, и т. д. В конце потока выполнения LabVIEW сообщает об ошибке.

Объяснение ошибок

При возникновении ошибки щелкните правой кнопкой внутри кластера и выберите пункт Explain Error контекстного меню, чтобы открыть соответствующий диалог. Диалог Explain Error содержит информацию об ошибке. Если ошибок нет, но есть предупреждения, контекстное меню будет содержать пункт Explain Warning.

Диалог Explain Error также можно вызвать через пункт меню

Help>>Explain Error.

ВП и функции сообщают об ошибках либо при помощи числового кода, либо при помощи кластера ошибки. Как правило, числовые коды используются в функциях, а кластеры — в ВП, которые имеют для этого специальные входы и выходы.

Обработка ошибок при помощи структуры Case

В приведенном ниже примере кластер ошибки используется для выбора вариантов в структуре Case.

Урок 5 Отладка ВП

Рис. 5-3. Вариант No Error.

Рис. 5-4. Вариант Error.

При соединении кластера ошибки с терминалом селектора структуры Case, метка селектора автоматически показывает два варианта — Error и No Error, а рамка структуры меняет цвет на красный для варианта Error и зеленый для варианта No Error. При возникновении ошибки выполняется поддиаграмма Error.

Если с терминалом селектора соединен кластер ошибки, структура Case реагирует только на логический параметр status.

Обработка ошибок при помощи цикла While

Кластер ошибки можно соединить с терминалом условия цикла While. При этом на терминал передается только значение логического параметра status. Когда возникает ошибка, цикл останавливается.

Когда с терминалом условия соединен кластер ошибки, пункты контекстного меню Stop if True и Continue if True меняются на

Stop on Error и Continue while Error.

На рис. 5-5 кластер ошибки и кнопка останова совместно определяют условие выхода из цикла. Большинство циклов рекомендуется останавливать именно таким способом.

Урок 5 Отладка ВП

Рис. 5-5. Останов цикла While.

Листинг. Сценарий PowerShell для определения узлов с отсутствующим экземпляром Cluster WMI

$NodeNames = Get-ClusterNode
ForEach ($ClusterName in $NodeNames)
{
Write-Host -NoNewline «Testing $ClusterName»
Try
{
$result = (Get-WmiObject -Class «MSCluster_CLUSTER» `
-namespace «rootMSCluster» `
-authentication PacketPrivacy `
-computername $ClusterName -erroraction stop).__SERVER
Write-host «: Successfully queried cluster node»
}
Catch
{
Write-host -NoNewline «: Failed to query cluster node»
Write-host -ForegroundColor Red -BackgroundColor Black `
$_.Exception.Message
}
}