Регистрация | Последние сообщения | Персональный список | Поиск | Настройка конференции | Личные данные | Правила конференции | Список участников | Top 64 | Статистика раздела | faq | Что нового v.2.3 | Чат
Skunk Forum - Техника, Наука, Общество » АСУТП »
оборудование Lenze и чтение\запись параметров по CAN-шине

Версия для печати (настроить)

Новая тема | Написать ответ

Подписаться

Автор Тема:   оборудование Lenze и чтение\запись параметров по CAN-шине
kohausen
Junior Member

Сообщений: 17
Регистрация: Декабрь 2006

написано 18 Июня 2007 10:23ИнфоПравкаОтветитьIP

Кто-нибудь работает с оборудованием Lenze(ПЛК и Преобразователи частоты)? Интересует следующее: требуется организовать чтение\запись параметров из/в Преобразователь Частоты, используя сервопривод с встроенным ПЛК Lenze servo_PLC 9300. Среда программирования Drive Developer studio (аналогичная CoDeSys). Имеются фирменные библиотеки (.lib) с необходимыми функциональными блоками чтения\записи парметров по CAN-шине. в мануале сказано, что для корректной работы этих блоков необходимо их вставлять в циклическую задачу (PLC_PRG) т.к. с одной проходки не происходит чтения \записи заданных значений. Однако при одновременном чтении\записи нескольких параметров (8-10 шт.) возникла проблема - подвисание шины и подглючивание основной программы - один раз двигатель ушел в неуправляемый режим :-)...Может имеется какие специфические требования к оргранизации пользовательской программы по чтению\записи параметров, например одновременно должен происходит запись только одного параметра, частоа запросов на запсиь\чтение или нечто подобное? в оффициальной документации не нашел нужной инфы...

bessonov3
Junior Member

Сообщений: 12
Регистрация: Май 2007

написано 18 Июня 2007 11:15ИнфоПравкаОтветитьIP

kohausen
в мануале сказано, что для корректной работы этих блоков необходимо их вставлять в циклическую задачу (PLC_PRG) т.к. с одной проходки не происходит чтения \записи заданных значений. Однако при одновременном чтении\записи нескольких параметров (8-10 шт.) возникла проблема - подвисание шины и подглючивание основной программы - один раз двигатель ушел в неуправляемый режим :-)
Такие фишки надо добавлять в копилку "сравнение PLC", то что вы написали, говорит о том, что это дурной контроллер. На CAN такого быть не должно, всё разруливается на уровне микрух. Возможно на ПЧ слабый проц, поэтому не успевает обрабатывать всё пакеты, но это почти не реально.

Попробуйте увеличить время цикла опроса/записи.

kohausen
Junior Member

Сообщений: 18
Регистрация: Декабрь 2006

написано 18 Июня 2007 12:05ИнфоПравкаОтветитьIP

не думаю, что дело на аппаратном уровне. Вообще у меня принцип сначала искать причину в себе, а потом уже пенять на производителя. Не думаю, что Lenze - дурной контроллер. Просто надо разобраться.

IP
Member

Сообщений: 72
Откуда: Russia
Регистрация: Июнь 2006

написано 18 Июня 2007 14:23ИнфоПравкаОтветитьIP

Как именно называются эти фирменные CAN библиотеки?
Не может ли оказаться, что их функциональные блоки выполняются асинхронно? Может быть лучше не пихать все в одну PLC_PRG, а сделать отдельную циклическую задачу. Т.е. развязать управляющую и коммуникационную задачи, поскольку тут еще нужно понять, где первопричина сбоя.

kohausen
Junior Member

Сообщений: 19
Регистрация: Декабрь 2006

написано 18 Июня 2007 16:56ИнфоПравкаОтветитьIP

