- Обязательно представиться на русском языке кириллицей (заполнить поле "Имя").
- Фиктивные имена мы не приветствуем. Ивановых и Пупкиных здесь уже достаточно.
- Не писать свой вопрос в первую попавшуюся тему - вместо этого создать новую тему.
- За поиск, предложение и обсуждение пиратского ПО и средств взлома - бан без предупреждения.
- Рекламу и частные объявления "куплю/продам/есть халтура" мы не размещаем ни на каких условиях.
- Перед тем как что-то написать - читать здесь и здесь, а студентам - обязательно здесь.
- Не надо писать в ЛС администраторам свои технические вопросы. Администраторы форума отлично знают как работает форум, а не все-все контроллеры, о которых тут пишут.
S7 коммуникации Ethernet
-
- эксперт
- Сообщения: 1055
- Зарегистрирован: 11 ноя 2012, 18:21
- Имя: Нурисламов Руслан М.
- Страна: Казахстан
- город/регион: Алматы
- Благодарил (а): 23 раза
- Поблагодарили: 32 раза
S7 коммуникации Ethernet
Подскажите и сориентируйте в S7 Ethernet коммуникациях.
Надо будет сделать обмен DB блоками между S7-300 контроллерами /несколько станций/ и S7-400 станцией.
Стандартными блоками Simatic Net хотел сделать. Вариантов FB несколько, помогите определиться.
Есть ли разница особая. /S7-коммуникации или через UDP пакет обмен/.
Блоки данных будут стандартные данные, с плавающей точкой.
Надо будет сделать обмен DB блоками между S7-300 контроллерами /несколько станций/ и S7-400 станцией.
Стандартными блоками Simatic Net хотел сделать. Вариантов FB несколько, помогите определиться.
Есть ли разница особая. /S7-коммуникации или через UDP пакет обмен/.
Блоки данных будут стандартные данные, с плавающей точкой.
-
- авторитет
- Сообщения: 878
- Зарегистрирован: 21 авг 2009, 14:25
- Имя: Василий Иванович
- Благодарил (а): 1 раз
- Поблагодарили: 3 раза
-
- эксперт
- Сообщения: 1055
- Зарегистрирован: 11 ноя 2012, 18:21
- Имя: Нурисламов Руслан М.
- Страна: Казахстан
- город/регион: Алматы
- Благодарил (а): 23 раза
- Поблагодарили: 32 раза
Re: S7 коммуникации Ethernet
Я хотел отработать на стенде, S7-400 у меня без CP, но с профинет портом. И честно сказать не могу ни одну коммуникацию настроить. Говорит ресурсов нет.
На объекте должен быть дополнительный CP с S7-400 контроллером. До этого ранее вел разговор с представителем Сименса, меня заверили что можно наладить комминикацию на внутренних портах контроллера.
Но честно слово, не выходит правильная конфигурация. Кто-нибудь бы подсказал.
Предполагаю всеже что CP абсолютно обязателен.
На объекте должен быть дополнительный CP с S7-400 контроллером. До этого ранее вел разговор с представителем Сименса, меня заверили что можно наладить комминикацию на внутренних портах контроллера.
Но честно слово, не выходит правильная конфигурация. Кто-нибудь бы подсказал.
Предполагаю всеже что CP абсолютно обязателен.
-
- авторитет
- Сообщения: 878
- Зарегистрирован: 21 авг 2009, 14:25
- Имя: Василий Иванович
- Благодарил (а): 1 раз
- Поблагодарили: 3 раза
Re: S7 коммуникации Ethernet
Связь через встроенный порт CPU строится на других блоках, чем через CP. Не знаю, как делать через него S7-протокол, но все остальные делаются при помощи блоков TCON, TDISCON, TSEND, TRECV. Описание построения связи найдете на сименсовской странице суппорта. Их использовать удобнее в том смысле, что можно спроектировать, загрузить и подсоединиться-отсоединиться, не роняя CPU в стоп. Правда нужно будет поковыряться с конфигурацией соединения.
-
- авторитет
- Сообщения: 878
- Зарегистрирован: 21 авг 2009, 14:25
- Имя: Василий Иванович
- Благодарил (а): 1 раз
- Поблагодарили: 3 раза
Re: S7 коммуникации Ethernet
Если же делать через СР, то соединение надо запараметрировать в NetPro, после чего строить обмен через соответствующие блоки. Недостатком будет необходимость ронять CPU в стоп при переконфигурации, а также невозможность разорвать соединение.
Мы пользуемся AG_SEND, AG_RECV, от PUT-GET уж давно отказались. Эти блоки служат для связи с СР, который сам подключается и поддерживает соединение на протяжении всего периода работы. Если обмениваться данными только с S7, то пойдет и S7-протокол, а если могут быть другие устройства, то лучше пользоваться чем-то более универсальным типа UDP. UDP удобен в смысле скорости передачи, а также тем, что известен объем принятых данных. То есть можно запустить блочок на приём, скормив ему адрес буфера, то CP сложит всё, что пришло, в буфер. Если делать через TCP, то СР будет ждать, пока не наберётся столько данных, чтобы этот буфер полностью заполнит, и только потом зальёт туда данные.
Все неприятности чаще бывают от того, что неправильно сконфигурировано соединение - адреса, номера портов, типы соединения и т.п. Очень внимательно нужно относиться к этому делу. Сперва можно просто прописать соединение в NetPro и включить онлайн, посмотреть, есть ли коннект. И только когда есть зелёный треугольник, можно пробовать писать или читать. Через встроенный порт соединение конфигурируется путём записи данных в определенный DB, причём там куча параметров - один раз ошибся и усё. Когда это дело прописано, вызываем TCON и проверяем, что он там понаписал на выходах. Есть соединение - можно попробовать. слать и принимать.
Как-то так, в общем.
Мы пользуемся AG_SEND, AG_RECV, от PUT-GET уж давно отказались. Эти блоки служат для связи с СР, который сам подключается и поддерживает соединение на протяжении всего периода работы. Если обмениваться данными только с S7, то пойдет и S7-протокол, а если могут быть другие устройства, то лучше пользоваться чем-то более универсальным типа UDP. UDP удобен в смысле скорости передачи, а также тем, что известен объем принятых данных. То есть можно запустить блочок на приём, скормив ему адрес буфера, то CP сложит всё, что пришло, в буфер. Если делать через TCP, то СР будет ждать, пока не наберётся столько данных, чтобы этот буфер полностью заполнит, и только потом зальёт туда данные.
Все неприятности чаще бывают от того, что неправильно сконфигурировано соединение - адреса, номера портов, типы соединения и т.п. Очень внимательно нужно относиться к этому делу. Сперва можно просто прописать соединение в NetPro и включить онлайн, посмотреть, есть ли коннект. И только когда есть зелёный треугольник, можно пробовать писать или читать. Через встроенный порт соединение конфигурируется путём записи данных в определенный DB, причём там куча параметров - один раз ошибся и усё. Когда это дело прописано, вызываем TCON и проверяем, что он там понаписал на выходах. Есть соединение - можно попробовать. слать и принимать.
Как-то так, в общем.
-
- эксперт
- Сообщения: 1055
- Зарегистрирован: 11 ноя 2012, 18:21
- Имя: Нурисламов Руслан М.
- Страна: Казахстан
- город/регион: Алматы
- Благодарил (а): 23 раза
- Поблагодарили: 32 раза
Re: S7 коммуникации Ethernet
Спасибо большое. В свете того что я уже в командировке, такой хороший основательный ответ просто бесценнен.
Достал я уже CP процессор в другом городе. Авто очень обидно что сломалась, но CP-шник уже в наличии. Как будут нормальные условия буду пробовать.
Пока проблемы выжить в чужом городе и из точки А в точку Б попасть без приключений.
Когда ньюансами делятся, даже не представляете насколько это упрощает все возникающие вопросы.
Достал я уже CP процессор в другом городе. Авто очень обидно что сломалась, но CP-шник уже в наличии. Как будут нормальные условия буду пробовать.
Пока проблемы выжить в чужом городе и из точки А в точку Б попасть без приключений.
Когда ньюансами делятся, даже не представляете насколько это упрощает все возникающие вопросы.
-
- эксперт
- Сообщения: 1055
- Зарегистрирован: 11 ноя 2012, 18:21
- Имя: Нурисламов Руслан М.
- Страна: Казахстан
- город/регион: Алматы
- Благодарил (а): 23 раза
- Поблагодарили: 32 раза
Re: S7 коммуникации Ethernet
Подскажите пожалуйста. Настроил коммуникацию через TCP коннект, получил данные через AG_SEND и AG_RECV. Для тестовой конфигурации я использовал два CPU 314 + CP343-1 Lean.
Что хотел узнать. Нужен будет обмен несколькими DB блоками. То есть один контроллер должен отправить от себя DB блок, и от другого принять DB. Насколько я понимаю, количество коннект соединений лимитировано.
То есть больше определенного числа коннекций я не могу использовать?
И еще вопрос. Все что проверял на тестовом примере относится только к тестированию. По факту будет
CPU S7-400 вести обмен с S7-300 станциями.
Исходя из мануалов, AG-SEND и AG-RECV относятся к s7-300 контроллерам. Для 400-серии контроллеров набор
блоков более расширен /функц. блока позволяют вести обмен большим объемом и есть модификации позволяющие передавать и принимать с большей скоростью чем стандартного промышленного Ethernet/.
Какими функциональными блоками лучше воспользоваться для S7-400 станции? Или AG_Send и AG_RECV пойдут и на S7-400 контроллере?
Такой вопрос задаю ввиду того, что S7-400 контроллер работает в плотном режиме и отрабатывает программу целого производства. Поэкспериментировать с разными режимами передачи на нем не имею возможности.
Любая ошибка чревата срывом процесса и остановом производства.
Что хотел узнать. Нужен будет обмен несколькими DB блоками. То есть один контроллер должен отправить от себя DB блок, и от другого принять DB. Насколько я понимаю, количество коннект соединений лимитировано.
То есть больше определенного числа коннекций я не могу использовать?
И еще вопрос. Все что проверял на тестовом примере относится только к тестированию. По факту будет
CPU S7-400 вести обмен с S7-300 станциями.
Исходя из мануалов, AG-SEND и AG-RECV относятся к s7-300 контроллерам. Для 400-серии контроллеров набор
блоков более расширен /функц. блока позволяют вести обмен большим объемом и есть модификации позволяющие передавать и принимать с большей скоростью чем стандартного промышленного Ethernet/.
Какими функциональными блоками лучше воспользоваться для S7-400 станции? Или AG_Send и AG_RECV пойдут и на S7-400 контроллере?
Такой вопрос задаю ввиду того, что S7-400 контроллер работает в плотном режиме и отрабатывает программу целого производства. Поэкспериментировать с разными режимами передачи на нем не имею возможности.
Любая ошибка чревата срывом процесса и остановом производства.
-
- эксперт
- Сообщения: 1055
- Зарегистрирован: 11 ноя 2012, 18:21
- Имя: Нурисламов Руслан М.
- Страна: Казахстан
- город/регион: Алматы
- Благодарил (а): 23 раза
- Поблагодарили: 32 раза
Re: S7 коммуникации Ethernet
И кстати, почему-то S7-коннекция у меня не пошла/хотя вроде как S7-коммуникации не ограничиваются Profibus DP сетью или сетью MPI/, TCP коннекция вполне благополучно настроилась.
-
- авторитет
- Сообщения: 878
- Зарегистрирован: 21 авг 2009, 14:25
- Имя: Василий Иванович
- Благодарил (а): 1 раз
- Поблагодарили: 3 раза
Re: S7 коммуникации Ethernet
AG-блоки прекрасно работают и на 400 серии тоже. Причем даже если их взять из библиотеки для S7-300 (несмотря на то, что есть своя версия для S7-400). Вы можете также использовать AG_LSEND/AG_LRECV, они позволяют слать большие объёмы данных, а также AG_SSEND, AG_SRECV - если надо быстрее. Есть ещё AG_CNTRL - с помощью его можно сделать дисконнект и сброс соединения.
Число конфигурируемых соединений ограничено и зависит от железяки, в которую входит сетевой кабель. Для трехсотого СР это 8. Если хотите слать больше, можете сложить несколько малых DB в один большой и отправлять его через одно соединение, раздёргивая данные после приёма снова по нескольким DB.
Насчет S7-соединения помочь не могу - не пользуюсь.
Число конфигурируемых соединений ограничено и зависит от железяки, в которую входит сетевой кабель. Для трехсотого СР это 8. Если хотите слать больше, можете сложить несколько малых DB в один большой и отправлять его через одно соединение, раздёргивая данные после приёма снова по нескольким DB.
Насчет S7-соединения помочь не могу - не пользуюсь.
-
- эксперт
- Сообщения: 1055
- Зарегистрирован: 11 ноя 2012, 18:21
- Имя: Нурисламов Руслан М.
- Страна: Казахстан
- город/регион: Алматы
- Благодарил (а): 23 раза
- Поблагодарили: 32 раза
Re: S7 коммуникации Ethernet
Большое спасибо. Все вроде бы получается.
У меня такой вопрос. На одну передачу я могу определить только один DB блок как я понимаю /если данных много, то все представлять одним блоком/.
Из мануала выходит такая информация: With AG_SEND / AG_RECV program blocks, the data length per job is restricted to <=240 bytes.
Если нужно несколько DB переслать, соответственно можно сделать несколько конекций и уже несколько DB перекидывать?
Моя ситуация такая, что с многих мест идет сбор данных посредством S7-300 контроллеров с коммуникационником, все передается на S7-400
контроллер в итоге. И как я понимаю все эти изыски, типа блоков с повышенной скоростью передачи, или блоков позволяющих передавать большие DB блоки в 8кбайт в моем примере не применимы никак, раз идет соединение S7-300 к S7-400. Все ограниченно тем что может S7-300.
Коннекций 8 для 300 позволят 240 х 8 =1920 байт в максимуме передать с одного S7-300.
Сколько в пределе коннекций позволительно иметь на СР для 400 контроллера? 64???
У меня такой вопрос. На одну передачу я могу определить только один DB блок как я понимаю /если данных много, то все представлять одним блоком/.
Из мануала выходит такая информация: With AG_SEND / AG_RECV program blocks, the data length per job is restricted to <=240 bytes.
Если нужно несколько DB переслать, соответственно можно сделать несколько конекций и уже несколько DB перекидывать?
Моя ситуация такая, что с многих мест идет сбор данных посредством S7-300 контроллеров с коммуникационником, все передается на S7-400
контроллер в итоге. И как я понимаю все эти изыски, типа блоков с повышенной скоростью передачи, или блоков позволяющих передавать большие DB блоки в 8кбайт в моем примере не применимы никак, раз идет соединение S7-300 к S7-400. Все ограниченно тем что может S7-300.
Коннекций 8 для 300 позволят 240 х 8 =1920 байт в максимуме передать с одного S7-300.
Сколько в пределе коннекций позволительно иметь на СР для 400 контроллера? 64???
-
- авторитет
- Сообщения: 878
- Зарегистрирован: 21 авг 2009, 14:25
- Имя: Василий Иванович
- Благодарил (а): 1 раз
- Поблагодарили: 3 раза
Re: S7 коммуникации Ethernet
AG_SEND/AG_RECV для S7-300 могут слать и принимать пакеты размером до 8 килобайт! Это их версия для S7-400 шлёт 240 байт, но у четырехсоток для больших объёмов есть AG_LSEND/AG_LRECV. Исходя из этого через один CP для S7-300 можно единовременно продавить до 64 килобайт. Если нужно больше - втыкайте ещё один СP или мультиплексируйте как-нибудь.
Максимальное число TCP-соединений нужно читать в описании конкретного СР. Для CP443-1 это будет как правило 64.
Максимальное число TCP-соединений нужно читать в описании конкретного СР. Для CP443-1 это будет как правило 64.
-
- авторитет
- Сообщения: 878
- Зарегистрирован: 21 авг 2009, 14:25
- Имя: Василий Иванович
- Благодарил (а): 1 раз
- Поблагодарили: 3 раза
Re: S7 коммуникации Ethernet
Кстати, чистый TCP для циклической пересылки областей данных использовать очень не советую, поскольку в протоколе нет пакетирования - начало и конец данных могут потеряться. Либо UDP, либо Iso-on-TCP.
-
- эксперт
- Сообщения: 1055
- Зарегистрирован: 11 ноя 2012, 18:21
- Имя: Нурисламов Руслан М.
- Страна: Казахстан
- город/регион: Алматы
- Благодарил (а): 23 раза
- Поблагодарили: 32 раза
Re: S7 коммуникации Ethernet
Имел уже секас с другими контроллерами, до Сименса недавно дошел. И как раз у меня на ТСР передаче на нижнем уровне столько проблем было. И кстати получилось то все как раз на UDP.
Я поэтому по Сименсу только вопросы и задаю, но то что мне лучше UDP где-то костным мозгом догадываюсь.
Вопрос теперь по соединению. При прописывании соединения
один контроллер инициирует передачу по определенному ID. Другой принимает.
Значит ли это что мне необходимо два разных ID, если у меня в двух разных
направлениях два разных DB пересылаются? Я создал одно ID и на двух контроллерах сделал отправку одного и прием другого блока.
Если активный узел на шине один, наверное это в корне не правильно, и соответственно я не должен ничего принять на одном блоке/? /по факту я что-то видел в результате пересылки, но возможно циклически оно работать не обязано/
Просто на TCP есть указание, кто активирует запрос посылки. А на UDP
нет. И не ясно, должно оно так работать. Или под один ID коннекта будте добры, принимайте только один DB блок?
У меня от CPU400 станции должны идти DB блок под 500 байт на CPU300.
Если я задействую AG_LSEND на 400, стандартный блок под S7-300 примет ли эти 500 байт? /тривиальный может вопрос, завтра буду пробовать в практике конечно/
Расстояние между двумя контроллерами около 4 км, так что совсем все быстро везде все посмотреть как-то не выходит.
Я поэтому по Сименсу только вопросы и задаю, но то что мне лучше UDP где-то костным мозгом догадываюсь.
Вопрос теперь по соединению. При прописывании соединения
один контроллер инициирует передачу по определенному ID. Другой принимает.
Значит ли это что мне необходимо два разных ID, если у меня в двух разных
направлениях два разных DB пересылаются? Я создал одно ID и на двух контроллерах сделал отправку одного и прием другого блока.
Если активный узел на шине один, наверное это в корне не правильно, и соответственно я не должен ничего принять на одном блоке/? /по факту я что-то видел в результате пересылки, но возможно циклически оно работать не обязано/
Просто на TCP есть указание, кто активирует запрос посылки. А на UDP
нет. И не ясно, должно оно так работать. Или под один ID коннекта будте добры, принимайте только один DB блок?
У меня от CPU400 станции должны идти DB блок под 500 байт на CPU300.
Если я задействую AG_LSEND на 400, стандартный блок под S7-300 примет ли эти 500 байт? /тривиальный может вопрос, завтра буду пробовать в практике конечно/
Расстояние между двумя контроллерами около 4 км, так что совсем все быстро везде все посмотреть как-то не выходит.
-
- авторитет
- Сообщения: 878
- Зарегистрирован: 21 авг 2009, 14:25
- Имя: Василий Иванович
- Благодарил (а): 1 раз
- Поблагодарили: 3 раза
Re: S7 коммуникации Ethernet
ID не играет никакой роли для контроллера на той стороне. Он служит лишь для нумерации соединений внутри одного CP. Для контроллера-партнёра играет роль лишь номер порта (ну и IP-адрес, конечно). И всё. Хотите два соединения между контроллерами - будьте добры зарезервировать две пары портов.
Эта галочка в TCP-соединении означает не того, кто данные шлёт, а того, кто является TCP-клиентом, т.е. инициирует коннект. Когда коннект уже установлен (как правило, как только взлетел из стопа второй СР из пары), данные через соединение могут слаться в оба конца. Для UDP эта галочка отсутствует, поскольку в этом протоколе коннект отсутствует в принципе (что увы не улучшает надёжность передачи данных). И для UDP тоже можно слать через одно и тоже соединение данные в оба конца.
На Ваш тривиальный вопрос будет тривиальный ответ - да. Стопудово.
Эта галочка в TCP-соединении означает не того, кто данные шлёт, а того, кто является TCP-клиентом, т.е. инициирует коннект. Когда коннект уже установлен (как правило, как только взлетел из стопа второй СР из пары), данные через соединение могут слаться в оба конца. Для UDP эта галочка отсутствует, поскольку в этом протоколе коннект отсутствует в принципе (что увы не улучшает надёжность передачи данных). И для UDP тоже можно слать через одно и тоже соединение данные в оба конца.
На Ваш тривиальный вопрос будет тривиальный ответ - да. Стопудово.
-
- эксперт
- Сообщения: 1055
- Зарегистрирован: 11 ноя 2012, 18:21
- Имя: Нурисламов Руслан М.
- Страна: Казахстан
- город/регион: Алматы
- Благодарил (а): 23 раза
- Поблагодарили: 32 раза
Re: S7 коммуникации Ethernet
Пытался я через одно соединение и дата блок с 300 контроллера стянуть, и через него же в датаблок данные записать, однозначно для этой задачи по разным портам данные должны идти.
Добавил новые соединения. И с 400 контроллера LSEND запустил. Все данные получил.
Одно но, пару км расстояния иногда дают свою лепту. Данные бывают частично
искаженные приходят. Как-то можно избежать этого.
В блок передаются данные настроек, и часть значений бывает идет нулями.
Что не есть гуд. Но совсем без помех думаю никак не выйдет.
Добавил новые соединения. И с 400 контроллера LSEND запустил. Все данные получил.
Одно но, пару км расстояния иногда дают свою лепту. Данные бывают частично
искаженные приходят. Как-то можно избежать этого.
В блок передаются данные настроек, и часть значений бывает идет нулями.
Что не есть гуд. Но совсем без помех думаю никак не выйдет.
-
- авторитет
- Сообщения: 878
- Зарегистрирован: 21 авг 2009, 14:25
- Имя: Василий Иванович
- Благодарил (а): 1 раз
- Поблагодарили: 3 раза
Re: S7 коммуникации Ethernet
Я нигде там вверху не писал, что соединение дуплексное. Оно полудуплексное. Т.е. в один момент времени либо шлёте, либо принимаете, но не то и другое вместе.
С Вашими проблемами использовать UDP противопоказано. Ставьте ISO-on-TCP - он самый надёжный.
С Вашими проблемами использовать UDP противопоказано. Ставьте ISO-on-TCP - он самый надёжный.
-
- эксперт
- Сообщения: 1055
- Зарегистрирован: 11 ноя 2012, 18:21
- Имя: Нурисламов Руслан М.
- Страна: Казахстан
- город/регион: Алматы
- Благодарил (а): 23 раза
- Поблагодарили: 32 раза
Re: S7 коммуникации Ethernet
Передачу данных отстроил получше. Вроде как все поменялось в лучшую сторону. Данные меняются несколько раз в секунду.
Я думаю пока для обкатки вполне достаточно так оставить. Мне интересно, если таких соединений будет не один десяток.
Динамичность системы не поменяется? Насчет дуплекса - спасибо. Теперь я уверен, что программа как надо работает, и в ней все в порядке.
Еще бы знать не помешало насколько хорошо все будет работать с очень большим количеством соединений. Иногда ведь все работает до некоего
предела, после которого могут возникать какие-то непредсказуемости.
Даже на обычном Wi-Fi споте если ему одному предстоит под полсотни устройств обслужить, периодически бывает по сеансу связи обрывы одного конечного соединения.
Конечно на хорошем железе этот порог изначально большой.
Я думаю пока для обкатки вполне достаточно так оставить. Мне интересно, если таких соединений будет не один десяток.
Динамичность системы не поменяется? Насчет дуплекса - спасибо. Теперь я уверен, что программа как надо работает, и в ней все в порядке.
Еще бы знать не помешало насколько хорошо все будет работать с очень большим количеством соединений. Иногда ведь все работает до некоего
предела, после которого могут возникать какие-то непредсказуемости.
Даже на обычном Wi-Fi споте если ему одному предстоит под полсотни устройств обслужить, периодически бывает по сеансу связи обрывы одного конечного соединения.
Конечно на хорошем железе этот порог изначально большой.
-
- авторитет
- Сообщения: 878
- Зарегистрирован: 21 авг 2009, 14:25
- Имя: Василий Иванович
- Благодарил (а): 1 раз
- Поблагодарили: 3 раза
Re: S7 коммуникации Ethernet
Для СР не просто так прописано максимальное число соединений, а для обеспечения определённого качества связи. Т.е. всё будет работать и с десятками соединений так же. У нас, во всяком случае, работает.