CODESYS форум

Добро пожаловать на официальный форум CODESYS
Deutsche Version English version russian version 
Текущее время: Вс май 28, 2017 1:55 am

Часовой пояс: UTC+01:00




Начать новую тему  Ответить на тему  [ 17 сообщений ]  На страницу 1 2 След.
Автор Сообщение
 Заголовок сообщения: Свой ПЛК с CoDeSys
СообщениеДобавлено: Сб сен 22, 2007 11:40 am 
Не в сети

Зарегистрирован: Пн сен 03, 2007 10:44 am
Сообщения: 0
Наша компания разрабатывает электронику на заказ, в том числе контроллеры. Программируем обычно на языке Си. В одной работе возникла необходимость сделать специализированный встраиваемый контроллер, но желательно чтобы пользователь мог сам его программировать, лучше всего на языках МЭК 61131-3. Сейчас речь идет о выпуске 15 таких контроллеров. Можно ли использовать для этого CoDeSys? Какой микропроцессор лучше поставить?

Кроме того, в этом контроллере было бы очень хорошо иметь возможность менять некоторые настройки удаленно по сети с офисных компьютеров. Какое ПО тут можно применить?


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Сб сен 22, 2007 12:30 pm 
Не в сети

Зарегистрирован: Сб сен 22, 2007 10:34 am
Сообщения: 0
Обычно установка CoDeSys в свое оригинальное устройство требует проведения так называемой адаптации. Это имеет смысл, только если есть планы серийно изготавливать ПЛК. Для 10-20 контроллеров это сложновато и дороговато.

Однако… Обратите внимание на очень любопытный микроконтроллер, точнее компьютер в микросхеме Beck IPC@CHIP. Реально это полноценный компьютер, со встроенной операционной системой, Ethernet, ftp, web и… CoDeSys.
Изображение

По минимуму к нему нужно добавить блок питания, Ethernet трансформатор, RS232 микросхему и все. Получаете нормальный процессорный блок для ПЛК.

Все ПО бесплатно! В комплекте идет специальная утилита: CoDeSys Platform Builder - в ней Вы задаете нужные параметры контроллера, (распределение памяти, описание входов/выходов и др) в диалоговом режиме. Далее автоматически генерируются конфиг. файлы для CoDeSys (причем с названием Вашей компании и контроллера), obj файл и файл на языке Си. В нем содержаться заготовки для драйверов ввода/вывода. Дописываете их, компилируете, получаете исполняемый файл - все, полноценный собственный ПЛК с CoDeSys готов!

С web-визуализацией, Ethernet, RS.., беспроводной сетью, и даже EtherCAT CANopen!!!

Подробнее тути тут.

Примеры применений тут.

Кстати в чипе есть встроенный web-сервер. Ваш пользователь может сам нарисовать нужные ему экранные формы с настройками в CoDeSys и включить web-визуализацию. С любого офисного компьютера в сети можно будет управлять им. Из ПО достаточно будет иметь Internet Explorer.


Вернуться к началу
СообщениеДобавлено: Чт ноя 20, 2008 6:53 am 
Не в сети

Зарегистрирован: Ср ноя 19, 2008 10:42 am
Сообщения: 0
Здравствуйте!
Нами поставлена задача разработка собственного ПТК.
На данном этапе идет разработка аппаратной части и принято решение использование готового ПО.
В связи с этим возникают некоторые вопросы:
1. На сколько сложно происходит портирование CoDeSys, и сколько это занимает по времени?
2. Возможна ли несовместимость аппаратной части и CoDeSys?
3. Как рассчитывается цена лицензии?


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт ноя 20, 2008 2:42 pm 
Не в сети
Site Admin

