andw

А в какой именно документации есть эта таблица с кодами и вообще более подробное описание модуля M-3802? На странице поддержки http://www.moxa.com/support/sarch_result.aspx?type=doc&prod_id=493&type_id=8 есть только краткое описание (Analog Input Modules Datasheet (555.66 KB) Released 2011-05-06). И еще вопрос: диапазон тока 4..20 мА фиксирован в данных модулях или возможно как-то сместить (программной настройкой?) значения крайних точек этого диапазона?

К сожалению, это довольно большой проект, из которого надо еще вытаскивать непосредственную работу с NPort. А в целом код такой же, как в примере на Delphi. Использована обертка для вызова (через P/Invoke) функций из IPSerial.dll (сделанная на основе примера на C# из поставки NPort Administrator). В том-то и дело, что используемая среда разработки не влияет на поведение IPSerial.dll. В случае использования Delphi влияние побочных факторов сведено к минимуму.

Я возможно неточно объяснил ситуацию: - сначала была сделана программа на C#, которая в ходе работы записывала собственное состояние в csv файл, графики были построены в Excel по данных из этого файла - потом для исключения разных побочных эффектов (в основном менеджера памяти .NET) был сделан минимальный пример на Delphi, выложенный здесь. В нем оставлен только вывод в консоль, для контроля работоспособности, а уже параметры процесcа заносились в таблицу Excel вручную из окна диспетчера задач. Итоговый вывод (про 1,3Кб) как раз и сделан на основе этих данных. Замеры сведены в приложенную таблицу. Я последовательно исключал вызов разл. методов внутри цикла, в итоге остались только open/close. По известному расходу памяти в час и числу вызовов был определен средний расход памяти на одну пару вызовов. MemLeakTest1.zip

Выложенные ранее график был построен в обычном Excel'е с использованием сформированного самой программой в ходе работы csv-файла, содержащего основные параметры процесса. Для выложенного тестового примера значения расхода памяти записывались вручную каждый час, по показаниям "Диспетчера задач", потом был рассчитан средних расход памяти на 1 пару вызовов open/close. Также замеры делались с помощью оснастки "Performance" (счетчики производительности) в Win2003.

MemLeakTest.zip

В архиве собственно исходник - MemLeakTest.dpr. Остальное: IPSerial.pas - из примеров, IPSerial.dll - версии 1.6.0.0 из NPort Administrator 1.16. Ну и файлы проекта D7. Впрочем, я сейчас всю работу с NPort реализовал напрямую (аналог checkalive() через ICMP-запросы и прием/передача данных через 950-й TCP порт). Проблем с ресурсами/памятью нет, минус такого решения только в том, что взаимодействие с NPort по этой схеме недокументировано (?).

Кратко о результатах тестирования программы, сделанной в Delphi7: ОС: Win2003 x86, IPSerial.dll последней версии (1.6.0.0), консольное приложение с вызовом внутри цикла nsio_open()...nsio_close(). Каждая такая пара вызовов приводит к увеличению расхода памяти на 1,3 Kb.

По результатам тестирования в течении ~1,5 часов (в цикле с интервалом 15 секунд вызывается nsio_checkalive, nsio_open, nsio_write, nsio_read, nsio_close, без подключенных к RS485 устройств): с количеством handles проблемы сейчас нет (как и в версии 1.5.7.0 библиотеки из NPort Adm. Ver1.14.9) а вот с расходом памяти пока не все понятно... на графике видно, что объем занятой памяти увеличивается примерно на 250 Кб в час. В ближайшее время попробую сделать минимальный тестовый пример на Delphi, чтобы исключить возможные эффекты менеджера памяти среды исполнения .NET.

Напишу о результатах тестирования одной из версий IP Serial Lib. Версия IPSerial.dll - 1.5.7.0; ОС - Win2003 x86; программа собрана под .NET 3.5. Устройства к порту RS485 (NPort 5130A) не подключены; между ПК и NPort - 2 свитча в незагруженной сети. Bнициализация (nsio_init()) выполняется один раз при запуске программы и соотв. вызов nsio_end() делается один раз при завершении. Внутри в цикле последовательно вызываются nsio_checkalive, nsio_open, nsio_write, nsio_read, nsio_close. На всякий случай все сделано в одном потоке, т.к. информации о потокобезопасности данной библиотеки нет. Программа работала непрерывно около 12 часов. Число handles менялось в диапазоне 304..366, постоянного увеличения их числа не было. Наблюдалась небольшая утечка памяти... с этим еще буду разбираться. Скорее всего, так и надо использовать эту библиотеку, а не вызывать nsio_init/nsio_end в каждом сеансе связи с устройством.

IPSerial.dll / NPort Adm. v.1.5.0.0 (Ver1.10.1) v.1.5.1.0 (Ver1.12.3, Ver1.14, Ver1.14.7) v.1.5.7.0 (Ver1.14.9) v.1.5.11.0 (Ver1.14.11)

Поставил, попробовал... только вот проблема исправлена не в ней, а в предыдущей бета версии (1.14.9), но опять же, не до конца. В общем, вот результаты по использованию IPSerial.dll разных версий. Проверял под x86 и x64, результат одинаковый. Версия dll/nsio_init()/nsio_end() (v.1.4.3.0) +12557 -12550 (v.1.5.1.0) +12557 -12550 (v.1.5.7.0) +13 -7 (v.1.5.11.0) +12557 -6 Что касается предельного количества handles - в WinXP x86 начались сбои (непрорисовка меню, невозможность открытия новых окон) при handles count около 3,8 млн.

Кстати вопрос насчет последней версии: В процессе поиска ответа на вопрос о количестве дескрипторов наткнулся на Release Notes, в которых упоминается уже Ver1.14.11 Build 10102017 (только вот ошибка с handles все равно не исправлена). А нет ли еще более свежей версии?

Обнаружилась проблема при использовании IPSerial.dll. Проверено на ОС: Win7 (x64), WinXP SP3 и Win2003 (x86); программа делается на C#2008, собирается под x86. Также проверены примеры на Delphi из поставки NPort Adm Suite. Версия IPSerial.dll - 1.5.1.0. После вызова nsio_init() счетчик дескрипторов процесса (handles, по показаниям диспетчера задач) увеличивается примерно на 12500 (Большинство процессов используют всего лишь 300-400). При последующих вызовах nsio_end() количество дескрипторов уменьшается, но уже не на 12500, а меньше. В результате происходит их накопление... и скорее всего в итоге может привести к сбою системы (пока не успел проверить). При использовании IPSerial.dll версии 1.5.11.0 - число handles вообще не уменьшается после nsio_end(). Пока что единственный вариант решения - периодический перезапуск процесса, работающего с NPort. Но... совсем не хотелось бы так делать.