Блок Device (Link)

[tvf]

Из справки на блок Device (Link): Блок предназначен для сбора статистики о работе портов ввода/вывода контроллера. Попытался с помощью этого блока контролировать обмен через Ethernet на контоллере Pixel (2G). Ни чего не вышло. Перечитал справку еще раз. Насколько я понял, обмен через Ethernet контролируется только для контроллеров 2Gi. Есть ли штатные средства SMLogix для контроля обмена через Ethernet для контроллеров типа Pixel (2G)? Хотя бы на уровне успешно принятых запросов?

[Arsie]

Сообщение от tvf

Из справки на блок Device (Link): Блок предназначен для сбора статистики о работе портов ввода/вывода контроллера. Попытался с помощью этого блока контролировать обмен через Ethernet на контоллере Pixel (2G). Ни чего не вышло. Перечитал справку еще раз. Насколько я понял, обмен через Ethernet контролируется только для контроллеров 2Gi. Есть ли штатные средства SMLogix для контроля обмена через Ethernet для контроллеров типа Pixel (2G)? Хотя бы на уровне успешно принятых запросов?

Номер порта указываете верный? Вам нужна статистика как для слейва?

[tvf]

Номер порта указываете верный? Вам нужна статистика как для слейва?

Все указываю как написано в справке. Статистика нужна вне зависимости от того, кем является контроллер (мастер или слейв). Для мастера желательно еще и разделение по адресу слейва. Но это так, пожелание.

Видимо "неработа" блока Device (Link) в контроллерах Pixel (2G) связана с тем, где разбираются пакеты ModBus. Для RS485 это процессор контроллера вне зависимости от марки (Pixel, 2G, 2Gi). Для Ethernet это процессор контроллера (2Gi) или процессор модуля связи (Pixel, 2G). А модуль связи передает только голую информацию, без статистики. Хотя это тоже домыслы. Так что повторяю свой вопрос:

Есть ли штатные средства SMLogix для контроля обмена через Ethernet для контроллеров типа Pixel (2G)? Хотя бы на уровне успешно принятых запросов?

Если нет, то будет ли это сделано? Если да, то каким образом?

[Arsie]

Сообщение от tvf

Для мастера желательно еще и разделение по адресу слейва. Но это так, пожелание.

Чем вас не устраивает Slave(link)?

Сообщение от tvf

Так что повторяю свой вопрос:Если нет, то будет ли это сделано? Если да, то каким образом?

1) Slave(link)

2) Переменная типа "Echo"

3) "Одноразовые запросы"

4) Контроль постоянно изменяющейся переменной

[tvf]

Чем вас не устраивает Slave(link)?

Согласно справке на блок Slave(link) имеем:

Querys - для мастера: количество полученных ответов от слейвов
TrmPacket - для мастера: количество посланных слейвам запросов
NoRespons - для мастера: количество неответов от слейвов

То есть для мастера блок Slave(link) определяет "средную температуру по больнице". А хочется определять температуру для каждого пациента (слейва). Если вы можете определить, какой из слейвов дает наибольший процент ошибок, то поделитесь этой сакральной информацией.

1) Slave(link)
2) Переменная типа "Echo"
3) "Одноразовые запросы"
4) Контроль постоянно изменяющейся переменной

1)Slave(link) без проблем работает только по RS485. По Ethernet работает только на 2Gi.
2-4)Эти способы требуют соответствующей подготовки мастера. Слейв только отвечает на запросы мастера. А вот к мастеру привязываться не хотелось бы. Да и к интерфейсу обмена тоже.
Уточню вопросы:
1. Когда и как контроллеры Pixel (2G) смогут контролировать обмен и качество обмена по Ethernet находясь а режиме слейва?
2. Когда и как контроллеры Pixel (2G, 2Gi) смогут контролировать обмен и качество обмена с каждым конкретным слейвом, в объеме предусмотренным блоком Slave(link)?

[Arsie]

Сообщение от tvf

Согласно справке на блок Slave(link) имеем:

Быть может всё же Device(link)?

Сообщение от tvf

