Свободное чтение RS-485

Вид для печати

Показывать 40 сообщений этой темы на одной странице

22.06.2022, 11:32
Raikkonen

Цитата:

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

Ну это не корректно. Такое чтение превратит буфер в мусор.

А я планировал читать по двукратному объему информации, и как только считал меньше чем нужно - беру предыдущий кусок, который содержит в себе 2х инфы, где точно есть нужный мне пакет.
22.06.2022, 11:41
Samel

Цитата:

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

А я планировал читать по двукратному объему информации, и как только считал меньше чем нужно - беру предыдущий кусок, который содержит в себе 2х инфы, где точно есть нужный мне пакет.

А где хранится что считал раньше? Простая задача очень усложняется! В этой задаче главный вопрос цикл вызова функции Read!
22.06.2022, 11:44
melky

Если есть какой-то функционал остановки опроса и известен конец, то да, можно считывать с Х байта, ловить конец, проверять весь ли пакет попал в чтение и либо уже дочитывать новый пакет, либо разбирать полученное.

з.ы. подозреваю, что на ПЛК так быстро такие вещи не сделать, проще читать 2х пакета и искать начало и конец., надо прикинуть будет ли в этом случае коллизии, но вроде не должны. Либо два пакета будут полными, либо будет 1 обрезок + полный + 2 обрезок.
22.06.2022, 11:51
Samel

Цитата:

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

Если есть какой-то функционал остановки опроса и известен конец, то да, можно считывать с Х байта, ловить конец, проверять весь ли пакет попал в чтение и либо уже дочитывать новый пакет, либо разбирать полученное.

з.ы. подозреваю, что на ПЛК так быстро такие вещи не сделать, проще читать 2х пакета и искать начало и конец., надо прикинуть будет ли в этом случае коллизии, но вроде не должны. Либо два пакета будут полными, либо будет 1 обрезок + полный + 2 обрезок.

А какие проблемы сделать это на ПЛК. Читай из буфера с циклом 5 мс, формируй свой буфер и ходи по ниму ищи свой пакет
22.06.2022, 12:02
melky

Samel честно не знаю можно ли. например в RapidScada разработчик по моей просьбе дорабатывал код остановки опроса, можно посмотреть у него в исходниках. Но вот под силу такое ПЛК, который кроме опроса еще должен заниматься кучей других дел ? На ПК то это в потоке отдельном работает.... А то тоже была с подобным проблема, потому что в протоколе не было фиксированной длины данных, пакеты из-за этого могли быть разной длины и не поддавались рассчету.
22.06.2022, 12:12
Samel

Цитата:

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

Samel честно не знаю можно ли. например в RapidScada разработчик по моей просьбе дорабатывал код остановки опроса, можно посмотреть у него в исходниках. Но вот под силу такое ПЛК, который кроме опроса еще должен заниматься кучей других дел ? На ПК то это в потоке отдельном работает.... А то тоже была с подобным проблема, потому что в протоколе не было фиксированной длины данных, пакеты из-за этого могли быть разной длины и не поддавались рассчету.

У меня никогда не было проблем разбирать пакеты разной длины.
Скорость, частота посылок, предпологаемы объем данных -> время цикла задачи
23.06.2022, 09:39
melky

Валенок если правильно понял, то что-то было связано с Виндовым кодом работы с портом (NET Framework), нужно задать размер обязательно, и если мы задаем размер заведомо больше, чтобы все влезло, а пакет короткий по факту, привет Timeout.... По этому остановка была софтовая...

Дальше не вдавался в подробности почему, разработчик помог решить задачу, и ладно...

Если ПЛК аналогично может читать и сразу проверять, то отлично, можно реализовать по аналогии.
Как-то мне в голову не придет, реализовывать протокол Allen Bradley на ПЛК, там застрелиться проще... :)
28.06.2022, 16:14
Sergey666

Цитата:

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

Как-то мне в голову не придет, реализовывать протокол Allen Bradley на ПЛК, там застрелиться проще... :)

А можно подробнее, в целях повышения образованности, что это за протокол "Allen Bradley"???
28.06.2022, 18:12
melky

Sergey666 DF1 (тоже RS485), переменная длина пакета, два вида контрольных сумм, при этом отличается состав пакета для проверки контрольной суммы и многое другое.
Хотя если их ПЛК вполне справляется с задачей, то возможно и другой справится, но боюсь там это реализовано на уровне прошивки самого ПЛК а не программы.
28.06.2022, 18:21
keysansa

