Управление ВЭ МДВВ

Товарищи! Посмотрите, пожалуйста. Вот имеется модуль МДВВ. И я хочу установить, например, выход 3 в состояние "включено". Для этого, насколько я понимаю, требуется установить оперативный параметр r.OE третьего ВЭ в 1. Для этого в модуль по сети RS-485 требуется послать пакет. Правильно ли я понимаю, что при использовании протокола ОВЕН, пакет должен иметь формат, описанный ниже?

Вариант 1 (протокол ОВЕН)
__________________________________________________ _________________________________

Начало кадра |Адрес узла | HASH имени параметра| Значение параметра | CRC | Конец кадра
__________________________________________________ _________________________________

Пусть базовый адрес модуля (параметр Addr) равен, например, 16. Тогда пакет будет иметь следующий вид:

# 18| HASH (r.OE) | 1 | CRC | CR

А кто считает HASH и CRC? Где вычисляются значения этих полей?
---------------------------------------------------------------------------------------------------------------------
Вариант 2 (протокол DCON)

______________

@1604[CHK]CR
______________

Тут в поле CHK указывается контрольная сумма, вопрос тот же: кто и как ее считает?

брателло, или научись читать и понимать документацию, или убери подпись - не позорь альма матерь. как мифист тебе говорю.

Говорить Вы мне можете все, что угодно, это Ваше дело..но дело в том, что мне Ваше мнение, мягко скажем, не очень нужно, у меня возник вопрос, и я его задал, Вашей оценки, по-моему, я не спрашивал..

Как я понял из описания протокола ОВЕН, при генерации CRC и HASH используется РСЛОС с характеристическим многочленом определенного вида. То есть принципы формирования HASH и CRC одни и те же. Странно, но допустим. Хорошо. Также в описании вышеупомянутого протокола приведено описание функции на С++, позволяющая рассчитать значения HASH и CRC:
__________________________________________________ _____________

unsigned Hash(char Byte, char nbit, unsigned CRC)
{
for (int i = 0; i < nbit; i++, Byte <<= 1)
{
if ( ( Byte ^ (CRC>>8) ) & 0x80 )
{
CRC <<= 1; CRC ^= 0x8F57;
}
else CRC <<= 1;
}
return CRC;
}
__________________________________________________ _______________

HASH и CRC формируются побайтно, не совсем понятно, почему. Почему нельзя подавать сразу весь пакет на вход РСЛОС? Зачем формировать контрольные коды поблочно?

Цитата:

---

Сообщение от light_finder

Говорить Вы мне можете все, что угодно, это Ваше дело..но дело в том, что мне Ваше мнение, мягко скажем, не очень нужно, у меня возник вопрос, и я его задал, Вашей оценки, по-моему, я не спрашивал..

---

:cool: :cool:
Зря Вы так с начальником отдела программирования ОВЕН...
:cool: :cool:

Цитата:

---

Сообщение от Николаев Андрей

:cool: :cool:
Зря Вы так с начальником отдела программирования ОВЕН...
:cool: :cool:

---

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

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

Поставлю вопросы поконкретнее:

1. Параметр r.OE Имя этого параметра, насколько я понимаю, по концепции, принятой в протоколе ОВЕН, состоит из трех символов. В том же протоколе написано, что в качестве имен ПОЛЬЗОВАТЕЛЬСКИХ параметров используются четырехсимвольные имена. Если соединить два этих факта, то можно сделать вывод о том, что параметр r.OE не является пользовательским. Вопрос в том, что подразумевается под пользовательскими параметрами и правильно ли я понимаю, что код имени данного параметра, поступающий побайтно в качестве аргумента в функцию HASH, имеет следующий вид - 55 48 28?

2. Все же непонятно, как формируется CRC в протоколе DCON.
__________________________________________________ __________________
ps Кто формирует HASH и CRC по протоколу ОВЕН я разобрался. Также разобрался, как формируется HASH и CRC одного байта.