1)Slave(link) без проблем работает только по RS485. По Ethernet работает только на 2Gi.
2-4)Эти способы требуют соответствующей подготовки мастера. Слейв только отвечает на запросы мастера. А вот к мастеру привязываться не хотелось бы. Да и к интерфейсу обмена тоже.
Уточню вопросы:
1. Когда и как контроллеры Pixel (2G) смогут контролировать обмен и качество обмена по Ethernet находясь а режиме слейва?
2. Когда и как контроллеры Pixel (2G, 2Gi) смогут контролировать обмен и качество обмена с каждым конкретным слейвом, в объеме предусмотренным блоком Slave(link)?

1) Слейвы в modbus вообще не контролируют обмен, это задача мастера

2) Блок Slave(link) в них работал всегда

Если же говорить о блоке Device(link), то это специальный отладочный блок, который и знать не знает, сколько и чего подключено к порту. Его дело - считать пакеты, пришедшие на порт и ушедшие с него.

[tvf]

Быть может всё же Device(link)?

Да действительно Device(link). Не заметил подмены. И все в предыдущем сообщении относилось именно к нему.

1) Слейвы в modbus вообще не контролируют обмен, это задача мастера

Тем не менее ПЧ типа ATV212 при управлении по интерфейсу встают по ошибке при отсуствии обмена. А сеть именно modbus и ПЧ там стоят слейвами. Так что все реализуемо. Было бы желание. И в существующей ситуации, при обмене по RS485 все уже работает, остался Ethernet.

Если же говорить о блоке Device(link), то это специальный отладочный блок, который и знать не знает, сколько и чего подключено к порту. Его дело - считать пакеты, пришедшие на порт и ушедшие с него.

Ну так добавить вход с названием "Адрес". Стоит на входе 0 - считаем все подряд, стоит n - считаем пакеты только с адреса n. Изменение значения - сброс всех счетчиков.

[Arsie]

Сообщение от tvf

Да действительно Device(link). Не заметил подмены. И все в предыдущем сообщении относилось именно к нему.

Никакой подмены нет, это два разных блока, выполняющие две разные задачи.

Сообщение от tvf

Тем не менее ПЧ типа ATV212 при управлении по интерфейсу встают по ошибке при отсуствии обмена. А сеть именно modbus и ПЧ там стоят слейвами. Так что все реализуемо. Было бы желание. И в существующей ситуации, при обмене по RS485 все уже работает, остался Ethernet.

У ATV212 какой порт?

Сообщение от tvf

Ну так добавить вход с названием "Адрес". Стоит на входе 0 - считаем все подряд, стоит n - считаем пакеты только с адреса n. Изменение значения - сброс всех счетчиков.

Если вы будете продолжать невнимательно читать мои ответы, мы с вами так ни до чего и не договоримся.

[tvf]

Никакой подмены нет, это два разных блока, выполняющие две разные задачи.

С этим не спорю. Только Slave(link) работает только на мастере, а Device(link) и на мастере и на слейве. Разницу в названиях просто проглядел.

У ATV212 какой порт?

RS485 ModBus. Если вы на именно на порт намекаете, то в 2Gi Device(link) как то контролирует обмен и по Ethernet. Значит варианты есть.

Если вы будете продолжать невнимательно читать мои ответы, мы с вами так ни до чего и не договоримся.

Ну так добавить вход с названием "Адрес". Стоит на входе 0 - считаем все подряд, стоит n - считаем пакеты только с адреса n. Изменение значения - сброс всех счетчиков.

Сказанное относится именно к блоку Device(link). И является пожеланием, улучшающем информативность этого блока. Насколько это реализуемо, вам лучше знать. К слову говоря, некоторое удивление вызывает следующая фраза из справки:

PNum - номер порта уровня протокола (обязательно должен совпадать с CNum)

Зачем 2 разноименных входа, значения на которых должны обязательно совпадать? 1 обойтись недьзя было?

[Arsie]

Сообщение от tvf

Сказанное относится именно к блоку Device(link). И является пожеланием, улучшающем информативность этого блока. Насколько это реализуемо, вам лучше знать.

Device(link) оценивает работу порта, а не протокола на нём. Это первое.

Device(link) оценивает связь между сетевым модулем и контроллером. Это второе.

Device(link) - это средство контроля работы локальных портов.

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

Некрасиво и неизящно и так можно сделать - я вам привёл список способов. Зачем вы предлагаете удлиннить этот список?

Сообщение от tvf

