Форум TRACE MODE: техническая поддержка
Тема закрыта / Topic Closed  Тема закрыта / Topic Closed
Послать новую тему / Post New Topic  
Тема закрыта / Topic Closed  Тема закрыта / Topic Closed
мой профиль / my profile авторизация / login | регистрация / register | поиск / search | часто задаваемые вопросы / faq | начало / forum home

  Следующая старая тема / next oldest topic   Следующая новая тема / next newest topic
» Форум TRACE MODE: техническая поддержка » ТЕХНИЧЕСКАЯ ПОДДЕРЖКА / TECHNICAL SUPPORT TRACE MODE 6 » TRACE MODE 6 бесплатная Базовая версия / TRACE MODE 6 free Base version » Обмен данными по Modbus/TCP с контроллером upac-7186

   
Автор / Author Тема / Topic: Обмен данными по Modbus/TCP с контроллером upac-7186
merny
Active Forum Member / Активный участник форума
Участник № / Member № 2290


Icon 1 отправлено / posted      Профиль для / Profile for merny           Редактировать/удалить сообщение / Edit/Delete Post 
задача в общем такая: есть 2 типа процессов - процесс жесткого реального времени и процессы мягкого реального времени. первый реализуется специальным процессором, остальные с помощью модулей удаленного ввода/вывода icpdas. при этом в режиме мягкого реального времени подкачиваются данные в специальный процессор и в таком же режиме считываются его данные.
аппаратная и программная реализация: рабочее место - персональный компьютер (скорее всего ноутбук) с trace mode. подключение через rj-45. контроллер upac-7186 с шиной расширения и встроенной библиотекой modbus поскольку данные контроллеры trace mode более не поддерживает. соответственно это задает и протокол обмена - Modbus/TCP. остальные устройства подключаются в сеть rs-485, куда должны ретранслироваться запросы через соответствующий порт контроллера. специальный микропроцессор устанавливается внутрь контроллера в виде платы расширения.
контроллер уже у меня на руках, остальное в процессе приобретения. часть модулей ввода/вывода уже заказаны и будут через пару недель. поскольку окончательная версия проекта еще не сформулирована (на самом деле проектов минимум три, они похожие, но различаются в деталях) часть модулей будет дозаказана.
на данный момент тестируется обмен по Modbus/TCP с контроллером. написана на С программка, задающая для AI и AO пилообразный сигнал, меандр для DI с частотой около 1 Гц, проверка регистра DO с выводом значения на реле (контроль на слух - по щелчку). параллельно работает утилита icpdas отображающая значения регистров контроллера. тестовый проект на trace mode преобразован из справочного проекта "быстрый старт": добавлены аргументы экрана, к которым привязаны источники/приемники Modbus (образовались новые каналы). добавлены линии на тренд, отображающие значения данных аргументов. добавлен выключатель, связанный с регистром DO в контроллере (переключает реле). канал "управление" привязан к источнику/приемнику W_Word(6). при вводе значения утилита icpdas показывает изменение соответствующего регистра в контроллере. все работает как и предполагалось
что не получилось (точнее не совсем получилось): хотелось вывести синусоидальный сигнал попадающий из генератора синусоиды в канал "параметр" в контроллер через другой источник/приемник W_Word(6). однако в этом случае при привязке к Modbus происходила отвязка "параметра" от синусоиды. отправить синусоиду в контроллер удалось лишь при помощи канала "сумма". пришлось подредактировать программу на языке Техно ST (просто сумму приравнял к параметру).
в итоге для передачи генератора синусоиды в контроллер потребовалось аж 3 канала:
1) канал "параметр", принимающий генератор синусоиды
2) канал "сумма", передающий синусоиду в контроллер
3) программа, где значение "параметра" передавалось в "сумму"
на мой взгляд это слишком громоздкое и корявое решение. я практически, а не теоретически только начинаю работать с trace mode, так что пока не могу сказать что интуитивно чувствую систему. поэтому прошу особо не пинать за ошибки и указать возможно ли перекидывать данные из одних источников/приемников в другие без нагромождения большого количества каналов.

еще вопрос по обмену по протоколу Modbus:
насколько я понял 4-байтовые операции это частный случай по записи/чтению нескольких регистров (2 регистра). дополнение же к подтипу просто определяет трактовку данных монитором реального времени. возможны ли прием или передача большего числа данных? мне данные в процесс жесткого реального времени желательно передавать в виде текстовой строки и удобнее было бы перегонять строку целиком, а не по кусочкам

Сообщения / Posts 70 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
АдАстра. Техподдержка
Administrator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for АдАстра. Техподдержка           Редактировать/удалить сообщение / Edit/Delete Post 
1. СИНУСОИДА - вещественное число. Функция W_Word(6) передает только целое число. Т.к. речь идет об эксперименте, разумно заменить СИНУСОИДУ на ПИЛУ.
Меньше чем 2 каналами решить задачу "послать ПИЛУ через W_Word(6)" нельзя.
Канал CALL.Program. ARG_000 типа INPUT/UINT привязать непосредственно к "Источнику" "Генератор/Пила".
ARG_001 типа OUT/UINT привязать к атрибуту ВХОДНОЕ_ЗНАЧЕНИЕ канала, связанного с "Приемником" W_Word(6).