IP
речь идет о LenzeDrive.lib, а конкретно о блоках L_ParRead и L_ParWrite. Цитата из мануала:"...This FB is used to read parameters, with Lenze so-called codes. The FB can read both the PLC
codes and codes of other devices via the system bus (CAN).....The FB L_ParRead must be cyclically called to ensure that the read response is received. Due to the cycle time of the receiver, it may happen that the PLC receives the read response only after a few program cycles.
If the FB is not cyclically called (e.g. in an event-controlled task) the FB might ”get stuck” as a result." т.е. в обязательном порядке должны быть помещены в цикличную задачу. Я использую PLC_PRG лишь потому, что Drive Developer Studio не позволяет создавать (по крайней мере явным образом, через Task Configuration) циклические задачи - только лишь по прерыванию, событию и интервалу...
по поводу асинхронности работы: каким образом это можно отследить?

IP
Member

Сообщений: 73
Откуда: Russia
Регистрация: Июнь 2006

написано 18 Июня 2007 18:01ИнфоПравкаОтветитьIP

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

kohausen
Junior Member

Сообщений: 20
Регистрация: Декабрь 2006

написано 19 Июня 2007 08:55ИнфоПравкаОтветитьIP

IP
вы правы, указанные мною блоки L_ParRead и L_ParWrite имеют выход bDone, который принимает значение TRUE после того, как будет произведена операция чтения\записи.
Примеры, поставляемые Lenze достаточно просты, там читается/записывается 1-2 параметра. Проблемы возникают при увеличении их числа до 10 и более шт.
Я думаю, что надо идти по указанному Вами пути: т.е. проверять состояние выхода bDone 1-го блока, после того как он стал True, переходить к запуску чтения второго, проверять уже его выход bDone и т.д. Т.е. чтобы в один момент времени в программе читался\записывался только один параметр. Однако если это так, хотелось бы какое-то объяснение объяснение на уровне протокола или программной реализации...мне почему то казалось, что подобные проблемы должны быть решены на более низком уровне, хотя возможно я ошибаюсь..

Добавление от 19 Июня 2007 14:28:

Вообще-то странно наблюдать отсутствие реакции со стороны асутпшников...неужели ни у кого не возникают\возникали проблемы подобного рода?

IP
Member

Сообщений: 74
Откуда: Russia
Регистрация: Июнь 2006

написано 20 Июня 2007 12:54ИнфоПравкаОтветитьIP

цитата:
kohausen писал:
...неужели ни у кого не возникают\возникали проблемы подобного рода?

ИМХО: Возникают, но разные с разным оборудованием. Наверняка Lenze могли бы сделать поддержку CAN техничнее. Но, в Германии в приводных задачах сейчас доминирует SERCOS, поэтому CAN просто поддержан. В России же из оборудования Lenze используют самое простейшее с аналоговым управлением без всяких контроллеров. Используя столь продвинутые штуки, не стоит рассчитывать на поддержку широких масс пользователей

Мало того, делать документацию на русском легко берутся агентства технического перевода. Естественно они ничего не проверяют и вообще слабо соображают что пишут. См. например, тут и тут . Читая страничку на русском, я даже не могу понять, что это такое и зачем нужно. А жаль, KEB COMBICONTROL C5 штука достойная внимания (основная фишка – встроенная поддержка SoftMotion )…

Pike
Junior Member

Сообщений: 26
Откуда: Москва, РФ
Регистрация: Декабрь 2006

написано 20 Июня 2007 13:51ИнфоПравкаОтветитьIP

>Вообще-то странно наблюдать отсутствие реакции со стороны асутпшников...неужели ни у кого >не возникают\возникали проблемы подобного рода?

Просто остальные либо не использую ПЛК Lenze, либо не используют CAN.

kohausen
Junior Member

Сообщений: 21
Регистрация: Декабрь 2006

написано 20 Июня 2007 17:28ИнфоПравкаОтветитьIP

Pike
IP
Насколько я знаю Lenze входит в Альянс Автоматизации наряду с еще несколькими десятками производителей ПЛК и средств автоматизации. Логично предположить, что используя Codesys сего идеологией в качестве единой платформы для программирования ПЛК, будут возникать схожие проблемы и ,следовательно, схожие пути их решения.

