System.IO.Ports

[JurasskPark]

Если в драйвере подключить System.IO.Ports, то настойки будут браться из каталога подключенного выше например, в каталоге ScadaAdmin лежит библиотека. Я её подключил к проекту и она не может инициализировать сколько COM- портов находиться в системе Windows.
Взял последнюю версию с Nuget, на Net 6.0 Windows она правильно иницилизирует и определяет COM- порты

Предлагаю в качестве «развития» обновить библиотеку System.IO.Ports.dll с версии 6.0.21.52210 от 23.10.2021 (36.1 Кб) на 7.0.22.47203 от 23.09.2022 (84.1 Кб). Эта версия показывает COM-порты в Windows.

https://www.youtube.com/watch?v=dns8wST3rNA

• Эта тема была изменена 1 год, 3 месяца назад от Mikhail.

[JurasskPark]

Забыл добавить, что названия COM- портов из системы берутся функцией SerialPort.GetPortNames().

[Mikhail]

Да, GetPortNames — полезный метод. Со временем обновим зависимость. Чтобы не ждать, добавьте пока в дистрибутив своего модуля новую версию DLL, чтобы она перекрывала имеющуюся.

Какой модуль Вы разрабатываете?

[JurasskPark]

Если честно, то это модуль для счётчика газа ВТД-У.
Там в зависимости от версии может быть как протокол modbus RTU, так и свобственный сделанный на основе modbus RTU — только входных параметра 3 шт.
А так как я его делаю на основе своего старого приложения, то я реализовыю 4 варианта подключения: последовательный порт, tcp клиент, udp клиент, rapid SCADA (то есть вариант, когда выбран в RapidScada и она сама отправляет данные)

Сам вычислитель газа
http://www.dinfonpf.ru/vtd-u.html
Протоколы:
http://www.dinfonpf.ru/documents/protocol_vtd_u.pdf
http://www.dinfonpf.ru/documents/MODBUS_vtd_u.pdf

Страница на документы
http://www.dinfonpf.ru/protocol.html

[Mikhail]

То есть драйвер сможет работать как под управлением Коммуникатора, так и самостоятельно?

[JurasskPark]

То есть драйвер сможет работать как под управлением Коммуникатора, так и самостоятельно?

Если честно… то я тупой, мне сложно отвечать на такие вопросы…
У нас в свойствах библиотек есть переменные
CanSendCommands = false;
ConnectionRequired = false;
и у меня есть свойства канала, выбрав режим свой или RapidScada, я могу передать true или false в эти переменные… Я надеялся, что я могу так делать. =D Ну если нет… значит удалю режим RapidScada…

А логика там тупая и простая:
0 — инициализирован по свойствам канал связи.
1 — посмотрели какой протокол — сформировали запрос.
2 — посмотрели какой в конфигурации режим канала. от 1 до 4 — через switch зашли в нужный режим. Отправили данные и получили.
3 — посмотрели какой протокол — расшифровали запрос. удалили служебный информацию, оставили только массив входных данных.
4 — вставили их в буфер и записали по свойствам команды. Вот тут есть различие в плане логики работы драйвера modbus и моего драйвера.
а) у вас по element group определяется начальный регистр и количество элементов — то есть это и команда и массив, где находятся уже теги с номерами регистров, которые последовательно разбираем данные.
В моем же историческом варианте (приложению больше 4х лет :D), у устройства есть буфер регистров, в которые мы сначала записываем данные отработав команду, а если нужно расшифровать по тегу значению, обращаемся к этому буферу и получаем по адресу тегу — номер элемента(ов) массив и превращаем их в результат расшифровки формата.
Плюсы: — я могу сохранять этот буфер в виде файла и если нужно потом считать его обратно в приложение(драйвер) при перезапуске. Это нужно для устройств, которые просыпаются 1 раз в 2 часа. А SCADA не объяснишь, извини, данных нет, поэтому вот тебе старые из буфера. 🙂
— я могу хранить в формате ulong 4 байтовые регистры т.е. когда регистр не 2 байта, а 4. То есть полученный массив делю не по /2, а по / 4 и складываю в регистр.
— я могу из TCP-сервера (поднятом в этом драйвере), могу находить устройство и данные, которые в нем. Это Gateway или в вашем случае Драйвер Modbus Slave. Такой же принцип.

Короче, раньше это работало. Сейчас я переношу из exe в драйвер. Частично переписываю лапшу из if {} else if {} в switch, что-то удаляю, что-то добавляю.
Идёт медленно, это библиотека пока идёт по принципу — нужно сделать быстро и лишь бы работало, нам нужно этот ВТД, а всё остальное потом и как-нибудь. 😀

P.S. И да. Использовать стандартный драйвер Modbus из-за особенности железок я не могу, могут быть разные потому там тоже реализован свой Modbus + мне нужно 4 байтовый режим для УУН + свои форматы тегов (datetime, bit(n-n) — это брать регистры с такого номера, по такой-то и т.д.)

Пример, интерфейса.
https://www.youtube.com/watch?v=yKj7x7-gP80

[Mikhail]

Драйвер устройства по задумке реализует логику опроса. Соединение TCP, UDP и т.п. реализует драйвер канала связи. Если стандартных каналов связи не хватает, то возможно, стоит написать свой драйвер для канала связи. Такой подход позволяет отделить канал связи от логики опроса, что делает код более понятным и коротким.

[JurasskPark]

Я осознал свою ошибку. Прошу прощения! 🙂
Я забыл, что это я подстраиваюсь под систему, а не наоборот. 😀
И вы правы. Лишний «код», который уже реализован в системе, его не нужно удалять. 🙂

• Этот ответ был изменен 1 год, 3 месяца назад от JurasskPark.

[Mikhail]

Использование имеющихся каналов связи не является обязательным, но в то же время довольно удобно. Зачастую, когда используются готовые библиотеки, например, MQTT или SNMP, работа с соединением уже зашита в них.

[Автор]

Сообщения