- Обязательно представиться на русском языке кириллицей (заполнить поле "Имя").
- Фиктивные имена мы не приветствуем. Ивановых и Пупкиных здесь уже достаточно.
- Не писать свой вопрос в первую попавшуюся тему - вместо этого создать новую тему.
- За поиск, предложение и обсуждение пиратского ПО и средств взлома - бан без предупреждения.
- Рекламу и частные объявления "куплю/продам/есть халтура" мы не размещаем ни на каких условиях.
- Перед тем как что-то написать - читать здесь и здесь, а студентам - обязательно здесь.
- Не надо писать в ЛС администраторам свои технические вопросы. Администраторы форума отлично знают как работает форум, а не все-все контроллеры, о которых тут пишут.
Codesys и вообще контроллеры с главным циклом - как?
-
- здесь недавно
- Сообщения: 8
- Зарегистрирован: 05 авг 2021, 20:59
- Имя: Петр
Codesys и вообще контроллеры с главным циклом - как?
Добрый день!
Уважаемые участники форума. Если можно, объясните, пожалуйста, такую штуку. Общий принцип работы с внешними данными в CDS 3.5, а то у меня какое-то глубинное непонимание. Особенно волнует работа с TCP. Возмем для примера библиотеку NBS. Прежположим, я сделал на ней сервер (или клиент, не важно). Что бы он работал, я, естественно, должен вызывать сервер (FB) в суперцикле. Но, предположим, между вызовами данные по сети поступили дважды - ведь в таком случае в приемном буфере будет только вторая порция данных. По небольшому опыту работы например в Delphi, там как правило использовалась идеология, когда приход данных вызывал событие, и их можно было тут же обработать. А тут нужно что-то делать в основном цикле и еще успевать принимать данные от устройств (устройств может быть штук десять, плюс еще и через последовательные порты). Как избежать потери (не обработки) данных?
Как назло, это проявляется в том, что уже несколько раз не проходили логические единицы от удаленного устройства, т.к. информацию о них, как я подозреваю, "перекрывали" поступающие с минимальным зазором данные об уровне принимаемого сигнала. И тут важный момент - передача данных идет не циклически, а как только один из контроллируемых параметров изменился. Например, тот же уровень сигнала. Не зная точно, в каком состоянии находится удаленный объект, не получается точно на него воздействовать. Т.е. например на приемнике локально аппаратной кнопкой включили Mute, а контроллер это не отловил. Из WEB интерфейса включаем Mute, а по факту он его выключает и приходит логический ноль. Удивляемся, что кнопка Mute не подсветилась... как то так. Согласен конечно, что протокол прибора не удачен.
Про Modbus TCP в качестве транспорта думал кстати, но смущает то, что он судя по отзывам не очень быстр. Люди испытывают (с их слов) проблемы с задержкой даже при подключении по нему обычных выключателей света, если их больше десятка примерно. Мне же нужна масштабируемость для передачи примерно 30 штук аналоговых величин (два байта), состояния до сотни кнопок, и символьных строк до нескольких десятков символов.
Вот все же думаю, а не случалось ли Вам работать или слышать о TCP сервере или клиенте, реализованном в CDS, который бог бы работать, как бы это сказать, сам по себе, без циклического вызова. И "дергать" внешние процедуры при получении данных. Или, возможно, достаточно просто динамического буфера (очереди) для принимаемых данных.
Вот не понимаю пока, ведь определенно контроллеры CDS используются не для управления одним-двумя устройствами. Такая же ситуация может быть, скажем, и при управлении камерами, особенно по IP. Раньше я пользовался другим проприетарным контроллером (не Сименс), так там вообще нет понятия главного цикла. По опыту, десяток устройств по сетке и столько же по последовательным интерфейсам не вызывают вообще проблем. Все работает как бы параллельно, и такой подход сильно меня расслабил. Но цена его - превышает все разумные пределы. Очень хочется нащупать пределы применимости доступных контроллеров на CDS, но что-то я пока не понимаю. В том оборудовании, с которым работаю я, пропускать ответы не желательно.
Уважаемые участники форума. Если можно, объясните, пожалуйста, такую штуку. Общий принцип работы с внешними данными в CDS 3.5, а то у меня какое-то глубинное непонимание. Особенно волнует работа с TCP. Возмем для примера библиотеку NBS. Прежположим, я сделал на ней сервер (или клиент, не важно). Что бы он работал, я, естественно, должен вызывать сервер (FB) в суперцикле. Но, предположим, между вызовами данные по сети поступили дважды - ведь в таком случае в приемном буфере будет только вторая порция данных. По небольшому опыту работы например в Delphi, там как правило использовалась идеология, когда приход данных вызывал событие, и их можно было тут же обработать. А тут нужно что-то делать в основном цикле и еще успевать принимать данные от устройств (устройств может быть штук десять, плюс еще и через последовательные порты). Как избежать потери (не обработки) данных?
Как назло, это проявляется в том, что уже несколько раз не проходили логические единицы от удаленного устройства, т.к. информацию о них, как я подозреваю, "перекрывали" поступающие с минимальным зазором данные об уровне принимаемого сигнала. И тут важный момент - передача данных идет не циклически, а как только один из контроллируемых параметров изменился. Например, тот же уровень сигнала. Не зная точно, в каком состоянии находится удаленный объект, не получается точно на него воздействовать. Т.е. например на приемнике локально аппаратной кнопкой включили Mute, а контроллер это не отловил. Из WEB интерфейса включаем Mute, а по факту он его выключает и приходит логический ноль. Удивляемся, что кнопка Mute не подсветилась... как то так. Согласен конечно, что протокол прибора не удачен.
Про Modbus TCP в качестве транспорта думал кстати, но смущает то, что он судя по отзывам не очень быстр. Люди испытывают (с их слов) проблемы с задержкой даже при подключении по нему обычных выключателей света, если их больше десятка примерно. Мне же нужна масштабируемость для передачи примерно 30 штук аналоговых величин (два байта), состояния до сотни кнопок, и символьных строк до нескольких десятков символов.
Вот все же думаю, а не случалось ли Вам работать или слышать о TCP сервере или клиенте, реализованном в CDS, который бог бы работать, как бы это сказать, сам по себе, без циклического вызова. И "дергать" внешние процедуры при получении данных. Или, возможно, достаточно просто динамического буфера (очереди) для принимаемых данных.
Вот не понимаю пока, ведь определенно контроллеры CDS используются не для управления одним-двумя устройствами. Такая же ситуация может быть, скажем, и при управлении камерами, особенно по IP. Раньше я пользовался другим проприетарным контроллером (не Сименс), так там вообще нет понятия главного цикла. По опыту, десяток устройств по сетке и столько же по последовательным интерфейсам не вызывают вообще проблем. Все работает как бы параллельно, и такой подход сильно меня расслабил. Но цена его - превышает все разумные пределы. Очень хочется нащупать пределы применимости доступных контроллеров на CDS, но что-то я пока не понимаю. В том оборудовании, с которым работаю я, пропускать ответы не желательно.
-
- почётный участник форума
- Сообщения: 5631
- Зарегистрирован: 07 окт 2011, 09:12
- Имя: Гаско Вячеслав Эриевич
- Страна: Россия
- город/регион: Рязань
- Благодарил (а): 600 раз
- Поблагодарили: 756 раз
Codesys и вообще контроллеры с главным циклом - как?
Во-первых, данные по сети не могут поступать чаще установленного интервала для данного тега. Чаще всего, нет никакого смысла передавать одно и то же. Соответственно, периоды опроса удалённой периферии должны быть выставленны правильно для медленных и быстрых точек.PetrP писал(а): ↑05 авг 2021, 21:11 Прежположим, я сделал на ней сервер (или клиент, не важно). Что бы он работал, я, естественно, должен вызывать сервер (FB) в суперцикле. Но, предположим, между вызовами данные по сети поступили дважды - ведь в таком случае в приемном буфере будет только вторая порция данных.
Во-вторых, дело не в среде исполнения/программирования CoDeSys или иной какой, а в архитектуре самого контроллера. Есть в нём сопроцессор связи или нет.
---------------------------------------------------
«У человека в душе дыра размером с Бога, и каждый заполняет её как может.» (Жан-Поль Сартр)
"Ту пустоту, которая остаётся в душе, когда в ней нет Бога, и весь мир не может заполнить." (святитель Николай Сербский)
«У человека в душе дыра размером с Бога, и каждый заполняет её как может.» (Жан-Поль Сартр)
"Ту пустоту, которая остаётся в душе, когда в ней нет Бога, и весь мир не может заполнить." (святитель Николай Сербский)
-
- здесь недавно
- Сообщения: 8
- Зарегистрирован: 05 авг 2021, 20:59
- Имя: Петр
Codesys и вообще контроллеры с главным циклом - как?
Согласен. Но тут речь едет об интеграции, скажем так, не промышленного оборудования. Нужно сделать удаленный пульт управления для устройства, которое валит в сеть информацию о своем состояниии по каждому событию на этом устройстве. Нажали кнопку на передней панели, изменился уровень принимаемого сигнала и т.д. Строгой периодичности отправки нет. При этом, очень вариабельна и длина отправляемых данных. Там могут быть еще и символьные сообшения на пару десятков байт. Вот так вот сделано.
Да, если бы у контроллера была большая завязанность на конкретную аппаратную реализацию (хотя бы прерывания) то, наверное, было бы проще. Однако, не понятно, почему бы не сделать в CODESYS (а может это и возможно как-то ?) хотя бы два типа входных буфера, как в некоторых других контроллерах. В первом типе вновь пришедшие данные затирают пришедшие ранее. А во втором - просто добавляются. Данные выбираются, буфер чистится принудительно. Даже при размере буфера в несколько килобайт, почти всех проблем можно было бы избежать.
Отправлено спустя 7 минут 23 секунды:
И здесь в общем согласен. Но скорее, тут еще многое зависи и от программного ядра контроллера. У многих контроллеров CODESYS на TI Sitara аппаратные средства поддержки коммуникаций вроде как есть. Но суперцикл остается со всеми вытекающими проблемами. Есть еще один контроллер, не помню кто делал. Там был процессор Motorola ColdFire 150mhz. И Ethernet, и RS-485. Внутри - NucleOS. Общего цикла не было. Но данные от десятка LAN-клиентов подобного типа никуда не пропадали. Как-то так.
Вот он, кстати, контроллер-то: https://www.crestron.com/Products/Contr ... stems/PRO2
-
- почётный участник форума
- Сообщения: 3575
- Зарегистрирован: 10 ноя 2009, 04:58
- Имя: Толмачев Михаил Алексеевич
- город/регион: г. Чехов, МО
- Благодарил (а): 6 раз
- Поблагодарили: 271 раз
Codesys и вообще контроллеры с главным циклом - как?
В системах автоматизации принято делать непрерывный циклический обмен. В умных домах это называется поллингом. Если какое-то значение тега было пропущено, то это не должно ломать систему. Если же это систему ломает, то надо идти на ухищрение: посылать в ответ подтверждение о получении, либо увеличивать длительность сигнала и т.п.
Решать проблему буфером данных - это глупость, ведь реально у вас система может генерировать 100 данных в секунду, а принимающая сторона может физически обрабатывать всего лишь 10 данных в секунду. Иначе, кроме как притормозить "генератор" путей нет. Гигабайтный буфер рано или поздно переполнится.
Делайте на "медленном" ПЛК ответ с подтверждением о получении.
Решать проблему буфером данных - это глупость, ведь реально у вас система может генерировать 100 данных в секунду, а принимающая сторона может физически обрабатывать всего лишь 10 данных в секунду. Иначе, кроме как притормозить "генератор" путей нет. Гигабайтный буфер рано или поздно переполнится.
Делайте на "медленном" ПЛК ответ с подтверждением о получении.
-
- здесь недавно
- Сообщения: 8
- Зарегистрирован: 05 авг 2021, 20:59
- Имя: Петр
Codesys и вообще контроллеры с главным циклом - как?
Увы, железка - черный ящик. Как сделана, так и сделана.
-
- здесь недавно
- Сообщения: 8
- Зарегистрирован: 05 авг 2021, 20:59
- Имя: Петр
Codesys и вообще контроллеры с главным циклом - как?
Ради интереса, подскажите - а есть среди промышленных контроллеров такие, в которых главный цикл (суперцикл) отсутствует в явном виде? Слышал, есть Siemens какие-то? Это так? В чем, с вашей точки зрения, достоинства и недостатки подобных контроллеров?
-
- здесь недавно
- Сообщения: 8
- Зарегистрирован: 05 авг 2021, 20:59
- Имя: Петр
Codesys и вообще контроллеры с главным циклом - как?
Для себя работаю с CODESYS на Raspberry и с контроллерами Crestron 2-серии (QM-RMC, MPC-M25, они дешевы на Ebay).
Подход Crestron интересен тем, что вот у них как раз нет главного цикла в явном виде.
Пишете например
Change Serial_Input_NNNN
{
//Делать что то, когда пришли данные через последовательный порт или по сети
}
Push Button
{
//Если кнопка или логический сигнал стал "1"
// или Release для перехода в ""0, а Change для любого изменения.
}
Очень удобно, кстати. Вывод данных почти анологично - например, Serial_Outpur_NNNN="dfdgfggfgfdg';
Встроенный язык по типу C, поддержка TCP, UDP, последоваьельных портов, RTC, статическая память от батарейки по типу 2032 (на 10 лет) 256кб и оперативная 32 мб. Вся прошивка вместе с ОС- примерно 1,5 мб. Чудо техники прошлых лет.
Последний раз редактировалось PetrP 07 авг 2021, 12:21, всего редактировалось 1 раз.
-
- не первый раз у нас
- Сообщения: 318
- Зарегистрирован: 31 окт 2017, 16:45
- Имя: Дмитрий
- Страна: Россия
- город/регион: Калининград
- Благодарил (а): 9 раз
- Поблагодарили: 82 раза
-
- здесь недавно
- Сообщения: 8
- Зарегистрирован: 05 авг 2021, 20:59
- Имя: Петр
Codesys и вообще контроллеры с главным циклом - как?
Спасибо, правда пока не понял, как у них обстоит дело с визуализацией интерфейсов? В Crestron как-то так, довольно просто делать: https://www.youtube.com/watch?v=e5lOS0mx6iA
-
- не первый раз у нас
- Сообщения: 318
- Зарегистрирован: 31 окт 2017, 16:45
- Имя: Дмитрий
- Страна: Россия
- город/регион: Калининград
- Благодарил (а): 9 раз
- Поблагодарили: 82 раза
Codesys и вообще контроллеры с главным циклом - как?
-
- здесь недавно
- Сообщения: 8
- Зарегистрирован: 05 авг 2021, 20:59
- Имя: Петр
Codesys и вообще контроллеры с главным циклом - как?
Судя по всему, в отличие от меня, с wirenboard Вы знакомы. А если не трудно - для написания логики программы там есть какой-то язык программирования?
-
- не первый раз у нас
- Сообщения: 318
- Зарегистрирован: 31 окт 2017, 16:45
- Имя: Дмитрий
- Страна: Россия
- город/регион: Калининград
- Благодарил (а): 9 раз
- Поблагодарили: 82 раза
-
- почётный участник форума
- Сообщения: 3575
- Зарегистрирован: 10 ноя 2009, 04:58
- Имя: Толмачев Михаил Алексеевич
- город/регион: г. Чехов, МО
- Благодарил (а): 6 раз
- Поблагодарили: 271 раз
Codesys и вообще контроллеры с главным циклом - как?
Кажется структура всей система задана в стандарте МЭК 61131, поэтому увы. Юзайте железки для умных домов, в них могут наворотить все, что угодно, и честно говоря, там очень много отстоя. А промышленные контроллеры работают. Если железка моргает своим выходом на доли секунды так, что не хватает времени зафиксировать этот сигнал, то ее надо заменить на другую. И все танцы с бубном. В умных домах разработчики могут не понимать этого, вот и живи с этим, как хочешь.
-
- здесь недавно
- Сообщения: 8
- Зарегистрирован: 05 авг 2021, 20:59
- Имя: Петр
Codesys и вообще контроллеры с главным циклом - как?
С этим трудно поспорить. Но все же, буфер был бы не таким уж и плохим выходом, пусть и не на каждый день. Более того, в CODESYS (библиотека NBS) есть NBS.TCP_Read, а есть и NBS.TCP_ReadBuffer. Окна-то в сообщениях есть, т.е. было бы время обработать совсем короткое сообщение, которое сейчас пропускается. И бывает это (ттт) очень редко. Но как работать с этим NBS.TCP_ReadBuffer документации вообще нет. У меня вообще есть подозрение, что там не накапливающий буфер имеется ввиду, а просто работа через указатели в явном виде. Дальше пока не разобрался.
Чисто для себя сделал вывод - если надо что-то для дома и есть в наличии дешевые контроллеры Crestron - то он, честно говоря, легко заруливает все остальное. И по удобству программирования, и по стабильности, и по визуализации интерфейсов. При условии, что инфраструктуру, прежде всего разводку, сразу продумывали головой. Если нет Crestron или нужно относительно легко добавить сторонних примочек (MQTT например или беспроводное управление - хотя здесь радио это ересь еще та), то Raspberry + CODESYS.
P.S. Вспомнил, что в CODESYS есть для главной задачи не только Циклическое выполнение, но и по событию. Но, т.к. принимающий данные блок, по крайней мере из библиотеки NBS, работает "не сам по себе", а требует циклического вызова, то это опять ничего не дает. А так, вообще было бы интересно - вызов задачи управлялся бы потоком данных. Почему бы и нет? Тем более, в моем случаее сейчас среднее время цикла 150 мкс, это довольно мало.
-
- почётный участник форума
- Сообщения: 3575
- Зарегистрирован: 10 ноя 2009, 04:58
- Имя: Толмачев Михаил Алексеевич
- город/регион: г. Чехов, МО
- Благодарил (а): 6 раз
- Поблагодарили: 271 раз
Codesys и вообще контроллеры с главным циклом - как?
NBS.TCP_ReadBuffer - я думаю то, что надо. Указатель там потому, что блок неопределенной длины... Скорее всего.
-
- read only
- Сообщения: 577
- Зарегистрирован: 19 фев 2019, 22:38
- Имя: Сергей
- Страна: Россия
- город/регион: Краснодар
- Благодарил (а): 17 раз
- Поблагодарили: 77 раз
Codesys и вообще контроллеры с главным циклом - как?
Не бывает таких промышленных контроллеров!
Что это за библиотека? Для какого CoDeSys! Для каког вендора?
Вообще от подобных вапросов возникает глубинное непонимание....
Where is mie black Gun!..на большом каретном
-
- освоился
- Сообщения: 277
- Зарегистрирован: 28 авг 2014, 09:30
- Имя: Воднев Александр Васильевич
- Страна: РФ
- город/регион: Томск
- Благодарил (а): 21 раз
- Поблагодарили: 28 раз
Codesys и вообще контроллеры с главным циклом - как?
Есть такая штука, как счетчик событий на удаленном устройстве ввода. Даже не очень почитаемые на этом форуме модули "Овен" имеют в своей архитектуре такой прибамбас. Смотрите, может у Вашего прибора есть что-нибудь аналогичное, а иначе теория вероятности и прогноз погоды в Лос-Анджелесе Вам в помощь независимо от применяемых протоколов.
-
- осмотрелся
- Сообщения: 106
- Зарегистрирован: 16 дек 2018, 16:35
- Имя: Антон
- Благодарил (а): 5 раз
- Поблагодарили: 4 раза
Codesys и вообще контроллеры с главным циклом - как?
У ТС явное непонимание принципов построения ПЛК и основ обработки информации.
Основной принцип ПЛК- детерминированность. Ни какой определённости времени выполнения цикла, а, значит, минимальном времени между внешними событиями, нельзя говорить, когда есть обработка асинхронных событий по прерывания. Поэтому в правильной программе ПЛК не_должно быть обработки прерываний при нормальном течение процесса. Обработку прерываний есть смысл делать только по событиям, ломающим нормальную работу в прямом и переносном смыслах, то есть при аварии.
Разберитесь с настройками блока Modbus/TCP. Сам протокол TCP в принципе не может работать без буферов, поэтому, если что-то теряется, то это или неправильная настройка обработки информации, или приёмник не успевает её обрабатывать.
Основной принцип ПЛК- детерминированность. Ни какой определённости времени выполнения цикла, а, значит, минимальном времени между внешними событиями, нельзя говорить, когда есть обработка асинхронных событий по прерывания. Поэтому в правильной программе ПЛК не_должно быть обработки прерываний при нормальном течение процесса. Обработку прерываний есть смысл делать только по событиям, ломающим нормальную работу в прямом и переносном смыслах, то есть при аварии.
Разберитесь с настройками блока Modbus/TCP. Сам протокол TCP в принципе не может работать без буферов, поэтому, если что-то теряется, то это или неправильная настройка обработки информации, или приёмник не успевает её обрабатывать.
-
- здесь недавно
- Сообщения: 68
- Зарегистрирован: 21 май 2021, 21:06
- Имя: Марат
- Благодарил (а): 22 раза
- Поблагодарили: 1 раз
Codesys и вообще контроллеры с главным циклом - как?
Я тоже искал промышленный контроллер со свободно программируемым поведением - и не смог найти. На данный момент пользуюсь упомянутым выше wirenboard для некритичных ко времени задач. Неспешно дописываю к нему рантайм для МЭК языков с целью совмещения коня и трепетной лани. В time-critical приложениях - использую спарку из классического ПЛК и ВБ.
Вообще, идея об устройстве двойного функционала бродит среди меня очень давно, да и реализовать его - не боинг посчитать. Останавливает только невостребованность оного на рынке, иначе бы все уже такие делали.
Подумываю взять на подергать последние Wago - цены адовые, конечно, но там заявлен не только классический рантайм, но и доступ к линуху, под которым он крутится; если из юзерспейса есть доступ к переменным рантайма, игрушка должна быть богатая.
Вообще, идея об устройстве двойного функционала бродит среди меня очень давно, да и реализовать его - не боинг посчитать. Останавливает только невостребованность оного на рынке, иначе бы все уже такие делали.
Подумываю взять на подергать последние Wago - цены адовые, конечно, но там заявлен не только классический рантайм, но и доступ к линуху, под которым он крутится; если из юзерспейса есть доступ к переменным рантайма, игрушка должна быть богатая.
Таблица Менделеева сначала приснилась Пушкину, но он ничего не понял.
-
- не первый раз у нас
- Сообщения: 318
- Зарегистрирован: 31 окт 2017, 16:45
- Имя: Дмитрий
- Страна: Россия
- город/регион: Калининград
- Благодарил (а): 9 раз
- Поблагодарили: 82 раза
Codesys и вообще контроллеры с главным циклом - как?
здесь могу посоветовать вместо ВБ использовать коммуникационные контроллеры (шлюзы протоколов, контроллеры ТМ) производства https://yugsys.ru/produktsiya/tmk-kompas-tm-2-0 , они не программируемые, а параметрируемые, с кучей протоколов, подбираются по количеству нужных интерйфейсов, есть автоматичесое управление по логике если нужно.
или использовать OPC UA и ПЛК200/210 от овен с кодесисом (да кодесис, но на сайте много документации и видео)
связка -это правильно, даже у сименса так, например 1200 ПЛК и коммуникационный процесор 1243-1 IEC
Последний раз редактировалось Sokolov_Dmitry 18 сен 2021, 16:04, всего редактировалось 1 раз.
-
- здесь недавно
- Сообщения: 68
- Зарегистрирован: 21 май 2021, 21:06
- Имя: Марат
- Благодарил (а): 22 раза
- Поблагодарили: 1 раз
Codesys и вообще контроллеры с главным циклом - как?
Вот именно. Для телеметрии, может, и подойдут, спасибо за ссылку. Хотя mqtt и opc/ua с первого диагонального взгляда не увидел.
А для сетевого взаимодействия - точно нет. В моих же проектах это необходимая задача.
Таблица Менделеева сначала приснилась Пушкину, но он ничего не понял.
-
- не первый раз у нас
- Сообщения: 318
- Зарегистрирован: 31 окт 2017, 16:45
- Имя: Дмитрий
- Страна: Россия
- город/регион: Калининград
- Благодарил (а): 9 раз
- Поблагодарили: 82 раза
Codesys и вообще контроллеры с главным циклом - как?
совершенное верно, там MQTT не используют, нет меток времени, в телеметрии метки это главное.
Еще есть ТМИУС для ВБ https://www.cea-energo.ru/ru/products/tmius-linux (как и для ПЛК Овен и Reallab)
-
- здесь недавно
- Сообщения: 68
- Зарегистрирован: 21 май 2021, 21:06
- Имя: Марат
- Благодарил (а): 22 раза
- Поблагодарили: 1 раз
Codesys и вообще контроллеры с главным циклом - как?
Интересно. Подергали уже?
Таблица Менделеева сначала приснилась Пушкину, но он ничего не понял.
-
- не первый раз у нас
- Сообщения: 318
- Зарегистрирован: 31 окт 2017, 16:45
- Имя: Дмитрий
- Страна: Россия
- город/регион: Калининград
- Благодарил (а): 9 раз
- Поблагодарили: 82 раза
Codesys и вообще контроллеры с главным циклом - как?
лично тмиус не использовал, только контроллеры с по югсистема