Вопрос по применению библиотеки UNM

[nestor]

Добрый день. Изучил несколько примеров, прочитал наверное все темы где встречается слово "unm", но у меня так и не получается опросить устройство (лазерный датчик). Запрос отправляется, это я отследил portmon'ом, приходит всякая ересь, где-то что-то я делаю не так. Нет ли самого простого примерчика (желательно на CFC), где отправка запроса, и прием ответа, состоящего из нескольких байт(у меня 4), чтобы получилась строка принятых байт? Покажите, если несложно, а то я скоро мозг себе сломаю.
Вот что у меня пока получилось:

[Гарчев Евгений]

Здравствуйте!
Посмотрите пример опрса параметров электросчетчика с помощью библиотеки UNM.lib или пример реализации протокола с помощью библиотеки SysLibCom.lib http://www.owen.ru/forum/showthread.php?t=11279 .

[nestor]

Все равно не совсем понятно. Правильно ли думаю, последовательность должна быть такая: посылка запроса, пауза, прием одного байта с помощью GetByte, преобразование принятого байта в строку с помощью RBDATA_TO_STRING, прием следующего байта GetByte, преобразование в строку и т.д. пока не будет принято нужное количество байт, потом склеивание строк в одну. Так? Если так то как осуществляется прием следующего байта? Нужно использовать указатели?

[Александр Приходько]

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

Работа с портом очень проста на самом деле.

Для корректной работы очень рекомендую использовать оператор Case. Он позволяет каждое новое условие обрабатывать в следующем цикле.

Теперь к делу. Немного об операторе CASE:


Инструкция CASE
C помощью CASE можно нескольким различным значениям целочисленной переменной сопоставить различные инструкции.

Синтаксис:

CASE <Var1> OF

<Value1>: <Instruction 1>

<Value2>: <Instruction 2>

<Value3, Value4, Value5>: <Instruction 3>

<Value6 .. Value10>: <Instruction 4>

...

<Value n>: <Instruction n>

ELSE <ELSE instruction>

END_CASE;



Если переменная <Var1> имеет значение <Value i>, то выполняется инструкция <Instruction i>

Если <Var1> не принимает ни одного из указанных значений, то выполняется <ELSE Instruction>.

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

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

Пример:



CASE INT1 OF
1, 5: BOOL1 := TRUE;
BOOL3 := FALSE;
2: BOOL2 := FALSE;
BOOL3 := TRUE;
10..20: BOOL1 := TRUE;
BOOL3:= TRUE;
ELSE
BOOL1 := NOT BOOL1;
BOOL2 := BOOL1 OR BOOL2;
END_CASE



Теперь поговорим о портах.

1) Необходимо сформировать посылку.
Посылка может быть строкой определенного формата или заданной последовательностью байт.
Самое главное на этом этапе - расчет контрольной суммы. Она есть практически у всех устройств, она позволяет защитить отсылаемые команды от помех и предотвратить передачу ложной информации.
2) Далее команду нужно отослать. Делаете запись в порт. Не зависимо от того какой вы библиотекой будете пользоваться - UNM или SysLibCom все команды записи возвращают число отправленных байт.
Данную команду необходимо выполнять до тех пор, пока возвращаемое число байт не сравняется с длиной команды.
Как только число байт будет верным необходимо запустить таймер. Данный таймер нужен, для того, чтобы задать время ожидания ответа.
3) Теперь начинаем опрос порта. Каждый цикл команда чтения порта возвращает число принятых байт. Если за цикл ни чего не пришло число байт будет равняться 0.
С этого момента начинается все самое интересное. В зависимости от навыков программирования, можно сходу анализировать информацию, которая приходит в порт. Но я рекомендую собирать принятую информацию в некоторый буфер и работать с буфером.

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

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

Если ответ пришел раньше чем закончил работу таймер переходим в стадию расшифровки.

Инога очень полезно делать паузы между запросами, чтобы не перегружать интерфейс.

[nestor]

Спасибо, с этим вопросом я разобрался, помог пример с опросом счетчика меркурий.

[rovki]

Может что типа этого http://sesorov.narod.ru/que.html:)

[rovki]

Как можно перегрузить-то ? Или куча мастеров ?


думаю только в этом случае можно что-то перегрузить :) Это типа когда пять человек хотят с одним поговорить:D одновременно.

[Николаев Андрей]

Загадочная фраза :)
Как его можно перегрузить ?

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

[Александр Приходько]

Загадочная фраза :)
Как его можно перегрузить ?

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

[Александр Приходько]

От он. (Со-аффтар ?)
PS PS
И нафига вообще - эти задержки ответа. Везде делаю 0, и не имею проблем

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

2) Про задержки ответа (именно задержки ответа, а не что-то другое) могу сказать, что их я тоже не использую. Но! в некоторых случаях они реально бывают нужны. Вот недалече столкнулся с такой проблемой, когда наш клиент СП270 использовал как ПЛК. Когда на всех модулях стояли задержки ответа 0, RS-485 все время обваливался, как только данный параметр устанавливался в 1 или 2 связь налаживалась.

3) Еще паузы между запросами очень полезны в отладочном режиме, кода протокол пытаетесь свой написать. Если задержки не будет, то просмотреть огромный поток цифр крайне сложно. А установив паузу в 1 секунду можно проводить эксперименты. К тому же появляется возможно проверить нагрузочную способность сети.