Комплексная диспетчеризация бизнес-центра

(*Проверка занятости*)

IF NOT fb_FB_ReadWrite_OnChange_36B.ReadBusy THEN

(* Чтение Lon - данных *)

СASE fb_FB_ReadWrite_OnChange_36B.NV_Index OF

    10: (*Порядковый номер переменной входа на контроллере Beckhoff*)

Result:=MEMCPY(ADR(SHUV1), ADR(fb_FB_ReadWrite_OnChange_36B.ParameterReadvalue)  , 8);

(*8 –  длина переменной, 8 байт*)

(* Сдвиг на 32 бита для чтения второй переменной*)

SHUV11:=SHR(SHUV1,32);

 

(*Конец  цикла*)

END_CASE

END_IF

Для создания для модуля Kl6401 сетевых переменных, для их конфигурирования и присвоения уникальных порядковых номеров, используется специальная утилита «KS2000». Имеется возможность создать и одновременно использовать до 63 входных/выходных переменных. 

Создаём в KS2000 таблицу с переменными, для каждой указываем нужный нам тип, номер и настройку «nvi» - для входных и «nvo» - для выходных переменных.

Рисунок 4.2.

Конфигурирование  модуля KL6401 c помощью KS2000

Как можно  видеть из рисунка 4.2, с помощью KS2000 осуществляется настройка Neuron ID, универсальный номер, который пригодится нам в дальнейшем при присоединении контроллера Beckhoff к проекту в LonMaker.

После того, как выставлены и сконфигурированы все входы – выходы нашей 

KL6401, мы производим загрузку нашей конфигурации в модуль и сохраняем её на жёсткий диск компьютера. Конфигурационный файл с разрешением .XML потребуется нам позднее. После того, как отконфигурирован  модуль Kl6401, настроен программный код для чтения/записи необходимых параметров, приступим к конфигурирования Lon – сети.

Для этого  понадобится сетевой адаптер  «Echelon» FT/TP и лицензированное программное обеспечение «Echelon LonMaker» с необходимым количеством «кредитов», снимаемых автоматически при добавлении устройств.

После создания и конфигурации свойств проекта  в LonMaker, открывается Microsoft Visio, программное обеспечение для редактирования Lon – сетей. Контроллер Beckhoff  BC9020 добавляется по уникальному Neuron ID и по XIF – файлу, полученному с помощью KS2000.  После этого в проект добавляются все остальные контроллеры управления вентиляции, для них Neuron Id берутся из технической документации, Xif – файлы предоставляет производитель.

Создание  связей осуществляется методом «Drag&Drop», то есть простым «перетаскиванием» выхода одного устройства на вход другого. Готовый проект выглядит следующим образом:

 

 

 

 

 

 

 

 

 

 

 

 

Рисунок 4.3

Конфигурация  сети в Lon – Maker для контроллеров вентиляции нижних этажей БЦ «Антарес»

 Справа  на схеме располагается сетевая  конфигурация контроллера BC9020, левее – контроллеры «Corrigo E» из 15 и  13 щита управления вентиляцией соответственно. Из рисунка 4.3 можно видеть, что на контроллер «Beckhoff» выведены лишь некоторые из возможных параметров, такие как «nvoAlarm», «nvoFrostProtect» (температура охладителя), «nvoRunMode» (состояние установки).

 При  наладке связей возникли неполадки,  связанные с частичной потерей  команд из – за «коллизии»  устройств. Она связаны с тем,  что топология соединения контроллеров  «шлейф», когда рекомендуемое  соединение для сетей Lon – «звезда». В данном проекте топология «звезда» не применима, т.к. она требует прокладки нескольких километров дорогостоящих двухжильных проводов типа «lonworks». Проблему удалось решить подстройкой уникальных интервалов опросов для каждого контроллера и установкой специализированого

терминатора «Echelon», устройства, усиливающего сигнал. Более того, со временем необходимость в нём пропала – Neuron – чипы в контроллерах путём автоматической настройки и тестов смогли убрать коллизию вовсе.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4.3 Наладка  связей с контроллерами управления  вентиляцией по протоколу «Modbus RTU»

 

4.3.1. Краткие  сведения о протоколе «Modbus RTU».

 

Modbus разработан фирмой Modicon (в настоящее время принадлежит Schneider Electric) для использования в контроллерах с программируемой логикой. Впервые спецификация этого протокола была опубликована в 1979 году. Это был открытый стандарт, описывающий формат сообщений и способы их передачи в сети различных электронных устройств.

Первоначально контроллеры MODICON использовали последовательный интерфейс RS-232. Позднее  стал применяться интерфейс RS-485, так  как он позволяет использовать более длинные линии связи и подключать к одной линии несколько устройств.

Многие производители электронного оборудования поддержали протокол Modbus, на рынке появились сотни использующих его изделий. Сейчас развитием протокола занимается некоммерческая организация Modbus-IDA. Она основана производителями и пользователями электронных приборов.

Modbus относится к протоколам прикладного уровня сетевой модели OSI. В соответствии с ним контроллеры взаимодействуют, используя клиент-серверную модель, основанную на транзакциях, состоящих из запроса и ответа.

Он определяет как Master (MS) и Slave (SL)

1.Устанавливают и прерывают контакт,

2.Идентифицируются отправитель и получатель,

3.Устонавливают   каким образом происходит обмен  сообщениями,

4.Устонавливают  как обнаруживаются ошибки.

