Вид для печати
Здравствуйте. Я не могу наладить обмет по 485 интерфейсу с прибором.
Параметры обмена 19.2 , 8 бит, адрес 1 совападают.
Формат посылки #GHHGROTVJNPQ /0x0D.
Хочу прочитать параметр PV.
При передачи моргает светодиод RS, а ответа нет.
Пользуюсь проц. ReadFloat24(1,0,'PV ',val,-1), а так же посылкой от МК.
УРА. Обмен с ПК наладил с помощью библ. ОВЕНа. Читает темпер. верно.
Но вот при посылке от микроконтроллера
#GHHGROTVJNPQ/0x0D
прибор упорно отвечает
#GGGJGIJJJHGGGGGURLGG/0X0D
Что бы это значило? Сразу видно, что адрес прибора вместо 1 есть 0.
Хотелось бы получить параметр PV.
прибор скорее всего отвечает #GGGJGIJJJHGGGGGURL\xD. если разобрать этот пакет, то видно, что прибор возвращает ошибку 0x31 - размер поля данных не соответствует ожидаемому.
так как посылка составлена правильно, скорей всего вам отвечает другой прибор.
если к контроллеру подключено несколько приборов, проверьте, что диапазоны адресов многоканальных приборов не пересекаются. то есть два ТРМ202 должны быть подключены на адреса 0 и 2.
если к контроллеру подключен другой ТРМ202, он может оказаться со старой микропрограммой, в которой каналы адресуются через индекс, а он как раз передается в поле данных.
в библиотеке можно включить отладочный вывод, и посмотреть, какие посылки формирует библиотека, и как отвечает прибор.
В линии находится только один ТРМ202. В ПК я использую процедуру
res:=ReadFloat24(1,0,'PV ',val,-1); насколько понимаю индексы не принимают участие.
Я посмотрел посылки ПК посылает #GHHGROTVJNPQ/0x0D, а прибор отвечает
#GHGJROTVSGGJVHIGLN/0x0D. Почему микроконтроллеру прибор не "хочет" отвечать?
УРА. Мой Атмега48 "достучался" до ТРМ202. Приходится два раза посылать приведённый выше запрос и более менее стабильно работает на скорости 4800 и времени задержки ответа 45 мс.
Контроллер работает на частоте 3,6864 МГц. Почему программа не работает с большими скоростями? Попробую увеличить частоту кварца до 14 МГц.
ПОДСКАЖИТЕ ПРОГРАММКУ или ИСТОЧНИКИ как осуществить перевод Float24 в десятичную дробь. Спасибо.
Я не очень представляю как вы управляете приемо передатчиком RS485, но думаю через рассчет времени. Проблема в том что это не всегда срабатывает. Оптимальный способ управления состоит в прослушивании своей передачи (TX->RX). В тот момент, когда принимается конец запроса (в случае с ОВЕН 0xD),
нужно переключить 485 на прием.
Мой контроллер работает в реживе Мастера. Драйвер 485 интерфейса обычная ST485, постоянно находящаяся в режиме приёма. Мега48 переключает драйвер в режим передачи посылает два запроса (когда один запрос ТРМ202 не отвечает) и снова возвращает его в режим приёма, ожидая при этом прерывания по получению байта по УСАРТ.
Float24 - это значение в формате IEEE 754 c отброшенным младшим байтом. то есть обычное значение с плавающей запятой.Цитата:
Сообщение от Антон_Б
согласно протоколу овен первым в посылке передается старший байт, и на архитектуре интел (little-endian) процедура перевода поля данных во float выглядит так:
Код:void unpackFloat24(unsigned char* data, size_t dataSize, float* value)
{
unsigned char* p = (unsigned char*)(value);
assert(data);
assert(dataSize == 3);
assert(value);
p[0] = 0;
p[1] = data[2];
p[2] = data[1];
p[3] = data[0];
}
Я дико извиняюсь, но почему бы не поставить вместо меги48 что нибудь типа ОВЕН ПЛК??? Подозреваю что по стоимости внедрения обойдется на порядок дешевле. А еще - как собираетесь бороться с ЭМС???
Я уже к склоняюс к ПЛК ОВЕН, но смогу ли я получить 4 ШИМ 10 разрядов? И поддерживает ли ПЛК протокол ОВЕН?