Поиск аналогов ICP DAS I-7188EXD

Сообщение **Injir** » 13 мар 2020, 11:19

Доброго времени суток!
Кто имел опыт работы с данным продуктом, подскажите.
Используем данную штуку давно, используем как сборщик, написана добротная программа для отправки и получения данных по последовательным портам без привязки к протоколам, с отправкой на сервер посредством Ethernet-порта. Однако, поддерживать/дорабатывать/допиливать уже не представляется возможным.
Сталкивался кто-нибудь с устройствами с подобным функционалом, чтобы не было необходимости писать собственное ПО на сях и прочем?

Сообщение **VADR** » 13 мар 2020, 12:52

Перенёс в более подходящую ветку.

Сообщение **leon78** » 13 мар 2020, 12:54

Injir писал(а): ↑13 мар 2020, 11:19 для отправки и получения данных по последовательным портам без привязки к протоколам

Injir писал(а): ↑13 мар 2020, 11:19 чтобы не было необходимости писать собственное ПО на сях и прочем

Взаимоисключающие требования

https://www.cea-energo.ru/ru/products/tmius-linux или https://www.cea-energo.ru/ru/products/tmius-os7
http://yugsys.ru/produktsiya/tmk-kompas-tm-2-0 или http://telescada.ru/tsp/tsp200.shtml
https://owen.ru/catalog/kontrolleri_dly ... a_resursov

Сообщение **Jackson** » 13 мар 2020, 19:10

Injir писал(а): ↑13 мар 2020, 11:19 для отправки и получения данных по последовательным портам без привязки к протоколам

Данные нельзя передать по последовательным портам без привязки хотя бы к одному протоколу, который физически может работать на последовательных портах (IP, к примеру, не может). Передача данных даже силой мысли (телепатически) тоже ведётся по определённому протоколу.

Как-то Вы странно задачу ставите.

Сообщение **Injir** » 16 мар 2020, 06:01

Jackson писал(а): ↑13 мар 2020, 19:10 Данные нельзя передать по последовательным портам без привязки хотя бы к одному протоколу, который физически может работать на последовательных портах

Ну почему же. Мы так писали ПО, что у нас "выплевывается" посылка в порт (неважная какая) и принимается по сконфигурируемым правилам в каждом конкретном случае (по CRC, или проверкой по двум первым байтам, или просто по длине ответа), но контроллер по сути не понимает, что отправляет посылку по ModBus, DCON или протокол ОВЕН и пр., да ему это и не нужно. И получается более-менее универсальный сборщик.

Сообщение **Jackson** » 16 мар 2020, 10:44

Контроллер что, голосом произносит данные?

Сообщение **Injir** » 19 мар 2020, 06:54

Jackson писал(а): ↑16 мар 2020, 10:44 Контроллер что, голосом произносит данные?

Смотрите. Написано ПО, в котором параметрируется данный контроллер, а именно запросы, которые формирует контроллер в последовательный порт в асинхронном режим (запрос-ответ).
Конфигурирование запроса не привязано к конкретному протоколу передачи, а параметрируется определенными правилами, которые состоят из 4 основных принципов:
1)Тело отправляемой команды (например, 01 03 0000 0001 XXXX или 4030310d), то есть произвольная последовательность, необходимая нам в данном конкретном случае, в зависимости от протокола slave-устройства.
2) Правила отправки пакета, где формируется:
- Номер порта, куда будем отправлять
- Длина этого запроса в байтах
- Период опроса
- Тип подсчета контрольной суммы (если необходимо), и в каком месте посылки она находится
и др.
3) Правила приема пакета ответа, где формируются:
- установка длины ответа
- проверка по контрольной сумме
- проверка заголовка
и др.
4) Правила обработки пакета ответа, т.е отправить на сервер, преобразовать или не делать ничего (если, к примеру, это командная посылка)

Например, хотим опрашивать с МЭ110.1Т значение тока по модбасу.
1) Сначала пишем тело команды: 01 03 001D 0002 AAAA
2) Формируем правила отправки: Тип запроса - циклический
Период опроса - 1000 мс
Номер порта - порт №2
Длина запроса - 8 (байт)
Время ожидания пакета ответа - 2000 мс
Подсчет CRC: Стартовая позиция - 0 (байт по очереди), Длина последовательности - 6 (байт),
Тип подсчета(Modicon Modbus CRC)
3) Формируем правила приема: Длина ответа - 9 (байт)
Проверка заголовка - 2 (байт)
Проверка контрольной суммы - Тип подсчета(Modicon Modbus CRC)

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

Сообщение **Jackson** » 19 мар 2020, 13:57

Injir писал(а): ↑19 мар 2020, 06:54 Конфигурирование запроса не привязано к конкретному протоколу передачи, а параметрируется определенными правилами, которые состоят из 4 основных принципов:

это и есть протокол. :)

Сообщение **tonyk** » 19 май 2020, 16:20

Jackson писал(а): ↑13 мар 2020, 19:10 который физически может работать на последовательных портах (IP, к примеру, не может)

Да ну! А про SLIP и CSLIP, видать, не знаете?

Сообщение **Madwolf** » 01 июн 2020, 11:01

Если некому допиливать программы на Си, берите то же самое только не 7186EX а 7186EG, с поддержкой изаграф. Стоит копейки, поддержка такая же. Установив плату Х511, получите в распоряжение 4 порта RX-485, и один 232. В изаграфе гораздо проще сконфигурировать будет.

Сообщение **tonyk** » 09 июн 2020, 06:54

Возьмите аналог:
https://icp-das.ru/catalog/upac-7186exd

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