This is topic Драйвер для последовательного интерфейса. Каналы вывода. in forum TRACE MODE 5 бесплатная версия / TRACE MODE 5 Free version at Форум TRACE MODE: техническая поддержка.


To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/18/t/000004.html

Posted by Lisachev Peter S. (Участник № / Member № 89) on :
 
Привет всем!

Вот тут возникла одна проблемка. Может кто сталкивался?
Есть протокол для работы с неким контроллером. Причем в нем есть команды, отправляемые в контроллер, которые состоят из НЕСКОЛЬКИХ параметров (допустим К штук). Ответом из контроллера будет также К штук параметров в одном сообщении.
Для реализации в Трейс-Моуд решено было использовать К + 1 канал типа ВЫВОД (К информационных и один -- сигнал о том (канал С), что пора начать передачу) и К каналов типа ВВОД.
Пользователь вводит значения К каналов типа ВЫВОД, а я в драйвере их сохраняю -- ИМЕННО СОХРАНЯЮ, никакого отправления НЕ ПРОИСХОДИТ. Затем, при нажатии на кнопку (Готово) посылаю в канал С единицу (начать передачу) и в драйвере формирую отправляемое сообщение.
Но проблема состоит в том, что когда не происходит отправления для канала типа ВЫВОД (в функции Set_xxx), МРВ НЕ ВЫЗЫВАЕТ для этого канала функцию Get_xxx, в которой можно выставить признак окончания передачи, и для этого канала ПРОДОЛЖАЕТ ВЫЗЫВАТЬСЯ функция Set_xxx.
Каким образом можно сбросить это значение канала С или как можно остановить вызовы Set_xxx для каналов ВЫВОД, если в предыдущем Set_xxx отправления не было?
И непонятно, глюк это ТМ или фича? И если глюк, то когда (в какой версии) будет поправлен?

Заранее спасибо за ответы.
 


Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Это НЕ ОШИБКА ТРЕЙС МОУД.
По спецификации функций вызова драйвера типа КОНТР_1 драйвер должен в функции Set_xxx сформировать значения max_send и max_rec - количество передаваемых и принимаемых байтов.
Если эти параметры будут равны 0 и возвращаемое функцией Set_xxx будет также равно 0, МРВ не будет обращаться к RS и перейдет к обработке следущего канала базы.
При этом на канале "без передачи" не будет выставляться флаг НЕДОСТОВЕРНОСТИ.
Канал управления передачей должен получить от драйвера параметры передачи с указанием буфера для посылаемой строки. Далее обработка этого канала должна идти по штатному алгоритму.
 
Posted by Lisachev Peter S. (Участник № / Member № 89) on :
 
"Это НЕ ОШИБКА ТРЕЙС МОУД."
Понятно, спасибо.

... дальше пропущено -- документацию уже читали-с ...
но дело-то в том, что этот канал (у которого в Set_xxx max_rec == 0 && max_send == 0) будет опять (на следующий цикл) вызван для передачи!!! И так бесконечно!!! Вот некрасивость-то где!

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

а вот тут непонятно..."Канал управления передачей" -- что это за зверь?

Вы хотите сказать, что в любом случае, чтобы МРВ вызвал Set_xxx с этим каналом НЕОБХОДИМО ЧТО_ЛИБО ПЕРЕДАТЬ и ПОЛУЧИТЬ?


А встречал ли кто-нибудь более приемлемые способы передачи данных в драйвер? Т.е. без общения с контроллером?

Я пробовал много разных способов прекращения этого замкнутого круга. Но выход пока нашел один: поставить кнопочку, при нажатии которой в канал посылается 0.
 


Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Для того чтобы исключить повторное обращение к драйверу от каналов, формируемых групповую посылку в контроллер, надо написать простенькую FBD, которая по анализу тенденций и флагов НЕДОСТОВЕРНОСТЕЙ этих каналов управляет ПОДКЛЮЧЕНИЕМ/ОТКЛЮЧЕНИЕМ ОБЪЕКТА, в который они входят.
Тогда после отработки очередного успешного акта групповой передачи в драйвер каналы пожно ОТКЛЮЧИТЬ, а вновь ПОДКЛЮЧИТЬ только при изменении значения какого-либо из этих каналов.
Аналогичные алгоритмы управления обменом с драйвером применяются нашими пользователями.
 
Posted by Lisachev Peter S. (Участник № / Member № 89) on :
 
Спасибо, Вы прояснили ситуацию.

Другими словами, недостатки в протоколе общения ТМ с драйвером устранимы ТОЛЬКО на верхнем уровне -- написанием FBD-программы. Я уже задумывался над этим вопросом, и я уверен, что более правильно было бы расширить возможности работы с драйвером на уровне алгоритма (DATA11) работы с драйвером.

Какова вероятность того, что это свойство появится в ближайших релизах ТМ5?
 


Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
В планах ближайших релизов версии ТМ 5.0 не предусмотрена корректировка спецификации функций вызова драйверов.
 
Posted by Lisachev Peter S. (Участник № / Member № 89) on :
 
Спасибо за ответы!
 


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2