Столкнулся с непонятной проблемой, связанной с автозагрузкой программы в 1756-MVI модуле.
Суть в следующем:
1. Прописываю в autoexec.bat программу, которую необходимо запустить.
2. Перезагружаю модуль.
3. Программа стартует, но с ошибкой.
4. Останавливаю программу.
5. Просто в терминале набираю ее имя, снова программа запускается и работает без ошибки.
Не могу понять, почему она сразу не хочет запуститься.
Немного о самой программе:
Мое приложение в main инициализирует все порты RS-232 (3 штуки), COM1 настраивается для работы в терминальном режиме, COM2, COM3 - на прием последовательных данных с приборов.
Также устанавливается соединение с Backplane ControlLogix.
Далее по событию запускаются две нити (threads), которые параллельно опрашивают свой порт (COM2 или COM3), обрабатывают принятые посылки и записывают результат в разные ячейки процессора с помощью функции MVIbp_WriteInputImage.
В принципе все написано по учебнику, и работает безо всяких проблем, если программу стартануть, как говориться, ручками. При автоматическом запуске всегда стартует только одна нитка, отвечающая за COM3, а COM2 - не работает. Думал, что может не успевает стартануть какой-нибудь драйвер, ставил задержки - не помогает.
Может кто сталкивался, а то автозапуск полезная штука в эксплуатации.
хм... интересно.
А если устроить в програме паузу при старте и только после неё пустить основной код?
Пытался делать задержки и перед запуском программы, и в main самой программы делал sleep, и нитки стартовал от разных событий, пока не помогло, однако.
У меня такое ощущение, что дело в com-порте. Это же не разделяемый ресурс, если одна программа (какая? не знаю) его заняла, то вторая его использовать не может. Может быть, он так инициализируется или занят чем-то.
Программа test-com.exe предназначена для расширенной проверки каналов последовательной связи (COM-портов), созданных на базе микросхем типа 16450 (стандартных микросхем IBM PC). Я ее написал еще в бытность работы на БЛПК. Программа предназначена для работы под MS-DOS, хотя работает и под Windows. В случае работы под Windows после окончания работы программы тестируемый канал может оказаться недоступным для других приложений. В этом случае необходимо перезапустить систему.
Может быть, программа test_com кому-нибудь пригодится.
При запуске производится определение количества каналов в системе и адреса их портов (ячейки переменных BIOS 40:0 - 40:7) и выводятся данные по каждому найденному каналу: тип используемой микросхемы, установленные скорость и режимы передачи. К сожалению, в процессе определения настроек канала, к которому подключена мышка, могут исказиться ее режимы работы. Для ликвидации этих последствий необходимо перезапустить систему.
Запуск программы test_com
При нажатии знака вопроса выводится список команд:
W - вывод адресов существующих последов. портов,
P - задание базового адреса тестируемого порта,
C - задание тестируемого канала COM,
X - вывод параметров заданного канала,
S - настройка параметров заданного канала,
T - запуск теста,
D - проверка служебных сигналов,
I - чтение содержимого заданного порта,
O - вывод байта в порт,
H - описание программы,
? - список команд,
ESC - выход в DOS.
После запуска программы необходимо ввести базовый адрес тестируемого канала. Это можно сделать при помощи либо режима "C" (ввод по номеру COM1 - COM4), либо режима "P" (ввод произвольного адреса в шестнадцатиричном виде в случае использования нестандартных адресов каналов {но не микросхем!!!}). В строке команды будут выводиться базовый адрес, тип микросхемы, скорость и режимы передачи тестируемого канала.
Скорость и режимы передачи можно изменить с помощью режима "S". Тестирование заданного канала (режим "T") можно проводить как с внешней заглушкой (замкнуть контакты 2 и 3 разъема), так и с внутренней (в микросхеме приемо-передатчика). Во втором случае буферные микросхемы преобразования TTL-RS232 не проверяются.
Пример отображения режима передачи:
8 - длина передаваемого слова, бит;
Н - контроль, Н-по нечету, Ч-по чету, О-отсутствие контроля, 1-бит четности всегда=1, 0-бит четности всегда=0;
1 - количество стоп-битов.
Режимы "I" и "O" позволяют контролировать работу отдельных произвольных портов компьютера.
Режим T (тест) - основной режим программы. Возможны три режима работы : "ТЕСТ", "ТРАНСЛЯЦИЯ" и "55".
В режиме "ТЕСТ" программа выдает на передатчик проверочный код, ждет готовность приемника, при ее наличии берет код с приемника и сравнивает его с переданным. В случае отсутствия готовности передатчика или приемника более 2-х секунд на консоль выдается сообщение "Нет Гт Пд" или "Нет Гт Пр", в случае несравнения переданного и принятого байтов - сообщение об ошибке. Проверочный код представляет собой последовательный перебор чисел от 00 до FF. Перед запуском теста необходимо замкнуть на проверяемом канале выход передатчика со входом приемника (при работе с внешним замыкателем). При безошибочной работе проверяемого модуля после каждого прогона тестовой последовательности от 00 до FF на консоль выдается сообщение "Цикл NN", где NN - просто порядковый номер цикла в 16-ричном коде. Работа программы - непрерывная, выход из нее - <ESC>.
В режиме "ТРАНСЛЯЦИЯ" (программная заглушка) программа ждет готовность приемника. По ее появлении на консоль выдается байт состояния приемо-передатчика, через тире - принятый код, затем этот код отсылается на передатчик. Этот режим является вспомогательным для полной проверки канала связи двух ЭВМ. На одной запускается "ТЕСТ", на другой - "ТРАНСЛЯЦИЯ". Режим может быть полезен для проверки скорости передачи. Выход из режима - <ESC>.
Режим "55" сделан для упрощения поиска неисправности в цепи прохождения импульсов от выхода передатчика (TTL-уровень) до входа приемника. В этом режиме на передатчик непрерывно, без анализа готовности, выдается код 55H ("вилка"). Для индикации работы программы на экране крутится "колесо". Выход из режима - <ESC>.
Спасибо за ответ, но дело точно не в портах, они гарантировано исправны и работают хорошо.
Насчет разделяемых ресурсов все понятно. Естественно необходимо следить, чтобы разные процессы не садились на один ресурс, для этого есть механизмы разделения. В своей проге я организовал две нитки, которые работают только со своими портами и не используют порт конфигурирования.
Пока все решилось комбинацией перестановок функций инициализации портов и Backplane API, а также добавлением после каждой функции типа Open небольшой задержки.
В итоге получилось приблизительно следующее:
1. Запуск программы, задержка
2. Инициализация и запрос конфигурации Backplane, задержка
3. Инициализация трех портов
4. Инициализация нитей опроса портов COM2-3
5. Задержка
6. Старт нитей опроса
...
После такой комбинации программа запустилась с автостарта.
Честно говоря, я не понял, в чем был мой глюк, но есть подозрение, что MVI-модуль медленно поднимает все свои ресурсы. Будем дальше наблюдать...
Интересный опыт, раскажите, пожалуйста, если наблюдения покажут что-нибудь ещё. Я уверен, что и производителю это было бы интересно знать.
Без проблем.
Дело в том, что у нас уже на двух объектах применяются MVI-модули, ну и, как водится, программы написаны одним и тем же человеком, а значит имеют одинаковую структуру. При этом удивительно то, что на первом объекте программы стартуют без всяких задержек. А вот на втором - увы, пришлось выкручиваться.
Помимо торможения самого модуля, могут быть, наверное, еще вот какие заморочки:
1. Версии (или ревизии) самих MVI. Дело в том, что на втором объекте у нас MVI более древние.
2. Версии процессорных модулей ControlLogix, с которыми ведется обмен. Тут у нас точно есть различие: в первом случае L61, во втором L55M23.
Я думаю, что процессоры Logix тут ни при чём, а дело в ревизии firmware модуля. производитель постоянно совершенствует модули, в частности, по вот такой информации об их поведении.
Если хотите, могу Вашу прогу погонять на своём модуле. Я как-то пробовал в 1756-MVI программки загонять, но оказалось, что применения этому модулю не намечается. Так и стоит без дела. Может и правда дело в ревизии. Ещё буду благодарен за какую-нибудь инфу по этому модулю, т.к. у меня есть только то, что шло с ним в комплекте с примереми программ (если нужно могу поделиться).
Пишите naslednik_djon@rambler.ru
Помимо торможения самого модуля, могут быть, наверное, еще вот какие заморочки:
1. Версии (или ревизии) самих MVI. Дело в том, что на втором объекте у нас MVI более древние.
Не могли бы Вы написать, какие конкретно версии (ревизии) MVI используются у вас на объектах? У нас тоже проблемы с MVI56-ADM (см. тему Проблемы и пути их решения -> Проблема с MVI56-ADM), так что есть с чем сравнить
Ревизии модулей, как видите, практически совпадают, однако во втором случае пришлось немножко подправить программу (см. выше).
Помимо того, что имеем разные процессоры, MVI модули у нас тоже разных поставок и отличаются надписью на передней панели: во втором случае - это надпись "MVI", а в первом "1756-MVI" (по памяти, перед глазами сейчас модулей нет).
Что касается программ, которые крутятся в модулях, то их структура принципиально совпадает, за исключением типа опрашиваемых приборов по RS232 (разница в структуре посылки).
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна. Открытие страницы: 0.129 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