Зарегистрирован: Ср июл 20, 2005 2:32 pm
Сообщения: 153
1) Сложность напрямую зависит от след. факторов:
А) Стоит ли на контроллере операционная система и какая?
Есть масса практически готовых вариантов под распространенные ОС (WinCE, Linux, VxWorks и др.). Тут контроллер можно оживить за час и еще через час включить встроенную визуализацию, CANopen и др. Вы сразу получите работающий исполняемый файл от 3S, останется только написать драйверы под свои модули ввода/вывода. Если ОС нет или она экзотическая, то однозначно придется погружаться в исходные тексты системы исполнения и править самим (системные прерывания, начальный загрузчик, запись кода в ППЗУ, низкоуровневую поддержку каналов связи, сетевых интерфейсов и др. и пр.). Попутно обязательно полезут огрехи в железе…
Б) Как устроен ввод/вывод? Если это компактный контроллер либо ввод/вывод подключается по стандартным филдбасам, то быстро. Если ПЛК содержит штук 50 типов своих оригинальных модулей, подключаемых по оригинальной шине и требующих хитрых времянок при обращении, сложной инициализации и др., то на написание драйверов уйдет много времени. Как правило, основное время – это не запуск самого CoDeSys SP а именно системная поддержка всех желаемых железок.
В) Как организована работа в компании. Если программист доверяет разработчикам и четко делает то, что необходимо и достаточно, а по вечерам культурно отдыхает (Немецкий подход) , то все получается очень быстро. Если он увлекается и хочет сам исследовать на всякий случай абсолютно все килобайты исходных текстов, сидит на работе до изнеможения ('наш' подход), то процесс может затянуться…

2) Какой процессор? Посмотрите список поддерживаемых процессоров и тех. требования.
Плохо если в CoDeSys нет компилятора для нужного процессорного семейства. Другие проблемы решаются в рабочем порядке. Не экономьте на микросхеме ОЗУ! Буфера каналов связи, динамические конфигураторы сетей, горячее обновление кода, встроенная и web визуализация, встроенный сервер данных, трассировка и пр. современные фишки память кушают. Конечно, все эти штуки опциональны и их можно просто отключить, но пользователи будут тыкать пальцем, почему у конкурентов такая расчудесная фишка работает, а у Вас нет.
Вообще правильная идея поставить CoDeSys на этапе отработки макетной платы, а не когда ПЛК уже в серию пошел. Например, при поддержке некой сети бывает проще подобрать микросхему, для которой в CoDeSys SP уже есть готовый драйвер, чем самим его писать. Или возьмем вопрос как сохранять энергонезависимые переменные МЭК программ? Например, можно писать их на диск по сигналу авария питания. Естественно нужно чтобы микросхемка - монитор питания была в аппаратуре. Бывает, что некую копеечную деталь не поставили и потом приходится отказываться от весьма полезной фишки или преодолевать это хитроумными способами.

3) Цена на лицензии зависит от типа ПЛК (сложный дорогой или простой дешевый) и объема выпуска ПЛК в год. Объем требуемой тех поддержки (работы для разработчиков) для изготовителей делающих 20 шт. в год и 20 тыс. шт. в год почти одинаков. Соответственно цена лицензии падает с ростом объема. В любом случае, этот вопрос надо обсуждать. Тут масса вариантов и всегда удается придумать такой, который всех устраивает.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 24, 2008 7:45 am 
Не в сети

Зарегистрирован: Ср ноя 19, 2008 10:42 am
Сообщения: 0
Спасибо Игорь за быстрый ответ!

Предполагаемая ОС uCLinux .
1. Есть ли для нее готовый вариант?
Микроконтроллер STR912FAW44 либо LPC2478FBD208;
Flash ~16Mb;
ОЗУ ~ 32М;

Если бы изделие представляло собой централизованную систему вопросов бы не возникло, но изделие представляет собой распределенную многопроцессорную систему. В результате этого возникает такие вопросы:
2. Существует ли Механизм меж контроллерного обмена в CoDeSys SP?
Для меж контроллерного обмена планируется нечто CANOpen протокола. Адресация происходит по физическому адресу.
3. Возможна ли загрузка по физическому адресу?
При горячей замене контроллера, по нашему замыслу, он посылает запрос на верхний уровень (инженерную станцию), и загружает оттуда требуемую конфигурацию. Возможно ли реализовать такой механизм? Пожалуй это ключевой вопрос!


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 24, 2008 4:20 pm 
Не в сети
Site Admin

