21 (2020-02-26 15:14:42 отредактировано retriever)

Re: Вопрос по FastViev

n00buK писал(а):
2020-02-26 13:01:27

Согласно стандарту частот дискретизации в пределах одного файла может быть много (до 999), так что стандарту это не противоречит.

Частота дискретизации - это 1/dt, dt - это период дискретизации (разница по времени между отсчетами).
И логично было бы предположить, что раз мы написали разные частоты дискретизации, то этому должны соответствовать записи в dat файле во второй колонке что-то типа

1, 0
2, 1000
3, 2000
4, 3000
5, 3500
6, 4000
7, 4500
(время от балды, вначале шаг по времени 1000 мкс=0.001 с - 20 отсчетов на период, потом в 2 раза меньше 500 мкс=0.0005 с -40 отсчетов на период).
и тогда надо написать, что в начале у нас частота дискретизации 1/(1000*10^-6)=1000, а потом 1/(500*10^-6)=2000, т.е.
1000,4  (1000 Гц до 4го отсчета)
2000,7  (2000 Гц до 7го отсчета)

А здесь, в случае с механотроникой, ерунда какая-то -  открываю dat файл, и шаг по времени никак не привязан к той цифре "до какого отсчета", он действительно меняется, но, видимо, округление все съедает.

2397.533936,12
2397.807617,36
2398.081543,84
2398.218506,180
2398.355469,204
2398.492432,252
2393.162354,276

А шаг по времени аж до 265 отсчета как был 417 мкс, так и остался.

по-моему частоту надо было отдельным каналом писать, а не в cfg совать....

22

Re: Вопрос по FastViev

n00buK писал(а):
2020-02-26 14:20:04

Т.е. частоту для регистраторов, записывающих с постоянной частотой дискретизации, FastView не посчитает (а, жаль).

Верно, не посчитает. Но даже если бы и считал. Вы бы верили расчету? То есть, на каком основании по частоте, рассчитанной просмоторщиком, можно судить о правильности срабатывания алгоритма АЧР какого-нибудь терминала? В терминале может быть другой алгоритм расчета или другие окна усреднения или различные блокировки. Почему мы больше желаем доверять алгоритмам просмоторщика, а не алгоритмам блока?

23 (2020-02-26 15:40:52 отредактировано n00buK)

Re: Вопрос по FastViev

retriever писал(а):
2020-02-26 15:09:22

А здесь, в случае с механотроникой, ерунда какая-то -  открываю dat файл, и шаг по времени никак не привязан к той цифре "до какого отсчета", он действительно меняется, но, видимо, округление все съедает.

Так и есть. Для 5-ой частоты дискретизации период составляет 416.929 мкс, для 6-ой - 417.857. Отбрасываем дробную часть и всё сходится.

retriever писал(а):
2020-02-26 15:09:22

по-моему частоту надо было отдельным каналом писать, а не в cfg совать....

Стандарт не против, так почему бы и нет? Конечно, если нужна именно частота - то надо уж ее пихать в канал.

retriever писал(а):
2020-02-26 15:09:22

(время от балды, вначале шаг по времени 1000 мкс=0.001 с - 20 отсчетов на период, потом в 2 раза меньше 500 мкс=0.0005 с -40 отсчетов на период).

Это при частоте 50 Гц, что бывает далеко не всегда.
Решение необычное, не спорю. Но стандарту не противоречит и имеет право на жизнь.

zigzag писал(а):
2020-02-26 15:15:25

Верно, не посчитает. Но даже если бы и считал. Вы бы верили расчету? То есть, на каком основании по частоте, рассчитанной просмоторщиком, можно судить о правильности срабатывания алгоритма АЧР какого-нибудь терминала? В терминале может быть другой алгоритм расчета или другие окна усреднения или различные блокировки. Почему мы больше желаем доверять алгоритмам просмоторщика, а не алгоритмам блока?

Согласен. При анализе работы терминала - если уж нужна частота, то надо ее записывать канал. Бреслер сделал интересный костыль, практическое применение которого я четко не вижу, но идея почему-то понравилась Default/smile=)
Но если анализировать именно аварию, я бы не отказался от некого универсального метода, который пусть будет сложный и тяжелый (и поэтому нереализуемый в терминале из-за требований производительности), чтобы попытаться оценить не то, что насчитал терминал, а то, что было "реально". Например, посчитав частоту с разных терминалов, подключенных к разным ТН.