Цитата:

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

Был в отпуске. У меня дозирование.

Я не пойму самого главного - когда я использую Read - я из начала или из конца буфера читаю?

Буфер=очередь, стек, FIFO, FILO почитайте. Обязательно.
28.06.2022, 18:35
keysansa

Цитата:

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

Ну в целом да, получается это очередь а не стек.
А как тогда мне лучше производить чтение чтобы получать данные ближе к последним?
В одном цикле можно делать много чтений?
типа:

Код:

while SysComRead(com_settings.Port,ADR(buffer[1]),50,0) > 0 do (*не важно какая обработка*) end_while

??

У вас дозирование. Вам надо реагировать на изменение веса как можно чаще. Это при взвешивании, можно себе позволить небольшую паузу.
Выделяйте для обмена отдельный поток, с минимальным временем цикла там только опрашивайте, и присваивайте глобальную переменную: "текущая масса". Если не успеваете, надо взять процессор помощнее или снизить частоту посылок. Чем чаще вы узнаете вес при дозировании, тем лучше.

Цитата:

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

(*не важно какая обработка*)

Важно. Тут максимум - string -> int.
30.06.2022, 09:29
Samel

Кратко и по существу :)
02.07.2022, 18:49
keysansa

Цитата:

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

Чаще чем всё - не получится, но тута это не нужно - как-нить/что-нить выдернуть и так пойдет. Говорилось. Угрожали забанить ))

А все и не надо. Необходимо, что бы время реакции системы было в 2-3 раза больше, чем поток дозирования в отношении к допустимой точности дозирования.

Цитата:

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

Здесь их нет если только не про задачи, но манипуляции с кнопочками калькулятора подсказывают что и без всяких задач - без проблем. Даже всё, несмотря на.

Задачи запускаются отдельным потоком.
02.07.2022, 18:50
keysansa

Цитата:

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

Чаще чем всё - не получится, но тута это не нужно - как-нить/что-нить выдернуть и так пойдет. Говорилось. Угрожали забанить ))

А все и не надо. Необходимо, что бы время реакции системы было в 2-3 раза больше, чем поток дозирования в отношении к допустимой точности дозирования.

Цитата:

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

Здесь их нет если только не про задачи, но манипуляции с кнопочками калькулятора подсказывают что и без всяких задач - без проблем. Даже всё, несмотря на.

Задачи запускаются отдельным потоком.

Цитата:

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

Лично я не совсем тут понял - что это.

Чаще всего, весовые терминалы отправляют "plain" данные, в виде строки.
02.07.2022, 22:14
keysansa

Цитата:

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

Разброд и шатания :

или
?

Вы не чувствуете разницы между "как можно чаще" и "все"? Или у вас "разброд и шатание" сегодня?
Чем чаще вы снимаете данные с АЦП тензодатчика (ограничено скоростью преобразования АЦП), чем чаще вы получите данные в контроллере, и тем быстрее сможете отреагировать на заданный вес (ограничено скоростью контроллера, временем срабатывания исполнительных устройств, количеством материала, который уже невозможно остановить).
Конечно, если дозировать 2гр/мин при допустимой точности в +/-2 кг, можно и не торопиться. В дозу попадём. Видимо вы в таких условиях и работаете. Но у меня скорости дозирования выше. А так же требования к точности.

Цитата:

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

Это - напрягает.
И вы уже в курсе "допустимой точности дозирования" ?
Где здесь потоки ?

Написал чуть выше, поток в моем примере - 2гр/мин, точность +/- 2 кг. Я считаю, что разбираюсь, пишите аргументы, если не согласны.

Цитата:

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

Тут не нужно гадать - "максимум","чаще всего" и т.п. Тут всё чётко:

Вы видимо много пенистого взяли. )

Цитата:

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

и что там в данных вроде как пофиг

16 байт данных - там актуальное значение веса. Вы думаете Int (float) 16 байт занимает или string?

Цитата:

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

Где здесь потоки ?

Как вы думаете на контроллерах реализуются несколько "задач" с разными циклами?
02.07.2022, 23:39
Samel

Тема превращается во флуд, пора закрывать!!! Нельзя принимать/обрабатывать данные чаще чем они приходят!!! Скорость 115200 размер пакета 22 байта - итого пакет отправляется/принимается за 2 мс, а ещё между пакетами по-любому есть время тишины. Так что 5 мс цикл программы решает все проблем!!! А в 110/160 в 5 мс можно запихнуть огого!!!!
Тема закрыта!
02.07.2022, 23:42
keysansa

