На фирме АМГТ-Ресурс (Опытное КБ АМУР №3) разрабатывается шкаф управления насосами объемного действия с каскадным подключением и отключением 9 насосов. Насосы поддерживают давление и расход в зависимости от быстроменяющихся условий.
Управление насосами производится по сетевому интерфейсу CANopen.
Для реализации выбраны частотные преобразователи ОВЕН ПЧВ-3 с картой интерфейса CANopen, контроллер на CoDeSys 3.5 на борту с интерфейсом CANopen, китайской компании INVT (от официального представителя Русэлком).
Трудностьт в том, что нет отечественных производителей программирующих логических контроллеров с CANopen. Ни фирма Овен, ни НИИ системных исследований РАН (НИИСИ) пока не производят ПЛК с CANopen. Мы хотели использовать интерфейс Ethercat на контроллерах НИИСИ, но к преобразователям ОВЕН ПЧВ-3 нужно ждать модули расширения два месяца, поэтому остановились на CANopen, он просто был в наличии.
Для проверки мы создали стенд на базе центробежного насоса. Специально приобрели более слабый преобразователь ПЧВ-3. Программное обеспечение делалось в среде разработки ДРАКОН. Создано два модуля: первый модуль — регулятор пропорционально интегральный (ПИ-регулятор). Второй модуль: машина состояния ПЧ, так как функции ПЧ нам не подошли. В этом модуле написаны рампы разгона и торможения. Как только осуществлен разгон до текущего задания, переходим в рабочий режим, где нет рамп.
В видео видна скорость работы интерфейса CANopen, для этого и создавался стенд. На этом же стенде ранее испытывались ПЧ по интерфейсу Модбус RTU, где задание передавалось циклично и вводило задержку, прибавление частоты например по рампе разгона, добавлялось ступенчато по 1,5 гц в секунду. Здесь можно увидеть что частота меняется практически в реальном времени.
Система работает так. Датчик давления через FAI отправляет показания в ПЛК, ПЛК высчитывает мощность необходимую для поддержания заданного давления. По средствам интерфейса CANopen отправляет задачу в преобразователь частоты ПЧ, от ПЧ получает обратную связь о текущем состояний ПЧ. Скорость интерфейса 1 мбит/с
Авторы Алексей Муравицкий и Алексей Степанов.
CANopenCANopen — открытый сетевой протокол верхнего уровня для подключения встраиваемых устройств в бортовых транспортных и промышленных сетях. В качестве сетевого и транспортного уровня использует протокол реального времени CAN. Используется для связи датчиков, исполнительных механизмов и программируемых логических контроллеров между собой. Открытый стандарт.
Содержание1 Типичные области применения
2 Достоинства
3 Недостатки
4 Перспективы
5 Структура стандартов
6 Промышленные сети семейства CAN
7 См. также
8 Примечания
9 Ссылки
Типичные области примененияВ основном в системах управления перемещением, в сборочных, сварочных и транспортировочных агрегатах. Используется для однокабельного соединения многовходовых блоков датчиков, интеллектуальных датчиков, пневматических вентилей, считывателей штрихкодов, приводов и операторских пультов.
ДостоинстваПо сравнению с другими сетями на базе шины CAN, сеть CANopen в большей степени пригодна для быстродействующих систем управления перемещением и контуров регулирования с обратной связью. Высокая надёжность, рациональное использование пропускной способности, подача питающего напряжения по сетевому кабелю.
НедостаткиМалая распространённость за пределами Европы.
ПерспективыПомимо протокола прикладного уровня, CANopen означает членство в клубе разработчиков аппаратуры "по интересам". Подробнее можно узнать на сайте CiA (
www.can-cia.org). Вступить в данную организацию могут все, кто посчитает это нужным. Организация объединяет в том числе и ведущих производителей автомобилей в Европе.
Структура стандартовСтруктура организации перекликается со структурой стандартов регламентирующих работу CANopen-сетей.
В основе протокола прикладного уровня лежит документ DS.301, который, в свою очередь, является практическим развитием идей, декларированных в документах CiA DS-201-207. Он определяет протоколы конфигурирования и функционирования сети.
CANopen-сеть ориентирована на применение микроконтроллеров, в том числе и самых дешёвых, поэтому разбивается на ряд необязательных подсистем, что позволяет использовать только лишь необходимые функции.
Функционирование сети — это обмен данными. Для понимания функционирования сети CANopen разделим все данные на функциональные и технологические.
Функциональные данные — те данные, которые описывают целевое функционирование системы (температура, величины управляющих воздействий исполнительных механизмов), те данные, которые передавались бы между блоками, даже если бы в качестве связующего звена использовалась линия связи, отличная от CAN, например, LIN или USB, или Ethernet, или I2C.
Технологические данные — те, которые обеспечивают функционирование сети в целом, контроль корректной работы всех узлов, конфигурирование частей системы — те данные, появление которых связано с использованием сети CANopen и не зависит непосредственно от задач, решаемых системой.
Документ CiA DS-201 выделяет 4 основных группы подсистем (Fig.3 CiA DS-201)
CMS — передача сообщений. Сюда относятся: обмен функциональными данными, обмен срочными сообщениями, обмен данными по запросу,
управление объектным словарём
NMT — управление сетью, контроль работы устройств сети
DBT — динамическое распределение идентификаторов
LMT — управление конфигурированием устройства
1. Обмен функциональными данными в реальном времени ключевое слово PDO, CMS (основная подсистема, в принципе необязательная, но если не будет ни одной из остальных подсистем, то данное пустое множество может называться CANopen лишь потенциально).
Пример: Система поддержания температуры в помещении основной блок, измерители температуры, нагреватели/испарители
Словарь объектов — это не подсистема ключевое слово PDO, SDO, entry, Index. Словарь используется всеми подсистемами и описывает целевые данные, которыми надлежит обмениваться, правила обмена. Можно провести параллель с реестром в Windows.
Пример: Температура в отдельных точках и параметр управления нагревателями/испарителями
2. Синхронизация обмена данными ключевое слово SYNC (необязательная, но такая же целесообразная подсистема, как и подсистема 1). При использовании данной подсистемы в сети существует генератор синхросообщений, периодически передающий высокоприоритетное сообщение SYNC. После появления в сети такого сообщения все синхронизируемые устройства производят обмен данными в течение заданного временного интервала (окно синхронного обмена данными). Коллизии (одновременная передача данных двумя и более устройствами) разрешаются на уровне физического уровня протокола CAN. Словарь объектов содержит перекрёстные ссылки, откуда какие данные взять и какие куда положить. Таким образом, приложения не занимаются самостоятельно сбором данных, просто в определённых переменных (с точки зрения приложения) периодически оказываются свежие данные аналогично с управляющими воздействиями. При этом режиме обмен может происходить не только между датчиками и основным блоком, но и между датчиками, минуя основной блок.
Асинхронный обмен данными. Включает обмен сообщениями сетевого управления (управления узлами сети) Network Management, NMT Services, сообщениями подсистемы контроля работы сети (вариант обнаружения ошибок работы сети) Error Control, срочными сообщениями — авральными объектами (обнаружение ошибок работы узлов) Emergency Object, EMCY. Сообщения данного класса могут появиться в любой момент времени, в том числе и внутри окна синхронного обмена данными. Данные сообщения имеют высокий приоритет (выше, чем сообщений, составляющих пакеты данных), а коллизии разрешаются на уровне физического уровня протокола CAN. Для реализации данных подсистем в сети назначается (на этапе проектирования сети) устройство, ответственное за работу конкретной подсистемы. Помимо этого, имеются механизмы динамического назначения подобных устройств. Теперь подробно.
3. Управление узлами сети Network Management, NMT Services (необязательная подсистема). Сеть может быть спроектирована таким образом что после включения каждый прибор, завершив инициализацию, перейдёт в состояние готовности, но при этом не будет участвовать в обмене функциональными данными до тех пор, пока мастер управления работой сети (NMT master) не разрешит его работу. В состоянии готовности устройство не принимает участия в обмене функциональными данными, но может обмениваться технологическими данными. В состоянии готовности устройство может быть сконфигурировано (см. далее Подсистема управления словарём объектов). При помощи данной подсистемы мастер сети может выполнить сброс и перезапуск любого из узлов, для которого потребуется такая процедура. Мастер получает от прибора сообщения, в которых указано реальное состояние прибора, если реальное состояние не соответствует ожидаемому, то это расценивается как ошибка. Реакции на ошибки рассмотрены ниже по тексту.
4. Контроль работы сети (обнаружение ошибок работы сети) NMT Error Control Protocols, Node Guarding, Heartbeat Protocol (необязательная подсистема). Некоторые системы (особенно связанные с безопасностью) должны контролировать наличие и исправность всех штатных датчиков.
Пример: Датчик-концевик, при срабатывании которого должен сразу отключаться двигатель.
Если сам датчик стал вдруг неисправен, то при замыкании концевика он не передаст сообщение об этом основному блоку, что чревато аварийной ситуацией, поэтому при обнаружении неисправности такого датчика необходимо сразу отключать двигатель
Обнаружение ошибок работы сети (Node Monitoring) производится двумя сходными способами[1]
I. Перекличка узлов Node Guarding. Мастер периодически опрашивает узлы, которые отвечают. Как только узел перестаёт отвечать, отмечается ошибка для этого датчика, и мастер в соответствии с логикой работы может остановить потенциально опасные процессы. Узел, который не будет опрошен в течение определённого времени (оборвалась линия), также отмечает для себя ошибку. Недостатки этого способа - запросы от мастера отнимают часть пропускной способности сети и отказ единственного узла (мастера) приводит к отказу всей сети.
II. Контрольное тактирование. Heartbeat (букв. англ. "сердцебиение"). Все узлы сети самостоятельно, без запроса, регулярно передают сообщения о своём состоянии - "heartbeat message". Если в течение контрольного интервала сообщения от какого-то узла отсутствуют, другие узлы, подписанные на его сообщения, отмечают для себя ошибку. Этот способ лишён недостатков предыдущего и рекомендован к применению в современных системах[2].
Для каждой конкретной сети допускается использование только одного способа контроля или Node Guarding или Heartbeat Protocol.
5. Изменение объектного словаря. ключевые слова PDO, SDO, PDO-mapping Объектный словарь содержит данные, которыми производится обмен по принципу PDO, описывает состав и структуру этих данных. Используя обмен данными по запросу(SDO), можно изменить набор данных, которыми будет производиться обмен по принципу PDO. Обмен SDO-данными возможен как в состоянии готовности, так и в состоянии работы. Таким образом, имеется возможность после включения питания, но до запуска функционирования сети, настроить все приборы сети на обмен нужными данными, а затем запустить сеть. Во время изменения структуры словаря во время работы следует учитывать следующие моменты:
SDO-обмен имеет более низкий приоритет, чем обмен PDO, поэтому может возникнуть момент времени, когда часть словаря уже будет изменена в соответствии с новыми требованиями, часть ещё не изменится и в этот момент произойдёт обмен PDO.
Поскольку устройства, передающие и принимающие PDO, должны понимать друг друга, то может возникнуть ситуация когда одно устройство будет работать с новой структурой, а другое - со старой.
Эти два примера показывают целесообразность изменения структуры словаря только когда сеть остановлена, к сожалению это бывает не всегда возможно.
6. Изменение данных по запросу. Помимо изменения словаря, приложение одного устройства может загрузить данные в другое устройство. Различие PDO- и SDO-обмена данными с точки зрения приложения. При обмене PDO всё происходит автоматически по определённым правилам и приложение, не обращаясь к сетевым примитивам, получает данные из переменных, как будто бы данные получаются внутри этого самого прибора. Для получения данных по принципу SDO приложение должно при помощи сетевых сервисов запросить данные у другого устройства, и только потом, получив ответ, использовать данные для работы. Поэтому основу-хребет обмена данными следует строить на PDO-обмене. К сожалению, имеются ограничения на размер данных(8 байт для PDO, но можно использовать несколько таких штук). И только при особой необходимости использовать SDO. При SDO-обмене данными устройство, к которому обратились с запросом на получение или запись (dowload/upload) данных, называется SDO-сервером, а устройство, которое инициировало обмен, называется клиентом. В зависимости от объема передаваемых данных обмен производится по разным алгоритмам и может быть не менее эффективен, чем PDO-обмен. SDO-обмен допускает производить контроль безошибочности данных, что позволяет даже загружать куски исполняемого кода.
7. Авральные объекты, срочные сообщения.Emergency Object, EMCY. В процессе работы прибор может обнаружить ошибки в работе своей программы или в работе электроники. В таком случае чем скорей об этом будут оповещены все остальные части системы, тем будет лучше и работа такой системы будет безопасней. Для этой цели используются высокоприоритетные срочные сообщения. Такие сообщения посылаются в момент обнаружения неисправности и в момент исчезновения этой неисправности. Стандарт описывает классы ошибок, такими параметрами могут быть ток, напряжение, температура. Если в сети задействован механизм срочных сообщений, то устройства обязаны понимать по крайней мере два сообщения — Общая ошибка (без уточнения категорий), сброс ошибки. Каждый тип ошибки может быть уточнён ещё целым байтом, который может кодировать например номер контролируемой цепочки.
Обработка ошибок. Базовый стандарт описывает только способы оповещения об ошибках и задаёт категории ошибок. Дальнейшие уточнение и реакция на ошибку определяется разработчиком системы.
Приведённые выше пункты описываются в документах CiA DS-201-207 и CiA DS-301. Разработчик системы «с нуля» может самостоятельно определить функциональные требования к сетке, контролируемые параметры и сценарии поведения при появлении неисправностей. Но поскольку CANopen-сети использует большое количество производителей, которые уже разработали системы, охватывающие множество сфер промышленности, то появились рекомендации того, какими параметрами, как минимум, должна оперировать та или иная система, и какие типы реакций на те или иные конкретные ошибки, которые свойственны конкретному классу устройств. Данные рекомендации оформлены в виде стандартов серий CiA DS-4**. Это позволяет производить не системы в целом, а части систем, и эти новые приборы будут прекрасно интегрироваться с системами, разработанными именитыми производителями. Часть этих стандартов уже открыта (устоявшиеся), часть остаются достоянием небольших групп производителей (новые, подверженные изменениям). Основная причина того, что существует так много закрытых документов - то, что это не просто рекомендации, но стандарты, при несоблюдении которых нарушается работоспособность системы. При внесении изменений в документы новые версии рассылаются всем участникам данной группы «по интересам». Группы по интересам не являются замкнутой кастой, все желающие могут вступить в ту или иную группу. Обязательным условием является денежный взнос. Взимаемые суммы зависят от размера фирмы и являются демократичными по отношению к малому бизнесу.
РАЗМЕР ФИРМЫ ЧЛЕНСКИЙ ВЗНОС (ГОД) С УЧЁТОМ ГЕРМАНСКИХ НАЛОГОВ
более чем 100 000 сотрудников: 8 700,00 Euro 10 353,00 Euro
от 10 000 до 99 999 сотрудников: 5 200,00 Euro 6 188,00 Euro
от 1 000 до 9 999 сотрудников: 4 100,00 Euro 4 879,00 Euro
от 100 до 999 сотрудников: 2 100,00 Euro 2 499,00 Euro
от 50 до 99 сотрудников: 1 500,00 Euro 1 785,00 Euro
от 10 до 49 сотрудников: 900,00 Euro 1 071,00 Euro
от 1 до 9 сотрудников: 650,00 Euro 773,50 Euro
для школ и университетов : 520,00 Euro 618,80 Euro
Все данные, касающиеся того, какие группы существуют, какие стандарты они выработали и как к ним подключиться, находятся на сайте can-cia.org, который в данном случае является основным организационным органом и механизмом связи с общественностью.
Промышленные сети семейства CANCANbus
DeviceNet
Вход
FAQ
Поиск