24

Re: Вопрос по FastViev

n00buK писал(а):
2020-02-26 15:30:58

Это при частоте 50 Гц, что бывает далеко не всегда.

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

Но то, что отсутствует прямая связь между данными в дат-файле (из-за округления) и вот этими цифрами в cfg - как-то все равно не очень.

n00buK писал(а):
2020-02-26 15:30:58

Например, посчитав частоту с разных терминалов, подключенных к разным ТН.

вообще технически можно по каналам напряжения из комтрейда найти частоту, но там все равно будут какие-то глюки в области, соответствующей переходу из режима КЗ в нормальный и наоборот. И по каналам тока тоже можно, но там еще хуже....
так что с точки зрения "посмотреть частоту в просмотрщике осциллограмм" можно было бы просто запилить отдельную функцию, типа как векторная диаграмма...

25

Re: Вопрос по FastViev

retriever писал(а):
2020-02-26 15:50:25

И по каналам тока тоже можно, но там еще хуже....

Формально - низзя. У нас частота - это частота напряжения. Но если бы и можно - там насыщение, ну его нафиг.

retriever писал(а):
2020-02-26 15:50:25

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

Было бы неплохо. Но, что-то мне подсказывает, что никто этим не займется.

Присоединяйтесь!!! Мы в социальных сетях и на Ютуб.

26

Re: Вопрос по FastViev

По поводу частоты дискретизации (или дискредитации?) от Механотроники сам нечистый ногу сломит. Что это за плавающая частота? Кто-то из альтернативных просмотрщиков с этим справляется с трудом, в достоверности результатов сомневаюсь.. Кто-то может, но при этом предупреждает: полагаю, что решение такое-то, но я Вас предупреждаю о сомнительности результатов!
Понимаю, когда концы линии оснащены однотипной аппаратурой. А как у нас в свое время на одной линии и смежных было 6 (!) РАС разных типов, где приходилось для полного анализа все переводить в COMTRADE и искать единое средство просмотра.
48 Гц вообще уму непостижимо.

27

Re: Вопрос по FastViev

doro писал(а):
2020-02-26 16:03:19

По поводу частоты дискретизации (или дискредитации?) от Механотроники сам нечистый ногу сломит.

Коллеги.
Есть блоки БМРЗ которые записывают осциллограмму. Есть программа FastView которую мы делали для анализа осциллограмм записанных в первую очередь нашими блоками. Это ведь логично, если программа еще и бесплатная.
В блоках БМРЗ есть два варианта расчета частоты сети, для обоих мы должны предоставить возможность просмотра. Первый вариант через частоту дискретизации второй это запись частоты которую рассчитал блок.
Во всех последующих блоках мы будем реализовывать второй вариант.
Делать функцию расчета частоты сигнала по любому каналу мы точно не будем делать.
Для прозрачности стоит в редакторе формул для функции расчета Частоты указать для блоков БМРЗ.  Для решения возникшей проблемы мы это сделаем.

28

Re: Вопрос по FastViev

retriever писал(а):
2020-02-26 15:50:25

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

С расчетом Фурье это не должно быть связано. Потому что, если принять за исходное положение, что на периоде (независимо от его длины) всегда одно и тоже количество точек, а именно это и делается когда частота дискретизации подстраивается под частоту сети, то в формуле фильтра Фурье будет только это число N и тригонометрические функции углов k*2*pi/N. Текущая частота сети и частота дискретизации не влияет. Но по стандарту надо писать частоту дискретизации, вот она и пишется.

retriever писал(а):
2020-02-26 15:50:25

пришлось бы городить отдельный канал, и как-то притягивать его к фурье

Так и сделано в устройствах с постоянной частотой дискретизации. Отдельная трасса частоты учитывается при расчете Фурье.

29

Re: Вопрос по FastViev

Потому что, если принять за исходное положение, что на периоде (независимо от его длины) всегда одно и тоже количество точек, а именно это и делается когда частота дискретизации подстраивается под частоту сети, то в формуле фильтра Фурье будет только это число N и тригонометрические функции углов k*2*pi/N.