В сети 485 есть мастер и слейв (ведущий и ведомый). Мастер формирует пакет - ведомый (если это не широковещательный запрос) отвечает.
HASH и CRC формирует мастер. В общем случае в качестве мастеров могут выступать ПК (конфигуратор, OPC + SCADA, пользовательская программа +owen_io.dll, ПЛК, ТРМ151). Определите, что Вам хотелось бы использовать в качестве мастера.
На вопросы поконкретнее
1. Дополняйте r.oe до 4-х символов "ro.e"->"r.oe " и считайте HASH
2. В протоколе DCON CRC формируется двумя способами - по полиному DS и простое суммирование без учета переполнения. Да поможет Вам великий Яндекс

Дико извиняюсь, но если не секрет - в каком году выпускались?

Цитата:

---

Сообщение от Малышев Олег

Определите, что Вам хотелось бы использовать в качестве мастера.

---

В качестве мастера выступает ПК с пользовательской программой, написанной на языке С++, работающей с COM-портом.

Цитата:

---

Сообщение от Малышев Олег

На вопросы поконкретнее
1. Дополняйте r.oe до 4-х символов "ro.e"->"r.oe " и считайте HASH

---

Ясно. Спасибо.

Цитата:

---

Сообщение от Малышев Олег

2. В протоколе DCON CRC формируется двумя способами - по полиному DS и простое суммирование без учета переполнения. Да поможет Вам великий Яндекс

---

Простите, если вопрос покажется глупым, а какой вид имеет полином DS? Вот в протоколе ОВЕН вид полинома указан в явном виде. Может, конечно, DS, это какое-то общепризнанное обозначение некого полинома, вид которого неизвестен только мне одному, но тем не менее, он мне неизвестен и хотелось бы все-таки уточнить, как он выглядит.

Еще непонятен следующий момент: по Вашим словам, в качестве CRC может выступать либо "нормальный" CRC - многочлен, "оставшийся" в РСЛОС с характеристическим многочленом загадочного вида DS, после поразрядного XOR с каждым битом исходного сообщения, либо же в качестве того же CRC может использоваться простая контрольная сумма. Это понятно, хотя называть контрольную сумму CRC-кодом у меня как-то язык не поворачивается. Ну Бог с ней, дело не в этом. Насколько я понимаю, если существуют два варианта контроля, то мастер должен выбрать из них какой-то один и каким-то образом сообщить об этом выборе slave'у, которому посылается пакет и который, собственно, должен сформировать контрольный блок по тому же принципу, по которому этот блок был сформирован master'ом и сравнить значение, полученное от master'a, с вычисленным. Логично предположить, что информация о выборе метода контроля передается в том же пакете. Поправьте меня пожалуйста, если я ошибаюсь. Где же именно указывается тип формирования контроля?

ps Буду Вам очень признателен, если Вы укажете мне источник, где представлено официальное описание протокола DCON

Цитата:

---

Сообщение от Малышев Олег

Дико извиняюсь, но если не секрет - в каком году выпускались?

---

Не секрет. Я еще учусь.

Так нет официального. Это сборная солянка - все придумывают что во что горазд.
А полином - стандартный для 1-Wire.

Для тех, кто не дружит с Яндексом

/*
DOW_CRC.h
*/

#ifndef _DOW_CRC
#define _DOW_CRC
unsigned char Calculate_DOW_CRC(unsigned char *string, unsigned long size);
#endif //DOW_CRC.h

/*DOW_CRC.c*/
#include "DOW_CRC.h"

