Чтение из базы данных PostgreSQL

Стартовая страница Форумы Понять, как работает ПО Чтение из базы данных PostgreSQL

Просмотр 15 сообщений - с 16 по 30 (из 61 всего)
  • Автор
    Записи
  • #33833
    JurasskPark
    Участник

    Ну понял, а это как то взаимосвязанно с тем, что при настройке в канале типа данных Unicode и ASCII рвется связь с коммуникатором?

    Сложно ответить… Вы первый кто об этом говорит.

    Если не против, то я бы сам поковырялся в драйвере с целью доработки, единственное хотелось бы примерно понимать где указывается размерность тега(сейчас исходник глянул, пока не понятно) или нужно допиливать что то ещё кроме DbImportPlus?

    Ну для этого он в свободном доступе на GitHub и находится. 🙂 Всё равно код не мой, а Михаила, поэтому мне не жалко. 🙂
    Если допилите, то потом скажите, я смогу в свой код добавить. 🙂

    #33834
    asutp42
    Участник

    Сложно ответить… Вы первый кто об этом говорит.
    В некоторых обсуждениях я встречал такую проблему, но решения конкретного не увидел пока. Вроде как по умолчанию тип данных используется Double, а при выборе ASCII sctring или Unicode string связь с коммутатором рвется.

    #33835
    asutp42
    Участник
    #33836
    asutp42
    Участник
    #33837
    asutp42
    Участник

    Короче одну проблему с помощью тегов получилось решить, осталось понять почему связь рвется))

    #33838
    JurasskPark
    Участник

    https://forum.rapidscada.ru/?topic=получение-строки-неизвестной-длины&paged=2#post-29025

    1. Почему при указании типа данных — ASCII String внутри драйвера теряется привязка к каналу, у которого не указан тип данных? Почему не достаточно привязки только по коду тега?, отображение это уже другой вопрос, но привязка канала должна сохраняться, если код тега соответствует…
    У меня получилось вывести строку из первых 8-ми байт в лог Коммуникатора.

    Почему при указании типа данных — ASCII String внутри драйвера теряется привязка к каналу, у которого не указан тип данных?

    Специально так сделано, чтобы тег устройства и канал соответствовали друг другу.

    #33839
    asutp42
    Участник

    Ну да, видел эту тему. Только конкретного ответа нету там))

    #33840
    JurasskPark
    Участник

    Как нет?
    В свойствах канала не указано тип данных или пришедшее значение не соответствуют типу данных.

    #33848
    Mikhail
    Модератор

    В канале длина данных = 1. А в настройках драйвера?

    #33863
    asutp42
    Участник

    Так в том то и дело, что всё указано. С SQL данные идут типом «NVARCHAR» в драйвере указываем формат тега «строка» в канале указываем тип данных «Unicode string». Данные в итоге появляются и исчезают так как рвется связь с коммуникатором. Длинна данных 8 байт, соответственно 1 тег.

    #33864
    asutp42
    Участник

    Остальные данные идут без проблем, проблема только с Unicode.

    #33865
    asutp42
    Участник
    #33866
    asutp42
    Участник

    Настройки драйвера подразумевается настройка формата тега?

    #33867
    asutp42
    Участник

    Или может в конфигурационных файлах нужно, что нибудь менять?

    #33870
    JurasskPark
    Участник

    Давайте зайдем к вопросу с другой стороны. Как вы определяете что связь пропала? По каким признакам?

Просмотр 15 сообщений - с 16 по 30 (из 61 всего)
  • Для ответа в этой теме необходимо авторизоваться.