Зарегистрирован: Ср июл 20, 2005 2:32 pm
Сообщения: 153
VARG писал(а):
Предполагаемая ОС uCLinux . 1. Есть ли для нее готовый вариант?

Да :D

VARG писал(а):
Микроконтроллер STR912FAW44 либо LPC2478FBD208;
Flash ~16Mb; ОЗУ ~ 32М;

Отлично.

VARG писал(а):
Существует ли Механизм меж контроллерного обмена в CoDeSys SP?
Да и не один. Проще всего в применении сетевые переменные (общие переменные для ряда контроллеров в сети – передача значений по сети идет автоматически, для МЭК программы это обычные переменные). Либо есть вариант синхронного обмена инициируемый из МЭК программы. + В CoDeSys V3 есть поддержка сервера данных в контроллере. Через него легко организовать взаимодействие с компьютерами не программируемыми в CoDeSys, например через OPC.
В CoDeSys V3 в одном проекте можно писать программы сразу для всех контроллеров сети. Части программ могут быть общими. Сверх того в одном контроллере могут быть несколько независимых приложений (виртуальных контроллеров). Технология их применения такая же, как и для сетевых контроллеров.

VARG писал(а):
Для меж контроллерного обмена планируется нечто CANOpen протокола. Адресация происходит по физическому адресу.

Хорошо. CANopen в CoDeSys поддержан полноценно. Есть встроенный в среду программирования конфигуратор сети. Стеки CANopen мастер/слейв реализованы в в виде библиотек, которые неявно включаются в проект, при использовании данной сети.
Все механизмы меж контроллерного обмена для этой сети работают. Загрузка (в V3 ) возможна даже через сегменты с разными сетями (например PC – Ethernet – PLC1 – CAN – PLC2).

VARG писал(а):
При горячей замене контроллера, по нашему замыслу, он посылает запрос на верхний уровень (инженерную станцию), и загружает оттуда требуемую конфигурацию. Возможно ли реализовать такой механизм?


:? Имеется в виду физическая руками замена контроллера целиком с его отключением, т.е. холодная замена? Что значит 'конфигурация' в данном случае? Соотв-я прикладная программа со всеми настройками, ОС или что?

Если ОС работает и работает сеть, то конечно нет никаких проблем скачать нужные файлы с верхнего уровня и запустить. Однако, как новый контроллер при старте узнает какая конфигурация ему требуется? Некий идентификатор в него надо втыкать или настраивать руками...
Сделать конечно можно все, систему исполнения Вы можете менять, в том числе загрузчик.
Живьем видел вариант, когда в голый контроллер (взят со склада) монтажник вставляет определенную usb флешку и с нее автоматом обновляется все ПО (биос, ОС, CoDeSys SP и МЭК программу).
В принципе, загрузку можно запрограммировать на прикладном уровне прямо в CoDeSys. Пишем универсальную стартовую программку. При запуске она будет определять, в какой позиции стоит данный контроллер, считывать с файлового сервера (или своего диска) нужную программу (или ее обновление), прописывать ее в автозагрузку и запускать.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт ноя 27, 2008 5:30 am 
Не в сети

Зарегистрирован: Ср ноя 19, 2008 10:42 am
Сообщения: 0
Отлично Игорь, ваши ответы обнадеживают!!!
Igor Petrov писал(а):
В CoDeSys V3 в одном проекте можно писать программы сразу для всех контроллеров сети. .

1. А в 2.3 эта возможность не поддерживалась?
2. Игорь, а могу ли я без железа, на данный момент, написать программки для двух контроллеров и в режиме эмуляции наблюдать взаимодействие двух контроллеров?
3. Если в Адаптерах (Устройства В/В) нет CoDeSys отображение в дереве проектов возможно?
4. Возможно, ли настраивать Адаптеры (параметризовать, либо загружать простую программу) при отсутствии в них CoDeSys?


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт ноя 27, 2008 12:28 pm 
Не в сети
Site Admin