в принципе, это правильно, но откуда взять N? В комтрейде не задана N, там задана частота_дискретизации=f*N и номинальная частота сети fnom.

N можно достать из частоты дискретизации делением на номинальную частоту сети с округлением, но ни из какой части файла не следует, что, скажем, N=48 всегда.
т.е. можно использовать алгоритм типа N=round(частота_дискр/fnom), и далее всегда делать фурье с N, но тогда N будет вычисляться правильно не при любых частотах, а только при близких к 50 Гц.
возможно, кому-то пришла в голову идея сделать "универсальный" вариант, записывая частоты дискретизации, чтобы Фурье всегда шло с "правильным" N.

30

Re: Вопрос по FastViev

retriever писал(а):
2020-02-26 17:49:21

в принципе, это правильно, но откуда взять N? В комтрейде не задана N, там задана частота_дискретизации=f*N и номинальная частота сети fnom.

Разработчики точно должны знать чему равно N. И исходя из этого всё и работает. А так как трасса частоты, рассчитанная FastView, получается как f_sampling / 48, то мы знаем, что N = 48 всегда (как минимум так должно быть).

31 (2020-02-26 18:26:02 отредактировано retriever)

Re: Вопрос по FastViev

Разработчики точно должны знать чему равно N

но комтрейд-то универсальный)

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

я делал как-то свой просмотрщик комтрейда, как раз долго думал, откуда там N взять. имхо, либо N=round(частота_дискр/fnom), либо делать базу данных на устройства и доставать оттуда N по названию.
а частоту сети далее добывать как f=частота_дискр/N

ну так-то да, проблема с фурье выглядит немного надуманной, все равно, если N считать по той формуле N=round(частота_дискр/fnom), то для частот, близких к 50 Гц все четко.

32 (2020-02-26 18:54:18 отредактировано n00buK)

Re: Вопрос по FastViev

retriever писал(а):
2020-02-26 18:15:23

я делал как-то свой просмотрщик комтрейда, как раз долго думал, откуда там N взять. имхо, либо N=round(частота_дискр/fnom), либо делать базу данных на устройства и доставать оттуда N по названию.
а частоту сети далее добывать как f=частота_дискр/N

Есть еще один вариант: надеяться, что производители читают стандарт по Comtrade Default/smile=), где приведен ряд частот дискретизации (Annex B).
Тогда можно реализовать нечто такое (пример а-ля python) с учетом максимального отклонения частоты в 10% (45-55 Гц):

def _get_points_on_period(fd: float) -> int:
   if 2160<fd<2640: # Для частоты дискретизации 2400
      return 48
   elif 2880<fd<3520 # Для частоты дискретизации 3200
      return 64
   elif.. # и так далее

33

Re: Вопрос по FastViev

retriever писал(а):
2020-02-26 18:15:23

но комтрейд-то универсальный)

Yesли бы! Стандарт определяет общие принципы. А каждый разработчик допускает свои вариации. В свое время написал статью в журнал Релейная защита и автоматизация. Кто-то из разработчиков попросил подзадержать публикацию для доработки (кому-то часы понадобились, кому-то - месяцы, а кто-то и по сей день спустя годы дуется: ты чей заказ выполнял?).
Файлы каждого разработчика, к тому же сохраненные в разных форматах COMTRADE, разные просмотрщики смотрят по разному.

34

Re: Вопрос по FastViev

Данные из comtrade это пары (время, значение). Зная только это всегда можно посчитать составялющую 50 Гц. И совершенно неважно ряд по времени равномерный (одна частота дискретизации) или неравномерный (много частот дискретизации). Выбираем окно в 20 мс, принимаем решение, что делать, если в этом окне оказалось нецелое количество периодов дискретизации и вперед: умножаем и складываем.

Другое дело что реализовать формулу с постоянным N легче, чем с переменным (дробным) и то, что не сильно она врет при небольших отклонениях частоты основной гармоники от 50 Гц.