const unsigned char DOW_CRC_table[256] = {
0, 94, 188, 226, 97, 63, 221, 131, 194, 156, 126, 32, 163, 253, 31, 65,
157, 195, 33, 127, 252, 162, 64, 30, 95, 1, 227, 189, 62, 96, 130, 220,
35, 125, 159, 193, 66, 28, 254, 160, 225, 191, 93, 3, 128, 222, 60, 98,
190, 224, 2, 92, 223, 129, 99, 61, 124, 34, 192, 158, 29, 67, 161, 255,
70, 24, 250, 164, 39, 121, 155, 197, 132, 218, 56, 102, 229, 187, 89, 7,
219, 133, 103, 57, 186, 228, 6, 88, 25, 71, 165, 251, 120, 38, 196, 154,
101, 59, 217, 135, 4, 90, 184, 230, 167, 249, 27, 69, 198, 152, 122, 36,
248, 166, 68, 26, 153, 199, 37, 123, 58, 100, 134, 216, 91, 5, 231, 185,
140, 210, 48, 110, 237, 179, 81, 15, 78, 16, 242, 172, 47, 113, 147, 205,
17, 79, 173, 243, 112, 46, 204, 146, 211, 141, 111, 49, 178, 236, 14, 80,
175, 241, 19, 77, 206, 144, 114, 44, 109, 51, 209, 143, 12, 82, 176, 238,
50, 108, 142, 208, 83, 13, 239, 177, 240, 174, 76, 18, 145, 207, 45, 115,
202, 148, 118, 40, 171, 245, 23, 73, 8, 86, 180, 234, 105, 55, 213, 139,
87, 9, 235, 181, 54, 104, 138, 212, 149, 203, 41, 119, 244, 170, 72, 22,
233, 183, 85, 11, 136, 214, 52, 106, 43, 117, 151, 201, 74, 20, 246, 168,
116, 42, 200, 150, 21, 75, 169, 247, 182, 232, 10, 84, 215, 137, 107, 53};


unsigned char Calculate_DOW_CRC(unsigned char *string, unsigned long size)
{
unsigned char result=0;
while (size--) result=DOW_CRC_table[(*string++)^result];
return result;
}

Спасибо Вам, а все же не могли бы Вы написать конкретный вид полинома, так как работа с таблицей, конечно, наглядна, но занимает большое время, а в моем случае дорога каждая миллисекунда

Вот ссылка http://www.icpdas.com/download/7000/manual.htm там описания приборов ICP DAS и в нем описания CRC.

По 1wire посмотри DALLAS http://www.elin.ru/1-Wire/?topic=info

PS учись студент искать информацию и читать ее.

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

Цитата:

---

Сообщение от light_finder

понимаю, что при использовании протокола ОВЕН, пакет должен иметь формат, описанный ниже?

Вариант 1 (протокол ОВЕН)
__________________________________________________ _________________________________

Начало кадра |Адрес узла | HASH имени параметра| Значение параметра | CRC | Конец кадра
__________________________________________________ _________________________________

Пусть базовый адрес модуля (параметр Addr) равен, например, 16. Тогда пакет будет иметь следующий вид:

# 18| HASH (r.OE) | 1 | CRC | CR

---

неправильно. там есть еще один байт с младшими битами 11-битного адреса, битом запроса и размером поля данных.

после расчета crc полученный двоичный пакет переводится в ascii, и уже к нему добавляются маркеры начала и конца кадра.

надо ли говорить, что вся эта информация есть в описании протокола ОВЕН?

в приложенном файле -- пример работы с протоколом овен. надеюсь, это вас займет на несколько дней.

Цитата:

---

Как я понял из описания протокола ОВЕН, при генерации CRC и HASH используется РСЛОС

---

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

Цитата:

---

То есть принципы формирования HASH и CRC одни и те же. Странно, но допустим.

---

ничего странного. crc -- хеш-функция не хуже других.

Цитата:

---

HASH и CRC формируются побайтно, не совсем понятно, почему. Почему нельзя подавать сразу весь пакет на вход РСЛОС?

---

а это -- тайна покрытая мраком. можно и нужно считать от всего пакета.

Цитата:

---

Сообщение от light_finder

Спасибо Вам, а все же не могли бы Вы написать конкретный вид полинома, так как работа с таблицей, конечно, наглядна, но занимает большое время, а в моем случае дорога каждая миллисекунда

---

Не знаю, чему учат в МИФИ, но табличный метод быстрее.

Цитата:

---

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

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


ничего странного. crc -- хеш-функция не хуже других.



а это -- тайна покрытая мраком. можно и нужно считать от всего пакета.

---

Спуститесь на землю, пришелецы из 2200 года. Пока встроенные процессоры - 8 битные.

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

Цитата:

---

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

ничего странного. crc -- хеш-функция не хуже других.

---

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

Цитата:

---

Сообщение от Филоненко Владислав

Не знаю, чему учат в МИФИ, но табличный метод быстрее.

