uPAC-7186EG не могу связаться со слейвом по Modbus RTU

[Reasoning]

Здравствуйте, уважаемые специалисты!
Ситуация следующая: имеется контроллер uPAC-7186EG, связанный с модулями ввода/вывода - тоже "семятысячниками" по RS-485. Протокол обмена между модулями с контроллером, как известно, DCON.
Контроллер модули видит, все работает прекрасно.
Проблема возникла в необходимости связать контроллер со слейвом по Modbus RTU. Кинули витую пару на тот же COM-порт RS-485 (поскольку у этого контроллера их всего два COM1 - RS-232 и COM2 - RS-485), далее добавил в программе (используется IsaGRAF 3.55) в меню "Соединение В/В" оборудование 'mbus: Modbus RTU master' настроив на работу со слейвом. После всех манипуляций конфигурация "Соединение В/В" выглядит следующим образом:

Параметры соединения с модулями

------------------------------------------------------------
Параметры соединения со слейвом по Modbus RTU


В результате, при online отладке, IsaGRAF выкидывает в лог сообщение "Не могу открыть плату ... №10" - т.е. не видит слейв, но работает с модулями. Однако, если поменять местами оборудование 'bus7000c' и 'mbus' в "Соединение В/В", IsaGRAF снова фыркнет "Не могу открыть плату ... №10", т.е. на этот раз покажет что есть связь со слейвом, но нет с модулями! Хорошо, думаю, давайте хотя бы протестируем обмен со слейвом. Добавляю в программу функциональный блок MBUS_R со следующими параметрами: SLAVE_2010 (где 2 - номер COM-порта, 10 - NET_iD слейва (замечу, что NET_iD слейва выбран уникальный, т.е. не пересекается с идентификатором модулей) ), ADDR_1 (стартовый адрес регистра - 1), CODE_3 (функция чтения регистров хранения - 3), NUM_12 - читать 12 регистров; значения на выходе записываются в 12 internal integers. Запускаю отладку, связь со слейвом есть и шлем запросы на чтение регистров, "на том конце" слейв принимает запрос, отвечает но содержимое 12ти internal integers все по нулям! Статус блока "MBUS_R" - FALSE, т.е. ответы от слейва контроллер не получает (?).
Думаю, что вины слейва в этом нет, пробовал через конвертор RS-485-to-USB с ноутбука читать регистры слейва - все ОК.
Ну и собственнно, вопрос - как быть? Сталкивался ли кто-то с опытом подвязки слейвов на данный контроллер по Modbus RTU, при этом сохраняя работу с модулями? Проблема программного рода или не стоит вообще пытаться на один COM2-порт вешать и модуля и слейвы?
Буду признателен за любые советы.

[Reasoning]

Сейчас прочитал в спецификации Modbus RTU что при отстутствии проверки четности требуется выставлять два стоповых бита. Может быть причина в этом?

[MuadDib]

Как вы уже сами убедились, ISaGRAF не позволяет подключать 2 разных устройства к одному и тому же последовательному порту. Это не "проблема программного рода", а ошибка при проектировании системы. Образно говоря, вы заложили одну трубу, а потом пытаетесь провести по ней и питьевую воду, и канализацию. На каждом порту должен быть один протокол обмена. Исправить ошибку можно двумя способами

1. Приобрести мезонинную плату с дополнительным последовательным портом. Есть, например, X511 с 3мя портами RS-485, а документация на библиотеку ISaGRAF утверждает, что и устройство mbus, и bus7000 поддерживают COM2 и COM3 (последний - младший из портов на мезонинной плате). Однако, сразу скажу, что я такую конфигурацию не испытывал. Мы применяли мезонинные платы с портами RS-232, и порт работал в "свободно-программируемом" режиме. О возможности работы платы X511 с ISaGRAF в качестве порта mbus (bus7000) лучше уточнить у поставщика. Но, предположительно, проблем быть не должно.
2. Использовать модули ввода-вывода из серии M-7000 и перевести всю коммуникацию на Modbus RTU.

По поводу отсутствия обмена со слейвом.

