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

[light_finder]

Товарищи! Посмотрите, пожалуйста. Вот имеется модуль МДВВ. И я хочу установить, например, выход 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 указывается контрольная сумма, вопрос тот же: кто и как ее считает?

[Дмитрий Егоренков]

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

[light_finder]

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

[light_finder]

Как я понял из описания протокола ОВЕН, при генерации 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]

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

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

[light_finder]

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

[light_finder]

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

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 и простое суммирование без учета переполнения. Да поможет Вам великий Яндекс

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

[light_finder]

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

В качестве мастера выступает ПК с пользовательской программой, написанной на языке С++, работающей с 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

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

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