SysLibCom.lib помощ

Доброго времени суток!

При подключении к контроллеру ПЛК160-220.А-М внешнего устройства, обменевающегося данными через COM порт, возникли некоторые трудности.
Обмен состоит из посылки в устройство команды, приема команды устройством и выдачи некоторого ответа.

При подключении этого устройства непосредственно к COM порту персонального компьютера, и тестировании программами-терминалами COM порта устройство работает как надо. Т.е. принимает команды и выдает ответы.

В приложении частично работоспособный проект.
По идеи при срабатывании пятого либо шестого дискретного входа должна осуществляться передача команды устройству и прием ответа. Но в режиме CoDeSys Login в значениях переменных видно, что ответ приходит только после двукратного сработывания дискретного входа. Т.е. в собранной установке необходимо подать "1" на каой-либо вход дважды.
Еще один момент заключается в том, что переменная, в которую записывается принемаемые данные заполняется всяким мусором. Если получем 10 символов, а в следующем сеансе 3 символа, то в переменной остаются 10 символов и перезаписывается первых 3 символа.

С уважением.

1) Прежде чем работать с портом, необходимо очистить буфер. Необходимо прочитать из буфера все, и только потом делать обмен.
2) Время цикла стоит ставить 5-10 мс при работе с данной библиотекой.

Цитата:

---

Сообщение от Александр Приходько

2) Время цикла стоит ставить 5-10 мс при работе с данной библиотекой.

---

1.+
2.-
Ставил от 0 (плк110) до 2. Все работает.
По ходу сидит на прерываниях, поэтому время между циклами не критично.
Вывод - делал обмен в обе стороны модбас-пакетами с реальным временем отправки 20..30мс. При этом цикл - 1мс. Все работает.

Просто не надо в кинув что-то в порт в этом же цикле ждать ответ, рекомендую использовать один буфер и для чтения и для записи, читать из него только когда в нем чего-то реально появится, и сохранять данные в отдельный буффер,и не забывать, что syscomread не обязан в конец данных нулик писать. Набор байтов это не asciiz.

PS
А попытки дискретным входом так управлять обменом - бред.

Цитата:

---

Сообщение от Александр Приходько

Прежде чем работать с портом, необходимо очистить буфер. Необходимо прочитать из буфера все, и только потом делать обмен.

---

Нигде не нашел информации как очистить буфер.
Так же не совсем понял смысл второго предложения. Ведь прежде чем прочитать из буфера что-либо туда необходимо что-либо записать, а запись происходит именно при обмене.
Вообще мне не плохо бы поиметь информацию о том, как работать с портами контроллера и как вообще эти порты работают, а найти её не могу.

Цитата:

---

Сообщение от Валенок

Ставил от 0 (плк110) до 2. Все работает.
По ходу сидит на прерываниях, поэтому время между циклами не критично.
Вывод - делал обмен в обе стороны модбас-пакетами с реальным временем отправки 20..30мс. При этом цикл - 1мс. Все работает.

Просто не надо в кинув что-то в порт в этом же цикле ждать ответ, рекомендую использовать один буфер и для чтения и для записи, читать из него только когда в нем чего-то реально появится, и сохранять данные в отдельный буффер,и не забывать, что syscomread не обязан в конец данных нулик писать. Набор байтов это не asciiz.

---

Если честно, то я немного новичёк. Нутром чую, что Вы написали что-то важное, но вот пока в сленге не силён.

Цитата:

---

Сообщение от Валенок

А попытки дискретным входом так управлять обменом - бред.

---

Почему бред? Вроде все логично. Например, тара приехала на весы и замкнула конечник. Это замыкание для контроллера является сигналом к действию - он начинает опрашивать весы на предмет того сколько на них положено. Полученные контроллетом от весов данные с тановятся видны в SCADA (хотя SCADA это уже другая песня).

С уважением.

Что касается чистки буфера - командой syscomread делаете чтение, пока буфер не станет пустым, либо другой вариант -нажать кнопку сброс(но этот вариант не прокатит, не будете же вы все время стоять у плк). Поэтому прежде чем слать запрос, делаете чтение пока данная команда не будет возвращать 0 прочитанных байт.

Далее вам необходимо сформировать команду,
далее ее отправить
и только потом читать ответ.