К слову говоря, некоторое удивление вызывает следующая фраза из справки:
Зачем 2 разноименных входа, значения на которых должны обязательно совпадать? 1 обойтись недьзя было?

Исторически сложилось (с)

[tvf]

Device(link) оценивает работу порта, а не протокола на нём.

Как то вы вольно трактуете работу блока Device (Link). Или выдаете желательное за действительное. Справка по блоку Device (Link) прямо говорит:

CRst - сброс собранной статистики о физическом уровне.
PRst - сброс собранной статистики о работе протокола (CRC, TrmPacket, NoRespons, IFunc, Size).

Или по вашему параметры CRC, TrmPacket, NoRespons, IFunc, Size относятся к работе порта?

Device(link) оценивает связь между сетевым модулем и контроллером.

У меня на Pixel стоит сетевая плата. На каких выходах блока Device (Link) должны меняться показания при наличии обмена по Ethernet?

Device(link) - это средство контроля работы локальных портов.

Тогда давайте определимся, что считать локальным портом. Сетевая плата, установленная в контроллер Pixel, является локальным или удаленным портом?

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

Это не моя, а ваша задача предложить мне красивое и изящное решение. Отсуствие такого решения (для Pixel с сетевой платой) и заставляет решать задачу

Некрасиво и неизящно

[Arsie]

Сообщение от tvf

Это не моя, а ваша задача предложить мне красивое и изящное решение.

Всё, что я вам мог предложить, я уже предложил.

[ujin]

Я ввел переменную unix_time. Меняется каждую секунду. Для мастера - это показатель что слейв online. Для слейва - что мастер online. Соответственно используется и как heartbeat и как источник периодической синхронизации времени. Запаковка распаковка в long действует до 2038 г. и широко описана. Потом 8 байт понадобится.

[tvf]

Сообщение от ujin

Я ввел переменную unix_time...

На данный момент я примерно так и делаю. Одна переменная - связь, вторая - дата/время. Суть дискусси не в том, что контроль обмена нельзя сделать в принципе. А в том, что его нельзя сделать штатными средствами лоджика. По крайней мере в полном объеме, вне зависимости от интерфейса, роли в сети и типа контроллера. Под штатными средствами подразумевается

красивое и изящное решение

не требующее взамной увязки алгоритмов на мастере/слейве и роли контроллера в сети.

[Arsie]

Сообщение от tvf

Под штатными средствами подразумевается не требующее взамной увязки алгоритмов на мастере/слейве и роли контроллера в сети.

Проблема в том, что в протоколах типа "запрос-ответ" принципиально не существует "красивых" решений контроля связи со стороны слейва.

Возьмём упомянутый вами частотник. Вы предложили один костыль заменить на другой костыль. И я объясню, почему.

Объективно, команды на частотник нужно отправлять только при смене режимов работы. Т.е. отправили с утра команду "пуск", а команду "стоп" отправили вечером. Состояние самого частотника считываем раз в час. Этого для работы некоторых объектов достаточно.

Но что сделает частотник? Он через 10 секунд (такое у большинства частотников время предустановленное) разорётся, что связь пропала.

А она не пропала. Просто харатер обмена такой.

Поэтому только мастер всегда знает, что происходит со связью. Потому что он инициатор обмена, только он знает все правила, потому что именно он их устанавливает, а все слейвы пляшут под его дудку.

Т.е. абсолютно всегда нужно совершать телодвижения на стороне слейва, чтобы верно детектировать связь. Либо делать телодвижения на стороне мастера, чтобы выполнить требование программы на стороне слейва. Вашему частотнику требуется организовывать циклический опрос, нашему Пикселю с сетевым модулем - поставить переменную.

Другими словами: два костыля - пара (c)

Один костыль ничем не лучше другого, просто с первым костылём вы уже привыкли работать и принимаете его как должное и естественное. И не замечаете, как происходит "увязывание алгоритмов на мастере/слейве".

[ujin]

Сообщение от tvf

А в том, что его нельзя сделать штатными средствами лоджика. По крайней мере в полном объеме, вне зависимости от интерфейса, роли в сети и типа контроллера.

У Вас есть пример, где это сделано на Модбасе? ПЛК где я встречал сигнал online на слейве использовал периодическое к нему обращение.
В модбасе нет проводов DTR, DSR. Поэтому любой способ детектирования связи возможен только через периодическое обращение к этому слейву и ответу от него. Блок Device(link) на пикселе разве не увеличивает значение Querys при запросе от мастера по ethernet?