Зарегистрирован: Ср июл 20, 2005 2:32 pm
Сообщения: 153
VARG писал(а):
1. А в 2.3 эта возможность не поддерживалась?
2. Игорь, а могу ли я без железа, на данный момент, написать программки для двух контроллеров и в режиме эмуляции наблюдать взаимодействие двух контроллеров?
3. Если в Адаптерах (Устройства В/В) нет CoDeSys отображение в дереве проектов возможно?
4. Возможно, ли настраивать Адаптеры (параметризовать, либо загружать простую программу) при отсутствии в них CoDeSys?

1. Нет.
2. Через сетевые переменные по Ethernet? Интегрированный непосредственно в CoDeSys симулятор этого не умеет. Можно взять пару SoftPLC типа SP RTE и запустить на двух компьютерах. Достаточно демо-версий. Демо работает час непрерывно, затем нужно его закрыть и опять запустить. Для опытов нормально.
3. Да, конечно. Все так и делают.
4. Можно настраивать (только в V3). Если простая программа написана в CoDeSys, то CoDeSys SP в них нужен.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср дек 03, 2008 11:38 am 
Не в сети

Зарегистрирован: Ср ноя 19, 2008 10:42 am
Сообщения: 0
1. Игорь, где-то встречал упоминание, что протокольный стек можно реализовать в CoDeSys средствами МЭК программирования.
(В нашей задачи это реализация связи с устройствами В/В.)
Так ли это? И как это реализуется?
2. На сайте Пролога есть любопытный продукт Beck IPC@CHIP SC23-IEC, указано наличие SPI, I2C - аппаратные, а сколько каналов не указано. Есть ли изделие с двумя SPI?
А может, подскажите, есть ли аналогичные SC23-IEC изделия других производителей?


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср дек 03, 2008 3:24 pm 
Не в сети
Site Admin

Зарегистрирован: Ср июл 20, 2005 2:32 pm
Сообщения: 153
VARG писал(а):
…протокольный стек можно реализовать в CoDeSys средствами МЭК программирования

Можно. Есть так называемые системные библиотеки. Они представляют собой прямой интерфейс к разным агрегатам железа. Например, к последовательному порту. Есть функции настройки, приема и передачи данных. По сути, со стороны CoDeSys это голый интерфейс к функциям реализованным в системе исполнения (обычно на языке Си). Т.е. для начала нужна системная биб-ка для работы с соотв. портом на низком уровне. Если контроллер чужой, то надо спросить изготовителя какие сист. биб-ки поддержаны. Когда контроллер свой, то соотв. их надо поддержать. Если есть ОС то вызовы сист. биб-ок ложатся один в один на вызовы аналогичных функций API. Для послед. порта открыть, передать, принять данные, закрыть порт.
Далее в CoDeSys на МЭК языках пишем свою библиотеку для реализации нужного протокола на базе примитивных функций соотв. системной биб-ки.
Плюсы: 1) просто писать и отлаживать 2) переносимость
Минус: конечному пользователю надо включать Вашу биб-ку в каждый свой проект.

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

Изготовителям ПЛК удобнее встроить нужные протоколы в систему исполнения + поддержать настройку в конфигураторе ПЛК. В результате, например, пользователь добавляет в конфигурацию ПЛК мышкой модуль Modbus Master, к нему вставляет нужные Slave, в их каналах прописывает имена своих переменных и все. Далее все делается автоматически, ему ничего программировать не надо. Заданная им конфигурация пакуется, и посылается в контроллер, где разбирается, смориться какой там протокол и какие функции для него надо вызывать. Пользователю технические детали получаются до фонаря. Что встроенный в контроллер вход, что удаленный, через дюжину хитрых протоколов и шлюзов, его программа не меняется.

VARG писал(а):
…Beck IPC@CHIP SC23-IEC, указано наличие SPI, I2C - аппаратные, а сколько каналов не указано. Есть ли изделие с двумя SPI?

По одному. Редкостное требование второго SPI. К одному можно подключить кучу ведомых. При нужде 2й канал можно реализовать программно на дискретных выводах, как в SC13.

VARG писал(а):
А может, подскажите, есть ли аналогичные SC23-IEC изделия других производителей?

