CC BY
44
Разработанная система регистрации малых перемещений и обработки сигналов позволяет проводить метрологическую аттестацию средств регистрации малых (до 10-9 м) сигналов, регистрировать сигналы АЭ в широкой полосе частот и давать оценку степени деформирования конструкции.
Основу системы составляют:
- лазерный голографический интерферометр [1- 4];
- прибор АП - 51 ЭМ, осуществляющий предварительную обработку сигналов
[5];
- аналого-цифровой преобразователь, имеющий возможность работы в автономном режиме (без ПЭВМ) и осуществляющий первичную статистическую обработку сигналов;
- методика обработки и анализа информативных параметров АЭ [5].
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Паринов И.А.., Попов А.В., Рожков Е.В., Прыгунов А.Г. Калибровка акустических преобразователей методом голографической интерферометрии.// Дефектоскопия. 2000. №1. С.14 - 18.
2. Паринов И.А., Попов А.В., Рожков Е.В., Прыгунов А.Г., Трепачёв В.В. Патент РФ № 2169348. Измеритель перемещений с объёмной голограммой. Приоритет от 28.09. 99.
3. Попов А.В., Прыгунов А.Г. Голографический метод регистрации акустико-эмиссионных сигналов при деформации твердых тел// Дефектоскопия. 2000. № 6. С. 64 - 69.
4. Попов А.В., Прыгунов А.Г. Регистрация малых перемещений при деформации твердых тел голо-
графическим интерферометром// Известия вузов. Приборостроение. 2001. № 2. С. 50 - 55.
5. Расщепляев Ю.С., Попов А.В. Оценка степени опасности дефектов на основе инвариантов при акустико-эмиссионном неразрушающем контроле// Контроль. Диагностика. 2001 № 3 (33). С. 29 - 32.
Б.А. Телеснин
ОСОБЕННОСТИ РЕАЛИЗАЦИИ ВВОДА И ОБРАБОТКИ ЗВУКОВЫХ СИГНАЛОВ
Программная реализация ввода и обработки звукового сигнала всегда имеет особенности, в силу объема данных. В принципе, возникающие проблемы имеют схожую природу на самых разных платформах, поэтому в данной статье рассматривается платформа Win32. Следует оговориться, что речь не пойдет об IP-телефонии, речь идет о вводе звуковых данных с помощью звуковой карты. Конечно, не возникает особых проблем, в случае если вы хотите записать данные фиксированного размера, решение этого вопроса осуществляется средствами API без особых затей. Проблема возникает в случае, если есть необходимость вводить и обрабатывать данные в “реальном времени”.
Задача при этом такова - есть обработчик, который работает в реальном времени только за какой-то большой период (T1). При этом на некоторых участках данных он может существенно не успевать с их обработкой. Существенно в том смысле, что время обработки небольшого интервала^) много больше (>>) чем само t, но не более чем T1, когда время обработки интервала близко к T1. Решение этой задачи можно осуществить соответствующей реализацией ввода и обработки данных. Задача нетривиальна, ибо если бы это было так, то самое простое решение - записывать данные в файл последовательно, все время, пока требуется обработка. На частоте 40 кГц такое решение представляется “не серьезным”. Кроме того, очень часто невыгодно попроцессное (в смысле WIN32) разделение программы на ввод и обработку, невыгодно по технологическим причинам, так как это увеличивает время разработки, из-за необходимости взаимодейст-
Компьютерные технологии в инженерной и управленческой деятельности
вия обеих программ. Стоит, правда, заметить, что разделение именно процессов может существенно, повысить надежность обеих компонент.
По мнению авторов, фактор взаимодействия обеих частей плюс некоторой управляющей компоненты (она, понятно, есть в каждой программе) и классифицирует реализацию ввода и обработки данных. Типичным (с точки зрения Win32) способом взаимодействия является “ожидание события”. В нашем случае "ввод" должен устанавливать свой Event в сигнальное состояние, а обработка должна выйти из API-процедуры WaitForSingleObject и начать обработку новых данных (как ни странно, иногда обработка может работать с опережением, в противном случае - ждать незачем). В этом случае обработка должна находиться в отдельном потоке, и собственно это является трудностью, так как затрудняет ее взаимодействие с головным потоком. Для полноты взаимодействия с головным потоком придется вызывать WaitForMultipleObject, при этом она должна иметь столько Event-объектов, сколько у нее всего точек взаимодействия с головным потоком. Другой путь взаимодействия менее типичен, так как базируется на очереди сообщений (и в смысле Win32, и в более широком смысле), другое название -метод асинхронных сообщений. При этом отсутствуют ограничения на место реализации обработки, она может находиться в любом потоке. Однако в том случае, если она не одна разделяет поток (например, в главном потоке), ей приходится дробить себя на приемлемые по времени исполнения куски. Последнее утверждение поясним более подробно: пусть имеется цикл "For i:=0 to 10000 do" и его можно разбить, скажем, на 10 частей. После выполнения очередной части следует послать самому себе асинхронное сообщение через очередь сообщений (например, PostMessage) и следующую часть обрабатывать, когда оно собственно придет, при этом не должна нарушиться возможность интерактивного взаимодействия с программным комплексом. Последнее замечание не случайно, так как непосредственная реализация может привести к полному зависанию головного потока на асинхронных сообщениях. Причина в PostMessage - в Win32 эти сообщения имеют максимальный приоритет, и, следовательно, все пользовательские сообщения будут находиться в очереди до тех пор, пока поток сообщений из PostMessage не прекратится окна приложения не будут реагировать на запросы пользователя. Собственно это та самая причина, по которой подобный образ взаимодействия «нетипичен» для Win32.
Существует, однако, способ преодоления подобных неприятностей. Для этого требуется собственная реализация очереди сообщений, которая будет работать параллельно уже существующей. Остановимся подробнее на взаимодействии очередей.
Выборка сообщений в новой очереди (О1) происходит в моменты выборки сообщений из основной очереди (Ом), ибо это самые удобные моменты с точки зрения перехвата управления. Самым «легитимным» является метод собственной реализации разбора сообщений основной очереди. Но при использовании стандартных меню ситуация такова, что процесс не получает управления после перехода фокуса окна на объекты меню, поэтому самым правильным перехватом управления является использование функций перехвата HOOK (setWindowsHookEx). Понятно, что в случае отсутствия сообщений вообще ситуация грозит для О1 простаиванием. Во избежание этого следует время от времени использовать PostMessage. Самый удобный момент - тот, когда новое сообщение поступает в O1, при этом следует только проверить основную очередь на наличие сообщений вообще и посылать Post только в случае полной пустоты очереди. При обработке можно распределять нагрузку путем ограничения на количество обрабатываемых сообщений из О1 за один цикл, то есть за одно сообщение из ОМ. Таким об-
разом, получена гарантированная доставка асинхронных сообщений, не нарушающая работу основной очереди сообщений.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Секунов Н.Ю. Обработка звука на РС. СПб. 2001. 1248с.
2. РихтерДж. Windows для профессионалов. СПб. 2002. 752с.
А.А. Зори, Р.З. Амиров ИНФОРМАЦИОННО-ИЗМЕРИТЕЛЬНАЯ СИСТЕМА ДИСТАНЦИОННОГО СЧИТЫВАНИЯ ШТРИХОВЫХ КОДОВ ПРИ УТИЛИЗАЦИИ РАДИОАКТИВНЫХ ОТХОДОВ
В связи с растущими объемами радиоактивных отходов (РАО) средней и слабой активности возникает задача надежной их изоляции от биосферы. Это реализуется прессованием отходов под давлением в пределах 4,9^ 107 - 6,8-107 Па, маркировкой полученных брикетов штриховым кодом (ШК) и последующей оптимальной укладкой брикетов в специальные контейнеры длительного хранения.
Дистанционное считывание маркера брикета и идентификация типоразмера брикета в экстремальных условиях (оптические, электромагнитные помехи, радиоактивность) для осуществления оптимальной укладки брикетов в контейнер реализуются информационно-измерительной системой (ИИС) идентификации типоразмеров брикетов [1]. Высокая скорость протекания технологического процесса утилизации радиоактивных отходов, а также выполнение ряда преобразований измерительного сигнала в оптическом и преобразующем каналах ИИС требуют высокоскоростной обработки информации, что может быть реализовано применением сигнального процессора. С его помощью реализуются алгоритмы обработки изображений, накопление измерительной информации, диагностика первичного измерительного преобразователя.
Идентификация типоразмера брикета в технологии утилизации радиоактивных отходов заключается в выполнении последовательности операций:
- прием первичным преобразователем отраженного от объекта контроля оптического сигнала;
- выполнение первичным преобразователем фотоэлектрических преобразований;
- дискретизация сигнала;
- обработка цифровым обработчиком информации полученного измерительного сигнала;
- идентификация типоразмера брикета.
Сложный оператор последовательных преобразований измерительного сигнала имеет вид
и ф = Р1 • Р2 • Рз • Р4 • Р5 • Рб • Р7,
где иф - сигнал на выходе цифрового обработчика информации; Р1 - оператор излу-
чения оптического сигнала объектом; Р2 - оператор воздействия среды распространения сигнала (СРС) на оптический сигнал; Р3 - оператор оптической системы приемника излучения; Р4 - оператор фотоэлектрического преобразования измерительного сигнала; Р5
- оператор преобразования фототока в напряжение; Р6 - оператор дискретизации; Р7 -оператор цифровой обработки измерительного сигнала.