[tvf]

Возьмём упомянутый вами частотник. Вы предложили один костыль заменить на другой костыль. И я объясню, почему.
Объективно, команды на частотник нужно отправлять только при смене режимов работы. Т.е. отправили с утра команду "пуск", а команду "стоп" отправили вечером. Состояние самого частотника считываем раз в час. Этого для работы некоторых объектов достаточно.

Не все так примитивно. Из документации на ПЧ ATV212:

[Не активна]: выполняется последняя команда управления
[Ост. с темпом]: ПЧ тормозится с заданным темпом. Контроль сети сохраняется
[Выбег]: ПЧ прекращает питание двигателя и он останавливается. Контроль сети сохраняется
[Err5 или Err8]: ПЧ блокируется по неисправности связи Err5 или по неисправности сети Err8.

Выбор реакции на потерю связи достаточно широк. И я волен выбирать любую реакцию на потерю связи без вмешательства во внутренее ПО ПЧ. И без использования дополнительного костыля в виде гоняния туда/сюда дополнительной переменной. В ПЧ просто нет такой переменной. Теперь представим, что это не ПЧ, а Пиксель, упраляющий несколькими ПЧ. Если связь идет через RS485, то все можно сделать. А если по Ethernet - нет. Причем моя задача - только Пиксель и его ПЧ. Кто дает Пикселю команду на включение я понятия не имею, да и не интересует меня это. Это проблемы мастера. Моя задача - дать предсказуемую и вариабельную реакцию Пикселя на потерю связи и правила определения факта потери связи. А дальше пусть решает Мастер, ибо

только мастер всегда знает, что происходит со связью

и что при этом делать.
Если Пиксель выступает мастером, то все чуть лучше. Slave(link) определит превышение лимита ошибок, но причину вряд ли. В этом деле помог бы Device(link), но он показывает "средную температуру по больнице" да и то при связи через RS485, при связи через Ethernet он и этого не покажет.
Вот и получается, что в Лоджике вроде есть блоки для анализа качества связи, но толку от них немного. Вот и приходится пользоваться "некрасивыми и неизящными" решениями.

Если не планируется изменения в работе блока Device(link), то дальнейшая переписка не имеет смысла. Я свою потребность до вас донес, как мог аргументировал. Ваша реакция тоже ясна - все и так хорошо. Какой смысл переливать из пустого в поржнее?

[Arsie]

Сообщение от tvf

Не все так примитивно. Из документации на ПЧ ATV212:Выбор реакции на потерю связи достаточно широк. И я волен

Отключение контроля это именно его отключение. Вы вольны либо копать, либо не копать. Без вариантов.

Сообщение от tvf

Теперь представим

Не хочу я представлять. Нафантазировать в отрыве от реальности можно что угодно.

Поэтому сначала поставьте задачу, далее рассмотрим с вами варианты её решения. Если будет актуально, то подумаем, как лучше всего сделать диагностику: один блок модифицировать или десяток новых блоков создать.

На всякий случай я уточню, что такое PLC. PLC не частотник. PLC сам управляет объектом, а частотник создан быть управляемым кем-то, это его предназначение в жизни. Что такое автономная работа ПЧ я знаю, не нужно тратить своё и моё время на очевидные вещи.

Другими словами, вентустановка или котельная или ИТП от отключения диспетчеризации не умрёт. Она в нормальном режиме будет работать дальше. И информация о наличии диспетчеризации, откровенно говоря, не очень-то и нужна.

Сообщение от tvf

Если не планируется изменения в работе блока Device(link), то дальнейшая переписка не имеет смысла. Я свою потребность до вас донес, как мог аргументировал. Ваша реакция тоже ясна - все и так хорошо. Какой смысл переливать из пустого в поржнее?

Вы можете и не продолжать диалог, но тогда ничего и не изменится. Под лежачий камень вода не течёт.

[Arsie]

Сообщение от tvf

Если Пиксель выступает мастером, то все чуть лучше. Slave(link) определит превышение лимита ошибок, но причину вряд ли. В этом деле помог бы Device(link), но он показывает "средную температуру по больнице" да и то при связи через RS485, при связи через Ethernet он и этого не покажет.
Вот и получается, что в Лоджике вроде есть блоки для анализа качества связи, но толку от них немного.

