ADAM-5510E/TCP-A связь ч/з OPC

Первоначально опубликовано Sergey Sorokin Существует возможность Off-line подписки на все сообщения форума или конкретной конференции.

Я знаю Сергей, спасибо. Только для того, чтобы ответить на вопрос, необходимо это все равно делать on-line. А если вопрос серьезный, то предпочитаю спокойно ответить дома, в почтовой программе, а наутро отправить.

Первоначально опубликовано _IP_  Если бы эти Адамовские контроллеры подерживались CoDeSys ... Сейчас каждый пользователь должен сам изобретать велосипед ...

Игорь! При всем уважении к Вам и к CoDeSys замечу все-таки, что не всегда данное решение оптимально. Точно так же, как и не всегда программирование на C++ является наилучшим выходом. Потому многие и приобретают "голые" PC-совместимые контроллеры, что для некоторых задач МЭКовские среды разработки либо являются избыточными, либо просто неудобны, а зачастую и то и другое сразу. Почитайте архив, года полтора назад тут не стихали сражения на тему "МЭК против C++"

То же самое касается и SCADA пакетов с OPC серверами. Мне доводилось участвовать в одном проекте, где для небольшой системы сбора данных применялась SCADA (Trace Mode, кстати). Необходимость в "ручном" программировании возникла все равно. И, дописывая специальную приблуду к TM5 на Visual Basic, я думал, насколько проще, быстрее и дешевле вся эта задача решалась бы вообще без использования SCADA, целиком на VB например.

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

Первоначально опубликовано _IP_ М да! Если бы для эти Адамовские контроллеры подерживались CoDeSys таких вопросов не возникло бы совсем.

Если говорить про МЭКовские языки, то в настоящее время поддерживаются KW и UltraLogik. Вопрос портирования CodeSys на Адамы в настоящее время рассматривается.

Первоначально опубликовано compm2001 может быть самому все делать... OPC клиент есть (компонент Delphi), OPC сервер есть, примеры на С++ для контроллера есть, литература тоже есть, опыта только нет... Что посоветуете, господа профессионалы?[

Вам уже посоветовали - определится с задачей. Вы хотите просто поковырятся с контроллером? Тогда делайте с ним что хотите, и не спрашивайте советов.А если нужно сделать какую-никакую систему автоматизации - что же вы хотите от нее получить? Поставте сами себе задачу, распишите функциональность, которую должна выполнять система:
- Отображение оперативных параметров
- Управление с верхнего уровня
- Звуковая и световая сигнализация
- Ведение истории
- Просмотр истории
- Формирование отчетов

Что должен делать контроллер? Просто выдавать значения сигналов на своих входах? Или же крутить какую-то программу управления? Насколько сложная программа? На чем бы вам ее хотелось написать - на ФБД, или же на С? Если писать самому на С - как организовать доступ к переменным по TCP/IP? Будете городить свой протокол, или можно использовать для задачку Модбас для этого контроллера, вроде такая есть?

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

В дополнение. Я практически уверен, что на портирование KLogic в этот контроллер время уйдет на порядок меньше, чем написание своей программы на C. Если, конечно, вообще есть опыт работы с языком C, и со средой Borland C++ 3.

И еще. Уже есть OPC-сервер. Так попробуйте сделать что нибудь, чтобы просто получить данные от контроллера. Попробуйте сделать на сторонней программе, попробуйте написать сами, сравните, и уже появится какая-то определенность - как быть дальше.

Первоначально опубликовано Максим Ананских При всем уважении к Вам и к CoDeSys замечу все-таки, не всегда данное решение оптимально.

Конечно да!

 

Я не фанат CoDeSys абсолютно. Мы более 10 лет поддерживали собственную систему программирования своих ПЛК ДИАРС. Решение бросить ее и взять готовую среду далось болезненно. Однако, когда можно сделать работу трактором за 10 минут, стоит ли копать неделю лопатой?

 

По секрету, мы не используем CoDeSys для автономных встраиваемых систем. Даже был случай когда мы специально адаптировали CoDeSys в блок управления дизелем, только для моделирования и отладки. Далее переписали программу с ST на С. Это оказалось быстрее, чем сразу делать в С. В конечном продукте программирование не нужно, поэтому нет смысла снабжать его лицензиями 3S.

 

На прошлой неделе наши специалисты автоматизировали огромную и жуткую машину по прессовке мусора. За 3 дня (!) старый ПЛК Мюллера был заменен новым контроллером с CoDeSys. Честно сказать я ожидал, что эта работа займет не менее месяца! Смотреть страшно , но работает и деньги   уже получены  …