Для начала, выкините из проекта bus7000. Затем проверьте полярность (с обозначениями Data+, Data-, A, B часто бывает путаница). Проверьте все настройки последовательного порта. Действительно, рекомендация на 2 стоповых бита есть в спецификации, но на практике ей мало кто следует. Раз у вас есть контакт на ноутбуке, повторите все настройки из программы, используемой для опроса, в проекте ISaGRAF. Также учтите, что в китайской реализации Modbus master ISaGRAF номер регистра для чтения задается не так как положено по стандарту (младший регистр - 1), а так, как регистр передается в запросе протокола (т.е. нумерация идет с нуля). С этим тоже могут быть проблемы. Например, вы пытаетесь прочитать несуществующий 13й регистр, и слейв выдает код исключения.

Если ничего не помогает, приведите здесь программу, вызывающую блок MBUS_R. Будем посмотреть :)

[Reasoning]

Большое спасибо за ответ, MuadDib!

ошибка при проектировании системы

- абсолютно с Вами согласен. Однако проектировали схему и монтажом шкафа автоматики занимались более опытные сотрудники - на их опыт я полагался, и как оказалось зря. Как итог, на прошлой неделе спалили 485ый COM2 на контроллере и, как сегодня выяснилось, COM на плате слейв=девайса. Контроллер и плата слейва заменены.
По поводу платы расширения - такую идею я высказывал своему руководству, на что был получен отказ. Была еще идея повесить слейв на COM1 RS-232 (предварительно прошив контроллер, чтобы COM1 расценивался как мастер-порт). Но необходимого конвертера 485-to-232 для подключения слейва тоже не оказалось. Кстати такой вариант вообще возможен?
Сейчас думаем кинуть витую пару на COM-порт панели Weintek MT8100i и уже ее программировать на опрос слейва и пересылать значения в контроллер по Modbus TCP, т.е. панель будет в роли буфера :) На первый взгляд - встроенный язык сценариев в EasyBuilder8000 позволяет это сделать. Как думаете, жизнеспособная идея?

[MuadDib]

Была еще идея повесить слейв на COM1 RS-232 (предварительно прошив контроллер, чтобы COM1 расценивался как мастер-порт). Но необходимого конвертера 485-to-232 для подключения слейва тоже не оказалось. Кстати такой вариант вообще возможен?

Возможен. Порты с 1го по 3й поддерживаются в качестве Modbus master (не более двух одновременно; есть ограничение и на количество функциональных блоков MBUS_... в проекте). Главное, чтобы конвертер 232-485 правильно переключал прием/передачу. Модель конвертера не подскажу, т.к. такую конфигурацию оборудования мы никогда не собирали.

Сейчас думаем кинуть витую пару на COM-порт панели Weintek MT8100i и уже ее программировать на опрос слейва и пересылать значения в контроллер по Modbus TCP, т.е. панель будет в роли буфера :) На первый взгляд - встроенный язык сценариев в EasyBuilder8000 позволяет это сделать. Как думаете, жизнеспособная идея?

Да, так сделать можно. Но, сами понимаете, функции контроллера в таком случае будут завязаны на работу HMI-панели. Если панель отключена или перезагружается, контроллер не будет получать данные от слейва и не сможет им управлять. Пострадает и скорость обмена (циклический скрипт Weintek однозначно ворочается медленнее, чем цикл ICPDAS). Приемлемо это или нет - решать вам.

[Reasoning]

MuadDib, позвольте еще задать вопросы не совсем по теме:
1) как я уже говорил, по Modbus TCP контроллер у нас связан c Вайнтековской панелькой. Периодически пропадает связь (панель выводит собщение что-то вроде "PLC not connected") на 2-3 секунды и снова восстанавливается. В EasyBuilder8000 в настройках соединения выставлен лимит на таймаут - 1 секунда. Неужели это мало?
2) в связке имеется два 6ти канальных модуля аналогового ввода i-7015, на которые поступают показания с 8ми датчиков температуры (6ть на первый и 2а на второй модуль соответственно). Температура считывается, все ОК. Далее, в программе показания температуры сверяются с уставками (хранящимися в EEPROM) на предмет предупредительных/аварийных значений.
Запускаю программу - все нормально, входные показания в пределах нормы, температура 29-31 градус. В уставках предупредительные/аварийные значения выставлены от 60-70 град. и выше. В какой-то произвольный момент у меня отображается в отладчике что по всем датчикам сработали и предупредительные, и аварийные триггеры. Хотя, в этом же отладчике (список шпиона в IsaGRAF) значения температуры отображаются те же. Пробовал в программе ставить выдержку по аварии - 1.5 секунды - бестолку. При этом предупрждение/авария продолжает сохраняться (хотя алгоритмически, после падения температуры ниже критической аварии сбрасываются) вплоть до перезапуска программы. Перезапуск программы - и снова все ок, до определенного момента... Может быть это имеет значение - работы со шкафом автоматики ведем в цеху, где постоянно проходят сварочные работы, а в непосредственной близости находится высоковольтная ячейка, подающая напряжение на двигатель 10 кВ. Хотя, в принципе, такое происходит вроде и когда ячейка отключена