Конкуренты среди ПЛК ядер есть. Например, такой. Однако чипы Beck:
1) выигрывают по цене у всего, что нам удалось найти
2) совершенно гениальная фишка CoDeSys Platform Builder (см. выше). Все конкуренты имеют некую штатную прошитую систему исполнения под некую жесткую конфигурацию. ХХ дискретных входов, ХХ выходов… Более хоть тресни, ничего не сделаешь. Можно конечно через биб-ки хитро обращаться ко всяким расширениям, но это же не то. Конфигурация ПЛК остается заданной, под нее приходится жестоко ужимать свои хотелки.
Platform Builder позволяет задать конфигурацию такую как надо и сгенерировать конфиг. файлы для CoDeSys и шаблоны для драйверов. Например, я могу кучу АЦП по SPI или как хочу подключить, драйверок написать и мой пользователь в CoDeSys будет все это видеть как нормальные полноценные аналоговые входы. Причем при выборе типа контроллера он будет видеть название моей фирмы и моего контроллера. Он получает абсолютно нормальный полноценный ПЛК, без всяких ограничений! У конкурентов ничего такого близко нет.
Конечно, совсем уж все переделать в системе исполнения CoDeSys под себя, как это позволяет OEM комплект разработчика CoDeSys SP Builder не позволяет, но зато типовые штуки делаются быстро и экономично :)[/url]


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 08, 2008 10:21 am 
Не в сети

Зарегистрирован: Ср ноя 19, 2008 10:42 am
Сообщения: 0
1. Возвращаясь к прошедшему обсуждению:
Igor Petrov писал(а):
Если ОС работает и работает сеть, то конечно нет никаких проблем скачать нужные файлы с верхнего уровня и запустить. Однако, как новый контроллер при старте узнает какая конфигурация ему требуется? Некий идентификатор в него надо втыкать или настраивать руками...
В принципе, загрузку можно запрограммировать на прикладном уровне прямо в CoDeSys. Пишем универсальную стартовую программку. При запуске она будет определять, в какой позиции стоит данный контроллер, считывать с файлового сервера (или своего диска) нужную программу (или ее обновление), прописывать ее в автозагрузку и запускать.


Упомянутый вами файловый сервер входит в штатный пакет CoDeSys?
Если не входит, как туда помещать требуемые прикладные программы для PLC?
Как осуществляется поиск требуемой прикладной программы для PLC по географическому адресу?

2. Можно ли без живого PLC создавать проект?
Создавать виртуальные контроллеры, модули В/В, привязывать переменные к этим модулям, назначать программы контроллерам, а потом при появлении живого оборудования, просто перенести (залить) созданный проект в него?


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн дек 15, 2008 1:05 pm 
Не в сети
Site Admin

Зарегистрирован: Ср июл 20, 2005 2:32 pm
Сообщения: 153
Кто и как изначально задает 'географический' адрес? Он некими перемычками задается или программируется?
Сколько вариантов прикладных программ может быть в системе? Как они сопоставлены с географическими адресами? Кто и когда настраивает эти связи?

Итак, мы говорим о холодной замене ПЛК. По включению питания некое ПО в нем сидеть все-таки должно. Как минимум это ОС + некая хитрая программа-загрузчик, которая определяет свой 'географический' адрес и шлет запрос наверх. Вопрос: почему вместо этой хитрой программы просто не прошить в контроллер непосредственно готовую к работе МЭК программу?

Обычно это делается именно так. Во все контроллеры прошивается все ПО. Если вариантов прикладных программ несколько, то предусматриваем несколько лишних дискретных входов задания конфигурации. По ним контроллер при старте определяет какую программу запустить. Все. Запуск контроллера происходит очень быстро и гарантированно надежно.
Как иначе можно гарантировать загрузку нужной управляющей программы в контроллер после глобального сбоя? Очевидно, компьютер верхнего уровня будет загружаться при старте дольше, чем контроллеры, он может быть не исправен или сеть может не работать некоторое время. Контроллер же обязан работать всегда, тратить время на попытки загрузки он не должен.