2. Групповые Modbus-запросы на чтение и запись реализуются с помощью каналов CALL.ChGroupReq, привязанных к соответствующим Modbus-компонентам слоя "Источники/Приемники" (см.описание канала CALL.ChGroupReq).

Сообщения / Posts 17109 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
merny
Active Forum Member / Активный участник форума
Участник № / Member № 2290


Icon 1 отправлено / posted      Профиль для / Profile for merny           Редактировать/удалить сообщение / Edit/Delete Post 
quote:
Отправитель / Originally posted by AdAstra Technical Support:

Канал CALL.Program. ARG_000 типа INPUT/UINT привязать непосредственно к "Источнику" "Генератор/Пила".
ARG_001 типа OUT/UINT привязать к атрибуту ВХОДНОЕ_ЗНАЧЕНИЕ канала, связанного с "Приемником" W_Word(6).

правильно ли я понял:
- ARG_000 и ARG_001 это аргументы программы
- ARG_000 непосредственно привязан к источнику
- внутри программы операция присваивания ARG_001=ARG_000
- есть канал, связанный с W_Word(6), и к нему привязан ARG_001

Сообщения / Posts 70 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
merny
Active Forum Member / Активный участник форума
Участник № / Member № 2290


Icon 1 отправлено / posted      Профиль для / Profile for merny           Редактировать/удалить сообщение / Edit/Delete Post 
quote:
Отправитель / Originally posted by AdAstra Technical Support:

2. Групповые Modbus-запросы на чтение и запись реализуются с помощью каналов CALL.ChGroupReq, привязанных к соответствующим Modbus-компонентам слоя "Источники/Приемники" (см.описание канала CALL.ChGroupReq).

правилен ли следующий порядок действий для передачи текстовой строки в контроллер:
- в узле создается группа каналы
- в группе каналы создается компонент call
- в редакторе компонента call устанавливается тип вызова ChGroupReq
- в свойствах компонента call во вкладке аргументы создается аргумент типа string
- создается источник/приемник, например, W_Word(6)
- осуществляется привязка аргумента и приемника
- в результате каждый символ строки будет записываться в свой 16 битовый регистр

сколько слов будет записано в регистры AO: равное максимально возможному числу элементов строки или равное реальной длине строки?

Сообщения / Posts 70 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
АдАстра. Техподдержка
Administrator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for АдАстра. Техподдержка           Редактировать/удалить сообщение / Edit/Delete Post 
1. По "передаче "Пилы" в контроллер: поняли правильно. Повторяем: аргумент программы ARG_001 типа OUT/UINT привязать к атрибуту ВХОДНОЕ_ЗНАЧЕНИЕ канала, связанного с "Приемником" W_Word(6).

2. Передача строковых переменных по протоколу Modbus не предусмотрена. Передаются целые числа. Поэтому аргументы канала ChGroupReq должны иметь тип данных UINT.
Вы можете в эти аргументы записывать целочисленные коды текстовых символов: 1 аргумент - 2 байтовых символа.
Количество переданных символов будет равно количеству аргументов*2.
Количество аргументов ограничивается стандартом Modbus - 125 регистров (250 байтов).

Сообщения / Posts 17109 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
merny
Active Forum Member / Активный участник форума
Участник № / Member № 2290


Icon 1 отправлено / posted      Профиль для / Profile for merny           Редактировать/удалить сообщение / Edit/Delete Post 
quote:
Отправитель / Originally posted by AdAstra Technical Support:

2. Передача строковых переменных по протоколу Modbus не предусмотрена. Передаются целые числа. Поэтому аргументы канала ChGroupReq должны иметь тип данных UINT.

я допускал, что переменная string может рассматриваться в системе как массив байтов или слов (в зависимости от кодировки). но раз нет так нет. способы преобразования данных из одного формата в другой уже не относятся к теме modbus. здесь свои проблемы и вопросы, но я под них открою другую тему попозже
Сообщения / Posts 70 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
merny
Active Forum Member / Активный участник форума
Участник № / Member № 2290


Icon 1 отправлено / posted      Профиль для / Profile for merny           Редактировать/удалить сообщение / Edit/Delete Post 
спасибо за консультации
Сообщения / Posts 70 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
   

Послать новую тему / Post New Topic  
Тема закрыта / Topic Closed  Тема закрыта / Topic Closed
Открыть тему / Open Topic   Feature Topic   Переместить топик / Move Topic   Удалить топик / Delete Topic Следующая старая тема / next oldest topic   Следующая новая тема / next newest topic
 - Printer-friendly view of this topic
Перейти к / Hop To


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2