|
Повідомлення створено: 25. 03. 2014 [11:52]
|
|
Waterdisp
Александр Иванов
Автор теми
Зареєстрован(а) с: 03.10.2013
Повідомлення: 32
|
Добрый день!
Пробую сделать функцию в модуле JavaLikeCalc Сбора данных, для многоступенчатого опроса прибора. Необходимо поднять транспорт (в данном случае используется модем через Com-порт), опросить прибор(используется Modbus), проанализировать ответ, на его основе сделать новый запрос и так несколько раз, транспорт все это время включен.
Для всех запросов ипользуется стандартный механизм, наподобие указанного внизу:
rez=SYS.Transport.Serial.out_UVR_test.messIO(Special.FLibSYS.strEnc2Bin(DAQ.JavaLikeCalc.lib_servProc.CRC_myimpl(tval)),5);
while ( true )
{
bstr=SYS.Transport.Serial.out_UVR_Test.messIO("");
if (!bstr.length) break;
rez+=bstr;
}
rez1=Special.FLibSYS.strDec4Bin(rez);
Далее, соответсвенно идет обработка посылки прибора и новый аналогичный запрос к нему с сохранением результата в другую переменную.
Пробую запустить функцию на вкладке "Исполнить", и вижу что у меня результаты первого и второго запросов оказались перепутаны местами... (я просто за большое количество опытов уже знаю, что прибор шлет в ответ на какой запрос). Попробовал увеличить таймаут в messIO с 5 вплоть до 20 секунд, но это не помогло. В самом транспорте стоят таймауты 10000:1000. Где искать причину подобной "рокировки"?
P.S. После уменьшения таймаута до величин меньше 1 результаты обоих запросов оказались одинаковы (наверное ответ на следующий запрос не успел дойти и были вычитаны резльтаты предыдущего). Но по прежнему совсем не могу объяснить, каким образом они меняются местами при таймаутах свыше 1 сек... :bang:
[Повідомлення редагувалось 1 раз(ів), останній раз 25.03.2014 в 11:57.]
|
|
Повідомлення створено: 25. 03. 2014 [13:23]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"Waterdisp" wrote:
Пробую сделать функцию в модуле JavaLikeCalc Сбора данных, для многоступенчатого опроса прибора. Необходимо поднять транспорт (в данном случае используется модем через Com-порт), опросить прибор(используется Modbus), проанализировать ответ, на его основе сделать новый запрос и так несколько раз, транспорт все это время включен.
Если там реально модем, то читаем про модемы: http://wiki.oscada.org/Doc/Serial#h835-4
"Waterdisp" wrote:
Для всех запросов ипользуется стандартный механизм, наподобие указанного внизу:
Для ModBus есть ещё более стандартный: http://wiki.oscada.org/Doc/ModBus#h592-7
"Waterdisp" wrote:
Далее, соответсвенно идет обработка посылки прибора и новый аналогичный запрос к нему с сохранением результата в другую переменную.
Пробую запустить функцию на вкладке "Исполнить", и вижу что у меня результаты первого и второго запросов оказались перепутаны местами... (я просто за большое количество опытов уже знаю, что прибор шлет в ответ на какой запрос). Попробовал увеличить таймаут в messIO с 5 вплоть до 20 секунд, но это не помогло. В самом транспорте стоят таймауты 10000:1000. Где искать причину подобной "рокировки"?
Если там реально модем, то с его ЭХО там может быть что угодно, а с прямым запросом такого быть не может в принципе, ну разве только кто-то висит рядом на том-же порту и флудит.
Разбирайтесь с работой через модем, где стадии реального обмена должна предшествовать стадия подключения, что модуль Transport.Serial делает, при условии корректной конфигурации!
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 26. 03. 2014 [16:51]
|
|
Waterdisp
Александр Иванов
Автор теми
Зареєстрован(а) с: 03.10.2013
Повідомлення: 32
|
Разобрался, это я сам ошибку сделал (.
Заодно заметил одну особенность. Если на модеме выставлен режим подробных ответов на запросы соединения (ATX1-4), а в настройках модема ожидаемая строка-ответ модема на успешное соединение равно просто "CONNECT", то последующий ответ на Modbus запрос захватывает часть байтов из конца ответа модема на успешное соединение. То есть, например, после успешного соединения и получения из модема ответа CONNECT 9600/RLP<cr><lf> у меня в "ответ прибора" попадало 4 символа - LP<cr><lf>. Менял таймауты транспорта по всякому - не помогло, пока не просниффил com-порт, только тогда все прояснилось :)
|
|
Повідомлення створено: 26. 03. 2014 [18:51]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"Waterdisp" wrote:
Заодно заметил одну особенность. Если на модеме выставлен режим подробных ответов на запросы соединения (ATX1-4), а в настройках модема ожидаемая строка-ответ модема на успешное соединение равно просто "CONNECT", то последующий ответ на Modbus запрос захватывает часть байтов из конца ответа модема на успешное соединение. То есть, например, после успешного соединения и получения из модема ответа CONNECT 9600/RLP<cr><lf> у меня в "ответ прибора" попадало 4 символа - LP<cr><lf>.
Вопросы к модему, как он умудряется одну небольшую строку отправлять фактически отдельными посылками.
Модуль Transport.Serial завершения строк не ожидает и ему хватает факта совпадения участка строки.
Learn, learn and learn better than work, work and work.
|