VARG писал(а):
…как туда помещать требуемые прикладные программы для PLC?

Правильнее всего помещать их на встроенный диск PLC, дабы они все всегда были готовы к запуску мгновенно. Затем их можно обновлять по сети по мере нужды. Несколько запасных контроллеров на местах можно просто воткнуть в сеть (в режиме стоп) и пусть ПО на них обновляется не спеша по мере его обновления. В этом случае все PLC всегда гарантированно готовы к работе.

Возможно, я все-таки не верно понимаю суть обсуждаемой проблемы…
VARG писал(а):
Можно ли без живого PLC создавать проект?

На 99% можно, кроме привязки к модулям.
Все аппаратные модули имеют свою специфику, например для EtherCAT одни настройки и возможности для, CANopen другие, для Modbus третьи и др. и пр. Эмулировать их все не реально. Т.е. добавить модули в/в и привязать к ним переменные нужно будет, когда будет железо. Все остальное можно без ПЛК. :(


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Вт дек 16, 2008 8:18 am 
Не в сети

Зарегистрирован: Ср ноя 19, 2008 10:42 am
Сообщения: 0
Igor Petrov писал(а):

Итак, мы говорим о холодной замене ПЛК. По включению питания некое ПО в нем сидеть все-таки должно. Как минимум это ОС + некая хитрая программа-загрузчик, которая определяет свой 'географический' адрес и шлет запрос наверх.

Совершенно верно!

Igor Petrov писал(а):
Вопрос: почему вместо этой хитрой программы просто не прошить в контроллер непосредственно готовую к работе МЭК программу?

Ответ: Это задумано, чтоб уменьшись ручные операции, а следовательно и количество ошибок. В нашем варианте, если вышел из строя контроллер мы его заменяем на контроллер со склада, при старте он считывает свой «географический» адре скоторый формируется аппаратно, и посылает запрос на верхний уровень, что требуется МЭК программа. На верхнем уровне хранятся МЭК программы для каждого адреса (т.е. контроллера находящегося по этому адресу). Как вы предлагаете, предварительно в контроллер нужно залить МЭК программу, а потом устанавливать в систему, но при этом не исключена возможность заливки ошибочной МЭК программы. Хотя и такая возможность то же нами предусматривается.

Igor Petrov писал(а):
Как иначе можно гарантировать загрузку нужной управляющей программы в контроллер после глобального сбоя? Очевидно, компьютер верхнего уровня будет загружаться при старте дольше, чем контроллеры, он может быть не исправен или сеть может не работать некоторое время. Контроллер же обязан работать всегда, тратить время на попытки загрузки он не должен.

Глобальный сбой – глобальный выход из сбоя. Это уже детальные вопросы как будет вести себя система при старте или рестарте, при отказе того или иного узла. Для этого мне потребуется объяснить структуру системы, назначение узлов, возможные варианты загрузок, а на данном этапе обсуждения я не считаю целесообразным загружать Вас сразу всей этой информацией.

Igor Petrov писал(а):
Правильнее всего помещать их на встроенный диск PLC, дабы они все всегда были готовы к запуску мгновенно.

Откуда она там возьмется изначально?
Вот мы взяли контроллер со склада, в котором только «ОС + некая хитрая программа-загрузчик, которая определяет свой 'географический' адрес», воткнули его в систему и в него должна загрузиться требуемая МЭК программа. «Диск PLC» пустой изначально.

Igor Petrov писал(а):
Сколько вариантов прикладных программ может быть в системе?

Я полагаю, сколько контроллеров столько и программ, а контроллеров порядка 20.

Igor Petrov писал(а):
Как они сопоставлены с географическими адресами?

Этот вопрос я вам и задавал, и получил ответ, что МЭК программки могут храниться на файловом сервере, и по запросу могут быть загружены в PLC (каждая задача соответствует географическому адресу). Вследствие чего у меня и возникли дальнейшие вопросы, связанные с этим Файловым сервером, которые остались открытыми.
Igor Petrov писал(а):
Кто и когда настраивает эти связи?

В моем понимании это делает Системный инженер, или программист когда создает проект (МЭК программку), и назначает МЭК программу требуемому PLC, который расположен в определенном месте (с определенным "географическим"адресом).
Я, наверное, что-то не понял в вопросе, потому как не представляю иного способа конфигурирования (Программирования) PLC.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Вт дек 16, 2008 10:24 am 
Не в сети
Site Admin

Зарегистрирован: Ср июл 20, 2005 2:32 pm
Сообщения: 153
Что такое 'географический адрес'? Имеется в виду сетевой адрес? Например, в CAN это Node –ID задаваемый внешними перемычками? Так?

VARG писал(а):
Это задумано, чтоб уменьшись ручные операции, а следовательно и количество ошибок.

Логично бы для уменьшения количества ошибок упростить ПО и исключить лишние операции, в первую убрать ненадежную операцию начальной загрузки.
Что будет если начальная загрузка не пойдет? Например, сделали несколько попыток и всякий раз файл не докачен или получен с ошибками (допустим гроза, программа в ПЛК слетела и закачать новую не удается)? Контроллер все это время стоит и не работает? Разве это допустимо, когда ПЛК не может стартовать минут десять-двадцать? Все стремятся сделать загрузку ПЛК максимально быстрой, через 20 макс. 200мс ПЛК должен быть как огурец.

VARG писал(а):
Как вы предлагаете, предварительно в контроллер нужно залить МЭК программу, а потом устанавливать в систему, но при этом не исключена возможность заливки ошибочной МЭК программы.

Исключено. Во все контроллеры заливается единый проект, содержащий все программы. При старте, ПЛК смотрит по 'географическому адресу' какую программу запустить и делает это за 1 мс. Источником ошибки может быть только ошибочно заданный адрес. Более ничего. В Вашем варианте к этому добавляются возможные сбои сервера, сети, подключение кабеля, т.е. вероятность залить не ту программу значительно выше.

VARG писал(а):
Вот мы взяли контроллер со склада, в котором только «ОС + некая хитрая программа-загрузчик…

Откуда она там возьмется? Некто должен ее туда прошить? Зачем эта лишняя ручная операция? Почему бы не прошить сразу нормальный рабочий проект вместо этого промежуточного звена?

Проект в CoDeSys V3 может содержать много ПЛК. Они расположены в виде иерархического дерева и привязаны к положению в этом дереве. Конечно, каждый ПЛК имеет сетевой адрес. Его легко можно менять, он практически не на что не влияет. Некоторые ПЛК оказываются связанными с компьютером через несколько других ПЛК с возможно разными типами сетей между ними. Например: 'PC с CoDeSys – Ethernet – PLC1 – CANopen – PLC2'. В этом варианте CoDeSys не достаточно знать адрес Node ID PLC2 чтобы однозначно его идентифицировать и залить в него программу. Нужно знать иерархию проекта, дабы выстроить маршрут. Т.е. управление загрузкой организованно абсолютно четко и строго монархически сверху вниз, никой демократии.

В процессе нормальной работы системы, без ее останова, из CoDeSys можно обновить МЭК программы на дисках ПЛК. В результате они всегда готовы к работе.

Система исполнения CoDeSys SP содержит в себе загрузчик. Но сам он не может проявлять инициативы принципиально. Он работает только по запросу сверху. Каждое приложение получает свой уникальный ID. При подключении к контроллеру CoDeSys понимает, что в него загружено и предлагает обновить, если загруженное приложение не совпадает с тем, что в проекте.

Короче говоря, без всяких усилий можно сделать так. На верхнем уровне крутится визуализация, которая постоянно читает и отображает (архивирует и т.д.) нужные данные. Если данные перестали поступать, то оператор может принять решение перезапустить данный ПЛК дистанционно, либо закачать в него новое ПО, все его действия протоколируются.

Если очень сильно надо, то это можно автоматизировать эту операцию написав плагин к CoDeSys, для опроса и обновления ПО.

Но в любом случае инициатива тут идет сверху – опрос ПЛК и управление закачкой, но не наоборот, ПЛК не может сам инициировать закачку из CoDeSys.

В точности Ваш вариант можно реализовать двумя способами:
1) Без участия CoDeSys вообще, все программы загрузки пишем на Си и т.п.. Берем файлы с кодом МЭК программ после CoDeSys, кладем их на некий свой файловый сервер загрузки и качаем своим загрузчиком из ПЛК, затем уже стартуем CoDeSys SP.
2) Выделяем некий компьютер (например с SP RTE) или ПЛК который будет работать у нас сервером загрузки (их может быть и несколько). На его диске лежат все загрузочные файлы. У него есть таблица соответствия адресов и файлов. На ПЛК есть МЭК программа – начальный загрузчик. При старте она связывается сервером, сообщает свой номер и скачивает свою программу, кладет на свой диск, прописывает в автозагрузку и перезапускается. Все написано на МЭК языках в CoDeSys.

