ПЛК 73. Надо на одном COMе общаться с МСД-200, на втором слать логи в терминал.

[rapucha]

Опытно-экспериментальная установка, творцы хотят вести запись всех параметров системы в реальном времени. Чтобы, когда все сломается, изучить записи и понять, что они не так напроектировали ). Для записи этих данных решено использовать МСД-200. Логи в терминал -- на всякий случай, на этапе отладки. Для себя самого.

Больше устройств в сети нет и не предвидится. Обмен с МСД будет интенсивный, хочется сохранять данных побольше да почаще. В терминал -- пару строчек за цикл ПЛК, сам цикл хотелось бы иметь не длиннее 500 мс. Приема данных с терминала либо нет, либо редко. Обмен с терминалом сугубо текстовый.

Посоветуйте, пж., из практического опыта:

1) Какой протокол взять для обмена с МСД, Овен или Modbus? Кого назначить мастером, кого слейвом (или пофиг)?

2) Какие грабли меня ждут при работе с двумя COM-портами в ПЛК73? В актуальных прошивках порты полностю равноправны?

3) для работы с COM-портом в "свободном" режиме, что предпочесть -- SysLibCom или UNM? Интересует критерий ресурсоемкости, в основном -- чтобы жрало времени поменьше. Ну и безглючность.

Спасибо.

[capzap]

не беритесь за этот бесперспективняк

[rapucha]

не беритесь за этот бесперспективняк

Ого. А где грабли? Порты вроде рабочие, поочередно послать-принять получается, по крайней мере.

В чем видите засаду?

[capzap]

unm поддерживается только в 1хх серии контроллеров
передать пару строк за один цикл плк, вряд ли получится, обмен по последовательным портам не такой уж и быстрый, можете сами подсчитать зная скорость передачи сколько байт(включая служебную информацию) Вы сможете передать за один скан. Конечно если отталкиваться что среднее время цикла около 500мс, то всё должно получится, но как мне кажется это пойдет в ущерб основному предназначению контроллера.
ну и записывать побольше и почаще для того чтоб узнать что сломалось, тут к гадалке не ходи эта сама запись и будет ломаться или будет виновником глюков других объектов
модбас рту будет слегка побыстрее остальных протоколов и контроллеру легче отдавать, чем самому быть инициатором обмена для ведения логов

[rapucha]

unm поддерживается только в 1хх серии контроллеров

Вообще, в описании ея сказано, что на 63 работает. Но пробовать пока не пробовал. А она сильно лучше, правда?


передать пару строк за один цикл плк, вряд ли получится, обмен по последовательным портам не такой уж и быстрый, можете сами подсчитать зная скорость передачи сколько байт(включая служебную информацию) Вы сможете передать за один скан. Конечно если отталкиваться что среднее время цикла около 500мс, то всё должно получится, но как мне кажется это пойдет в ущерб основному предназначению контроллера.

да, 500 мс это край, медленнее уже никак, и 200 мс гораздо лучше.


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

Это возможно, ну придется умерить аппетиты разработчиков. Хотя, идея не в том чтобы узнать на ходу, где проблемы -- а в том, чтобы потом, когда все уже сломалось, посмотреть записи и понять, что пошло не так.


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

[Валенок]

Скорость отправки данных лимитирует не модель ПЛК, а настройки порта. Хоть ПК, хоть ПЛК.

в боевом режиме логи в терминал надо отключить
Отправке - пофиг. Не пофиг время работы кода генерации данных для отправки.

[rapucha]

Работа с портом - на реальных прерываниях (у Овена). Поэтому скорость отправки данных лимитирует не модель ПЛК, а настройки порта. Хоть ПК, хоть ПЛК.

Отправке - пофиг. Не пофиг время работы кода генерации данных для отправки.


Мнээ... во-1, SysComWrite по контракту возвращает "число реально записанных байт". Как трактовать эту фразу -- не очень понятно, но можно предположить, что она не возвращается, пока данные не отосланы.
во-2 даже если нет, все равно отсылка данных може не успеть, и на очередном цикле мы переполним FIFO.

[Валенок]

SysComWrite по контракту возвращает "число реально записанных байт".
.. в буффер.
во-2.
И ПЛК - не при делах.

[rapucha]

И ПЛК - не при делах.

Он-то да, но данные потеряны.


Трафик до 1500..1600 байт/сек. Но на все слейвы в сети.

Спасибо, должно хватить.

[Валенок]

Он-то да, но данные потеряны..
Проблема аффтора данных.
Для таких дел и придуманы подтвержения получения

PS
А откуда данные генерятся c обсуждаемой в 2х местах скоростью ?
ПЛК63/73. Di - фильтр 10мс, Ai - 0.4-0.8с на каждый канал. На основе чего в недрах ПЛК образуется какая-то другая информация ?

[rapucha]

А откуда дровишки данные генерятся c обсуждаемой в 2х местах скоростью ?
ПЛК63/73. Di - фильтр 10мс, Ai - 0.4-0.8с на каждый канал. На основе чего в недрах ПЛК образуется какая-то другая информация ?


Она и не образуется. но чтобы логи удобно было читать, там должно быть много текста.

[Валенок]

Она и не образуется. но чтобы логи удобно было читать, там должно быть много текста.
Когда много текста - это зовется спамом. Пишите самое критичное. Что все критично - даже не говорите.