Pike
Junior Member

Сообщений: 27
Откуда: Москва, РФ
Регистрация: Декабрь 2006

написано 20 Июня 2007 18:33ИнфоПравкаОтветитьIP

Я имел в виду пользователей этого ресурса.
Сходные проблемы у меня возникали когда я использовал FB для реализации ModBus обычном периферийном порту одного контроллера. Проблема решилась установкой нормального коммуникационного модуля в контроллер, что с экономило кучу места в программе и расширило возможности системы.
На счет SERCOS vs CAN. SERCOS заточен под достаточно навороченные задачи управления движением, что, кстати, сказывается на стоимости комплектов оборудования. CAN менее "возвышен", но при нормальной реализации его в контроллере будет по круче ModBus и может в определенных сегментах конкурировать с Profibus. Во всяком случае, в Италии, например, очень популярна тема управления частотниками по CAN на конвеерных линиях. Ну, и соответствено привода и контроллеры там не Lenze.

kohausen
Junior Member

Сообщений: 22
Регистрация: Декабрь 2006

написано 21 Июня 2007 09:01ИнфоПравкаОтветитьIP

Возможности CAN меня вполне устраивают в рамках решаемых задач: чтение\запись параметров работы ПЧ (текущей скорости, времени разгона\торможения и т.д.) т.к. вся математика (векторный режим управления, ПИД-регулирование и т.д.) реализовано непосредственно в ПЧ, а ПЛК формирует лишь дискретные упавляющие сигналы (пуск, стоп и т.д.)
немного не понятен термин -"нормально реализован". А каковы критери этой "нормальности"? Спрашиваю без всякой доли иронии т.к. оборудование Lenze - первое в моем практике, где реализован CAN (раньше работал с модбас и директНЕТ). Наличие библиотеки функций\функциональных блоков? или же какой то особый чипсет?

Pike
Junior Member

Сообщений: 28
Откуда: Москва, РФ
Регистрация: Декабрь 2006

написано 21 Июня 2007 09:55ИнфоПравкаОтветитьIP

"Нормально" - это когда к всем возможностям сети есть доступ без лишних проблем. На практике это когда все сетевые дела реализованны аппаратно, я лишь конфигурирую это дело, а дальше работаю только с памятью контроллера.

bessonov3
Junior Member

Сообщений: 15
Регистрация: Май 2007

написано 21 Июня 2007 11:41ИнфоПравкаОтветитьIP

kohausen
А каковы критери этой "нормальности"? Спрашиваю без всякой доли иронии т.к. оборудование Lenze - первое в моем практике, где реализован CAN (раньше работал с модбас и директНЕТ).
Проблему совместимости железок и настроек модбаса вынужден решать пользователь. Например, правильно задать адрес памяти, время задежки, параметры СОМ порта. В продвинутых интерфейсах (profibus, can и др.) часть проблем решена на аппаратном уровне. В случае Lenze возможно CAN установлен прямо в процессор контроллера.

Возможно в ЦП ПЛК Lenze криво реализована поддержка can, поэтому разработчики контроллера вынесли проблемы на уровень пользователя:
в мануале сказано, что для корректной работы этих блоков необходимо их вставлять в циклическую задачу (PLC_PRG) т.к. с одной проходки не происходит чтения \записи заданных значений. Однако при одновременном чтении\записи нескольких параметров (8-10 шт.) возникла проблема - подвисание шины и подглючивание основной программы - один раз двигатель ушел в неуправляемый режим

Ваш ответ:

Коды форума
Смайлики


Ник:    Пароль       
Отключить смайлики

Все время MSK

Склеить | Разбить | Закрыть | Переместить | Удалить

Новая тема | Написать ответ
Последние сообщения         
Перейти к:

Свяжитесь с нами | skunksworks.net

Copyright © skunksworks.net, 2000-2018

Разработка и техническая поддержка: skunksworks.net


Рейтинг@Mail.ru Яндекс.Метрика