[MuadDib]

MuadDib, позвольте еще задать вопросы не совсем по теме:
1) как я уже говорил, по Modbus TCP контроллер у нас связан c Вайнтековской панелькой. Периодически пропадает связь (панель выводит собщение что-то вроде "PLC not connected") на 2-3 секунды и снова восстанавливается. В EasyBuilder8000 в настройках соединения выставлен лимит на таймаут - 1 секунда. Неужели это мало?

У нас постоянно используется такая связка, причем с более медленными контроллерами 7188EG. Периодических пропаданий связи никогда не было. Проверьте следующее:

• Как осуществляется связь между контроллером и панелью? Если через некую сетевую инфраструктуру, попробуйте соединить через свич или вообще кроссом и посмотреть, изменится ли что.
• Пропадание связи на 2-3с может быть вызвано перезагрузкой контроллера. Сделайте в проекте программный счетчик перезагрузок. Создайте примерно такую программу:
[code] IF (NOT init) THEN init := true; RebootCounter := RebootCounter + 1; END_IF; [/code] Здесь init - обычная булевая переменная, а RebootCounter - целочисленная переменная с выставленной галкой Retain (Хранить), что позволит системе восстанавливать ее значение после перезагрузки. Если после очередного пропадания связи RebootCounter возрастет, нужно будет искать причину перезагрузок.
• Нет ли существенных замедлений цикла контроллера вашими алгоритмами? Конечно, 3 с - это что-то из ряда вон, таргет на контроллере такого допустить не должен, но чем черт не шутит... Попробуйте сделать элементарный проект на контроллере, скажем одна программка, которая увеличивает целочисленную переменную раз в секунду. Будут ли пропадания связи в таком случае?

2) в связке имеется два 6ти канальных модуля аналогового ввода i-7015, на которые поступают показания с 8ми датчиков температуры...

У нас такие контроллеры по жизни стоят рядом с высоковольтными ячейками, и я ни разу не видел срабатывающих без причины и "залипающих" триггеров. Пожалуйста, приведите фрагмент программы, где вы формируете предупредительные и аварийные сигналы (и исходный вариант, и вариант с выдержкой времени 1,5 с).

[Reasoning]

MuadDib спасибо за советы. Сегодня немного поправил программу. Обнаружил небезопасный вызов функции 'eep_wd_r':

Код: Выделить всё

if My_Write_to_EEP
	then
	TEMP:=eep_en();
	
	TEMP2:=eep_wd_w(2,PUstAvTempOp);
	...
	TEMP1:=eep_wd_w(20,PUstAvTempElectrolita);
	TEMP11:=eep_pr();
	My_Write_to_EEP:=false;
END_IF; 

	UstAvTempOp:=eep_wd_r(2);
	...
	UstAvTempElectrolita:=eep_wd_r(20);

Т.е. запись в EEPROM производилось корректно, а вот чтение, получается, происходило каждый программный цикл. Изменил на

Код: Выделить всё

if My_Write_to_EEP
	then
	ReadOnce:=false;
	TEMP:=eep_en();
	
	TEMP2:=eep_wd_w(2,PUstAvTempOp);
	...
	TEMP1:=eep_wd_w(20,PUstAvTempElectrolita);
	TEMP11:=eep_pr();
	My_Write_to_EEP:=false;
END_IF; 

IF (NOT ReadOnce) THEN
	ReadOnce:=true;

	UstAvTempPodPrivMeh:=eep_wd_r(6);
        ...
	UstPrTempStat:=eep_wd_r(18);
END_IF;

