CODESYS V3.5. Вопросы и ответы

[Петр Петрович]

> может, уже в конце концов, заняться инициатором посылок
Увы, это законченное изделие. Можно конечно от него отказаться, но где гарантия, что подобная ситуация, при расширении сферы применения CDS не встретится с другим устройством или у кого-то еще? Решение-то ведь напрашивается простое - буфер. Тем более, что переполнение его маловероятно, т.к. между сообщениями имеются изрядные "окна". По сути, это некая задача об обслуживании. Т.е. буфер делает обработчик (контроллер) более универсальным, как ни крути.

Еще интересный момент. В CODESYS ведь есть для главной задачи не только Циклическое выполнение, но и по "Cобытию". Но, т.к. принимающий данные блок, по крайней мере из библиотеки NBS, работает "не сам по себе", а требует циклического вызова, то это опять ничего не дает. А так, вообще было бы интересно - вызов задачи управлялся бы потоком данных. Почему бы и нет? В ряде применений это было бы очень эффективно.

[capzap]

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

[Петр Петрович]

>так какие проблемы, если вы сейчас в непонятках, вместо законченного изделия поставили программный эмулятор и экспериментируйте на здоровье, чтоб выяснить кто же в конечном итоге виноват
В том то и дело, что уже на 99,99% понятно, что в крайне редких случаях (1-2 раза в день) информация о нажатой кнопке в входном массиве байт затирается следующей порцией данных (случайным образом меняющийся уровень принимаемого сигнала), которая начинается опять с нулевого элемента массива. Если бы данные просто клались после принятых ранее, я бы успел их быстренько вытащить и обработать без потерь. Можно, конечно, еще сократить время цикла - но это не гарантия. Судя по некоторым данным, между передачами промежуток в особо неблагоприятных случаях бывает не более 1 мс. А потом может быть окно и в десятки миллисекунд. Вообще, мне кажется буфер это насторлько фундаментальная вещь, что без него не работает ни один современный коммутатор Ethernet например. Конечно, там работа с буферами вообще высший пилотаж, она и определяет совершенство коммутатора в конечном итоге. Мой же случай - простейший. Но почему-то думается, что он не уникален. Если этого у других не было, не факт, что не будет. Понятно, что правильные протоколы позволяют нивелировать эти эффекты, но при возрастании нагрузки не контроллер могуть быть скажем так подобные "выбросы" глюков, которые не сразу и поймешь отчего.

[capzap]

>так какие проблемы, если вы сейчас в непонятках, вместо законченного изделия поставили программный эмулятор и экспериментируйте на здоровье, чтоб выяснить кто же в конечном итоге виноват
В том то и дело, что уже на 99,99% понятно, что в крайне редких случаях (1-2 раза в день) информация о нажатой кнопке в входном массиве байт затирается следующей порцией данных (случайным образом меняющийся уровень принимаемого сигнала), которая начинается опять с нулевого элемента массива. Если бы данные просто клались после принятых ранее, я бы успел их быстренько вытащить и обработать без потерь. Можно, конечно, еще сократить время цикла - но это не гарантия. Судя по некоторым данным, между передачами промежуток в особо неблагоприятных случаях бывает не более 1 мс. А потом может быть окно и в десятки миллисекунд. Вообще, мне кажется буфер это насторлько фундаментальная вещь, что без него не работает ни один современный коммутатор Ethernet например. Конечно, там работа с буферами вообще высший пилотаж, она и определяет совершенство коммутатора в конечном итоге. Мой же случай - простейший. Но почему-то думается, что он не уникален. Если этого у других не было, не факт, что не будет. Понятно, что правильные протоколы позволяют нивелировать эти эффекты, но при возрастании нагрузки не контроллер могуть быть скажем так подобные "выбросы" глюков, которые не сразу и поймешь отчего.

т.е. на других устройствах типа ПК удавалось прочитать всю информацию от и до?

[Петр Петрович]

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

Кстати, в Crestron подобный подход.

STRING_INPUT some_data$[100]; // Так мы определяем вход для последовательных данных и макисмальный размер.

