S7 коммуникации Ethernet

[ASUTP_PLC]

Подскажите и сориентируйте в S7 Ethernet коммуникациях.

Надо будет сделать обмен DB блоками между S7-300 контроллерами /несколько станций/ и S7-400 станцией.

Стандартными блоками Simatic Net хотел сделать. Вариантов FB несколько, помогите определиться.
Есть ли разница особая. /S7-коммуникации или через UDP пакет обмен/.
Блоки данных будут стандартные данные, с плавающей точкой.

[Василий Иванович]

А порты какие - профинетовские или СР?

[ASUTP_PLC]

Я хотел отработать на стенде, S7-400 у меня без CP, но с профинет портом. И честно сказать не могу ни одну коммуникацию настроить. Говорит ресурсов нет.

На объекте должен быть дополнительный CP с S7-400 контроллером. До этого ранее вел разговор с представителем Сименса, меня заверили что можно наладить комминикацию на внутренних портах контроллера.
Но честно слово, не выходит правильная конфигурация. Кто-нибудь бы подсказал.
Предполагаю всеже что CP абсолютно обязателен.

[Василий Иванович]

Связь через встроенный порт CPU строится на других блоках, чем через CP. Не знаю, как делать через него S7-протокол, но все остальные делаются при помощи блоков TCON, TDISCON, TSEND, TRECV. Описание построения связи найдете на сименсовской странице суппорта. Их использовать удобнее в том смысле, что можно спроектировать, загрузить и подсоединиться-отсоединиться, не роняя CPU в стоп. Правда нужно будет поковыряться с конфигурацией соединения.

[Василий Иванович]

Если же делать через СР, то соединение надо запараметрировать в NetPro, после чего строить обмен через соответствующие блоки. Недостатком будет необходимость ронять CPU в стоп при переконфигурации, а также невозможность разорвать соединение.
Мы пользуемся AG_SEND, AG_RECV, от PUT-GET уж давно отказались. Эти блоки служат для связи с СР, который сам подключается и поддерживает соединение на протяжении всего периода работы. Если обмениваться данными только с S7, то пойдет и S7-протокол, а если могут быть другие устройства, то лучше пользоваться чем-то более универсальным типа UDP. UDP удобен в смысле скорости передачи, а также тем, что известен объем принятых данных. То есть можно запустить блочок на приём, скормив ему адрес буфера, то CP сложит всё, что пришло, в буфер. Если делать через TCP, то СР будет ждать, пока не наберётся столько данных, чтобы этот буфер полностью заполнит, и только потом зальёт туда данные.

Все неприятности чаще бывают от того, что неправильно сконфигурировано соединение - адреса, номера портов, типы соединения и т.п. Очень внимательно нужно относиться к этому делу. Сперва можно просто прописать соединение в NetPro и включить онлайн, посмотреть, есть ли коннект. И только когда есть зелёный треугольник, можно пробовать писать или читать. Через встроенный порт соединение конфигурируется путём записи данных в определенный DB, причём там куча параметров - один раз ошибся и усё. Когда это дело прописано, вызываем TCON и проверяем, что он там понаписал на выходах. Есть соединение - можно попробовать. слать и принимать.

Как-то так, в общем.

[ASUTP_PLC]

Спасибо большое. В свете того что я уже в командировке, такой хороший основательный ответ просто бесценнен.

Достал я уже CP процессор в другом городе. Авто очень обидно что сломалась, но CP-шник уже в наличии. Как будут нормальные условия буду пробовать.
Пока проблемы выжить в чужом городе и из точки А в точку Б попасть без приключений.

Когда ньюансами делятся, даже не представляете насколько это упрощает все возникающие вопросы.

[ASUTP_PLC]

Подскажите пожалуйста. Настроил коммуникацию через 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 контроллер работает в плотном режиме и отрабатывает программу целого производства. Поэкспериментировать с разными режимами передачи на нем не имею возможности.
Любая ошибка чревата срывом процесса и остановом производства.

[ASUTP_PLC]

И кстати, почему-то S7-коннекция у меня не пошла/хотя вроде как S7-коммуникации не ограничиваются Profibus DP сетью или сетью MPI/, TCP коннекция вполне благополучно настроилась.

[Василий Иванович]

AG-блоки прекрасно работают и на 400 серии тоже. Причем даже если их взять из библиотеки для S7-300 (несмотря на то, что есть своя версия для S7-400). Вы можете также использовать AG_LSEND/AG_LRECV, они позволяют слать большие объёмы данных, а также AG_SSEND, AG_SRECV - если надо быстрее. Есть ещё AG_CNTRL - с помощью его можно сделать дисконнект и сброс соединения.

Число конфигурируемых соединений ограничено и зависит от железяки, в которую входит сетевой кабель. Для трехсотого СР это 8. Если хотите слать больше, можете сложить несколько малых DB в один большой и отправлять его через одно соединение, раздёргивая данные после приёма снова по нескольким DB.

Насчет S7-соединения помочь не могу - не пользуюсь.

[ASUTP_PLC]

Большое спасибо. Все вроде бы получается.
У меня такой вопрос. На одну передачу я могу определить только один 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???

