Сохранение проекта Openscada в БД по команде из JavaLikeCalc кода
| Автор |
Сообщение |
|
Сообщение создано: 30. 01. 2015 [12:47]
|
|
pentagon128
Руслан Кучерявый
Создатель темы
Зарегистрирован(а) с: 15.11.2011
Сообщения: 102
|
Добрый день! Имею проект Openscada работающий на Raspberry Pi. В проекте имеется 2 шт. ПИД регуляторов с импульсными выходами для управления задвижками а также самописные блоки управления группами насосов. Переменные алгоблоков объединены в параметры и при работе блочного вычислителя эти переменные (атрибуты) периодически обновляются, в результате чего происходит периодическое взведение флага признака модификации проекта (кнопка Save в визуальном интерфейсе становиться зелёной). Raspberry Pi работает в качестве контроллера, её планируется ставить на удалённые объекты, связь на верхний уровень по GSM модему или по Ethernet путем проброса параметров техпроцесса по Modbus RTU и Modbus TCP, соответствующий входной транспорт на портах настроен, данные проходят нормально.
Если оператор удалённо переводит ПИД регуляторы в режим "ручное" , меняет задание а также меняет режимы работы насосов, то при этом меняются атрибуты в ОЗУ Raspberry Pi, и при перерыве электропитания схема работы возвращается к тому состоянию что записано в БД проекта Openscada, что есть проблема. В контроллерах где есть Nand Flash данная проблема решается размещением тегов проекта которые должны сохранять своё значение при перерывах эл. питания/рестартах контроллера - в области Nand Flash. При этом периодическая запись в них - убъёт Nand Flash, разработчик проекта МО(математическое обеспечение) и ПО(программное обеспечение) должен за этим следить. В моём случае БД проекта Openscada расположена на micro SD карте вставленной в Raspberry Pi в файле SQLITE. Если сконфигурирую периодическую запись проекта - убью SD карту или значительно снижу её ресурс. Пытаюсь создать простую функцию:
if(command)
{
SYS.setSavePeriod(period);
command=false;
count+=1;
}
где атрибут command доступен по Modbus RTU/TCP как Coil и при записи в него 1-цы выставляет ненулевой период автосохранения проекта, например 10 сек, потом будет в коде функции запускаться скажем 20 секундный таймер который затем обнулит ненулевой период автосохранения проекта и вернёт функцию в исходное состояние. В count будет храниться счётчик сохранений проекта, чтобы по Modbus с верхнего уровня было видно что команда сохранения проекта прошла (счётчик увеличиться на единицу). Также по модбас могу отобразить наверх дату модификации файла проекта. Т.е. нужна разовая команда сохранения БД проекта доступная из Java. К сожалению код SYS.setSavePeriod(period); или SYS.setSavePeriod(10); не работает, сообщений об ошибках нет и внутренняя переменная Openscada содержащая период автосохранения не меняется. В API Openscada описан объект TSYS. Вызов кода TSYS.setSavePeriod(10); приводит к ошибке. Т.е. имею проблему с синтаксисом вызова методов объекта TSYS.
Документацию и форум, примеры проектов Бойлер и АЛКГС просмотрел, решения пока не нашел. Т.е. моя проблема решается 2-мя путями:
1. Правильный синтаксис вызова методов объекта TSYS, чтобы создать функцию savebd на языке JavaLikeCalc при вызове которой происходит однократная запись проекта в БД.
2. Реализация команды разовой записи проекта Openscada в БД через API Openscada на языке Си.
Если Raspberry Pi доступен через web интерфейс для разработчика проблемы нет - нажал кнопку сохранения в конфигураторе - и атрибуты параметров сохранены в БД. Но оператору техпроцесса нельзя предоставлять доступ к конфигуратору Openscada.
В общем - прошу помочь советом или небольшим примером кода ).
[Сообщение редактировалось 2 раз(а), в последний раз 30.01.2015 в 12:58.]
|
|
Сообщение создано: 01. 02. 2015 [22:20]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3742
|
"pentagon128" wrote:
Если оператор удалённо переводит ПИД регуляторы в режим "ручное" , меняет задание а также меняет режимы работы насосов, то при этом меняются атрибуты в ОЗУ Raspberry Pi, и при перерыве электропитания схема работы возвращается к тому состоянию что записано в БД проекта Openscada, что есть проблема. В контроллерах где есть Nand Flash данная проблема решается размещением тегов проекта которые должны сохранять своё значение при перерывах эл. питания/рестартах контроллера - в области Nand Flash. При этом периодическая запись в них - убъёт Nand Flash, разработчик проекта МО(математическое обеспечение) и ПО(программное обеспечение) должен за этим следить. В моём случае БД проекта Openscada расположена на micro SD карте вставленной в Raspberry Pi в файле SQLITE. Если сконфигурирую периодическую запись проекта - убью SD карту или значительно снижу её ресурс. Пытаюсь создать простую функцию:
Не убьёт, у меня ещё ничего не убило и потом достаточно сохранения с периодом раз в сутки, как показала практика.
"pentagon128" wrote:
где атрибут command доступен по Modbus RTU/TCP как Coil и при записи в него 1-цы выставляет ненулевой период автосохранения проекта, например 10 сек, потом будет в коде функции запускаться скажем 20 секундный таймер который затем обнулит ненулевой период автосохранения проекта и вернёт функцию в исходное состояние. В count будет храниться счётчик сохранений проекта, чтобы по Modbus с верхнего уровня было видно что команда сохранения проекта прошла (счётчик увеличиться на единицу). Также по модбас могу отобразить наверх дату модификации файла проекта. Т.е. нужна разовая команда сохранения БД проекта доступная из Java. К сожалению код SYS.setSavePeriod(period); или SYS.setSavePeriod(10); не работает,
Естественно, где написано, что такие есть?
"pentagon128" wrote:
Документацию и форум, примеры проектов Бойлер и АЛКГС просмотрел, решения пока не нашел. Т.е. моя проблема решается 2-мя путями:
1. Правильный синтаксис вызова методов объекта TSYS, чтобы создать функцию savebd на языке JavaLikeCalc при вызове которой происходит однократная запись проекта в БД.
Не правильный, а то что там реально есть: http://wiki.oscada.org/Doc/OpisanieProgrammy#h920-6
"pentagon128" wrote:
2. Реализация команды разовой записи проекта Openscada в БД через API Openscada на языке Си.
Всё это решается через обращения к интерфейсу управления, т.е. то, что делается из конфигураторов: cntrReq().
Ищем по форуму поскольку тут уже масса примеров запросов через интерфейс управления было, включая и сохранение нужного.
"pentagon128" wrote:
В общем - прошу помочь советом или небольшим примером кода ).
Если советы, то к чему писать в тему "Запрос функций и услуг"?
Почитайте правила для чего эта тема!
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 02. 02. 2015 [18:14]
|
|
pentagon128
Руслан Кучерявый
Создатель темы
Зарегистрирован(а) с: 15.11.2011
Сообщения: 102
|
"roman" wrote:
Не убьёт, у меня ещё ничего не убило и потом достаточно сохранения с периодом раз в сутки, как показала практика.
как вариант "костыля" рассматривал, так и сделал, поставил период автосохранения проекта 86400 [сек.]
"roman" wrote:
Естественно, где написано, что такие есть?
нигде, это алгоритм реализации очередного "костыля" из моей головы, т.к. функции реализации команды "Сохранение проекта Openscada в БД по команде из JavaLikeCalc кода" у меня пока нет.
спасибо за подсказку.
"roman" wrote:
Всё это решается через обращения к интерфейсу управления, т.е. то, что делается из конфигураторов: cntrReq().
спасибо за подсказку.
"roman" wrote:
Ищем по форуму поскольку тут уже масса примеров запросов через интерфейс управления было, включая и сохранение нужного.
примеров как раз мало, а на запись только один.
"roman" wrote:
Если советы, то к чему писать в тему "Запрос функций и услуг"?
Почитайте правила для чего эта тема!
Правила читал прежде чем создавать тему. Потому что функции "Сохранение проекта Openscada в БД по команде из JavaLikeCalc кода" как я вижу нет. Если по Вашему мнению можно обойтись "костылём", то предлагаю эту тему перенести в разработку (http://oscada.org/ru/forum/topics/razrabotka/). На мой взгляд решения в порядке возрастания их качества такие: автосохранение с периодом в сутки и более, "костыль" функции однократного "автосохранения" с рабочим примером, метод пользовательского интерфейса с рабочим примером вызова.
Вариант "костыль" функции однократного "автосохранения" у меня сейчас выглядит так:
if(command)
{
req = SYS.XMLNode("set").setAttr("path","/WorkStation/%fgen%2fsavePeriod").setAttr("setSavePeriod",period);
SYS.cntrReq(req, "WorkStation");
retrez = req.attr("rez");
retmsg = req.text();
retmcat = req.attr("mcat");
command=false;
count+=1;
}
результат retrez=2 (ошибка)
retmesg=Элемент 'WorkStation' отсутствует или отключен!
Но узел WorkStation присутствует и включен.
[Сообщение редактировалось 1 раз(а), в последний раз 02.02.2015 в 18:17.]
|
|
Сообщение создано: 02. 02. 2015 [19:25]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3742
|
"pentagon128" wrote:
как вариант "костыля" рассматривал, так и сделал, поставил период автосохранения проекта 86400 [сек.]
Прекращайте нормальные решения, которые разве только Вы считаете "костылём" так называть! Чем периодическое сохранение по Вашему вообще отличается от управляемого? А ничем, поскольку централизованно сохранение осуществляется только для изменений!
"pentagon128" wrote:
"roman" wrote:
Ищем по форуму поскольку тут уже масса примеров запросов через интерфейс управления было, включая и сохранение нужного.
примеров как раз мало, а на запись только один.
http://oscada.org/ua/forum/posts//pomogite_s_xml//1/
SYS.cntrReq(SYS.XMLNode("save").setAttr("path","/sub_DAQ/mod_BlockCalc"));
P.S. Нечего проявлять невежество и гнать про "нет" и "костыли" не разобравшись. Хоть каплю сомнения включите в том, что Вы не правы: http://oscada.org/ru/forum/rules/
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 03. 02. 2015 [06:07]
|
|
pentagon128
Руслан Кучерявый
Создатель темы
Зарегистрирован(а) с: 15.11.2011
Сообщения: 102
|
"roman" wrote:
Прекращайте нормальные решения, которые разве только Вы считаете "костылём" так называть! Чем периодическое сохранение по Вашему вообще отличается от управляемого? А ничем, поскольку централизованно сохранение осуществляется только для изменений!
Управляемое решение позволяет сразу после сохранения перегрузить контроллер, или командой линукса "shutdown now" или передёргиванием электропитания. В случае периодического сохранения необходимо будет уменьшить период, выждать его, вернуть к прежнему значению. Действия разные, результат один. Цена вопроса - время, ресурс внутренней памяти устройства. Первый вариант более оптимальный. Если Вам приходилось конфигурировать роутеры типа Cisco или Zyxel то там в шелле есть прямая команда сохранения текущей конфигурации из оперативной памяти в файл конфига. Удобно и быстро, делается как правило при внесении изменений. По поводу терминологии - хорошо неоптимальные на мой взгляд решения- "костылём" называть не буду.
Спасибо за подсказку. Именно этот пример мне нужен и не попадался мне. Хотя поиск примеров делал по "cntrReq".
"roman" wrote:
P.S. Нечего проявлять невежество и гнать про "нет" и "костыли" не разобравшись. Хоть каплю сомнения включите в том, что Вы не правы: http://oscada.org/ru/forum/rules/
Извините если задело. Правила знаю, читал. Стараюсь соблюдать. На счёт "невежества" и сомнения по поводу "неправоты" скажу так, правда (истина) на каждом уровне развития своя, иногда правда верхнего уровня полностью опровергает правду нижнего уровня. Вне уровня правда не имеет смысла. Поэтому с более высокого уровня (разработчика системы) так называемая "правда/мнение/вариант решения" более низкого уровня (пользователя форума) всегда будет казаться "невежеством" и иногда и ложью, и это нормально. А задача ученика поднять свой уровень. Высшими всегда ценятся качества учителя. Естественно что за обучение ученику надо платить учителю. Если будет внедрен мой проект, то подниму вопрос о платной техподдержке. Пока у меня на руках опытный образец решения задачи, ещё не внедрённый ни на одном объекте. Естественно знаю что обучением никто заниматься не собирается, поэтому постоянно занимаюсь самообучением. Вот приходиться разбираться в чужом коде. В моей практике были случаи когда модель решения а главное реализация кода были настолько запутанные что быстрее и качественнее получалось самому разработать модель и заполнить её кодом с нуля.
Поддержка пользователей форума позволяет выявлять ошибки в коде и способствует повышению уровня Openscada, это лучше чем ничего, хотя недостаточно.
Не первый год уже разбираюсь с Openscada, и проблема на которую постоянно натыкаюсь - правильный синтаксис кода и трата времени на поиск примеров. Приходиться вспоминать MSDN где на каждую тему HELPа присутствует 3-4 маленьких рабочих примера (никто и не собирается выкладывать коммерческие решения) на разных языках. Естественно штат разработчиков там большой и проект проприетарный, т.е. сравнение конечно неккоректно.
[Сообщение редактировалось 1 раз(а), в последний раз 03.02.2015 в 06:08.]
|
|
Сообщение создано: 03. 02. 2015 [08:52]
|
|
pentagon128
Руслан Кучерявый
Создатель темы
Зарегистрирован(а) с: 15.11.2011
Сообщения: 102
|
Пример по ссылке выше в моём случае не помог. До вызова метода setSavePeriod достучаться через XML обёртку запроса не могу, постоянно получаю ошибку 2 что объекты не существуют, пробовал разные варианты синтаксиса пути. Значение переменной доступно в БД SYS ID=/SavePeriod т.е. можно реализовать вызов SQL запроса прямой записью в БД, с SQL проблемы с синтаксисом нет, может и реализую при случае. Напрягает отсутствие дерева объектов и свойств и примеров. Закидываю тему в долгий ящик.
|
|
Сообщение создано: 03. 02. 2015 [09:39]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3742
|
"pentagon128" wrote:
Управляемое решение позволяет сразу после сохранения перегрузить контроллер, или командой линукса "shutdown now" или передёргиванием электропитания.
Часто-ли оператор меняет настройки регулятора, правильно "никогда", поскольку делает это не он. Велика-ли вероятность того, что технолог сменит настройки регулятора (раз в год) и тут-же понадобится выключить контроллер — правильно, близка к нулю. И какая ценность или время срабатывания ваших этих изощрений — правильно, близка к нулю.
Есть-ли особая разница между настройками регулятора и текущими настройками другого оборудования, как то включенность насосов, да и просто текущий слепок рабочих алгоритмов — правильно, нет. Так почему на их потенциальную потерю в интервале периодического сохранения мы идём, а на настройки регулятора нет? Да потому-что шанс отказа мизерный и сам факт отказа много более весомей, чем потеря текущего слепка алгоритмов на мизерном, на этом фоне, интервале периодического сохранения!
"pentagon128" wrote:
Не первый год уже разбираюсь с Openscada, и проблема на которую постоянно натыкаюсь - правильный синтаксис кода и трата времени на поиск примеров. Приходиться вспоминать MSDN где на каждую тему HELPа присутствует 3-4 маленьких рабочих примера (никто и не собирается выкладывать коммерческие решения) на разных языках. Естественно штат разработчиков там большой и проект проприетарный, т.е. сравнение конечно неккоректно.
Вспоминайте ещё про это: http://oscada.org/ru/razrabotka/pomoshch/
... Любая критика об отсутствии того или иного функционала в этом случае разбивается о его ненадобность пользователям или нежелание этих самых пользователей, часто и критикующих отсутствие функционала, сделать что-нибудь для решения своего вопроса!
"pentagon128" wrote:
Пример по ссылке выше в моём случае не помог.
SYS.cntrReq(SYS.XMLNode("save").setAttr("path","/sub_DAQ/mod_BlockCalc/%2fobj"));
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 03. 02. 2015 [16:35]
|
|
pentagon128
Руслан Кучерявый
Создатель темы
Зарегистрирован(а) с: 15.11.2011
Сообщения: 102
|
"roman" wrote:
Часто-ли оператор меняет настройки регулятора, правильно "никогда", поскольку делает это не он. Велика-ли вероятность того, что технолог сменит настройки регулятора (раз в год) и тут-же понадобится выключить контроллер — правильно, близка к нулю. И какая ценность или время срабатывания ваших этих изощрений — правильно, близка к нулю.
Есть-ли особая разница между настройками регулятора и текущими настройками другого оборудования, как то включенность насосов, да и просто текущий слепок рабочих алгоритмов — правильно, нет. Так почему на их потенциальную потерю в интервале периодического сохранения мы идём, а на настройки регулятора нет? Да потому-что шанс отказа мизерный и сам факт отказа много более весомей, чем потеря текущего слепка алгоритмов на мизерном, на этом фоне, интервале периодического сохранения!
Важность сохранения настроек касаются не сколько настроек регуляторов, а сколько состояния насосов в группе из нескольких насосов. В настоящее время, когда группа находиться в режиме автомат, алгоритм чередует насосы по таймеру - для их равномерного износа. В случае например проблем в технологической схеме, а схема это ИТП (индивидуальный тепловой пункт), ну например - недержит/неисправен обратный клапан в линии рециркуляции, чтобы не заморозить здание, например школу - можно "подпереть" прямым давлением обратный клапан переключив группу насосов в ручной режим и вручную выбрать рабочие насосы. Такие случаи в моей практике были. Т.е. схема работает в полурабочем аварийном режиме - но работает, пока сервисная бригада не доберется до объекта и не заменит обратный клапан. Занимается этим оператор технолог сервисной фирмы которая обслуживает объект, и как правило она-же разрабатывала проект и делала монтаж с пусконаладкой. Объект может находиться за несколько сотен километров от сервера на который стекается телеметрия. Если применено автосохранение настроек с периодом в 1 сутки и ночью произойдёт перерыв электропитания - то утром получите замерзшее здание.
"roman" wrote:
Вспоминайте ещё про это: http://oscada.org/ru/razrabotka/pomoshch/
... Любая критика об отсутствии того или иного функционала в этом случае разбивается о его ненадобность пользователям или нежелание этих самых пользователей, часто и критикующих отсутствие функционала, сделать что-нибудь для решения своего вопроса!
Про это помню. Поднял вопрос о техподдержке, и завтра подниму перед высшим руководством. Также добавлю мой девиз "Критикуешь - предлагай, предлагаешь - делай, делаешь - отвечай". Критику как правило я пропускаю, а сразу предлагаю варианты хотя- бы начального решения вопроса. Тут моя позиция ближе к разработчику. Вспомните тему про отсутствие обработки флага f_start при первом запуске блочного вычислителя? Я когда форум перечитывал то обратил внимание, что 2 или 3 пользователя писали Вам о этой проблеме в той или иной форме, тем не менее решения своей проблемы они не получали, а необработка f_start оставалась, и только после того как мы с Вами почти 3 страницы перетирали эту тему - Вы увидели проблему и решили её.
"roman" wrote:
SYS.cntrReq(SYS.XMLNode("save").setAttr("path","/sub_DAQ/mod_BlockCalc/%2fobj"));
этот кусок кода рабочий. Спасибо. Через неделю у меня было запланировано с коллегой прошерстить исходный код на Си около кнопки сохранения, ибо выудить правильные пути можно оттуда, теперь благодаря Вашей поддержке часть времени сэкономлена. Теперь моя функция записи имеет вид:
if(command)
{
SYS.cntrReq(SYS.XMLNode("save").setAttr("path","/sub_DAQ/mod_BlockCalc/%2fobj"));
command=false;
count+=1;
}
естественно в документации не сказано что правильный путь сидит в блочном вычислителе.
на входе булева переменная command, на выходе целый счётчик count записи.
Далее вставляем функцию в блочный вычислитель, линкуем параметры, параметры выставляем на входящий транспорт Modbus.
|
|
Сообщение создано: 07. 02. 2015 [13:11]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3742
|
"pentagon128" wrote:
Важность сохранения настроек касаются не сколько настроек регуляторов, а сколько состояния насосов в группе из нескольких насосов. В настоящее время, когда группа находиться в режиме автомат, алгоритм чередует насосы по таймеру - для их равномерного износа. В случае например проблем в технологической схеме, а схема это ИТП (индивидуальный тепловой пункт), ну например - недержит/неисправен обратный клапан в линии рециркуляции, чтобы не заморозить здание, например школу - можно "подпереть" прямым давлением обратный клапан переключив группу насосов в ручной режим и вручную выбрать рабочие насосы. Такие случаи в моей практике были. Т.е. схема работает в полурабочем аварийном режиме - но работает, пока сервисная бригада не доберется до объекта и не заменит обратный клапан. Занимается этим оператор технолог сервисной фирмы которая обслуживает объект, и как правило она-же разрабатывала проект и делала монтаж с пусконаладкой. Объект может находиться за несколько сотен километров от сервера на который стекается телеметрия. Если применено автосохранение настроек с периодом в 1 сутки и ночью произойдёт перерыв электропитания - то утром получите замерзшее здание.
Почему? Алгоритм, после перегрузки, по идее при любом состоянии должен бы переанализировать и включить правильное состояние, раз он такой есть. Если-же нету тогда, включал такую схему по идее оператор, последний раз, а раз так то он вроде и рядом должен быть.
"pentagon128" wrote:
Про это помню. Поднял вопрос о техподдержке, и завтра подниму перед высшим руководством. Также добавлю мой девиз "Критикуешь - предлагай, предлагаешь - делай, делаешь - отвечай". Критику как правило я пропускаю, а сразу предлагаю варианты хотя- бы начального решения вопроса.
Но желательно делать это с каплей сомнения в своей абсолютной правоте, чтобы дать опоненту Вас поправить, а не рассматривать ожидаемое "правильное" предложение.
"pentagon128" wrote:
Вспомните тему про отсутствие обработки флага f_start при первом запуске блочного вычислителя? Я когда форум перечитывал то обратил внимание, что 2 или 3 пользователя писали Вам о этой проблеме в той или иной форме, тем не менее решения своей проблемы они не получали, а необработка f_start оставалась, и только после того как мы с Вами почти 3 страницы перетирали эту тему - Вы увидели проблему и решили её.
Не помню поднятых и не решённых проблем такого рода с BlockCalc, да и в других местах.
"pentagon128" wrote:
естественно в документации не сказано что правильный путь сидит в блочном вычислителе.
Естественно, документация не может знать какой вам объект для запроса понадобился конкретно сейчас, это ведь команда для конкретного объекта с распространением по нижерасположенным узлам.
Кстати документацию несколько дополнил!
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 08. 02. 2015 [12:41]
|
|
pentagon128
Руслан Кучерявый
Создатель темы
Зарегистрирован(а) с: 15.11.2011
Сообщения: 102
|
"roman" wrote:
Почему? Алгоритм, после перегрузки, по идее при любом состоянии должен бы переанализировать и включить правильное состояние, раз он такой есть. Если-же нету тогда, включал такую схему по идее оператор, последний раз, а раз так то он вроде и рядом должен быть.
Оператор должен работать удалённо через GSM модем. Сейчас такая схема реализована на других контроллерах. Алгоритм в любом случае должен грузить из БД признак ручного режима Есть/нет что сейчас реализовано, догадаться сам он никак не может. Перевёл схему в ручной режим, отдал команду записи изменений в контроллер, и забыл на сутки про него. Сейчас у меня реализована функция записи в БД через Модбас, а также через WEB интерфейс кнопкой сохранения. В параметры Блока приходиться заносить практически все атрибуты блока, т.к. связи блока недоступны извне, доступны только параметры, например через модбас. Параметры блока сохраняются в оперативной памяти а также в файл БД при их изменении сохранении проекта БД.
"roman" wrote:
Но желательно делать это с каплей сомнения в своей абсолютной правоте, чтобы дать опоненту Вас поправить, а не рассматривать ожидаемое "правильное" предложение.
Абсолютной правоты быть не может, понятие правоты всегда привязано к уровню индивида, системы и т.д. , поэтому поисками абсолютной правоты а тем более её даказательством перед кем-либо не страдаю и считаю это неблагодарным делом. Всегда рад поправкам, замечаниям, помощи.
"roman" wrote:
Не помню поднятых и не решённых проблем такого рода с BlockCalc, да и в других местах.
Было было, ветки форума правда древние 2011-2012 года. Сейчас попробовал найти - не нашел, но точно было, иначе бы не написал. Но проблема ушла, так что можно не ворошить.
"roman" wrote:
Кстати документацию несколько дополнил!
Роман, Спасибо за внимание и помошь в решении проблем!
|
|
|