Протокол  управляет циклом запроса и ответа, который происходит между устройствами MS и SL, как показано на рисунке 4.4

Рисунок 4.4.

Топология сети «Modbus RTU»

Протокол подразумевает на общей  шине один MS и до 247 SL. Хотя протокол и поддерживает до 247 SL, некоторые приборы ограничивают число SL, подключаемых к общей шине. Например, драйвер шины расходомера-счетчика УРСВ-10М позволяет подключить к одному сегменту двухпроводной линии RS485 максимум 32 прибора. Каждому SL присвоен уникальный адрес устройства в диапазоне от 1 до 247.

Только  MS может инициировать транзакцию. Транзакции бывают либо типа запрос/ответ (адресуется только один SL), либо широковещательные/без ответа (адресуются все SL). Транзакция содержит один кадр запроса и один кадр ответа, либо один кадр широковещательного запроса.

Некоторые характеристики протокола Modbus фиксированы. К ним относятся: формат кадра, последовательность кадров, обработка ошибок коммуникации и исключительных ситуаций, и выполнение функций.

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

1.Тип средства связи,

2.Скорость обмена,

3.Проверка на четность,

4.Число стоповых бит,

5.Режим передачи (ASCII или RTU).

 Параметры,  выбираемые пользователем, устанавливаются  (аппаратно или программно) на  каждой станции. Эти параметры  не могут быть изменены во  время работы системы.

При передаче по линиям данных, сообщения помещаются в «конверт». «Конверт» покидает устройство через «порт» и «пересылается» по линиям адресуемому устройству. Протокол Modbus описывает «конверт» в форме кадров сообщений. Информация в сообщении представляет адрес требуемого получателя, что получатель должен сделать, данные, необходимые для выполнения этого, и механизм контроля достоверности.

Когда сообщение  достигает интерфейса SL, оно попадает в адресуемое устройство. Адресуемое устройство вскрывает конверт, читает сообщение, и, если не возникло ошибок, выполняет требуемую задачу. Затем оно помещает в конверт ответное сообщение и посылает его «отправителю». Информация в ответном сообщении представляет собой адрес SLAVE устройства, выполненную задачу, данные, полученные в результате выполнения задачи, и механизм контроля достоверности. В большинстве случаях, MS посылает следующее сообщение другому SL либо после приема корректного ответного сообщения, либо после прохождения определенного пользователем интервала времени, если ответное сообщение не был получено. Все сообщения могут рассматриваться как запросы, генерирующие ответные сообщения от SL. Широковещательные сообщения могут рассматриваться как запросы, не требующие ответных сообщений от SL.

Основа структуры запросов и  ответов протокола Modbus – элементарный пакет протокола, так называемый PDU (Protocol Data Unit). Структура PDU протокола Modbus не зависит от типа линии связи и включает в себя код функции и поле данных. Код функции -  это однобайтовое поле. Оно может принимать значения в диапазоне 1…127. Значения 128…255 зарезервированы для кодов ошибок. Поле данных может быть переменной длины. Размер пакета PDU

 

ограничен 253 байтами.

 

 4.3.2. Наладка связей с контроллерами системы вентиляции «Corrigo», поддерживающими коммуникационный протокол «ModBus RTU».

 

Работа  с протоколом будет осуществляться с помощью коммуникационного  модуля RS – 485 Kl6041.        Рисунок 4.4.

Схема подключения  к коммуникационному модулю «Kl6041»

 

 

 

 

 

 

 

 

 

 

 

 

 
     

   Для коммуникации используется  специализированные библиотеки  для Modbus RTU, включающие в себя стандартные функциональные блоки чтения и записи регистров, а также блоки диагностики ошибок телеграмм.

Далее представлен  отрывок программного кода  чтения регистров 959 и 

 

40960.

CASE state OF

0: MB.ReadRegs(Execute:= FALSE); (*Начала цикла запросов *)

state := state + 1;

 

1: (* Read MBdata[20..40] from terminal address 100 *)

MB.ReadRegs(

UnitID:=1,(* Адрес устройства *)

Quantity:=1, (* Количество регистров для сч-я*)

MBAddr:=959,

cbLength:= 2, (*Длина телеграммы *)

pMemoryAddr:= ADR(MBVENT[1]), (*Адрес записи*)

Execute:= TRUE,

Timeout:= timeoutvalue,

Busy => busy );

NextStepTimer(IN:=TRUE,PT:=t#2s); (*Задержка между чтением регисторов*)

IF NOT busy AND NextStepTimer.Q  THEN

MB.ReadRegs(Execute:= FALSE);

NextStepTimer(IN:=FALSE);

state := 2;

END_IF

 

2: (* Чтение 2 адреса *)

MB.ReadRegs(

UnitID:=1,(* station address *)

Quantity:=1, (* WORDs *)

MBAddr:=40960,

cbLength:=2, 

pMemoryAddr:= ADR(MBVENT[2]),

 

Execute:= TRUE,

Timeout:= timeoutvalue,

Busy => busy );

NextStepTimer(IN:=TRUE,PT:=t#2s);

IF NOT busy AND NextStepTimer.Q  THEN

MB.ReadRegs(Execute:= FALSE);

NextStepTimer(IN:=FALSE);

state := 0;

END_IF

 

Параметр 959 запрашивает данные о текущем  режиме работы данного контура системы  вентиляции, параметр 40960 – информацию об авариях. Данные стали приходить  сразу же после запуска контроллера, дополнительная настройка с помощью  KS2000 не потребовалась.