Что касается разделения по времени записи и чтения - ПЛК необходимо разделить чтение и запись в разные циклы. Чтобы это сделать можете использовать оператор Case. Каждое из условий будет выполняться в разном цикле.

Если совсем примитивно, то ваша программа выглядит так:

Case stat of

0:
"Читаем буфер"
Если буфер пуст, то stat:=1;

1:
"Формируем команду для записи"
stat:=2;

2:
"Шлем команду в порт"
Если число отправленных байт совпадает с длинной команды, то stat:=3;
3:
"Читаем информацию из порта"
Далее организуете либо побитный анализ ответа, либо ждете пока не придет вся команда, и ее анализируете. Тут все в ваших руках
если ответ принят, то stat:=0;


При таком алгоритме вы делаете постоянный обмен, но помните, желательно между запросами ответами делать паузы, чтобы не перегружать линию интерфейса.

Подобные примеры есть на форуме в разделе ПЛК - примеры программ и полезности.Просмотрите несколько последних страниц.


Что касается SysLibCom и времени цикла. Тут, Валенок, я с вами не соглашусь. Имею солидный опыт организации протоколов и работы с портом на прямую. Довольно часто при малом времени цикла SysLibCom в буфере теряет информацию. В свое время смотрели форум Пролога, там данная ветка обсуждалась. SysLibCom в большинстве случаев требуется большой цикл, особенно когда организуется сложный алгоритм приема с анализом ошибок, CRC, и т.п.

В этом плане UNM мне сильно больше нравится.

Теперь снова к нашим зайцам. lpp, отправка запроса непосредственно по кнопке это и в заправду несколько не коректно. Если вам необходимо организовать чтение данных, то делайте это постоянно с периодом в 100-500мс, зависит от вашего девайса. И при таком опросе вы видите что реально с вашими весами происходит, даже когда на них ни чего нет.
А по наконечнику вы можете отрабатывать уже вашу программу дальше, если есть необходимость в этом!

Цитата:

---

Сообщение от Александр Приходько

При таком алгоритме вы делаете постоянный обмен, но помните, желательно между запросами ответами делать паузы, чтобы не перегружать линию интерфейса.

---

как понять что линия перегружена и чем это чревато?
у меня на шине rs485 сидит 6 устройств, у каждого в настройках задержка ответа 5мс, в программе плк интервал между запросом и приемом ответа 1 цикл, время ожидания ответа 150мс, пауза между запросами на разные модули 2 цикла.
и еще вопрос - в вашем примере по нестандартным протоколам все время выделена красным цветом ошибка invalid handle: 0, хотя связь есть, данные приходят без ошибок. в чем смысл этого?

Цитата:

---

Сообщение от Александр Приходько

Что касается SysLibCom и времени цикла. Тут, Валенок, я с вами не соглашусь. Имею солидный опыт организации протоколов и работы с портом на прямую.

---

Наверное мой опыт меньше.Написал собственного мастера и использую только его.при цикле 1-2мс - никаких проблем.

В чем не согласитесь ?
МВА8, 38400, читаю всё за раз - 96 байт. Процесс ответа (именно ответа) - 33мс. Цикл - 1мс. Все работает.
Просто так таймером задерживаю сам цикл до нескольких мс. !! Не вызываю реже, а время цикла удлиняю.Все работает.
Беру ПЛк150 - делаю minlenцикл - 0. Все работает. И демки выкладывал.

Цитата:

---

SysLibCom в большинстве случаев требуется большой цикл

---

Не требует. Уточняю - частота циклов и длинна какого-то существенного влияния на ком-порт не имеют.Не здесь основная часть собаки зарыта.

Цитата:

---

А попытки дискретным входом так управлять обменом - бред.

---

Извините. Погорячился. Я использую несколько иные подходы для обмена.
на invalid handle: 0 не обращайте внимания - обсуждалось.

Цитата:

---

Сообщение от swerder

как понять что линия перегружена и чем это чревато?
у меня на шине rs485 сидит 6 устройств, у каждого в настройках задержка ответа 5мс, в программе плк интервал между запросом и приемом ответа 1 цикл, время ожидания ответа 150мс, пауза между запросами на разные модули 2 цикла.
и еще вопрос - в вашем примере по нестандартным протоколам все время выделена красным цветом ошибка invalid handle: 0, хотя связь есть, данные приходят без ошибок. в чем смысл этого?

