Стартовая страница › Форумы › Понять, как работает ПО › Чтение из базы данных PostgreSQL
- В этой теме 60 ответов, 7 участников, последнее обновление 1 год, 11 месяцев назад сделано
asutp42.
-
АвторЗаписи
-
06.08.2024 в 11:09 #33833
JurasskParkУчастникНу понял, а это как то взаимосвязанно с тем, что при настройке в канале типа данных Unicode и ASCII рвется связь с коммуникатором?
Сложно ответить… Вы первый кто об этом говорит.
Если не против, то я бы сам поковырялся в драйвере с целью доработки, единственное хотелось бы примерно понимать где указывается размерность тега(сейчас исходник глянул, пока не понятно) или нужно допиливать что то ещё кроме DbImportPlus?
Ну для этого он в свободном доступе на GitHub и находится. 🙂 Всё равно код не мой, а Михаила, поэтому мне не жалко. 🙂
Если допилите, то потом скажите, я смогу в свой код добавить. 🙂06.08.2024 в 11:32 #33834asutp42
УчастникСложно ответить… Вы первый кто об этом говорит.
В некоторых обсуждениях я встречал такую проблему, но решения конкретного не увидел пока. Вроде как по умолчанию тип данных используется Double, а при выборе ASCII sctring или Unicode string связь с коммутатором рвется.06.08.2024 в 11:33 #3383506.08.2024 в 11:36 #33836asutp42
Участник06.08.2024 в 11:37 #33837asutp42
УчастникКороче одну проблему с помощью тегов получилось решить, осталось понять почему связь рвется))
06.08.2024 в 11:56 #33838
JurasskParkУчастникhttps://forum.rapidscada.ru/?topic=получение-строки-неизвестной-длины&paged=2#post-29025
1. Почему при указании типа данных — ASCII String внутри драйвера теряется привязка к каналу, у которого не указан тип данных? Почему не достаточно привязки только по коду тега?, отображение это уже другой вопрос, но привязка канала должна сохраняться, если код тега соответствует…
У меня получилось вывести строку из первых 8-ми байт в лог Коммуникатора.Почему при указании типа данных — ASCII String внутри драйвера теряется привязка к каналу, у которого не указан тип данных?
Специально так сделано, чтобы тег устройства и канал соответствовали друг другу.
06.08.2024 в 12:41 #33839asutp42
УчастникНу да, видел эту тему. Только конкретного ответа нету там))
06.08.2024 в 14:09 #33840
JurasskParkУчастникКак нет?
В свойствах канала не указано тип данных или пришедшее значение не соответствуют типу данных.06.08.2024 в 14:37 #33848
MikhailМодераторВ канале длина данных = 1. А в настройках драйвера?
07.08.2024 в 05:58 #33863asutp42
УчастникТак в том то и дело, что всё указано. С SQL данные идут типом «NVARCHAR» в драйвере указываем формат тега «строка» в канале указываем тип данных «Unicode string». Данные в итоге появляются и исчезают так как рвется связь с коммуникатором. Длинна данных 8 байт, соответственно 1 тег.
07.08.2024 в 06:01 #33864asutp42
УчастникОстальные данные идут без проблем, проблема только с Unicode.
07.08.2024 в 06:14 #33865asutp42
Участник07.08.2024 в 07:53 #33866asutp42
УчастникНастройки драйвера подразумевается настройка формата тега?
07.08.2024 в 08:09 #33867asutp42
УчастникИли может в конфигурационных файлах нужно, что нибудь менять?
07.08.2024 в 08:58 #33870
JurasskParkУчастникДавайте зайдем к вопросу с другой стороны. Как вы определяете что связь пропала? По каким признакам?
-
АвторЗаписи
- Для ответа в этой теме необходимо авторизоваться.