SysLibCom.lib помощ

[lpp]

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

При подключении к контроллеру ПЛК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
А попытки дискретным входом так управлять обменом - бред.

[lpp]

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

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

Ставил от 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мс, зависит от вашего девайса. И при таком опросе вы видите что реально с вашими весами происходит, даже когда на них ни чего нет.
А по наконечнику вы можете отрабатывать уже вашу программу дальше, если есть необходимость в этом!

[swerder]

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

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

[Валенок]

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

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

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

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

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

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

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

[Александр Приходько]

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

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

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


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

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

[lpp]

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

[swerder]

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