This is topic IEC 60870-101 in forum TRACE MODE 6 бесплатная Базовая версия / TRACE MODE 6 free Base version at Форум TRACE MODE: техническая поддержка.
Здравствуйте! Помогите, пожалуйста, разобраться с протоколом МЭК. Мне необходимо прочитать значение дискретного выхода по адресу 5. Почитав справку создал три канала UniversalPLC_type3 (группа Источники/Приемники.Пользовательские_драйверы.TYPE12). Параметры такие служедбный канал Параметр#1 0x0 Параметр#2 0x7 Параметр#3 0x0 Параметр#4 0x0 Параметр#5 0x0 Направление Input Тип данных Integer Дополнительно IEC; ASDU=<1>; COT=<1>; IOA=<1>; LAD=<1>;
Канал запроса данных Параметр#1 0x0 Параметр#2 0x7 Параметр#3 0xf1 Параметр#4 0x0 Параметр#5 0x0 Направление Output Тип данных Integer Дополнительно IEC;
Канал приёма данных Параметр#1 0x0 Параметр#2 0x7 Параметр#3 0x1 Параметр#4 0x40 Параметр#5 0x5 Направление Input Тип данных Integer Дополнительно IEC; Запускаю профайлер, он шлет запросы $10 $49 $07 $00 $50 $16 ------- В нем адрес двухбайтовый 0007, но я задал длину адреса один байт LAD=<1>; (LAD – размер (число байт) адреса контроллера (значение по умолчанию – 1) В чем проблема?
Posted by Nico (Участник № / Member № 5342) on :
< , > - не нужны
Posted by robot14 (Участник № / Member № 6741) on :
Спасибо, помогло!
Posted by robot14 (Участник № / Member № 6741) on :
Еще вопрос. Служебный канал для записи данных должен иметь направление input или output?
Posted by Nico (Участник № / Member № 5342) on :
input
Posted by robot14 (Участник № / Member № 6741) on :
Ну что-то никак не могу записать в устройство данные. По справке создал два канала. служедбный канал Параметр#1 0x0 Параметр#2 0x7 Параметр#3 0x0 Параметр#4 0x0 Параметр#5 0x0 Направление Input Тип данных Integer Дополнительно IEC; ASDU=1; COT=1; IOA=1; LAD=1;
и канал Выход 1 Параметр#1 0x0 Параметр#2 0x7 Параметр#3 0x45 Параметр#4 0x46 Параметр#5 0x1 Направление Output Тип данных Integer Дополнительно IEC;
В профайлере в служебном канале при установке атрибута (009)Q в 1 имеем обмен Master 10 49 07 50 16 slave 10 2B 07 32 16 Master 10 40 07 47 16 slave 10 20 07 27 16 и все. В канале Выход 1 манипуляции с этим атрибутом ни к чему не приводят. Подскажите, где ошибка, почему не передается ASDU 45?
Posted by Nico (Участник № / Member № 5342) on :
.изменения значения канала независимо от его направления (in,out) производятся через его атрибут вход(2) 0x45 - это в 16ой а нужен 45 в 10ой
Posted by robot14 (Участник № / Member № 6741) on :
спасибо, попробую
Posted by robot14 (Участник № / Member № 6741) on :
Спасибо за советы, обмен наладился. Но появился еще вопрос. TRACE MODE отправляет ASDU45 с прямой (непосредственной) командой. Возможно ли реализовать двухступенчатую команду (выбор и исполнение)?
Posted by Nico (Участник № / Member № 5342) on :
.автоматически нет .а так берется байт из выходного значения канала и посылается, формируйте старший бит сами
Posted by robot14 (Участник № / Member № 6741) on :
Понятно, спасибо!
Posted by robot14 (Участник № / Member № 6741) on :
Доброго времени суток! Хотел бы ещё спросить - почему сразу после передачи команды ТУ TRACE MODE отправляет "Запрос статуса канального уровня"? Посылка выглядит вот так 68 08 08 68 53 07 2D 01 06 07 01 01 97 16 10 49 07 50 16 Кроме того часто второй бит имеет неправильный формат 68 28 08 68 53 07 2D 01 06 07 01 00 96 16 10 49 07 50 16
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. "Запрос статуса канального уровня" в соответствии со стандартом осуществляется периодически, что бы при получении положительного ответа ("Есть данные") запросить данные класса 1. В данном случае имеет место простое совпадение по времени передачи команды ТУ и "Запроса статуса канального уровня".
2. В соответствии со стандартом в последовательности передаваемых клиентом команд управления и при посылках данных сервером бит 0x20 второго байта должен постоянно изменяться (1/0). Это делается для контроля передачи данных.
Posted by robot14 (Участник № / Member № 6741) on :
1. Здесь я с вами согласен. Хочу лишь уточнить - можно ли избежать таких совпадений? 2. Здесь я с вами не соглашусь. ГОСТ Р МЭК 870-5-1-95 пункт 6.2.4.2.2 "Кадры с пользовательскими данными состоят из двух стартовых одинаковых слов (1-го и 4-го слов), двух одинаковых слов, определяющих число L байтов пользовательских данных (2-го и 3-го слов), пользовательских данных, слова контрольной суммы кадра и одного слова окончания. L - число от 0 до 255, выраженное в двоичном исчислении. Правила передачи: ...... R6 - приемник контролирует: ........... - идентичность двух слов, характеризующих длину L. ..........." Бит о котором вы говорите (FCB) находится в контрольном байте. В кадре фиксированной длины он второй, а в кадре с переменной длинной - пятый.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Пришлите, пожалуйста, Ваш проект на адрес техподдержки hotline@adastra.ru со ссылкой на этот пост.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Избежать указанных "совпадений" можно только если в Вашей пользовательской программе ввести принудительное управление потоком "Запрос статуса канального уровня". Мы считаем это нецелесообразным.
2. В настройках компонентов слоя "Источники/Приемники" для драйвера МЭК-101 имеется неточность в использовании ключа FCBON. В ближайшем релизе это будет устранено.
Posted by robot14 (Участник № / Member № 6741) on :
То есть на этой версии TRACE MODE телемеханику с протоколом МЭК-101 сделать не получится, так?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Указанный Вами эффект имеет место только при отсутствии корректного ответа в течение заданного таймаута. Вам было предложено временно удалить из настроек ключ FCBON. Стандартом протокола МЭК-101 это допускается.
![[Пдмигивание / Wink]](wink.gif)