Драйвер ECL Comfort 300/200

Просмотр 15 сообщений - с 1 по 15 (из 47 всего)
  • Автор
    Сообщения
  • #23259
    7in
    Участник

    Совсем недавно познакомился с RapidSCADA. Без особых проблем удалось настроить получение данных с регуляторов отопления Danfoss ECL Comfort 210 т.к. там используется стандартный ModBus.
    Сейчас стоит задача получать данные с более старых контроллеров ECL300 и ECL200. Они имеют свой протокол обмена. У меня есть написанная мной программа на C#, которая читает и записывает необходимые мне значения.
    ECL300 Remote
    Протокол обмена соответственно так же имеется.
    Изучил статью Разработка драйверов устройств, а так же некоторые модули с открытым исходным кодом, доступные на github.
    К сожалению в том числе из за скудного опыта работы с системой не получается подступиться к написанию собственного драйвера. Быть может кто-то из сообщества готов помочь в реализации вышеописанного драйвера? Изначально планировал после тестирования реализации драйвера сделать его бесплатным и общедоступным сообществу.
    Протокол обмена ECL 300/200

    #23260
    7in
    Участник

    Насколько я понял сейчас новый драйвер нужно писать сразу под v6, я прав?

    #23261
    manjey73
    Участник

    Можно и под 5-ю версию написать. Если не использовать Оконный интерфейс, то соответствия 5-й и 6-й версии не такие глобальные. По крайней мере логику драйвера Меркурий 23х я запустил достаточно быстро. Были конечно некоторые непонимания из-за изменений в 6-й версии, но они оказались не такими страшными.

    Определитесь по протоколу, если там все статично, но можно просто все переменные прописать в драйвере. Мне же приходится плясать от шаблонов с возможностью настройки и модификации опроса….

    #23262
    manjey73
    Участник

    Покажите код самой логики обмена с приборами. насколько она там разветвленная.
    Вообще какие пожелания в плане настроек опроса ? Есть необходимость включать, отключать запросы, разделять запросы по времени и так далее…

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

    Насколько я понял сейчас новый драйвер нужно писать сразу под v6, я прав?

    Да. Зачем потом переделывать.
    Если Вы успешно написали программу опроса, то драйвер — решаемая задача.

    Потребуется VS2022.
    Драйвер для версии 6 состоит из как минимум 2 проектов:
    DrvXXXLogic — Class Library, .NET Standard 2.0 или.NET6.
    DrvXXXView — Windows Forms Class Library, .NET6
    В качестве начального примера смотрите драйверы DrvSimulator и DrvTester. Задавайте конкретные вопросы здесь на форуме.

    #23269
    7in
    Участник

    Логика достаточно простая. На данный момент мне было бы достаточно получать данные с датчиков температуры (6 штук). В будущем конечно планировал добавить запись значений, чтение конфигурации и т.д.
    Поэтому думаю вариант жестко задать в драйвере параметры, не прибегая к шаблонам — это как раз мой вариант.
    Единственное хотелось бы иметь возможность запрашивать только необходимые параметры (например только датчики № 1,3,4), нужны ли для этого шаблоны?

    Что касается примеров кода — свои исходники честно говоря мне стыдно показывать, т.к. там все ужасно написано, но есть <ahref=»https://github.com/codingandmore/ecl300″>библиотека на GitHub, написанная другим человеком. Написана на Java, но думаю сама логика запросов там будет понятна.
    Если кратко как происходит обмен: Посылаем 5 байт, в ответ контроллер отвечает тоже 5 байт.
    Структура запроса:
    Первый и второй байт — функция запроса и адрес в памяти устройства
    Третий и четвертый — записываемые значения (если просто читаем — равны 0)
    Пятый байт — контрольная сумма
    Структура ответа:
    Первый и второй байт — запрошенная функция, либо код ошибки
    Третий и четвертый — результат чтения
    Пятый — контрольная сумма

    Соответственно все значения считываются по одному, никакого объединения как в Modbus нет. Сетевого адреса у устройства тоже нет.

    #23270
    7in
    Участник

    Ссылка на гитхаб почему то сломалась. Вот нормальная : github.com/codingandmore/ecl300

    #23272
    manjey73
    Участник

    Не надо стыдиться :), видели бы мою первую версию драйвера 🙂

    Лучше в своем коде сделайте комментарии для лучшего понимания. я вообще кроме C# ни на чем пока не умею….

    То, что нет адреса очень плохо, получается один прибор — одна линия связи.
    Наверное для 6-й версии будет оптимальнее, так как там есть опрос по команде и настраивается запись в БД, если правильно понимаю, можно отключить для переменных запись в БД, что позволит подавать команды на изменение некоторых переменных без постоянного их сохранения.

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

    #23273
    manjey73
    Участник

    Не изучал пока протокол, особо некогда. За счет шаблона можно пойти путем создания любой команды, если по документации есть строгая архитектура.

    Я так в Меркурии команды делал, могу любую команду в счетчик послать, которая есть в документации. Если кроме команды еще нужно значение ответа в тег, то это немного усложняет, но тоже возможно.

    Главное найти и понять архитектуру протокола, чтобы это описать…

    #23277
    7in
    Участник

    Вот мой код, который запрашивает значение датчиков температуры:

    
    static byte[] SendCheck(byte a, byte b)//Функция принимает на вход 2 байта.
    //Функция отправляет массив байт, через задержку читает ответ и проверяет КС.
    {
    NetworkStream stream = client.GetStream();
    byte[] datasend = {a,b,0,0,0 };//массив байт для отправки
    int checksum = datasend[0] ^ datasend[1] ^ datasend[2] ^ datasend[3];
    //Считаем контрольную сумму массива для отправки
    datasend[4] = Convert.ToByte(checksum);
    //Записываем расчитанную контрольную сумму в конец массива (5 байт)
    stream.Write(datasend, 0, 5);//Записываем в TCP поток
    byte[] dataread = new byte[5];//Массив для приема
    Thread.Sleep(1000);//Ждем ответа
    stream.Read(dataread, 0, 5);//Читаем массив 5 байт из TCP потока
    checksum = dataread[0] ^ dataread[1] ^ dataread[2] ^ dataread[3];
    //Считаем контрольную сумму для принятых байт
                
    if (dataread[4] == Convert.ToByte(checksum) & dataread[1] == datasend[0])
    //Если КС совпадает - функция возвращает результат, иначе нули
    {
    byte[] readresult = { dataread[2], dataread[3] };
    return readresult;
    }
    else {
    byte[] readresult = { 0x00, 0x00 };
    Console.WriteLine("Ошибка чтения");
    return readresult;
         }   
    }
    
    static string[] ReadSensors()//Чтение значений всех датчиков
    {
    string[] temperature = new string[10];
    byte[] RAMadrSensors = { 0x3A, 0x38, 0x36, 0x34, 0x32, 0x30, 0x46, 0x48, 0x4A, 0x4C };
    //Адреса в RAM:S1,2,3,4,5,6,CalcCirc1,CalcCirc2,CalcReturn1,CalcReturn2
    byte i = 0;
    byte s = 1;
    
    foreach (byte b in RAMadrSensors) 
    {
    byte[] result = SendCheck(0xCE, b);
    // Отправляем функцию чтения из RAM и адрес в памяти из массива RAMadrSensors
    byte[] resultreversed = { result[1], result[0] };
    // Переворачиваем байты ответа наоборот
    short temp16bit = BitConverter.ToInt16(resultreversed, 0);
    // Получаем Int16 из массива двух байт
    float temp128 = (float)temp16bit / 128;
    // Превращаем значения в float 
    temperature[i] = temp128.ToString("F1");
    //Превращаем в строку
    Console.WriteLine("Sensor " + s + ": " + temperature[i] + "°C");
    i++;
    s++;
    }
    return temperature; //Возвращаем массив температур
    }
    
    #23278
    7in
    Участник

    Так понимаю это конфигурируемые приборы и не всегда используются все входы/выходы, как те же датчики. И тогда нет смысла читать то, что не используется, учитывая, что на каждый параметр свой запрос.

    Все верно. У приборов есть разные схемы применения, от них зависит набор доступных парамтеров для чтения и записи. Помимо этого согласно документации после получения ответа, перед отправкой новго запроса следует выждать 400мс. Таким образом чтение ненужных параметров будет очень сильно увеличивать время опроса.

    #23291
    manjey73
    Участник

    400 мс выдерживает логика драйвера по идее. Параметр Пауза в настройках Опроса Устройства. Ну или это параметр можно забирать в логику, если вообще опрос каждого параметра этого требует.

    #23292
    manjey73
    Участник

    byte[] datasend = {a,b,0,0,0 }

    В качестве a и b вы подставляете коды запросов? а потом два байта ответа после проверки полученного ответа представляют из себя всегда один и тот же тип данных ?

    #23293
    manjey73
    Участник

    Это и весь код или только связанный с датчиками?

    Вообще напрашивается как раз шаблон. В котором указать в параметрах то, что вы используете в качестве байта b
    и например параметр активности true или false.

    Соответственно в словарь при запуске линии занести активные параметры, сразу подготовить запросы с уже расcчитанными CRC и потом просто в цикле уже кидать готовые запросы в прибор. Ну и при чтении проверять CRC и наличие данных.

    #23296
    7in
    Участник

    два байта ответа после проверки полученного ответа представляют из себя всегда один и тот же тип данных

    К сожалению нет, типы данных разные. Приведенный код относится только к значениям температур. Остальные параметры хранятся в различных типах данных и требуют преобразования.

    Для начала я думаю вполне подойдет ваш вариант: задаем true/false около параметров, которые хотим/не хотим запрашивать. Контрольную сумму запросов действительно можно посчитать заранее и затем просто отправлять заготовленный массив байт.

    Пока не могу разобраться как скомпилировать свой проект из VS2022 в dll, чтобы он был доступен при выборе драйвера в приложении Администратор

Просмотр 15 сообщений - с 1 по 15 (из 47 всего)
  • Вы должны авторизироваться для ответа в этой теме.