---

Товарищ, если Вы не понимаете элементарных вещей, могу Вам посоветовать ознакомиться с цитатой из описания протокола ОВЕН, приведенной чуть ниже. Цитата взята со страницы 8 описания протокола от 15 января 2007 года.

ЦИТАТА:-------------------------------------------------------------------------------------------------------------------
Также можно воспользоваться готовой таблицей (однако следует понимать, что работа с таблицей происходит медленнее):
-----------------------------------------------------------------------------------------------------------------------------

уважаемый видимо путает криптографические хеш-функции, и обычные применения вроде хеш-таблиц и сверток.

может хватит уже?

Цитата:

---

Также можно воспользоваться готовой таблицей (однако следует понимать, что работа с таблицей происходит медленнее):

---

а это уже полный алес капут. то есть никаких других поводов считать, что таблица медленней, у вас нет?

это замечание, во-первых, спорное, во-вторых, относится к преобразованию символов, а не к вычислению crc. и, в-третьих, совершенно ошибочное для более-менее мощных современных процессоров.


не надо с нами спорить с таким гонором при столь ограниченном кругозоре.

Я не путаю, я называю вещи своими именами, хеш-функция это хеш-функция, хеш-таблица - это хеш-таблица.

По моим понятиям, обращение к массиву по индексу всегда занимает большее время, чем обращение к ячейке памяти по адресу переменной, так как в первом случае приходится дополнительно рассчитывать смещение.

Цитата:

---

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

в приложенном файле -- пример работы с протоколом овен.

---

Спасибо, а сразу нельзя было это сделать?

Цитата:

---

Сообщение от light_finder

По моим понятиям ...

---

жить надо по совести, а не по понятиям

Цитата:

---

Сообщение от light_finder

Спасибо, а сразу нельзя было это сделать?

---

нет. и я уже объяснил почему.

Цитата:

---

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

жить надо по совести, а не по понятиям

---

Сложно возразить..только давайте не будем друг друга учить жить..

Цитата:

---

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

нет. и я уже объяснил почему.

---

Ну если бы Вы сразу дали бы мне этот фрагмент, то результат был бы В ТОЧНОСТИ таким же, только без бесполезных пререканий, споров и лишних трат времени, как Вашего, так и моего.

Цитата:

---

Сообщение от light_finder

По моим понятиям, обращение к массиву по индексу всегда занимает большее время, чем обращение к ячейке памяти по адресу переменной, так как в первом случае приходится дополнительно рассчитывать смещение.

---

Оба-на. А собственно расчёт полинома со всеми этими сдвигами и XOR мы уже не считаем?
Да, низко упало образование. Слова красивые знают, а за ними пусто. Наука в религию превращается. В книжке написано, значит надо ВЕРИТЬ!

К тому-же, если уж идти до конца - многие процессоры операцию взятия значения по индексу массива делают за 1 команду.

Извините, но не очень понятно, что Вы хотели сказать в своем посте. Никакой полином мы не считаем, а он нам дается. А что касается сдвигов, то те же самые сдвиги делаются при заполнении таблицы. Поэтому первый этап в табличном методе (когда таблицы еще нет) занимает ГОРАЗДО больше времени, нежели выполнение деления. А вот последующие этапы, когда таблица уже инициализирована и заполнена, выполняются, естественно, за меньшее время, но тут, опять же, вопрос, что выполнится быстрее.

Интересно, а не поясните глупому студенту, как, имея адрес начала массива и смещение в нем, процессор за ОДНУ команду обратится к ячейке? Механизм страничной адресации кто-то отменил? Возможно появились какие-то новые типы процессоров или адресаций памяти. Если так, то я буду Вам премного благодарен, если Вы введете меня в курс дела.

Зря Вы с ним спорите. Он только что открыл глаза и смотрит на мир своим зрением.

PS. Из таких потом могут вырасти знаменитые ученые, которые делают открытия опровергающие общие теории и законы.

Вопрос решен.
Тема закрыта.
Господа спорщики, напоминаю про правила форума.
За сообщения, которые могут оскорблять других участников форума будут выносится штрафы.