Однако оба варианта требуют усилий по программированию, для переворота логики работы CoDeSys в противоположную сторону. Гораздо проще вместо программы-загрузчика сразу записывать в ПЛК рабочую программу(ы).


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср дек 17, 2008 2:25 pm 
Не в сети
Site Admin

Зарегистрирован: Ср июл 20, 2005 2:32 pm
Сообщения: 153
Вариант решения:
Давайте посмотрим в будущее и сразу усложним задачу, предусмотрев варианты развития распределенной системы. Дадим каждому ПЛК возможности:
- ПЛК может иметь несколько подчиненных сетей и соответственно может иметь не 1, а несколько ID + соотв. настройки
- ПЛК может быть соединен с верхним уровнем через несколько разнородных сетей
- ПЛК имеет право управлять ответственным оборудованием. Оставлять его без управления нельзя. Загрузка ПЛК должна выполнятся очень быстро и 100% надежно.
- ПЛК должен работать всегда, даже если нет связи с верхним уровнем.
- Сеть может быть гибкой без гарантии доставки сообщений
- Обновлять прикладное ПО в ПЛК можно дистанционно сверху, в любое время, без остановки, налету.
- ПЛК может иметь адаптивные алгоритмы. Например, при износе рабочих инструментов вносить индивидуальные поправки, вычисляемые автоматически или вводимые оператором. В результате даже ПЛК с одинаковыми программами должны иметь возможность различий в работе, путем настроек, сохраняемых при выключении питания.
- ПЛК можно менять со склада, без предварительного программирования. Это должно делаться на объектах силами обычного электрика или рабочего.

