Ситуация такова: на удалённом объекте есть некий контроллер, который собирает инфу с датчиков, и отдает по RS232. прикрутили к нему mikrotik RB912 - его COM-порту дали remote-accesss, всё как положено.. через 4g/lte и моб. инет по pptp связан с сетью предприятия, на виртуалке крутится scada, которая забирает эти данные с контроллера (у наладчиков такая же "десктопная" на ноуте).
НО: пока микротик "на столе в лаборатории", в локалке, или если приехать на объект с ноутом и воткнуться в него в eth (или даже подцепиться по wifi)- всё прекрасно читается, все хорошо. а вот через pptp всё плохо - то не видит контроллер, то видит, но не видит половины датчиков, даже номера датчиков перевирает безбожно. что только не делали - софту подняли таймауты, меняли симку на другого оператора, с mtu игрались - не помогает.. где могут быть грабли?
PS: есть таки смутное подозрение, что где-то в mtu собака порылась - у eth стандартное mtu 1500, у lte - 1480, а у pptp вообще 1450...
объекте есть некий контроллер, который собирает инфу с датчиков, и отдает по RS232. прикрутили к нему mikrotik RB91
а можно больше подрбностей именно в этой части преобразований, если это rs to usb стоит забыть о перендачэ этого кроме как на usb(com to uart может и переварит но не сеть), в ответе ниже точнее описаны проблемы преобразований поточной передачи с rs232, хотите rs to eth ставте именно его он именно для этого
Ps ограничение на уровне разностей протоколов и их преобразований
Pss rs232(com protocol как и rs485) слишком древний и не преднозначен для интернета, только локалка, и даже там может глючить на bit lock если приемник не настроен на определенный bit rate
Zerg89, нет. никакого usb. еще раз: подключение в eth или по wifi - с rs232 всё читается отлично. подключение "издалека" - через мобильный интернет и туннель pptp - проблемы. Но в этом собственно весь смысл конструкции, ибо объект удаленный, и тянуть туда инет проводами ради считывания данных с несколькими приборами накладно.
контроллер точно modbus rtu гонит, не что-то другое? если да — дело не в mtu, tcp гарантирует порядок и целостность, цифры датчиков сами по себе не должны съезжать. похоже на джиттер lte: modbus rtu режет кадры паузой в 3.5 символа, а rfc2217 (com-порт микротика поверх tcp) эту паузу через pptp+мобильный теряет, отсюда и путаница с номерами. глянь baud/parity/stop bits с обеих сторон, а по-хорошему поставь на объекте modbus rtu→tcp шлюз вместо прозрачного com-порта, надёжнее выйдет.
там у микротика на порту есть 2 режима - raw и rfc.. пробовал оба - без разницы.
baud/parity/stop bits - проверял, все совпадает... на контроллере не выставишь, на микротике выставлял, чтобы соответствовало.
Вот только твоя зарплата за месяц должна быть выше в несколько, чем стоимость такого шлюза, даже если ты вчерашний студент. И если контора не может себе такой шлюз позволить - значит скорее всего и асушника не может, а тебе повесили на шею задачу не по прямому профилю. Я бы порекомендовал послать нафиг, объяснив, что гонять обмен modbus rtu через интрнет в целом, а тем более через мобильную сеть - шиза.
ADarkin, раз baud совпадает, попробуй прогнать тест без pptp — напрямую по tcp через lte, и подними таймауты/ретраи на скаде. Не выйдет, сними дамп с обеих сторон, сразу будет видно где рвётся rtu-кадр.
О, отлично, MOXA — по сути тот же rtu→tcp шлюз, о котором я говорил: кадры теперь разбираются на месте, а не гоняются raw через pptp+lte, вот путаница с датчиками и пропала.
Пума Тайланд, да, но в том-то и затея была, чтобы не тратить "моху", раз у микротика свой rs232 имеется...потому что она стОит даже больше, чем тот микротик. а умножаем на несколько десятков объектов... :-(
Простой
Сложный
Средний
Простой