Кстати, зачем вам знать причину потери связи во время работы объекта? Хотя бы один объективный аргумент.

Повторю второй раз: ПНР - это НПР. ПНР не являются типичной рабочей ситуацией на объекте.

[Nick]

Сообщение от tvf

Если Пиксель выступает мастером, то все чуть лучше. Slave(link) определит превышение лимита ошибок, но причину вряд ли. В этом деле помог бы Device(link), но он показывает "средную температуру по больнице" да и то при связи через RS485, при связи через Ethernet он и этого не покажет.

блок Дивайс-линк должен работать и по 485 и по Ethernet в любом контроллере.
опишите подробнее с показанным примером, как у вас законфигурен этот блок, с фоткой куска проекта или примером проекта. Может чтото не так. посмотрим.

[ujin]

Сообщение от Arsie

Кстати, зачем вам знать причину потери связи во время работы объекта? Хотя бы один объективный аргумент.

Во первых извиняюсь не разобрался, что с ethernet работает только Device(link) на 2Gi. Хотя вроде при отладке пикселя видел, что связь определяется (проверю).
Необходимость контроля возникнет если использовать пиксель как модуль расширения для другого контроллера. Связь с которым организована по ethernet.
Были у нас такие объекты где мастер пром компьютер слейвы блоки расширения. Связь по дублированной ethernet.
Просто как вариант применения.

[Arsie]

Сообщение от ujin

Необходимость контроля возникнет

Что контроль иногда нужен - с этим я никогда не спорил

Сообщение от ujin

если использовать пиксель как модуль расширения для другого контроллера. Связь с которым организована по ethernet.
Были у нас такие объекты где мастер пром компьютер слейвы блоки расширения. Связь по дублированной ethernet.
Просто как вариант применения.

Чуть поподробнее, будьте добры. У вас был какой-то неизвестный контроллер с неизвестной вам программой и вы подсунули ему Pixel, сымитировав сгоревший оригинальный модуль расширения?

[Arsie]

Сообщение от ujin

Во первых извиняюсь не разобрался, что с ethernet работает только Device(link) на 2Gi. Хотя вроде при отладке пикселя видел, что связь определяется (проверю).

В Пикселе работает, порт №5

[ujin]

Сообщение от Arsie

Чуть поподробнее, будьте добры. У вас был какой-то неизвестный контроллер с неизвестной вам программой и вы подсунули ему Pixel, сымитировав сгоревший оригинальный модуль расширения?

Мысль у Вас летит слишком быстро вперед. Это сложно. Хотя если есть описание и образец для экспериментов, то можно.
У нас был ПТК Торнадо. Пром компьютер ADVANTECH. Модули расширения торнадо с дублированным езернет. Два кольца езернет. Два свича moxa. Программа тоже торнадо. При отключении Advantech модули расширения определяют, что нет связи и переходят в безопасный режим. Поймал себя на мысли что все можно сделать точно так же и на пикселях только с одним езернетом. Где-то ранее я вам этот вариант расписывал в виде верхняя сеть RS-458 нижняя сеть RS-458 сеть диспетчеризации езернет. У них (торнадо) все дублированный езернет. У Вас Езернет на борту есть блоки диагностики есть, хотя мне юникс время больше нравится. Сразу и heartbeat и сразу синхронизация времени. Этот вариант я Вам ранее так же расписывал. И не надо мне говорить что это другая аппаратура. Народ делает в безнес центрах связь на оптоволокне между ПЛК на аналогичной вашей аппаратуре.
И в Вашей аппаратуре я препятствий для этого не вижу даже в сегодняшнем виде.

[Arsie]

Сообщение от ujin

Мысль у Вас летит слишком быстро вперед.

Модули расширения торнадо с дублированным езернет. Два кольца езернет. Два свича moxa. Программа тоже торнадо. При отключении Advantech модули расширения определяют, что нет связи и переходят в безопасный режим.

Я всего лишь пытаюсь донести, что подходить к отдельному ПЛК мерками модуля расширения нельзя.

