| Author |
Message |
|
Written on: 16. 05. 2014 [12:57]
|
|
shdimka
Дмитрий Шабунов
Topic creator
registered since: 05.12.2011
Posts: 35
|
Возможно ли получение данных со станции через поледовательный интерфейс используя транспорт последовательный порт?
На данный момент получаю данные используя сокет, необходимо подключить аварийный канал через последовательный порт.
Пытался создать хост и тип транспорта последовательный порт. На удаленной станции настроен входной транспорт через последовательный порт SelfSystem протокол. При проверке связи получаю ответ REZ 3 co.
|
|
Written on: 16. 05. 2014 [16:48]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3747
|
"shdimka" wrote:
Возможно ли получение данных со станции через поледовательный интерфейс используя транспорт последовательный порт?
Данные вообще — да.
DAQGate гипотетически тоже, но сам используемый им протокол "SelfSystem" не предусматривает контроля целостности данных, без которого в Serial могут быть проблемы.
"shdimka" wrote:
Пытался создать хост и тип транспорта последовательный порт. На удаленной станции настроен входной транспорт через последовательный порт SelfSystem протокол. При проверке связи получаю ответ REZ 3 co.
Типовая настройка таймаутов, а конкретно здесь увеличить время символа.
Learn, learn and learn better than work, work and work.
|
|
Written on: 23. 05. 2014 [09:30]
|
|
shdimka
Дмитрий Шабунов
Topic creator
registered since: 05.12.2011
Posts: 35
|
В принципе работает. На скорости 115200 даже данные обновляются корректно с типовыми таймаутами. Проблема неправильного ответа в том что я не поставил галочку выжидать таймаут.
Тоесть между двумя станциями вопросов нет, указываю одновременно 2 типа транспорта, последовательный и сокет и при выпадании одного из них данные все равно передаются.
Вопрос по добавленной схеме. Имеет ли место жить такая схема. Можно ли на одну линию RS485 вешать несколько станций? Пока не представляю каким образом возможно использование несколькими станциями одного канала.
При программировании микроконтроллеров для работы на линии RS485 мне приходилось программно идентифицировать запросы по ID номеру присвоенному конкретному микроконтроллеру и так как один только был инициализатором запросов то конфликтов не возникало.
В моем понимании, станция оператора инициализирует запросы, и я так понимаю что запросы к станциям будут идти последовательно и в теории конфликтов в канале не должно быть если выдерживать необходимую задержку.
Каким образом можно идентифицировать станцию куда приходит запрос? Сейчас я не вижу такой возможности в протоколе SelfSystem.
Так ли это?
Attachment
Drawing1.jpg (File type: image/jpeg, Size: 30.3 kilobytes) — 1710 downloads
|
|
Written on: 23. 05. 2014 [13:20]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3747
|
"shdimka" wrote:
В принципе работает. На скорости 115200 даже данные обновляются корректно с типовыми таймаутами. Проблема неправильного ответа в том что я не поставил галочку выжидать таймаут.
Это где?
Нет и не нужно для протокола SelfSystem такого, поскольку в нём есть информация о размере, по которой он ровно и ожидает, читаем: http://wiki.oscada.org/Doc/Serial#h835-6
"shdimka" wrote:
Можно ли на одну линию RS485 вешать несколько станций?
Можно, если мастер/сервер один, а судя по схеме он один. Хотя в таком случае нужна адрессация внутри протокола, чего там нет.
"shdimka" wrote:
Каким образом можно идентифицировать станцию куда приходит запрос? Сейчас я не вижу такой возможности в протоколе SelfSystem.
Так ли это?
Да, нет там такого поскольку он не предусматривался для работы по "сырым" каналам и там адрессации внутри нет, хотя добавить принципиально можно.
Learn, learn and learn better than work, work and work.
|
|
Written on: 23. 05. 2014 [15:32]
|
|
shdimka
Дмитрий Шабунов
Topic creator
registered since: 05.12.2011
Posts: 35
|
Спасибо за ответы.
Если можно помогите разобраться с настройками последовательного транспорта. На скорости 115200 работает на расчетных таймаутах. Если выбираю меньшую скорость то связь пропадает. Диагностирую соеденение и обнаруживаю такую вещь.
Запрос:SES_OPEN root ХХХХХ
Ответ: REZ 0 1628170108
Запрос: REQ 16 114 <CntrReqs path="/DAQ/"><get path="/JavaLikeCalc/date_time/time/%2fserv%2fattr" hostTm="1" sepReq="0" /></CntrReqs>
Здесь некорректно считался номер сессии и поэтому запрос пошел не с тем номером, на что получаем логичный ответ
REZ 1 Auth error. Session no valid.
Проверяю на вкладке исходящего транспорта последовательного интерфейса, Запрос "SES_OPEN root ХХХХХ". Если не ставить галочку Wait timeout то ответ получаю тот же, если стоит галочка, то ответ получаю с корректным номером сессии. Изменение значения время символа результатов не дает. В чем может быть проблема?
|
|
Written on: 23. 05. 2014 [18:21]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3747
|
"shdimka" wrote:
Если можно помогите разобраться с настройками последовательного транспорта. На скорости 115200 работает на расчетных таймаутах. Если выбираю меньшую скорость то связь пропадает. Диагностирую соеденение и обнаруживаю такую вещь.
Запрос:SES_OPEN root ХХХХХ
Ответ: REZ 0 1628170108
Запрос: REQ 16 114 <CntrReqs path="/DAQ/"><get path="/JavaLikeCalc/date_time/time/%2fserv%2fattr" hostTm="1" sepReq="0" /></CntrReqs>
Здесь некорректно считался номер сессии и поэтому запрос пошел не с тем номером, на что получаем логичный ответ
REZ 1 Auth error. Session no valid.
Трудно сказать, трейсить нужно, как минимум включением режима "Отладки", хотя как раз и похоже на искажение данных.
"shdimka" wrote:
Проверяю на вкладке исходящего транспорта последовательного интерфейса, Запрос "SES_OPEN root ХХХХХ". Если не ставить галочку Wait timeout то ответ получаю тот же, если стоит галочка, то ответ получаю с корректным номером сессии. Изменение значения время символа результатов не дает. В чем может быть проблема?
В непонимании процесса.
В этой вкладке, ручной режим, флаг "ожидать таймаута" ставить нужно всегда, особенно для Serial, поскольку здесь ничего про структуру запроса функция отправки не знает, а значит и размера проверить не может.
Кстати именно на запросе "SES_OPEN" протокол SelfSystem не проверяет полноту ответа поскольку, опять же, не рассчитан на Serial, где даже такие посылки уже длинные и могут приходить частями. Позже добавлю проверку и дожидание ответа по этому запросу, да и по всем тоже, поскольку даже заголовок REQ запроса может прийти частично, что не позволит определить размера.
Learn, learn and learn better than work, work and work.
|
|
Written on: 24. 05. 2014 [16:37]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3747
|
"roman" wrote:
Кстати именно на запросе "SES_OPEN" протокол SelfSystem не проверяет полноту ответа поскольку, опять же, не рассчитан на Serial, где даже такие посылки уже длинные и могут приходить частями. Позже добавлю проверку и дожидание ответа по этому запросу, да и по всем тоже, поскольку даже заголовок REQ запроса может прийти частично, что не позволит определить размера.
Добавил!
Learn, learn and learn better than work, work and work.
|
|
Written on: 27. 05. 2014 [14:06]
|
|
shdimka
Дмитрий Шабунов
Topic creator
registered since: 05.12.2011
Posts: 35
|
Спасибо. Обновлю систему, проверю что получилось.
Достаточно долго уже слежу за проектом и очень приятно что вы его поддерживаете и имеете терпение и силы отвечать на все вопросы.
Очень надеюсь что это продлится еще долго.
|