[Василий Иванович]

AG_SEND/AG_RECV для S7-300 могут слать и принимать пакеты размером до 8 килобайт! Это их версия для S7-400 шлёт 240 байт, но у четырехсоток для больших объёмов есть AG_LSEND/AG_LRECV. Исходя из этого через один CP для S7-300 можно единовременно продавить до 64 килобайт. Если нужно больше - втыкайте ещё один СP или мультиплексируйте как-нибудь.
Максимальное число TCP-соединений нужно читать в описании конкретного СР. Для CP443-1 это будет как правило 64.

[Василий Иванович]

Кстати, чистый TCP для циклической пересылки областей данных использовать очень не советую, поскольку в протоколе нет пакетирования - начало и конец данных могут потеряться. Либо UDP, либо Iso-on-TCP.

[ASUTP_PLC]

Имел уже секас с другими контроллерами, до Сименса недавно дошел. И как раз у меня на ТСР передаче на нижнем уровне столько проблем было. И кстати получилось то все как раз на UDP.
Я поэтому по Сименсу только вопросы и задаю, но то что мне лучше UDP где-то костным мозгом догадываюсь.
Вопрос теперь по соединению. При прописывании соединения
один контроллер инициирует передачу по определенному ID. Другой принимает.
Значит ли это что мне необходимо два разных ID, если у меня в двух разных
направлениях два разных DB пересылаются? Я создал одно ID и на двух контроллерах сделал отправку одного и прием другого блока.
Если активный узел на шине один, наверное это в корне не правильно, и соответственно я не должен ничего принять на одном блоке/? /по факту я что-то видел в результате пересылки, но возможно циклически оно работать не обязано/
Просто на TCP есть указание, кто активирует запрос посылки. А на UDP
нет. И не ясно, должно оно так работать. Или под один ID коннекта будте добры, принимайте только один DB блок?
У меня от CPU400 станции должны идти DB блок под 500 байт на CPU300.
Если я задействую AG_LSEND на 400, стандартный блок под S7-300 примет ли эти 500 байт? /тривиальный может вопрос, завтра буду пробовать в практике конечно/
Расстояние между двумя контроллерами около 4 км, так что совсем все быстро везде все посмотреть как-то не выходит.

[Василий Иванович]

ID не играет никакой роли для контроллера на той стороне. Он служит лишь для нумерации соединений внутри одного CP. Для контроллера-партнёра играет роль лишь номер порта (ну и IP-адрес, конечно). И всё. Хотите два соединения между контроллерами - будьте добры зарезервировать две пары портов.
Эта галочка в TCP-соединении означает не того, кто данные шлёт, а того, кто является TCP-клиентом, т.е. инициирует коннект. Когда коннект уже установлен (как правило, как только взлетел из стопа второй СР из пары), данные через соединение могут слаться в оба конца. Для UDP эта галочка отсутствует, поскольку в этом протоколе коннект отсутствует в принципе (что увы не улучшает надёжность передачи данных). И для UDP тоже можно слать через одно и тоже соединение данные в оба конца.
На Ваш тривиальный вопрос будет тривиальный ответ - да. Стопудово.

[ASUTP_PLC]

Пытался я через одно соединение и дата блок с 300 контроллера стянуть, и через него же в датаблок данные записать, однозначно для этой задачи по разным портам данные должны идти.
Добавил новые соединения. И с 400 контроллера LSEND запустил. Все данные получил.
Одно но, пару км расстояния иногда дают свою лепту. Данные бывают частично
искаженные приходят. Как-то можно избежать этого.
В блок передаются данные настроек, и часть значений бывает идет нулями.
Что не есть гуд. Но совсем без помех думаю никак не выйдет.

[Василий Иванович]

Я нигде там вверху не писал, что соединение дуплексное. Оно полудуплексное. Т.е. в один момент времени либо шлёте, либо принимаете, но не то и другое вместе.
С Вашими проблемами использовать UDP противопоказано. Ставьте ISO-on-TCP - он самый надёжный.

[ASUTP_PLC]

Передачу данных отстроил получше. Вроде как все поменялось в лучшую сторону. Данные меняются несколько раз в секунду.

Я думаю пока для обкатки вполне достаточно так оставить. Мне интересно, если таких соединений будет не один десяток.
Динамичность системы не поменяется? Насчет дуплекса - спасибо. Теперь я уверен, что программа как надо работает, и в ней все в порядке.

Еще бы знать не помешало насколько хорошо все будет работать с очень большим количеством соединений. Иногда ведь все работает до некоего
предела, после которого могут возникать какие-то непредсказуемости.
Даже на обычном Wi-Fi споте если ему одному предстоит под полсотни устройств обслужить, периодически бывает по сеансу связи обрывы одного конечного соединения.
Конечно на хорошем железе этот порог изначально большой.

[Василий Иванович]

Для СР не просто так прописано максимальное число соединений, а для обеспечения определённого качества связи. Т.е. всё будет работать и с десятками соединений так же. У нас, во всяком случае, работает.

[ASUTP_PLC]

Большое спасибо, проект запустил. Со всем чем требовалось разобрался.