Цитата:

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

Тема превращается во флуд, пора закрывать!!! Нельзя принимать/обрабатывать данные чаще чем они приходят!!! Скорость 115200 размер пакета 22 байта - итого пакет отправляется/принимается за 2 мс, а ещё между пакетами по-любому есть время тишины. Так что 5 мс цикл программы решает все проблем!!! А в 110/160 в 5 мс можно запихнуть огого!!!!
Тема закрыта!

То, что вы не понимаете, что тут обсуждается, не значит, что это флуд.
02.07.2022, 23:48
Samel

Цитата:

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

Добрый день всем!
Имею устройство, которое 24/7 без смс и регистрации отправляет по 485 портику на скорости света 115200 посылку вида:

байт FF
байт 03 (типа его адрес)
байт CC (типа функция)
16 байт данных
байт контрольной суммы CRC
байт FF
байт FF

итого 22 байта.

я уже все это получаю и разбираю следующим кодом:

Код:

PROGRAM com_read_prg VAR com_settings: COMSETTINGS; com_service_fb: COM_SERVICE; com_port_num: PORTS := 0; com_port_ready: BOOL; bytes_read: DWORD; buffer: ARRAY [1..50] OF BYTE; package: ARRAY [1..22] OF BYTE; p_pointer: POINTER TO ARRAY [1..22] OF BYTE; i,ii: INT; weight: weight_package; p1: POINTER TO BYTE; END_VAR IF com_service_fb.ready=FALSE THEN com_settings.Port:=com_port_num; com_settings.dwBaudRate:=115200; com_settings.byParity:=0; com_settings.dwTimeout:=0; com_settings.byStopBits:=0; com_settings.dwBufferSize:=0; com_settings.dwScan:=0; com_service_fb(Enable:=TRUE, Settings:=com_settings, Task:=OPEN_TSK); com_port_ready:=FALSE; ELSE com_service_fb.Enable:=FALSE; com_port_ready:=TRUE; END_IF IF com_port_ready THEN bytes_read := SysComRead(com_settings.Port,ADR(buffer[1]),50,0); (*каждый цикл читаем 50 байт данных потому что в них я точно найду нужные мне 22 байта*) IF bytes_read > 0 THEN (*если что-то нашли*) FOR i:=1 TO 28 DO (*то начинаем искать совпадение*) IF (buffer[i] = 16#FF) AND (buffer[i+1] = 16#03) AND (buffer[i+2] = 16#CC) AND (*не парюсь ищу совпадение по началу и концу которые всегда одинаковые*) (buffer[i+20] = 16#FF) AND (buffer[i+21] = 16#FF) THEN p_pointer := ADR (buffer[i]); (* если нашли то при помощи указателя*) package := p_pointer^; (*копируем найденное в массив ровно на 22 байта, это я потом чтобы контрольную сумму считать*) p1 := ADR(weight.ch1); (* weight - это структура тупо из 8 UINT, поэтому я свой массив перевожу в уинт чтобы далее его использовать*) FOR ii:=4 TO 19 DO p1^ := package[ii]; p1 := p1+1; END_FOR EXIT; END_IF END_FOR END_IF END_IF

И у меня возникло несколько вопросов:
1. Так как скорость 115200, я думаю считывая по 50 байт каждый цикл (50 мсек), мне кажется рано или поздно случится переполнение буфера?

Я не очень понимаю как этот буфер устроен.
2. Не понимаю - я читаю данные из конца или из начала этого буфера?
3. Вроде как прочитанные данные из буфера стираются, это так или не очень?

Анализируя данные в буфере я обратил внимание что посылки бывают кусками, хотя по факту я на 100000000000000% уверен что они всегда ровненькие и одинаковые
4. Почему в буфере могут быть обрывки? это потому что я своими 50 байтами там оставляют объедки от них?

Ну и самый главный вопрос - если у кого-то есть бесплатные идеи по оптимизации - готов бесплатно их выслушать =)
Или в целом концепция как лучше поступить в моей ситуации - просто слушать эти 22 байта

Мне казалось что обсуждалось это. Так на эти вопросы ответы уже даны! Все остальное флуд
03.07.2022, 00:12
keysansa

Это не вам, а ТС решать ))
03.07.2022, 15:08
Валенок

Ну пофлудим

Цитата:

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

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

Кто-то с этим спорит ? Ранее сказано - "Чаще чем всё - не получится" - чтo-то не так ? теперь получится ?