Сегодня несколько часов гонял программу на контроллере - вроде все нормально, значение 'RebootCounter' не увеличивалось. Со связью с панелью проблем тоже пока не заметил, хотя контроллер преимущественно находился подключенным к ноутбуку.

Пожалуйста, приведите фрагмент программы, где вы формируете предупредительные и аварийные сигналы (и исходный вариант, и вариант с выдержкой времени 1,5 с).

Код был написан так. Для предупредительных сигналов:

Код: Выделить всё

if ((iTempPodProtivPrivMeh>=UstPrTempPodPrivMeh) and not ObTempPodProtivPrivMeh)
then
	PrTempPodProtivPrivMeh:=true;
ELSIF  ((iTempPodProtivPrivMeh < (UstPrTempPodPrivMeh-2))and not ObTempPodProtivPrivMeh)
					then
							PrTempPodProtivPrivMeh:=false;

end_if;

где 'iTempPodProtivPrivMeh' - преобразованное значение температурного датчика (входное значение делится на 100 для округления), 'UstPrTempPodPrivMeh' - уставка, хранящаяся в EEPROM, 'ObTempPodProtivPrivMeh' - проверка нет ли обрыва этого датчика (проверяется в другой процедуре). По такому же принципу срабатывает и аварийный триггер, только сравнения с аварийной уставкой:

Код: Выделить всё

if ((iTempPodProtivPrivMeh>=UstAvTempPodPrivMeh) and not ObTempPodProtivPrivMeh)
then
	AvTempPodProtivPrivMeh:=true;
ELSIF  ((iTempPodProtivPrivMeh < (UstAvTempPodPrivMeh-2))and not ObTempPodProtivPrivMeh)
					then
							AvTempPodProtivPrivMeh:=false;

end_if;

И так на все 8мь датчиков. Потом завожу все в две переменные предупредительную и аварийную по температуре, затем в общиие переменные аварии и предупреждения:

Код: Выделить всё

MyTempPred:=(PrTempPodPrivMeh or PrTempPodProtivPrivMeh
or PrTempStatA or PrTempStatB or PrTempStatC
or PrTempStatA1 or  PrTempStatB1 or PrTempStatC1);


MyTempAvar:=(AvTempPodPrivMeh or AvTempPodProtivPrivMeh
or AvTempStatA or AvTempStatB or AvTempStatC
or AvTempStatA1 or AvTempStatB1 or AvTempStatC1);

My_Avar:=(MyTempAvar or not AvarStop or Avar_UMPCH or not UMPCH_Isprav or AvarStop_A7);
My_Pred:=(MyTempPred or WireBreak or not NapriajNorm);

C выдержкой по времени (добавив экземпляры FB 'TON') выглядело так:

Код: Выделить всё

ton_b1 (MyTempAvar, t#1500ms);
MyTempAvarValid:=ton_b1.q;
ton_b2 (MyTempPred, t#1500ms);
MyTempPredValid:=ton_b2.q;

My_Avar:=(MyTempAvarValid or not AvarStop or Avar_UMPCH or not UMPCH_Isprav or AvarStop_A7);
My_Pred:=(MyTempPredValid or WireBreak or not NapriajNorm);

Надеюсь все же проблема была в вызове функции чтения из EEPROM.

[MuadDib]

Процесс записи в EEPROM - вещь сравнительно длительная, а вот чтение должно выполняться на несколько порядков быстрее. С другой стороны, неизвестно, что там наворотили разработчики таргета. Если устранение излишних вызовов фукнций eep_...() действительно помогло, проблема вполне могла быть связана с ними.

В вашем коде ничего особо криминального я не вижу. Единственный момент, вы вроде как пытались бороться с излишними срабатываниями (запоминанием "лишней" тревоги/аварии), а выдержку времени поставили _после_ запоминания.

Кстати, код, подобный вашему сравнению с аварийными границами, проще всего выполнять в виде FBD или LD программ. При отладке такой программы вы сразу видите состояние всех участвующих в деле переменных, и становиться проще понять, почему срабатывает или не срабатывает тот или иной триггер. При составлении и просмотре длинных "списков шпиона", легко пропустить что-то важное или что-нибудь перепутать, а в "графических" языках все видно в виде компактной схемы. Да и воткнуть выдержку времени в FBD/LD гораздо проще.