могу рекоммендовать фаильтровать данные на входе. RS допускает потерю, коллизию 0.3% пакетов.
кстати, если Вы не поставите условие записи уставки в коде, что приложили и будете его вызывать циклично, Вы в скором времени потрёте память прибора
могу рекоммендовать фаильтровать данные на входе. RS допускает потерю, коллизию 0.3% пакетов.
кстати, если Вы не поставите условие записи уставки в коде, что приложили и будете его вызывать циклично, Вы в скором времени потрёте память прибора
Спасибо. условие записи сделал. Ошибки при чтении идут постоянно дело наверно не в коллизиях.
изначально пропустил настройку порта
Settings.dwTimeout:=20; - сделайте равный нулю, так пойдёт лучше. на практике с таймаутом возникают ошибки, нужна тонкая настройка, с нулём будет лучше.
также советую в вашем коде, между запросами сделать шаги паузы на 10 мс, например
step_pause(IN := TRUE , pt:= t#10ms);
IF step_pause.Q THEN
state := следующий шаг;
step_pause(IN :=FALSE);
END_IF
для RTU это поможет исключить необходимые тайминги времени между фреймами.
Вы только с ТРМ-ами настраиваете обмен?
Таймаут убрал,но не помогло. Проблема была в том что надо читать из буфера по флагу Complete. Помимо ТРМ три модуля ввода аналоговых и один дискретный вывода.
кто гарантирует что драйвер девайса работает идеально, т.е. с задержками не заметными программисту плк?
на своём опыте встречал и энергоанализаторы и считыватели магнитных карт ( aka RFID ) которые.. хммм, зачем то физически удерживали шину 485ого чуть ли не до 30 мс после таймаута фрейма(согласно протоколу). упс, такая реализация, говорили они. а выявить это только на осцилографе можно было.
я лишь стараюсь донести мысль о том, что такое может иметь место. и осознание необходимости "ручной" задержки, иногда идёт во благо всей системе
по второму пункту - лучше использовать с ними ASCII, имхо.
Почему при попытке чтения регистров с помощью MB_RD_HOLD_REGS при опросе более 46 регистров начинают идти ошибки?