Цитата:

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

.. можно и не торопиться. В дозу попадём. Видимо вы в таких условиях и работаете..

Ну ? Что-то как-то выдернем и так пойдет. Не ? Ведь - да :

Цитата:

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

.. Вес измерять чаще чем раз в 20 сек смысла нет...

но

Цитата:

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

.
Я хочу просто быть уверенным в:
1. Не наступит переполнения буфера
2. Я получаю последние данные, а не те что дольше всех в буфере..

Получая всё - получается максимум уверености. А юзать можно и раз в год коли чаще смысла нет.

Цитата:

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

Написал чуть выше, поток в моем примере - 2гр/мин, точность +/- 2 кг. Я считаю, что разбираюсь, пишите аргументы, если не согласны.

Про пример - понятно. А тута точно всё точно ?

Цитата:

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

..Необходимо, что бы время реакции системы было в 2-3 раза больше, чем поток дозирования в отношении к допустимой точности ...

Цитата:

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

16 байт данных - там актуальное значение веса. Вы думаете Int (float) 16 байт занимает или string?

Я думаю ? Оно мне надо ? Стынет же. 16 байт - это просто данные. Про это - есть.
А Вы накой-то додумываете. Может и угадали ..:

Цитата:

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

Код:

PROGRAM com_read_prg VAR ... package: ARRAY [1..22] OF BYTE; p_pointer: POINTER TO ARRAY [1..22] OF BYTE; ... weight: weight_package; p1: POINTER TO BYTE; END_VAR ... p_pointer := ADR (buffer[i]); package := p_pointer^; (*копируем найденное в массив ровно на 22 байта...*) ... p1 := ADR(weight.ch1); (* weight - это структура тупо из 8 UINT, поэтому я свой массив перевожу в уинт...*) FOR ii:=4 TO 19 DO p1^ := package[ii]; p1 := p1+1; END_FOR ..

А может и нет )) Только время на гадания тратили.

Цитата:

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

Как вы думаете на контроллерах реализуются несколько "задач" с разными циклами?

Где здесь потоки ? (2й раз) Прямых данных от ТС нет, но раздел про ПЛК110[М02] а не абстрактные "контроллеры"

ps

Цитата:

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

Вы видимо много пенистого взяли. )

Бывает - много 8( ??? Вы точно не с планеты эльфов ? Всегда мало !!
04.07.2022, 22:12
keysansa

Цитата:

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

Кто-то с этим спорит ? Ранее сказано - "Чаще чем всё - не получится" - чтo-то не так ? теперь получится ?

Боже, наконец-то я понял, что вы хотели написать ) Так бы сразу и сказали, чаще, чем остальной ввод/вывод (а то - никогда не говори никогда - какое-то )) ). Про Овен - не знаю, но в других системах это возможно, про прерыванию АЦП (готовность данных), остальной В/В при этом мне не нужен, нужен только 1 выход, который управляет потоком. Остальной ввод/вывод может работать гораздо медленнее.

Цитата:

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

Ну ? Что-то как-то выдернем и так пойдет. Не ? Ведь - да :

На этапе проектирования часто кажется, что хватит...

Цитата:

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

Про пример - понятно. А тута точно всё точно ?

Начинается... Цепляемся к мелочам. Хороший подход. "Время реакции меньше" - лучше звучит? На мой взгляд - нет.

Цитата:

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

Я думаю ? Оно мне надо ? Стынет же. 16 байт - это просто данные. Про это - есть.
А Вы накой-то додумываете. Может и угадали ..:

Вам непонятно было, что я имею ввиду под фразой "там преобразование string - int". Я объяснил. Перечитайте.
Не хотите тратить время - не тратьте.

Цитата:

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

Где здесь потоки ? (2й раз) Прямых данных от ТС нет, но раздел про ПЛК110[М02] а не абстрактные "контроллеры"

Я уже объяснил, почитайте мое предыдущее сообщение. У ТС это нет, это только мое предложение (в сообщении через одно до этого).

ЗЫ.

Цитата:

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

Бывает - много 8( ??? Вы точно не с планеты эльфов ? Всегда мало !!

[/QUOTE]
Мне пиво тоже нравится. Именно тем, что слишком много его не выпить - в отличие от водки, которая при превышении нормы - просится наружу, пиво - тупо не лезет ))) Но когда оно уже не лезет - это много.

Показывать 40 сообщений этой темы на одной странице