Абсолютно все приведённые в этой теме примеры основаны на том, что Пиксель является именно модулем расширения, а не самостоятельным устройством. Модули расширения - это MR и MC, они нормально падают в безопасное состояние по правилам, принятым в их протоколе обмена.

Если использовать Пиксель в роли модуля расширения, то придётся программно реализовывать безопасное состояние и задавать критерии входа в него и выхода из него. Использование блока Device(link) для этого - опасное заблуждение. Блок покажет наличие обмена даже в том случае, когда всего один единственный запрос из десяти будет удачен. Безопасный режим отключится, а 9 значимых запросов пропадут и работа автоматики будет нарушена. Для полноценной работы нужно считать хотя бы контрольную сумму всех данных, а это означает введение дополнительных переменных. Ещё одна в роли "сердцебиения" никак не усложнит программирование системы.

[tvf]

блок Дивайс-линк должен работать и по 485 и по Ethernet в любом контроллере.

Согласно справке по блоку Device (Link)

CNum - номер порта физического уровня:
3 - Ethernet в SMH2Gi

PNum - номер порта уровня протокола:
3 - Ethernet в SMH2Gi

Так что или ошибка в справке на блок, или у вас ошибочное представление о работе блока. Возможно дело в том, что

"неработа" блока Device (Link) в контроллерах Pixel (2G) связана с тем, где разбираются пакеты ModBus. Для RS485 это процессор контроллера вне зависимости от марки (Pixel, 2G, 2Gi). Для Ethernet это процессор контроллера (2Gi) или процессор модуля связи (Pixel, 2G). А модуль связи передает только голую информацию, без статистики.

Надо ли приводить пример?

Если использовать Пиксель в роли модуля расширения, то придётся программно реализовывать безопасное состояние и задавать критерии входа в него и выхода из него. Использование блока Device(link) для этого - опасное заблуждение. Блок покажет наличие обмена даже в том случае, когда всего один единственный запрос из десяти будет удачен. Безопасный режим отключится, а 9 значимых запросов пропадут и работа автоматики будет нарушена. Для полноценной работы нужно считать хотя бы контрольную сумму всех данных, а это означает введение дополнительных переменных. Ещё одна в роли "сердцебиения" никак не усложнит программирование системы.

То есть принимая запрос с переменной "сердцебиения" и не принимая остальных 9 значимых запросов буде все ОК? Отличия между переменной "сердцебиения" и блоком Device (Link) в количестве информации о состоянии связи. Переменная "сердцебиения" выдает 1 параметр, блок Device (Link) выдает 10 параметров. А из 10 параметров можно получить куда больше информации. Как ее использовать, это уже дело каждого конкретного случая. Главное иметь такую возможность.

[Arsie]

Сообщение от tvf

То есть

Попробуйте прочесть, что я написал, ещё раз.

[Nick]

Сообщение от tvf

Согласно справке по блоку Device (Link)Так что или ошибка в справке на блок, или у вас ошибочное представление о работе блока.

у меня нет никакого представления о блоке...
я просто взял и проверил, ибо, когда делали этот блок, у меня была уверенность что он должен обрабатывать и Eзернет и Лонгворкс. Иначе... нафик он такой интересный нужен, с конфигурированеием портов и протоколов.

а справка... справка не богом создается ее тоже люди пишуть, так что извините.

[tvf]

В любом случае вопрос о качестве связи делится на 3 вопроса (как минимум):

1. Приходят ли данные?
2. Все ли данные приходят хорошими?
3. Все ли данные приходят из отправленных?

Ответ об однозначно хорошей связи может быть только при положительных ответах на все три вопроса.

Вы предлагаете 3 вопрос решить с помощью дополнительной переменной с контрольной суммой. Положим мы решили этот вопрос, хотя здесь не все так просто и однозначно.

Но как быть с 1 и 2? Если данные не приходят, или приходят битыми, то ответ на 3 вопрос теряет смысл. Положительные ответы на 1 и 2 вопрос являются необходимыми, но недостаточными для ответа о качестве связи. Именно ответы на вопросы 1 и 2 и должен давать блок Device (Link) вне зависимости от интерфейса.

[tvf]

Сообщение от Nick

Иначе... нафик он такой интересный нужен, с конфигурированеием портов и протоколов.

Именно этот вопрос и у меня возник. Но прочитав справку, дальше эксперементировать не стал. Попробую еще раз.