заходим http://www.kipshop.ru/CoDeSys/steps/codesys_v23_ru.pdf на страницу 349, там показана работа таймера в виде эпюр, которые должны объяснить работу таймера, чтоб поднять выход Q
заходим http://www.kipshop.ru/CoDeSys/steps/codesys_v23_ru.pdf на страницу 349, там показана работа таймера в виде эпюр, которые должны объяснить работу таймера, чтоб поднять выход Q
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Спасибо) но книгу я в голове держу, с пониманием проблемы нет. В целом к этому посту я уже разобрался что блок MB_UNI_IO держит строку tonTimer(); для двух случаев.
1. Это когда мы не принимаем данные, а только передаем. Тогда у нас таймер отработает с параметром TimeOut который мы передадим в ФБ. Т.к MB_RTU_RX вернет wait и DataSize будет больше 5 если все удачно передали. И по его выходу завершит работу ФБ.
2. И когда мы принимаем данные, он уже отработает с параметром T_FRTU как только функция MB_RTU_RX перестанем принимать байты из порта. И тогда через +-3мс закончится работа всего ФБ.
Собственно со всем этим ужасом я начал банально разбираться из-за 255 ошибки. И вывод тут один. Если вы читаете со слейва данные но получаете 255 и при этом 100% слейв работает адекватно и шлет все как надо(да и порт у нас RS485, на 232 проблемы не будет). Тут скорее всего проблема в том что слейв умудряется ответить быстрее чем за 5мс. Т.к. функция передачи в порт SysComWrite после передачи последнего байта еще гдето 5мс держит уровень на линии. И в этот момент ответ не возможен. В моем случае это помогло.
P.S. у ФБ SysComWrite , есть также таймаут который судя по документации определяет время которое ФБ шлет данные в порт. По факту меняй не меняй его ничего не меняется.