Но мы хотим большего, мы хотим видеть вектор не составляющей 50 Гц, а вектор основной гармоники, у которой частота 50+-delta. Чтобы ее посчитать нужны дополнительные сведения (нужно знать частоту этой основной гармоники). И тут есть варианты:
1. Механотроника для осциллограмм варианта 1 говорит "парни, не парьтесь, мы подстроили всё так, что на периоде всегда 48 точек, независимо от частоты сети. Берите их под сумму фильтра Фурье и будет всё правильно. Или просто используйте фаствью - там так и сделано.
2. Частота дискретизации постоянная. Каким то другим способом получена частота основной гармоники и показана в качестве отдельной трассы. В этом случае берем и суммируем то количество точек (периодов дискретизации) которое попадает в период реальной частоты. И это сделано также в фаствью для блоков, которые пишут частоту в осц.

Так что составляющую 50 Гц считаем без проблем. Основную гармонику считаем, только если каким то способом до расчета Фурье узнали ее частоту.

35 (2020-02-27 10:32:03 отредактировано n00buK)

Re: Вопрос по FastViev

zigzag писал(а):
2020-02-26 20:29:55

Основную гармонику считаем, только если каким то способом до расчета Фурье узнали ее частоту.

Вместо "узнали" можно "посчитали", о чем и писал в почте #23. Как считать - по ситуации. Например, тот же блок PLL в Simulink.

36

Re: Вопрос по FastViev

n00buK писал(а):
2020-02-27 10:29:48

Вместо "узнали" можно "посчитали"

Да, я это и имел в виду.

37 (2020-02-27 14:22:22 отредактировано doro)

Re: Вопрос по FastViev

n00buK писал(а):
2020-02-26 15:30:58

Так и есть. Для 5-ой частоты дискретизации период составляет 416.929 мкс, для 6-ой - 417.857. Отбрасываем дробную часть и всё сходится.

Я так понял, Вы - представитель этой фирмы. От того пояснения не стают более ясными. Сделайте так, чтобы любой просмотрщик (да и конечный потребитель) Вас понимал, и будет Вам счастье!

38 (2020-02-27 13:49:24 отредактировано n00buK)

Re: Вопрос по FastViev

doro писал(а):
2020-02-27 13:17:45

Я так понял, Вы - представитель этой фирмы. От того пояснения не стают более ясными. Сделайте так, чтобы любой просмотрщик (да и конечный потребитель) Вас понимал, и будет Вам счастье!

Нет, я не представитель фирмы-производителя. Более того, к производству оборудования не имею никакого отношения. И просмотрщики меня отлично понимают! А вот с COMTRADE файлами беда, не все просмотрщики их правильно понимают ICQ/ac:(

39 (2020-02-27 14:38:51 отредактировано retriever)

Re: Вопрос по FastViev

zigzag писал(а):
2020-02-26 20:29:55

Зная только это всегда можно посчитать составялющую 50 Гц. И совершенно неважно ряд по времени равномерный (одна частота дискретизации) или неравномерный (много частот дискретизации). Выбираем окно в 20 мс, принимаем решение, что делать, если в этом окне оказалось нецелое количество периодов дискретизации и вперед: умножаем и складываем.

Вы знаете, я еще подумал. Частоту дискретизации можно получить тупо из отсчетов времени, зачем ее напрямую указывать тогда в cfg, непонятно) Разве что ради знаков после запятой...

А если мы переходим из области с одной частотой дискретизации в область с другой частотой, то в любом случае придется делать ресемплирование, там нельзя брать константное N...

Пром. частота в cfg - да, имеет смысл, чтобы оценить кол-во отсчетов на период N и сделать правильное Фурье.
А точную частоту - есть алгоритмы, которые способны ловить эту частоту на коротком окне, не для любой осциллограммы, но для "обычных", где все около 50 Гц, вполне работают.

Можно было бы сделать как-то так: указать канал для контроля частоты (напряжение), обработать, устранить "выбросы" (из-за переходных процессов), разбить осциллу на отрезки: 50 Гц, 50.5 Гц, 50.2 Гц, 49.8 Гц и т.п., и далее делать Фурье с "правильной" частотой (лучше через ресемплирование осциллограммы).
Хотя, с другой стороны, если у нас все модели на 50 Гц, вряд ли уточнение частоты будет иметь смысл, разве что частоту считать ради анализа работы АЧР и т.п.