CHANGE some_data$ // вызов при приеме данных

{

// здесь пишем нужный нам обработчик

}


Еще интересный пример:
BUFFER_INPUT COM$[100]; // Это буферизованный вход, новые данные добавляются к старым
STRING IN$[100];

CHANGE COM$
{
IN$ = GATHER("\n", COM$); // Print сработает только тогда, когда в буфере появиться символ "\n", благодаря "STRING Gather(STRING Delimiter, STRING SourceString [INTEGER TimeOut]);"

PRINT("The value of IN$ is %s\n", IN$);
}

[Евгений Кислов]

А работал ли кто с NBS.TCP_ReadBuffer ? Не знаете случайно, там накапливающий буфер? Можно ли извлечь данные сразу для нескольких посылок от удаленной стороны?

Вопрос сформулирован некорректно - буферизацией данных занимается не NBS.TCP_ReadBuffer.
NBS.TCP_ReadBuffer - это блок, выполняющий операцию чтения из буфера сетевого адаптера.
С его помощью (как, кстати, и с помощью обычного NBS.TCP_Read) можно "извлечь данные сразу для нескольких посылок от удаленной стороны".

[Петр Петрович]

> С его помощью (как, кстати, и с помощью обычного NBS.TCP_Read) можно "извлечь данные сразу для нескольких посылок от удаленной стороны".

Интересно. Пока не нашел, как это сделать. Сложилось впечатление, что NBS.TCP_Read работает так:
1. Вызываем FUNCTION_BLOCK TcpServer
2. IF fbTcpRead.xReady THEN .... Если в этот момент есть поступившие данные, то определяем их длину через Bytes_Read_Count:=fbTcpRead.szCount;
3. Выставляем глобальный флаг, что PLC_PRG следует обработать данные из массива байт abyRx

Вот тут как бы Bytes_Read_Count:=fbTcpRead.szCount указывает на то, что это именно последние данные, прешедшие на момент чтения, а предыдущих данных уже нет,
если их явно не сохранить как-то, разве нет? А как сохранитиь, не понятно. Внутри FUNCTION_BLOCK TcpServer это не сделать, т.к. он сам вызывается периодически. Замкнутый круг.

[Евгений Кислов]

> С его помощью (как, кстати, и с помощью обычного NBS.TCP_Read) можно "извлечь данные сразу для нескольких посылок от удаленной стороны".

Интересно. Пока не нашел, как это сделать. Сложилось впечатление, что NBS.TCP_Read работает так:
1. Вызываем FUNCTION_BLOCK TcpServer
2. IF fbTcpRead.xReady THEN .... Если в этот момент есть поступившие данные, то определяем их длину через Bytes_Read_Count:=fbTcpRead.szCount;
3. Выставляем глобальный флаг, что PLC_PRG следует обработать данные из массива байт abyRx

Вот тут как бы Bytes_Read_Count:=fbTcpRead.szCount указывает на то, что это именно последние данные, прешедшие на момент чтения, а предыдущих данных уже нет,
если их явно не сохранить как-то, разве нет? А как сохранитиь, не понятно. Внутри FUNCTION_BLOCK TcpServer это не сделать, т.к. он сам вызывается периодически. Замкнутый круг.

https://dropmefiles.com/zUdup

[Петр Петрович]

Огромное спасибо. Внимательно изучаю. Пока не понятно только, что фактически отражает fbTcpRead.szCount. По идее, если буфер, то величина этого fbTcpRead.szCount должна увеличиваться. Пока, по крайней мере, буфер не будет очищен (или указатель не будет установлен на начало массива данных). В моем случае, кстати, этот fbTcpRead.szCount все время меняется, в том числе и в меньшую сторону. Бывает, он равен и 2. Это означает, например, что пришла логическая 1 или 0 и индекс сигнала в посылке длиной 2 байта.

[Максим Ульянов]

Доброго Времени Коллеги ! снова появились у меня глупые вопросы ..на это раз не работает Modbus TCP Slave...вернее он вроде бы работает)) но данные с него не читаются...cl1.pngcl2.png
Очень прошу помощи