---

Увидите сразу пойдут ошибки, прибор не будет отвечать и все в таком духе. Как правило такой эффект наблюдается, если в устройство слать огромное число запросов, а оно не будет успевать на все отвечать. Очень плохое качество обмена будет. Т.к. у вас весы, то можно обмен делать одн раз в 300-500 мс, думаю вполне достаточно.

То что красным подсвечивает, как написал Валенок, внимание просто не обращайте. В самом Codesys значение 0 в данной переменной вроде как не корректно, но для наших устройств RS-485 это именно порт 0.


Валенок, я может немного не корректно выразился. Тут не совсем проблема в SysLibCom, а совокупность времени работы и сетевого обмена.

Как мне показалось библиотека UNM сильно меньше на цикл влияет.

Мне не совсем понятно почему работает программа, которую я выкладывал. В качестве прототипа для разработки я брал пример, расположенные в разделе "ПЛК - примеры программ и полезности".
В описании библиотеки "SysLibCom.lib" сказано, что функции "SysComClose", "SysComSetSettings", "SysComWrite", "SysComRead" работают по дискриптору порта, возвращаемому функцией "SysComOpen", а фактически в программе используется значение перечисления PORTS. Не является ли это ошибкой и не может ли быть причиной некоторых некоректностей при выполнении?

первое - буфер всего 1, размер толи 512 толи 1024 байта.
второе - перед выполнением функции syscomwrite необходимо выполнять syscomread до тех пор, пока возвращаемое значение считанных байт не станет = 0 и только после этого syscomwrite. в противном случае будут возникать ошибки приема либо зависание плк с последующей перезагрузкой.
если ничего не напутано, то вопросы про работу приемника сами отпадают - он просто принимает то что приходит, а анализ буфера выполняется программой.
syscomread и syscomwrite работают с тем портом (номер), который указывается при вызове этой функции.

Цитата:

---

Сообщение от swerder

первое - буфер всего 1, размер толи 512 толи 1024 байта.
второе - перед выполнением функции syscomwrite необходимо выполнять syscomread до тех пор, пока возвращаемое значение считанных байт не станет = 0 и только после этого syscomwrite. в противном случае будут возникать ошибки приема либо зависание плк с последующей перезагрузкой.
если ничего не напутано, то вопросы про работу приемника сами отпадают - он просто принимает то что приходит, а анализ буфера выполняется программой.
syscomread и syscomwrite работают с тем портом (номер), который указывается при вызове этой функции.

---

Уважаемый swerder, вы ответили на мой вопрос про принципы работы порта хотя я, разобравшись, удалил их из своего сообщения. Ниже приведены ссылки на примеры работы с портом. Вместе с одним из примеров дано неплохое описание этих самых принципов.

Инициализация порта
примеры работы с нестандартными протоколами обмена

Все равно спасибо.
С уважением.

Столкнулся с проблемой при реализации нестандартного протокола с уровнемерами. Делаю на ПЛК100 через rs-485 и SysComLib.

Протокол аскишный. Сделал проект на основе примера №2 по ссылке из прошлого сообщения. Проблема в том, что после чтения в буферной строке оказывается мусор, не смотря на то что датчик отвечает правильной длиной (количество реально принятых байт соответствует). Может кто-нибудь что-то посоветует?
Прочитал несколько тем, в том числе и эту. В примерах работа с портом разбита не на 3 цикла а на 2 (чтение и запись, без очистки чтением). Может ли это как-то влиять? Хотя с чтением перед записью я тоже пробовал.
Еще такой вопрос, корректно ли передавать в функцию чтения указатель на строку, а не на массив байтов, как в примере? Не происходит ли тут каких-то сдвигов?

Отвечу сам себе. С SysComLib у меня так и не получилось. Переделал программу на UNM и заработало сразу. Немного пришлось повозиться с адаптацией примеров для SysComLib под UNM. Покопался, но адекватного примера UNM под ST не нашел. Может плохо искал.

Выкладываю блок записи/чтения, который у меня получился. Может кто-то найдет чего в нем можно улучшить.