Соглашусь, функция загрузки с USB полезная, много раз не хватало.
Вид для печати
Соглашусь, функция загрузки с USB полезная, много раз не хватало.
Я не рискну таким образом вносить изменения в программу. Не видя как изменения отработают на объекте.Цитата:
Сообщение от Николаев Андрей
Да и изменения в схеме запросто могут сделать в процессе эксплуатации.
Что поделать, за время, что я занимаюсь автоматизацией, сильно потерял веру в здравый смысл людей. :D
Особенно если это делает кто-то другой, добрый человек...Цитата:
Сообщение от Дмитрий Артюховский
Возможно, уже спрашивали, но я не нашёл.
Скажите, а в новых плк110 есть нормальный обмен по GPRS или так же придётся отказаться от Ethernet, как в предыдущей версии контроллера?
От Ethernet отказываться не придется точно - при чем здесь GPRS...
GPRS будет поддержан, но уже в М02 к сожалению (планируется к появлению осенью).
Спасибо, понятно, очень хорошо.
Просто я читал в документации к примеру связи по GPRS для плк110, что IP и шлюз в сети провайдера прописываются в секции modbus TCP, поэтому ни для загрузки программы, ни как-то ещё воспользоваться портом Ethernet не получится.
Извините, сейчас посмотрел - и не нашёл там подобного О_о. Надо испытать.
итак, начало июня состоялось! ну и где ПЛК????
Все там же.Цитата:
Сообщение от Дмитрий Артюховский
Когда начнутся продажи обновленного ПЛК110 ? Когда можно будет заказать?
В заказном номере (наименовании модели плк) будут какие-нибудь отличия от старых моделей?
Текущий прогноз начала продаж - середина июля.
Первая модификация.
Дальше будут с интервалом в 2 недели выходить следующие модификации
Середина июля?!
Обещанного три года ждут.Цитата:
Сообщение от Дмитрий Артюховский
Добрый день.Цитата:
Сообщение от Николаев Андрей
Что такое М02?
Меня очень заинтересовал новый плк110 и я создал тему с вопросами (эту не видел).
Перенесу сюда.
Цитата:
Сообщение от Scream
Да, ответы кратки и ясны. Ждёмс.
А на что отвечать, что не вопрос,так какая нибудь очевидная вещьЦитата:
Сообщение от Scream
Для меня нет тут очевидных вещей, с овеном так быть не может.Цитата:
Сообщение от capzap
Тогда жду этих очевидных ответов.
1) другой порт это другой порт, как захочет разработчик тем и будет, 110 и до модернизации были с двумя портами 485, а если разные то все плк несут на борту минимум два последовательных порта и в большинстве случаев вопросов по работе нет. И какое отношение это имеет к обновленному плк?
2) В дебрях темы обсуждалась запись файлов через библиотеку. Объем Флешки зависит от файловой системы на ней и сможет ли её прочитать ОС контроллера, сколько поддерживает fat?
3) брали многие и комменты в теме оставляли
4) слово вебинар приходилось слышать, читайте рассылку от овена и будете вкурсе всех мероприятий
567) вопросы лицензии ни как не связаны с модернизацией это касается всех плк, если конфигурация побайтно и с выравниванием укладывается в 360 то можно брать и с елькой
Как заказывать смотрим на сайте,когда модернизованный будет объявлен в каталоге
будут и L и M модификации.
Скинь маску, тут тебе не маскарад.Цитата:
Сообщение от Scream
Не тебе, а Вам. Будьте большим и воспитанным.Цитата:
Сообщение от IVM
Ваше сообщение не несет никакой смысловой нагрузки по теме, разве что набивание постов.
Ни слова о вебинаре там нет поэтому и спросил.Цитата:
Сообщение от capzap
fat поддерживает много. Так вот меня и интересует сколько сможет прочитать ОС контроллера.
Контроллер очень шустрый, ОС там нет(КДС 2.3)
Обращение на ВЫ еще надо заслужить.Цитата:
Сообщение от Scream
Кому они нужны эти посты.Цитата:
Сообщение от Scream
Мужики, а на тестовых ПЛК110 syslibsockets вообще работает?
Пытаюсь запустить клиента: сокет открывается, но не коннектится.
Такой же код на ПЛК150 работает.
В отличие от старой линейки функция accept теперь полнофункциональна и возвращает handle сокета. По нему и надо обращаться.
Владислав, я видимо не корректно поставил вопрос: у меня не работает клиент на ПЛК. Абсолютно одинаковый код, абсолютно одинаковый компьютер-сервер, к которому пытаюсь достучаться с ПЛК 110 new и c ПЛК150. Так вот на ПЛК150 всё хорошо, соединяется, обмен идёт. На ПЛК110 new SysSockCreate отрабатывает (возвращает 17,16,15 ...), SysSockConnect всегда возвращает 0 как и на ПЛК150, только там при этом обмен идёт, а на 110-м нет.
Выложите проект, посмотрю что к чему.
проект во вложении
sa.sin_addr := SysSockHtonl(dwIPAddr);
sa.sin_port := SysSockHtons(wPort);
И какой прошивкой пользуетесь? установочная версия на заводе 0.2.53
Спасибо огромное! Работает!
Последнюю прошивку которую заливал - 0.2.24
Увидел пометку о возможности программирования ПЛК110 под CDS3.
Это обозначает полный переход ПЛК110 под CDS 3? или как то будет реализована возможность выбора?
Очень не нравиться работа с библиотеками в CDS3 для ПЛК304 - ужасно.
Конфигуратор в CDS2.3 гораздо приятнее.
Развейте мои страхи. Ядро CDS3 встроено в чип ПЛК или насажено поверх Linux как в ПЛК304?
Возвращаемся в эфир.
ПЛК110 новый сейчас будет на платформе CODESYS 2. В дальнейшем, как тенденцию, планируем переводить на CODESYS 3. Он уже будет, с большой вероятностью, с Linux. Но для пользователя это будет оставаться так-же не сильно заметно.
По состоянию дел на данный момент.
Открытые продажи приборов начнутся уже на следующей неделе.
Но, к сожалению, модификации появятся не все и не сразу.
ПЛК110-24.30.Р-М. С них мы начнем.
ПЛК110-24.60.К-М. Планируются к концу октября.
Остальные - позже.
В первых числах октября проведем вебинар, на котором расскажем что да как. В чем отличия и пр. Следите за новостями.
Товарищи, подскажите пожалуйста:
Тестирую обмен данными через сокеты на новом ПЛК110. Скорость работы с сокетами конечно ломовая по сравнению с ПЛК150. Делаю такой тест: с компьютера-сервера посылаю команды (36 байт) контроллеру-клиенту в непрерывном цикле, на которые контроллер отвечает пакетами по 239 байт. Min время цикла ПЛК = 2 мс. Вызовы SysSockSend и SysSockRecv разнесены по разным циклам и чередуются (при наличии пакета для передачи). Когда количество таких циклов превышает 18 (т.е. передано более примерно 4кБ данных), прекращается передача данных со стороны контроллера, при этом функция SysSockSend корректно возвращает количество переданных байт, но сервер ничего не видит. При этом данные от сервера до контроллера доходят. Далее, через 20 сек. сервер закрывает соединение и после переподключения контроллера передача данных возобновляется. В связи с этим у меня вопрос: правильно я понимаю, что в моём случае происходит переполнение буфера отправки сокета? Почему передача не восстанавливается за 20 секунд таймаута? С какой максимальной скоростью ПЛК110 способен передавать данные через сокеты?
Хотелось бы посмотреть на программу, удалённо ничего сказать не могу. Та же связь по GetWay генерирует значительно больший трафик чем в описанном тесте и такого поведения не наблюдается.
P.S.- клиент и сервер не перепутаны местами в описании?Цитата:
с компьютера-сервера посылаю команды (36 байт) контроллеру-клиенту
P.P.S. Какая версия ПО? - если 0.2.24 - то тестирование на 0.2.24 не имеет смысла, т.к. с тех пор проведен огромный комплекс работ по тестированию, отладке и настройке ПО.
Нет, всё правильно у нас реализована событийная модель обмена, и клиент и сервер могут отправлять сообщения в произвольный момент времени, ожидая ответа или нет.Цитата:
- клиент и сервер не перепутаны местами в описании?
Да, версия ПО именно 0.2.24, эта версия последняя что публиковалась в этом топике, если я ничего не пропустил... А где взять последнюю?Цитата:
P.P.S. Какая версия ПО? - если 0.2.24 - то тестирование на 0.2.24 не имеет смысла
Часть проекта во вложении
1. Последнюю версию ПО можно запросить в нашей техподдержке + она должна появится на сайте.Цитата:
Сообщение от _Pavel_
2. Обязанность клиента (в терминологии стека ТСP) поддерживать соединение, постоянно передавая пакеты, иначе сработает таймаут.
3. Таймауты на повтор пакетов у Вас великоваты - 3 секунды - поставьте 1.
3а. Таймаут должен отсчитываться во всех состояниях с установленным соединением.
4. В программе ожидается определённое количество байт и считываются только они - если придёт лишний - он никогда не будет считан и буфера закончатся :) Правильно - всегда считывать все данные из сокета до момента возврата нуля в ответе SySSockRecv(). Иначе будет вышеописаное.
5. По задачам - за 1 цикл ПЛК способен выполнить только 1 задачу, даже если ещё 20 уже заждались очереди. Т.о. если я правильно расшифровал текстовые поля в описании задач - (лучше бы проект .pro прислали чтобы не мучится), то у Вас множество задач по событиям (т.е. возможно каждый цикл будут вызываться) и MainTask в режиме свободного вызова (крайне не рекомендую на CoDeSys 2 Embedded, ведёт себя непредсказуемо).
При такой конфигурации период вызова MainTask не определён. Попробуйте вычленить коммуникационную часть и с учётом рекомендаций 3 и 4 проверить в монопольной задаче.
Владислав, спасибо за ответ!
Хорошо, попробую запросить.Цитата:
1. Последнюю версию ПО можно запросить в нашей техподдержке + она должна появится на сайте.
Да, я это знаю. Только у нас это немного не так реализовано: при подключении клиента сервер начинает посылать раз в секунду специальные пакеты (PulsePacket), на которые клиент сразу же отвечает. Если сервер не получит хотя бы один из этих пакетов в течении определённого времени (20 сек), он закроет сокет.Цитата:
Обязанность клиента (в терминологии стека ТСP) поддерживать соединение, постоянно передавая пакеты, иначе сработает таймаут.
Таймаут в 3 секунды здесь задан как раз для контроля Pulse-пакетов от сервера, если в течении 3-х секунд мы не получили от сервера Pulse-пакет или вообще чего-нибудь, то мы закрываем сокет и переподключаемся.Цитата:
3. Таймауты на повтор пакетов у Вас великоваты - 3 секунды - поставьте 1.
3а. Таймаут должен отсчитываться во всех состояниях с установленным соединением.
Не совсем так: чтение происходит в несколько этапов:Цитата:
4. В программе ожидается определённое количество байт и считываются только они - если придёт лишний - он никогда не будет считан и буфера закончатся Правильно - всегда считывать все данные из сокета до момента возврата нуля в ответе SySSockRecv(). Иначе будет вышеописаное.
1. Читаем шапку пакета (4 байта) в которой мы должны распознать принадлежность пакета и считать его размер. (это заложено в нашем протоколе)
2. Запускаем процедуру обработки пакета, которая считывает из сокета определённое количество байт, указанное в шапке, далее идёт разбор пакета и выполнение определённых действий.
3. Далее мы повторяем вышеописанные действия, проверяя нет ли ещё данных в сокете. Завершаем цикл при выполнении одного из условий: чтение сокета вернуло 0, либо кончилось количество попыток. Может быть в этом и есть ошибка: я должен обязательно дочитать все данные до 0... Я ограничил количество попыток 5-ю, дабы потенциально не раздувать время цикла.
Да, событийных задач довольно много: срабатывание каждого дискретного входа ПЛК, задний фронт. Одна циклическая задачка 3 раза в секунду. Но, относительно времени цикла ПЛК ( не более 0,7 - 1,2 мс судя по модулю статистики), эти события ооочень редки,а выполняются они ооочень быстро, поэтому при временных расчётах ими вообще можно пренебречь. То есть ситуация когда событийные задачки будут вызываться каждый цикл абсолютно исключена. Т.о. коммуникационная часть выполняется максимально часто. Т.е. насколько я понял в моём случае нужно ставить минимальное время цикла в ноль.Цитата:
5. По задачам - за 1 цикл ПЛК способен выполнить только 1 задачу, даже если ещё 20 уже заждались очереди. Т.о. если я правильно расшифровал текстовые поля в описании задач - (лучше бы проект .pro прислали чтобы не мучится), то у Вас множество задач по событиям (т.е. возможно каждый цикл будут вызываться) и MainTask в режиме свободного вызова (крайне не рекомендую на CoDeSys 2 Embedded, ведёт себя непредсказуемо).
Есть ли лог снифера?
Чтобы мне погонять программу - нужен проект (можно по почте прислать), т.к. экспортный файл импортируется с ошибками.
И ответная часть - сервер на ПК.
Пробовал посмотреть: может какая ошибка сокета появляется с помощью ФБ SysSockGetLastError, но он почему-то bDONE никогда не бывает TRUE. Правильно я применяю этот ФБ?
Программу могу выслать, но вот серверную часть... :) Вы её врядли сможете запустить, т.к. она запускается из под DOSа весьма не тривиальным способом. Сниффера под dosом нет. Претензий к серверной части у меня нет, она давно уже отлажена и работает. Причём штатно она ворочает довольно большими объёмами строковой информации.Цитата:
SysSockGetLastError(bEnable := TRUE, diSocket := udiSocketHnd);
IF SysSockGetLastError.bDone THEN
dwSockLastError := MAX( dwSockLastError, SysSockGetLastError.dwLastError); SysSockGetLastError(bEnable := FALSE);
END_IF;
Отмечаю ещё один интересный факт: наш протокол предусматривает отправку сообщений серверу о событиях, происходящих на контроллере, а также ответные сообщения на команды сервера. Так вот если я эти сообщения передаю отдельными пакетами (~40 байт) в разных циклах то проблема с "умиранием" SysSockSend на контроллере появляется гораздо позже, чем если я склеиваю несколько этих событий в один пакет (200 - 500 байт) и вызываю SysSockSend. Такое ощущение, что я переполняю некий буфер у сокета и он из этого состояния не может выйти без переподключения.
Ещё раз формулирую проблему: при интенсивном обмене данными через сокеты возникает такой момент когда SysSockSend корректно возвращает количество переданных байт, но реально сервер их не получает, при этом SysSockRecv корректно получает данные. Помогает закрытие-открытие сокета на контроллере: обмен тутже восстанавливается.
Попробовал этот же код на ПЛК150, проблемы с SysSockSend не наблюдал, при аналогичном тесте соединение живёт, однако если при дальнейшем очень интенсивном обмене 150-ый вообще уходит в ребут :)