Одновременный прием данных по двум UART в панель СП310

[EFrol]

А если попробовать как обычно:

Receive(PLC,DataReceiveA,6,1000,10);
Receive(DOWNLOAD,DataReceiveB,6,1000,10);

Посылки делать не более 6 байт с периодом не менее 1 сек.
Что получится? По идее оба буфера получат одну и туже посылку.

[zaurm]

Валенок, на оба.

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

[EFrol]

А если каждую команду вызывать в разных макросах с параллельным выполнением?

[Валенок]

.. на оба...

Т.е. на одной линии висят 4 порта - 2 датчики и 2 панельных?
(может все и поняли, я - нет)

[zaurm]

А если каждую команду вызывать в разных макросах с параллельным выполнением?

В этом сообщении вариант 2 — как раз попытка реализовать Вашу идею.

Валенок, на одну линию повесить два датчика можно в том случае, если мы используем порт в режиме RS-485.
В моем случае один порт — один датчик. На два порта (PLC и DOWNLOAD) у меня приходит информация от двух датчиков, каждый датчик на свой порт.

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

[In_Da_Cher_A]

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

[melky]

Написание небольших программ (скриптов) на «СИ» подобном языке значительно расширяет возможности операторского интерфейса.

1. есть ли доступ к портам из скриптов?
2. Собственно хватит ли скорости при работе на скриптах, если это возможно

In_Da_Cher_A думаю что датчики посылают данные на свою "голову" и при этом надо данные от них принять еще и на панель.
Отсюда и требования не переводить датчики в режим slave чтобы делать опрос их со стороны СП

[melky]

4 При работе с портом запросы панели дублируются по обоим интерфейсам. Адресация устройств должна быть уникальной на уровне порта.
5 Доступна работа с COM-портами через макросы, что дает возможность реализации нестандартных протоколов.

а вот сносочка 4 мне не совсем понятна в описании панели ????

[zaurm]

1. есть ли доступ к портам из скриптов?
2. Собственно хватит ли скорости при работе на скриптах, если это возможно

1. Мне известно о возможности доступа только через вызов функции Receive.
2. При работе с одним портом все работает чудесно. Получаем нужное кол-во байт, обрабатываем, выводим на экран.
Для обработки двух портов скорости не хватает. Если бы можно было забирать из буфера данные по прерыванию или просто опрашивая интерфейс, то проблемы бы не было.

4-ю сноску я тоже не понял. Возможно, речь о modbus-режиме работы, но не уверен.

In_Da_Cher_A, на самом деле, если бы не требование получать данные от двух источников, то панель для моей задачи подходит идеально. Поэтому проще как раз на панели, а не на «любой нормальной скаде». Весь прочий функционал решается несколькими несложными скриптами.
И ТЗ в части требований к функционалу написано специально под эту панель (без учета только лишь одного пункта).

[melky]

Мне известно о возможности доступа только через вызов функции Receive.

Суть вызова этой функции у вас был из кода ST ? а я спрашиваю про СИ подобный язык для макросов, даже если он к этой же функции будет обращаться.
Собственно с чем связан вопрос? для панели указано, что возможна реализация нестандартных протоколов. Имеется 2 порта RS485, как бы предполагается, что на каждом порту может быть два устройства (одинаковых, разных и не с протоколом Modbus)

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