Dmitry.niimm
Junior Member / Новичок
Участник № / Member № 3380
отправлено / posted
Добрый день,
У нас система установлена на пром. компьютере, имеющем встроенный порт RS-485/RS-422. К сожалению, производители компа не озаботились полноценной поддержкой RS-485 по двухпроводной линии, в результате чего после соединения линий "+" и "-" передатчика и приемника (другого варианта нет) имеет место локальное эхо, т.е. все, что передается в линию, одновременно и принимается, причем игры с FlowControl, RTS/CTS и т.п. ситуацию исправить не могут 8-(.
Внимание, вопрос: будет ли в этих условиях работать протокол m-link для связи с контроллером WinCON, который, собственно, и сидит на втором конце кабеля? И если да, то какие дополнительный настройки нужно выставить?
И еще вопрос/непонятка.
Имеем проект с узлами RTM1 и Embedded1, связанными по RS/m-link. В узле RTM1 имеются несколько каналов Output (к примеру, O1 и О2), которые нужно забросить в соответствующие каналы Embedded'а (I1 и I2). Если привязывать как обычно, т.е. I1->O1.R, то при работе по Ethernet все проходит нормально, но в случае m-link такая связка не работает (как я понял, слейв не имеет права давать запросы, а мастер, хоть и знает, что к нему привязан чужой канал, но ему это глубоко фиолетово, т.к. проблемы индейцев шерифа не волнуют).
Попробовал сделать следующим образом: убрал привязку у канала I1, а поставил ее у канала O1, т.е. O1->I1.input (спасибо техподдержке в Киеве, подсказали). Теперь при изменении канала O1 он сам передает новое значение. Но есть и проблемы: а) что делать, если нужно передавать одно и то же значение нескольким клиентам (например, имеется два винкона, и оба нуждаются в каких-то общих настроечных данных), ведь при такой привязке параметр может передаваться только одному адресату? б) как обеспечить передачу параметра при рестарте контроллера, ведь обновление уходит только при изменении значения, а винкон попросить не имеет права? в) как, собственно, обновлять сам канал O1, ведь привязка у него только одна - на выход, а со входом что делать? Неужели тоже принудительно пропихивать? А если нельзя принудительно, например, этот канал получает данные не из экрана, а от генератора или другого устройства? г) (возможно, это что-то у меня в проекте накосячено, но работает у меня именно так, хотя и бред) Итак, по порядку: Работает узел RTM1 (профайлер), значения каналов O1 и O2 - 1 и 2 (по умолчанию). Загружается винкон и стартует узел Embedded1 (тоже профайлер, хотя и в исполнителе получается то же самое). Значения каналов I1 и I2 равны нулю (опять же по умолчанию), признак достоверность - каюсь, не посмотрел. Меняю вручную O1 в RTM1 на 5. У канала I1 атрибут In становится равным 5, R не меняется, достоверность = _F. Закрываю проект Embedded1 и запускаю снова (просто останов и новый запуск проекта не помогает, только выход из программы), и, чудо: I1.R=5, I1.I=_T, при дальнейшем изменении O1.R все исправно передается в контроллер. Но это касается только канала О1 - связка О2/I2 не работает по-прежнему до тех пор, пока не изменим О2 и не перезапустим проект Embedded1, тогда уже оба канала будут работать нормально. НО, если перезагрузить винкон, то опять начнется все сначала.
Сообщения / Posts 19 | Из / From: Украина
| IP / IP: IP адрес / IP address |
отправлено / posted
Не совсем понятна реализация физической линии связи, но для корректной работы протокола M-link эхо нужно убрать.
А) Для передачи данных нескольким клиентам необходимо будет создать несколько соответствующих каналов. Б) Отслеживать Master-ом статус Slave и принудительно отрабатывать необходимые каналы. К тому же при отсутствии связи при изменении параметра на Master, он будет производить посылки пока не получит подтверждение от Slave, соответственно при старте данные в Slave автоматически обновляться. В) Привязка канала Output указывает куда будут передаваться данные с этого канала. Б) Присылайте ваш проект с подробным описанием на hotline-ua@tracemode.com - по всей видимости, что то напутано с привязками.
Сообщения / Posts 58 | Из / From: Украина
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
