TRM138 + owen_io + C++ (qt)

Добрый день! Я покачто новичёк в программировании устройств. Задача следующая: разработать ПО для ТРМ-138. решил использовать qt и библиотеку ОВЕН. в связи с этим сразу несколько вопросов:
1) есть ли возможность заполучить исходные коды библиотеки owen_io ? это бы ускорило разработку, помогло бы мне лучше разобраться в функциях и в протоколе ОВЕН
2) решены ли библиотекой ОВЕН все проблемы, связанные с формированием HASH-сверток итд.. потому что тут на форуме это почемуто популярная тема...
а теперь ГЛАВНЫЙ вопрос
3) в примере и в исходниках библиотеки присутствует h-файл а также lib-файл, который видимо является библиотекой импорта. затем в примере для корректной работы с библиотекой требуется только #include "owen_io.h", но почему то этот метод работает только в VS, а я использую QtCreator с компилятором gcc, выскакивает ошибка памяти при доступе к любой функции из dll (такой же результат дает IDE CodeBlocks с тем же компилятором, поэтому мне кажется дело именно в нем ). В ходе дальнейших попыток заставить dll-ку подключаться явно было опробовано несколько программ генерирующих lib файл по dll, это не помогло... если есть идеи или способы решения - подскажите, потому что вытаскивание функций вручную из dll занятие черезчур кропотливое и слишком загрязняет код.
Теперь САМЫЙ ГЛАВНЫЙ вопрос
Не получается считать температуру с первого канала
судя по выводам функций - порт открывается корректно и функция чтения ошибок не выдает, но value и time равны 0.
-----------------------work with trm138---------------------
port opening... 0
ReadIEEE32:
0
rEAd = 0
time = 0
port closing... 0
--------------------------------------------------------------
К сообщению прикладываю код своего тестового приложения. в h-файле все потерто оставил только define-ы. Заранее благодарю за любой ответ!

мой вам совет -- выбросить из головы C++, Qt и gcc, и писать на C#.

посмотрите внимательней в owen_io.h -- там есть правильные объявления функций.

и вот еще: http://owen.ru/forum/showthread.php?p=28888#post28888

Цитата:

---

Сообщение от Дмитрий Егоренков

мой вам совет -- выбросить из головы C++, Qt и gcc, и писать на C#.

посмотрите внимательней в owen_io.h -- там есть правильные объявления функций.

и вот еще: http://owen.ru/forum/showthread.php?p=28888#post28888

---

Спасибо за совет, однако же, мне критично использовать именно С++ qt. Авторы библиотеки овен предполагали ее использование на С++, иначе этого бы небыло в описании к библиотеке и в примерах.
Порты открываются и закрываются корректно. В случае попытки повторного открытия порта или закрытия неоткрытого порта - функции возвращают верные коды ошибок, а значит функции я объявляю верно.
Хотелось бы уточнить использование функции
Покачто моя функция чтения только обнуляет принимаемые параметры time и value =(
может быть у кого-нибудь есть примеры считывания параметров на С++ ? поделитесь, буду благодарен

критично? вот это "решил использовать qt" называется критично? в чем смысл использовать qt для написания windows приложения (а других вы с owen_io.dll не напишите)?

> а значит функции я объявляю верно
никакой связи. функции объявлены неправильно. должно быть так:

typedef int _stdcall (*OPENPORT)(DWORD n,DWORD speed,DWORD parity,DWORD bits,DWORD stop,DWORD converter);

ссылку на то, как импортировать библиотеку без этих объявлений, я уже давал.

Уважаемый Дмитрий! выбор технологии предлагаю не обсуждать, так как это может затянуться в бесполезный спор из множества постов. По поводу вызова функций:
БОЛЬШОЕ СПАСИБО! заработала наконец то функция считывания =)
работаю над функцией смены установки параметра C.SP (это значение измеряемого параметра (в моем случае - температура), при котором должно сработать реле).
Почему то работает только запись параметра, а функция чтения выдает ошибку памяти (...память не может быть "written"...).

value = 20.0;
cout << "write C.SP :" << endl;
cout << WriteStoredDotS(145,0,"C.SP", value, -1) << endl;
cout << "read C.SP :" << endl;
cout << ReadStoredDotS(145,0,"C.SP", value, -1) << endl;
cout << "C.SP = " << value << endl;

базовый адрес прибора 144 реле во 2 канале. мб подскажете, где я не прав?

проверьте, что функция правильно объявлена и загружена.

спорить тут, в общем-то, не о чем. хотите тратить время на бессмысленную борьбу с c++ и прочим зоопарком? да пожалуйста!

Цитата:

---

Сообщение от Дмитрий Егоренков

ссылку на то, как импортировать библиотеку без этих объявлений, я уже давал.

---

Это уже пробывал - предложенный способ, результатов не дал.

Функцию объявляю следующим образом:

typedef int _stdcall(*READSTOREDDOTS)(DWORD adr,DWORD adr_type,char *command,float value, int index);

READSTOREDDOTS ReadStoredDotS;

if ((ReadStoredDotS = (READSTOREDDOTS)GetProcAddress(hDLL, "ReadStoredDotS")) == NULL)
{
cout << "error to find DLL function ReadStoredDotS" << endl;
}

Вызываю так:

float res = 0.0;
cout << "read C.SP :" << endl;
cout << ReadStoredDotS(144, 0, "C.SP", res, -1) << endl;
cout << "C.SP = " << res << endl;

со всеми остальными функциями проблем нет, только с этой, это раздражает, ведь у меня вся разработка стоит из-за нее(( Пожалуйста, подскажите, где ошибка!!!

typedef int _stdcall(*READSTOREDDOTS)(DWORD adr,DWORD adr_type,char *command,float& value, int index);

вот это то, о чем я предупреждал. C++ -- бесконечное поле усеянное граблями. на парочку вы уже наступили, дальше будет веселей.

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

столкнулся со странностью:
при записи параметра изменения уставки при помощи функции
WriteStoredDotS(realAdress, 0, "C.SP", CSP, -1)
(записывается параметр тип float!!!)
после этого я считываю записанное значение уставки при помощи функции
ReadStoredDotS(realAdress, 0, "C.SP", res, -1)
так вот, если посмотреть значение в конфигураторе или на приборе - то видно что параметр записывается всегда верно, но, если записать не целый параметр, то считывается он неверно, например:
при записи C.SP = 10.5 он считывается как 420.1
20.5 считывается как 430.1. Отсюда казалось бы просто вычесть 409.6, но это не сработает, если уставка станет целой =). быть может у кого нибудь есть идеи?

в общем я тут посмотрел, функция считывания ведет себя не стабильно, например на число 1.4 она считывает как 3 а число 1.2 - как 2.8 ... не пойму в чем тут дело, вроде бы я не ввожу ничего не умещающееся в 4 байта или не поддерживаемое прибором по точности...

попробуйте обновить библиотеку с сайта.

посоветовался, для нормальной работы устройства не требуется высокая точность. точность в 1 градус - приемлема, так что этот вопрос закрыт...
появился другой) значение ву (положение реле) считывается корректно, но не записывается... вернее не изменяется. это нормально? или я где-то ошибся и у меня должна иметься возможность программным путем изменить выходной сигнал? как тогда это будет коррелироваться с уставкой и всякими задержками? спасибо