| Автор |
Сообщение |
|
Сообщение создано: 16. 05. 2014 [12:57]
|
|
shdimka
Дмитрий Шабунов
Создатель темы
Зарегистрирован(а) с: 05.12.2011
Сообщения: 35
|
Возможно ли получение данных со станции через поледовательный интерфейс используя транспорт последовательный порт?
На данный момент получаю данные используя сокет, необходимо подключить аварийный канал через последовательный порт.
Пытался создать хост и тип транспорта последовательный порт. На удаленной станции настроен входной транспорт через последовательный порт SelfSystem протокол. При проверке связи получаю ответ REZ 3 co.
|
|
Сообщение создано: 16. 05. 2014 [16:48]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"shdimka" wrote:
Возможно ли получение данных со станции через поледовательный интерфейс используя транспорт последовательный порт?
Данные вообще — да.
DAQGate гипотетически тоже, но сам используемый им протокол "SelfSystem" не предусматривает контроля целостности данных, без которого в Serial могут быть проблемы.
"shdimka" wrote:
Пытался создать хост и тип транспорта последовательный порт. На удаленной станции настроен входной транспорт через последовательный порт SelfSystem протокол. При проверке связи получаю ответ REZ 3 co.
Типовая настройка таймаутов, а конкретно здесь увеличить время символа.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 23. 05. 2014 [09:30]
|
|
shdimka
Дмитрий Шабунов
Создатель темы
Зарегистрирован(а) с: 05.12.2011
Сообщения: 35
|
В принципе работает. На скорости 115200 даже данные обновляются корректно с типовыми таймаутами. Проблема неправильного ответа в том что я не поставил галочку выжидать таймаут.
Тоесть между двумя станциями вопросов нет, указываю одновременно 2 типа транспорта, последовательный и сокет и при выпадании одного из них данные все равно передаются.
Вопрос по добавленной схеме. Имеет ли место жить такая схема. Можно ли на одну линию RS485 вешать несколько станций? Пока не представляю каким образом возможно использование несколькими станциями одного канала.
При программировании микроконтроллеров для работы на линии RS485 мне приходилось программно идентифицировать запросы по ID номеру присвоенному конкретному микроконтроллеру и так как один только был инициализатором запросов то конфликтов не возникало.
В моем понимании, станция оператора инициализирует запросы, и я так понимаю что запросы к станциям будут идти последовательно и в теории конфликтов в канале не должно быть если выдерживать необходимую задержку.
Каким образом можно идентифицировать станцию куда приходит запрос? Сейчас я не вижу такой возможности в протоколе SelfSystem.
Так ли это?
Вложенный файл
Drawing1.jpg (Тип файла: image/jpeg, Размер: 30.3 килобайт) — 1772 загрузок
|
|
Сообщение создано: 23. 05. 2014 [13:20]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"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.
|
|
Сообщение создано: 23. 05. 2014 [15:32]
|
|
shdimka
Дмитрий Шабунов
Создатель темы
Зарегистрирован(а) с: 05.12.2011
Сообщения: 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 то ответ получаю тот же, если стоит галочка, то ответ получаю с корректным номером сессии. Изменение значения время символа результатов не дает. В чем может быть проблема?
|
|
Сообщение создано: 23. 05. 2014 [18:21]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"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.
|
|
Сообщение создано: 24. 05. 2014 [16:37]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"roman" wrote:
Кстати именно на запросе "SES_OPEN" протокол SelfSystem не проверяет полноту ответа поскольку, опять же, не рассчитан на Serial, где даже такие посылки уже длинные и могут приходить частями. Позже добавлю проверку и дожидание ответа по этому запросу, да и по всем тоже, поскольку даже заголовок REQ запроса может прийти частично, что не позволит определить размера.
Добавил!
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 27. 05. 2014 [14:06]
|
|
shdimka
Дмитрий Шабунов
Создатель темы
Зарегистрирован(а) с: 05.12.2011
Сообщения: 35
|
Спасибо. Обновлю систему, проверю что получилось.
Достаточно долго уже слежу за проектом и очень приятно что вы его поддерживаете и имеете терпение и силы отвечать на все вопросы.
Очень надеюсь что это продлится еще долго.
|