На практике решается так: панельные ПЛК немецкой фирмы Berghof имеют разъем USB в который включена обычна компьютерная флешка (диск). На ней хранится прикладная МЭК программа и все настройки (ID) и пр. Флешка одновременно служит идентификатором и хранилищем прикладного ПО. При замене ПЛК на взятый со склада пустой ПЛК, рабочий вынимает флешку из сломанного и втыкает в новый (может любой дурак, ошибиться не реально, сложнее чем сигарету с фильтра прикурить :) ). Флешки пронумерованы в соответствии типом прикладных программ (макс. видел 60 типов). Их можно готовить и копировать на любом PC без всякого доп. оборудования или прямо в ПЛК. На верхнем уровне стоит компьютер с CoDeSys и ENI сервером. Он ведет базу данных всех версий и изменений в программах. После коррекции программ они загружаются в ПЛК на ходу и записываются на их флешки.

Практически такая схема реализована на многих автозаводах в разных странах с весьма сложной структурой (пример тут) до сотни ПЛК в кусте. Есть живое применение (с другими ПЛК) на линии погрузки океанских сухогрузов в (Великобритания). Здесь стоимость одной погрузки превышает стоимость всего оборудования в несколько раз. Поэтому работа не останавливается, даже если, накрылась связь с верхним уровнем, рабочий получил травму, накрылся ПЛК (есть ручные пульты дублирующие ПЛК). Короче, описанный вариант проверен практикой в весьма и весьма ответственных применениях.


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 17 сообщений ]  На страницу 1 2 След.

Часовой пояс: UTC+01:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB