Дмитрий Юрьевич
Junior Member / Новичок
Участник № / Member № 3462
отправлено / posted
Добрый день
Имеется 4 частотных преобразователя на 485 шине, подключенных к контроллеру WinCon, которыми нужно управлять. К большому сожалению, максимальный битрейт, который можно выставить для данных частотников, равен 9600 бит/сек. Протокол взаимодействия с ними - ModbusRTU. Одна порция запрос-ответ занимает около 200 бит. Для каждого частотника имеется 4 ключевых параметра, которые необходимо обрабатывать, в результате для каждого из них COM-порт контроллера должен передать-принять 800-900 байт.
Вопрос 1. Как лучше разделить потоки данных для разных частотников, чтобы они не пересекались друг с другом. То есть добиться того, что в течение первых 200 миллисекунд контроллер общался только с ЧП1, с 250 по 450 - с ЧП2 и так далее. Время цикла при этом, к сожалению, не более 50 миллисекунд, поэтому каналами F1-F4 пользоваться неудобно.
Вопрос 2. Как можно добиться того, что команда ЧП будет отправляться тогда и только тогда, когда я произведу необходимые действия? Автоматически настроенные потоки данных реагируют на изменение значения в каналах, а я хочу отправлять некоторые посылки насильно, вне зависимости от факта изменения значения. Получится ли воспользоваться CALL.ChGroupReq, настроив его аргументы на соответствующие выходные каналы Modbus и записью 1 в EXEC вынуждать MicroRTM посылать на COM порт соответствующее сообщение?
Сообщения / Posts 4 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
1. При выбранной Вами производительности канала и структуре подключения полный цикл обновления информации от всех 4 ЧП будет безусловно не меньше 4-5 секунд. Ваше предложение ситуацию никак не улучшит. И цикл обработки базы каналов, и цикл обработки каждого из каналов в данном случае решающего значения не имеют. Ограничением является соотношение производительности канала и объема трафика. Управлением запросами к каждому контроллеру можно лишь распределить разные запросы в указанном цикле 4-5 секунд. Эффект от такого управления не прозрачен. Регламентировать запросы, не увеличивая существенно цикл обработки базы в целом, можно программным путем черех атрибуты СОСТОЯНИЕ каналов опроса ЧП. Однако лучше подумать о разнесении трафика с разными ЧП на разные COM-порты контроллера.
2. Принудительную отработку каналов OUT/Modbus можно реализовать через их атрибуты EXEC (39), даже если значения этих каналов не изменялись. Использование в качестве альтернативы каналов CALL.ChGroupReq оправдано, если адреса соответствующих переменных в ЧП строго последовательны.
Сообщения / Posts 17317 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Дмитрий Юрьевич
Junior Member / Новичок
Участник № / Member № 3462
отправлено / posted
Прошу дать комментарий на следующую строку из документации (к сожалению, на английском): "Processing OUTPUT channels, which must be processed in the base thread, and their output value analysis. Setting Q flags for channels, which output values have changed. Subsequent steps are accomplished according to the following algorithm:
– If a channel sends data asynchronously (network, RS) execution does not take place and Q flag is not reset. "
Как, когда и в какой последовательности реализуются асинхронные посылки?
У меня есть 2 параметра. UnlockCommands для разблокировки управления и DriveControl для отправки собственно команд. Естественно, сначала необходимо разблокировать управление, и лишь после этого посылать команды. Обратная связь, отображающая, разблокировано управление или нет, отсутствует. Если я на каком-то этапе в своём алгоритме одновременно присвою UnlockCommands := 1, а DriveControl := xxx, в какой последовательности и в какие моменты времени они отправятся в COM-порт? Будет ли эта последовательность соответствовать нумерации каналов?
Сообщения / Posts 4 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Поток RS-обмена принципиально является асинхронным. Флажки Q у каналов OUT возводятся синхронно, в соответствии с их ID и циклом обработки каждого канала. Асинхронный RS-поток после исполнения очередной транзакции, иницированной каналом с некоторым ID, проверяет наличие флажка Q у ближайшего большего ID канала, потенциально входящего в этот поток. Поэтому никак нельзя гарантировать, что одновременно поданные 2 команды на каналы с последовательными ID будут переданы именно в этой последовательности. Необходимо сначала удедиться, что команда UnlockCommands передана и реализована на нижнем уровне, и только потом передавать команду DriveControl. Если есть уверенность, что корректный протокольный ответ от нижнего уровня на команду UnlockCommands уже гарантирует разблокировку управления за время, которое может пройти до передачи DriveControl, то достаточно выполнить алгоритм: изменили значение канала UnlockCommands, убедились, что флажок Q у этого канала сначала взвелся, а потом через некоторое время сбросился, изменяем значение канала DriveControl. В более сложном случае может оказаться необходимым другим каналом INPUT считать с нижнего уровня подтверждение разблокировки управления и только после этого посылать DriveControl.
Сообщения / Posts 17317 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Дмитрий Юрьевич
Junior Member / Новичок
Участник № / Member № 3462
отправлено / posted
Спасибо. И ещё 2 вопроса, не напрямую связанных с предыдущими.
1. Как прочитать значение Exception при чтении каких-либо регистров? 2. Можно ли сделать контроллер WinCon не мастером Modbus, а slave? Что для этого нужно сделать? В случае Modbus RTU и в случае Modbus TCP/IP?
Сообщения / Posts 4 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
1. При обмене по Modbus TCP последние коды ошибок, возвращаемых устройством, могут быть определены с помощью канала @e_TCP_ModBus. При обмене по Modbus RTU в старшем байте переменной @e_ModBus формально присутствует код ошибки, возвращаемый устройством. Однако выделить его строго однозначно затруднительно, поскольку в этот байт по ИЛИ записывается и номер COM-порта. Мы приме меры в следующем релизе для осуществления более строгой диагностики.
2. Функция Modbus TCP Slave МикроМРВ для WinCON CE опциональна. Если Вам эта функция действительно необходима, надо решать вопрос о поставке соответствующего продукта с нашим отделом продаж.
Сообщения / Posts 17317 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
