Просмотр полной версии : MasterSCADA 4D 1.3.1 - Где обещанное быстродействие редактора проектов?
b_aleks2
10.03.2023, 11:42
Тут как-то в феврале вышел релиз такой инновационной платформы для автоматизации, учета и диспетчеризации, как MasterSCADA 4D. Такие красивые слова, описывающие данный продукт, я употребил не в саркастическом стиле - именно так заявляет производитель данного продукта.
66422
На сайте заявлено:
Среда разработки MasterSCADA 4D имеет простой и интуитивно понятный редактор мнемосхем, который позволяет в несколько «кликов» разработать интерфейс управления процессом или оборудованием.
По правде говоря, к быстродействию редактора проектов и к разработке в несколько "кликов" всегда были вопросы, и что удивительно, разработчик описываемого продукта даже неоднократно признавал данную ошибку. И вот совсем недавно, на одном из вебинаров, сотрудник компании МПС Софт сделал серьезное заявление, которое я решил проверить.
Прослушать его можно тут https://cloud.mail.ru/public/BPQj/5cTuLVhxM - это запись их вебинара, таймкод - 55:20
Не будем перечитывать весь WhatsNew версии 1.3.1, нас интересует только то, что добавлена возможность хранения проектов в PostgreSQL, что дает следующее:
o Поддержка многопоточной работы с БД
o Ускорение выборки в 4 раза
o Выгрузка неиспользуемых частей проекта – при длительной работе с проектом память не накапливается, так как загружены только используемые в данный момент документы
Небольшое лирическое отступление. Чтобы вы понимали, по мнению разработчиков из МПС Софт, многопоточная работа с БД выглядит следующим образом.
66416 66417
То есть 4 потока PostgreSQL и 27 потоков MasterSCADA 4D распределены всего лишь на два физических ядра, из восьми доступных. Если считать по логическим ядрам, представленным на скринах, то используются только 4 из 16.
Также в WhatsNew описаны доработки компилятора:
o Реализована параллельная компиляция узлов/задач/окон
o Кэширование результатов компиляции окон
o Компиляция переведена в режим многопоточности
Забегая вперед скажу, что во всех операциях, которые доступны с проектом используются только два физических ядра (или четыре логических).
Пройдемся по порядку. Поставили мы значит новый редактор, надо же обновить проект. Правильно? Ну погнали.
1. Вот само видео этого процесса: https://disk.yandex.ru/i/rnNYUVvnrD-hlQ
Чтобы не тратить драгоценное время, вот скрины
66418 66419 66420 66421
Если кратко, то также нагружены два ядра, общая нагрузка на процессор - не более 20 %, средняя нагрузка на диск не более 10 МБ/с.
Само обновление проекта и библиотек заняло по времени 10 минут.
Опять небольшое лирическое отступление. В новой версии обновили протокол Modbus. Ну как обновили, выдали некоторые исправленные ошибки за реализацию новой функции, но не об этом сейчас. Так вот, в новом протоколе Modbus TCP убрали свойство "Modbus через TCP", что приводит к тому, что при обновлении проекта вываливаются ошибки и само обновление проекта не происходит. Чтобы обновить проект, необходимо пропустить его обновление, снять флаг у указанного ранее свойства, а потом переоткрыть проект для его обновления. Это еще лишние 10 минут, которые можно было предусмотреть в процессе обновления проекта.
2. Итак, с горем пополам обновили проект, давайте попробуем его экспортировать, чтобы загрузить в исполнительную систему.
Вот видео этой неудачной (спойлер!) попытки: https://disk.yandex.ru/i/hO516WY4gld9Vw
Прождав 17 минут и словив два всплывающих окна, сообщающих о зависании, даже сама операционная система поняла, что дела тут совсем плохи, и приостановила этот процесс, вот скрин
66391
Пришлось закрыть программу из панели задач, но в диспетчере задач процесс остался, пришлось его "убить".
66392
Вот остальные скрины нагрузки на CPU и SSD
66393 66394
Опять же нагрузка на процессор около 15 %, на диск - не более 5 МБ/с
И 17 минут времени, потраченного в пустую.
То есть ВНИМАНИЕ - новый редактор проектов, который по заявлению разработчиков работает быстрее не в состоянии экспортировать проект. Говоря простыми словами - свой собственный проект я запустить никак не могу. К слову на старой версии, на которой я сейчас сижу - это 1.2.16 - экспорт проекта у меня занимает около 8 минут (на 1.3.1 - экспорт не работает, ждал почти 20 минут).
Летим дальше.
3. Выгрузить проект не получилось. А может быть мешают какие-то ошибки в проекте? Так давайте это проверим.
Проверяем конфигурацию узла. Вот видео: https://disk.yandex.ru/i/YsXSFmH6accA4g
Не трачу время 14 минут впустую, программа зависает, нагрузка на CPU такая же, как и в предыдущих пунктах - два ядра из восьми, общая нагрузка не более 15 %
66395
4. А может нам проверить целостность проекта? Поехали :)
Видео: https://disk.yandex.ru/i/5Ep1cntZOQqbYw
Не трачу время - 8 минут на поиск ошибки (которая находится в их библиотеке) и 7 минут на ее исправление. Нагрузка на CPU не меняется два ядра из восьми, общая нагрузка не более 15 %, на SSD - около 2 МБ/с
66396 66397 66398
5. Давайте просто попробуем осуществить навигацию про проекту, открывать окна, раскрывать деревья объектов
Видео: https://disk.yandex.ru/i/mzLe6t_036ajcQ
В целом, все также, как и на старых версиях, первоначальные открытия окон происходят долго (небольшие по 5-7 секунд, большие по 1-2 минуты), деревья раскрываются с подвисаниями. Ну ладно, ради инноваций можно и потерпеть. Нагрузка на CPU - не более 15 %, на диск - в пике было около 20 МБ/с
66404 66405
6. Давайте перейдем к "десерту". Попробуем сделать проект, который будет храниться во внешней БД PostgreSQL, может быть дела пойдут веселей :)
Не буду описывать то, что при первом подключении к PostgreSQL для создания проекта сыпятся непонятные ошибки, которые невозможно понять из-за странной кодировки: вместо текста ошибки - знаки вопроса. Ну да и ладно, у нас времени много. В результате при помощи кувалды и такой-то матери, все заработало.
Давайте попробуем перенести проект, который невозможно экпортировать из встроенной Firebird.
Переносим узел с 5000 переменными Modbus.
Видео: https://disk.yandex.ru/i/ANmZvbdUfiYwgw
Спустя 8 минут получилось скопировать и вставить в новый проект.
Сохраняем новый проект: https://disk.yandex.ru/i/s4d5ot4V6qzEtA
Тут у нас все зависло. Отвисло и сохранилось только через 40 минут. Чудесно. Инновации и улучшения на лицо.
Совместная работа MS4D и PostgreSQL дала следующее. Нагрузка на CPU общая - не более 20 % (также используются только два ядра из восьми), на SSD - в среднем около 5 МБ/с
Скрины для наглядности
66399 66385 66400 66401 66402 66386 66403
7. При работе с проектом, который хранится в PostgreSQL, также есть подвисания, например, при подключении библиотек.
Видео: https://disk.yandex.ru/i/ArOpSYMI7mi7Ww
При этом нагрузка на CPU также невысокая, например, PostgreSQL нагружает CPU на 8 %. Подозреваю, что виной тому MS4D, которая не в состоянии нагрузить СУБД больше.
66406
8. Попытка скопировать остальную часть проекта не увенчались успехом.
Методом прямого копирования не получается, поскольку вылетает ошибка, что копируемый объект не является экземпляром объекта.
Копирование через библиотеку всех объектов сразу также не увенчалось успехом - MS4D разростается до 27 ГБ в ОЗУ, копирование оканчивается неудачно и с ошибкой (скрин ниже)
66407
Видео: https://disk.yandex.ru/i/KJGl5J7VgLmWgw
На видео выше показаны попытки скопировать объекты в проект с внешней БД. Как можно увидеть на видео, это сопровождается постоянными вылетами нового проекта. По всей видимости, взаимодействие MasterSCADA 4D и PostgreSQL происходит не совсем корректно.
Также отмечу, что копировать получалось только по одному объекту. Сам объект включает в себя окна, программы, сообщения, параметры. Таких объектов у меня в проекте около 100 штук. Надеюсь, понятно, что с учетом медленной работы редактора проектов и его постоянных вылетов, говорить о разработке проекта в несколько "кликов" не идет и речи.
Вот еще несколько скринов:
66409 66410 66411 66412 66413 66414
Если кратко, то здесь тоже все плачевно, ни о какой многоядерности и како-то высокой скорости работы не идет и речи.
Так может быть у меня ПК слабый? Давайте разбираться. Смотрим системные требования к среде разработки:
Рекомендуемые системные требования:
·ОС – Windows 10 х64 или старше;
·процессор – современный многоядерный, не ниже Intel® Core™ i5, 3.4 ГГц
·ОЗУ – не менее 16 Гб;
·дискретная видеокарта, с актуальными драйверами (не старше 5 лет)
·дисплей – 1920х1080;
·жесткий диск - SSD
·свободное место на диске – 100 Гб
·клавиатура, мышь.
А вот мой ПК:
Intel Core i7-10700K
32 GB RAM DDR4
Samsung SSD 970 EVO Plus 250GB
Windows 10 Pro x64
Да вроде соответствуют. Чего не зватает? Не понятно :)
Хотя если поглядеть, как MasterSCADA 4D использует ресурсы, то очевидно, что хватит и любого Intel Pentium и дешманского HDD на 5400 оборотов.
Таким образом, становится понятно, что все обещания о каком-то быстром и эффективном редакторе проектов - не более, чем слова. Ведь гораздо проще наобещать с три короба на своем вебинаре, чем реально исправить косяк и сделать свой продукт лучше.
А неугодных пользователей, которые что-то пишут в комментариях в сообществах, проще забанить. Правда?
66415
Жаль, что вроде бы изначально неплохая задумка скатилось в такой унылый продукт.
Может все-таки стоит перестать водить людей за нос и попытаться сделать свой продукт лучше?
Вам не надоело возиться с этой инновационной средой? Давно бы уже переехали на что-то другое.
На счет неплохой задумки, окна то разделять по разным мониторим можно или это недоступно и требуется все время работать в одном окне, где все понатыкано?
b_aleks2
10.03.2023, 12:28
Вам не надоело возиться с этой инновационной средой? Давно бы уже переехали на что-то другое.
Вот бы еще кто-то деньги вернул за этот продукт и потраченное время. Знал бы изначально, во что ввязался, остался бы на третьей версии.
На счет неплохой задумки, окна то разделять по разным мониторим можно или это недоступно и требуется все время работать в одном окне, где все понатыкано?
Как раз в этой версии появилась такая возможность. Спустя пять лет :)
P.S. Ну и если бы они честно заявляли о возможностях своего продукта, то люди бы не вляпались бы по незнанию
Напишите претензию и сделайте даунгрейд на 3-ю версию... Другого выхода я не вижу...
Имхо, лучше сперва пробовать, прежде чем покупать, меня только одно редактирование пустого проекта после пробы ввергло в уныние, дальше даже смотреть не стал...
kondor3000
10.03.2023, 13:42
Как только поставил 4D посмотреть, пощупать, сразу понял, что это глючный шлак. Так и оказалось, многократно подтверждено другими.
Пусть сами свой продукт и хавают.
Виктор Момотов
11.03.2023, 01:00
Прокомментирую вопросы со стороны разработчика MasterSCADA 4D
Небольшое лирическое отступление. Чтобы вы понимали, по мнению разработчиков из МПС Софт, многопоточная работа с БД выглядит следующим образом.
66416 66417
То есть 4 потока PostgreSQL и 27 потоков MasterSCADA 4D распределены всего лишь на два физических ядра, из восьми доступных. Если считать по логическим ядрам, представленным на скринах, то используются только 4 из 16.
В Firebird чтение и запись в БД выполнялись всегда в одном потоке. В Postgre есть отдельный поток на запись, а чтение выполняется синхронно из вызывающего потока. На данный момент сценариев, где параллельные потоки выполняют операции чтения из БД немного, но при параллельной компиляции отдельных узлов это на некоторых проектах будет давать эффект. Одна из задач этих доработок - поддержка многопользовательского режима в дальнейшем.
В новой версии обновили протокол Modbus. Ну как обновили, выдали некоторые исправленные ошибки за реализацию новой функции
Новый драйвер Modbus был разработан с нуля, значительно расширен функционал -
Поддержка строк
Поддержка асинхронного опроса для повышения скорости опроса
Поддержка групповой записи нескольких тегов в одном запросе
Для устройства реализовано окно импорта и группового редактирования тегов –
Импорт из CSV, XLSX, Modbus Universal, Segnetics SM Logix.
Фильтрация дерева тегов по имени, адресу, типу данных сервера и устройства, региону, а также отдельным тегам.
Возможно выделения (в том числе группового) тегов. Через контекстное меню.
Групповые операции с отмеченными тегами - изменение адрес, региона, типа доступа, типа данных и шкалы.
Возможность редактирования отдельных тегов.
2. Итак, с горем пополам обновили проект, давайте попробуем его экспортировать, чтобы загрузить в исполнительную систему.
Пришлось закрыть программу из панели задач, но в диспетчере задач процесс остался, пришлось его "убить".
3. Выгрузить проект не получилось. А может быть мешают какие-то ошибки в проекте? Так давайте это проверим.
Проверяем конфигурацию узла. Вот видео: https://disk.yandex.ru/i/YsXSFmH6accA4g
Не трачу время 14 минут впустую, программа зависает, нагрузка на CPU такая же, как и в предыдущих пунктах - два ядра из восьми, общая нагрузка не более 15 %
В командах "Проверить конфигурацию" и "Экспорт конфигурации" была недоработка, из-за чего при наличии предупреждений или ошибок в проекте могло произойти зависание среды разработки. В версии 1.3.1 исправление будет ориентировочно во вторник.
При это команда "Подключить" работала корректно, по завершению компиляции выдавался список предупреждений/ошибок.
На исправленной версии я получил такие результаты на вашем проекте -
Первая компиляция сразу после открытия проекта (кеш окон еще не создан) - 13:25 (https://www.screencast.com/t/fDnRRkYsqQGp)
Повторная компиляция - 1:08 (https://www.screencast.com/t/YOixL8t2iS)
Первая компиляция сразу после открытия проекта (кеш окон был ранее создан) - 5:48 (https://www.screencast.com/t/dpYLPkgV4z5R)
По работе с PostgreSQL ответим позднее.
8. Попытка скопировать остальную часть проекта не увенчались успехом.
Методом прямого копирования не получается, поскольку вылетает ошибка, что копируемый объект не является экземпляром объекта.
В случае подобных ошибок просьба присылать отчет об ошибках в техподдержку
рука-лицо, я наконец-то понял, зачем придумали пасьянсы и другие подобные игры, чтобы занять время, пока там что-то пытается компилироваться по 6 и более минут :(
В Firebird чтение и запись в БД выполнялись всегда в одном потоке. В Postgre есть отдельный поток на запись, а чтение выполняется синхронно из вызывающего потока. На данный момент сценариев, где параллельные потоки выполняют операции чтения из БД немного, но при параллельной компиляции отдельных узлов это на некоторых проектах будет давать эффект. Одна из задач этих доработок - поддержка многопользовательского режима в дальнейшем.
Тогда я не совсем понимаю, почему должна повысится производительность и скорость работы редактора проектов. Что тогда подразумевают Ваши сотрудники, когда на своих вебинарах заявляют, что в версии 1.3.1 решены проблемы быстродействия и ресурсоемкости редактора проектов?
То есть Firebird и так был медленным по причине однопоточности чтения и записи, но Вы решили еще где-то сбоку нагородить взаимодействие с Postgree, которое, по Вашим же словам, даст выигрыш только в НЕКОТОРЫХ проектах. Пока что это выглядит, как flex tape meme.
В командах "Проверить конфигурацию" и "Экспорт конфигурации" была недоработка, из-за чего при наличии предупреждений или ошибок в проекте могло произойти зависание среды разработки. В версии 1.3.1 исправление будет ориентировочно во вторник.
При это команда "Подключить" работала корректно, по завершению компиляции выдавался список предупреждений/ошибок.
Это кстати то, о чем я писал в комментариях в Вашем телеграмм канале. Лишь бы побыстрее выкатить релиз, а то, что в нем есть ошибки, никого не волнует. Надо же побыстрее выкатить пресс-релиз, в котором будет написано, какие Вы молодцы.
На исправленной версии я получил такие результаты на вашем проекте -
Первая компиляция сразу после открытия проекта (кеш окон еще не создан) - 13:25 (https://www.screencast.com/t/fDnRRkYsqQGp)
Повторная компиляция - 1:08 (https://www.screencast.com/t/YOixL8t2iS)
Первая компиляция сразу после открытия проекта (кеш окон был ранее создан) - 5:48 (https://www.screencast.com/t/dpYLPkgV4z5R)
Я кончено, не знаю, какие спеки Вашего компутера, но Вам не кажется, что 13 минут - это слишком много?
Для сравнения, на своем ПК сделал компиляцию сразу после открытия проекта на версиях 1.2.16 (https://disk.yandex.ru/i/ip3oEmGt0_7eyg) и 1.3.1 (https://disk.yandex.ru/i/DyvM8O1lJyGpyQ) - 7 и 5 минут соответственно. Небольшая разница, согласитесь. Все-таки ждешь вау-эффекта, когда Ваши сотрудники делают такие публичные заявления. Но тут можно парировать словами классика о том, что ваши ожидания - ваши проблемы.
Собственно, вопрос то простой. Почему два ядра используются в большинстве операций? Зачем Вы даете такие рекомендации по системным требованиям к среде разработки? Ведь по сути, в большинстве операций, мой компутер просто простаивает.
В случае подобных ошибок просьба присылать отчет об ошибках в техподдержку
Если честно, то уже нет никакого желания. Во-первых, потому что уже сложилось впечатление, что у Вас нет какой-то цели сделать продукт лучше, просто идете какой-то дорогой. Во-вторых, я решил остаться на 1.2.16, потому что я не вижу чего-то принципиально хорошего, что могло бы побудить меня обновиться до текущей версии. Да и технического сопровождения у меня нет, смысла платить за него я не вижу, да и слишком хлопотно (спасибо всяким ФЗ и прочему шлаку) стало в моей конторе приобретать разного рода продукцию.
b_aleks а что там с ФЗ ? российское ПО? так целая масса его, даже под Linux, хоть Орел, хоть РЭД. При чем даже среду разработки можно будет запустить под Wine если потребуется.
b_aleks а что там с ФЗ ? российское ПО? так целая масса его, даже под Linux, хоть Орел, хоть РЭД. При чем даже среду разработки можно будет запустить под Wine если потребуется.
Я не силен в сфере закупок, но чтобы приобрести какой-то продукт, стоимостью более 10 000 рублей, мне надо запросить три КП, написать служебку, написать ТЗ, подписать всю эту макулатуру. После это будет торговаться через какой-то электронный магазин. В то время, как раньше я мог просто оплатить это напрямую по счету. Честно говоря, мне еще просто лень заниматься этой тупой работой, поэтому это также одна из причин, почему я не покупаю их саппорт.
И с каждым годом, такого рода шлака в виде законов и требований становится все больше и больше.
Хм, используйте бесплатное ПО, после внедрения докупайте платный функционал.
Но даже в плане если не занимаетесь закупками, своим закупантам покажите другой(ие) продукт(ы) из которых вас устроит функционал, даже если изначально оно все платное.
по мне, так я лучше тот же симплайт возьму, чем вот это вот поделие... Хотя..., ищите во всем плюсы, с такой средой разработки хоть выспаться можно прямо на работе :)
с такой средой разработки хоть выспаться можно прямо на работе :)
этим и занимаюсь :D:D:D:D:D:D
Виктор Момотов
11.03.2023, 09:39
Тогда я не совсем понимаю, почему должна повысится производительность и скорость работы редактора проектов. Что тогда подразумевают Ваши сотрудники, когда на своих вебинарах заявляют, что в версии 1.3.1 решены проблемы быстродействия и ресурсоемкости редактора проектов?
То есть Firebird и так был медленным по причине однопоточности чтения и записи, но Вы решили еще где-то сбоку нагородить взаимодействие с Postgree, которое, по Вашим же словам, даст выигрыш только в НЕКОТОРЫХ проектах. Пока что это выглядит, как flex tape meme.
В Firebird выигрыш за счет кеширования результатов компиляции окон и многопоточной компиляции (Повторная компиляция - 1:08 (https://www.screencast.com/t/YOixL8t2iS)).
Что касается ресурсоемкости, то тут дело в том, что при наличия кеша окна не загружаются в память вообще, на видео 2 и 3 там видно, что память не превышает 6Гб, а при первой компиляции пока кеш не создан, расход был выше.
Выигрыш с Postgree будет на всех проектах, хотя бы за счет того, что процедура чтения из него выполняется в 4 раза быстрее. Также при работе происходит выгрузка неиспользуемых элементов, что снижает расход памяти. Позже напишем на данном проекте какие будут результаты.
Особенность этого проекта, что в нем никак не задействованы экземпляры, однотипные объекты с окнами просто продублированы много раз. Но за счет кеширования повторные запуски в процессе работы занимают минуту вместо 10 как было на 1.2 (на ней у меня компиляция после открытия заняла 14 минут, из них 4 - загрузка элементов и 10 - собственно компиляция, память доходила до 16Гб https://www.screencast.com/t/IDa2HYVEkSh)
Я кончено, не знаю, какие спеки Вашего компутера, но Вам не кажется, что 13 минут - это слишком много?
Для сравнения, на своем ПК сделал компиляцию сразу после открытия проекта на версиях 1.2.16 (https://disk.yandex.ru/i/ip3oEmGt0_7eyg) и 1.3.1 (https://disk.yandex.ru/i/DyvM8O1lJyGpyQ) - 7 и 5 минут соответственно. Небольшая разница, согласитесь. Все-таки ждешь вау-эффекта, когда Ваши сотрудники делают такие публичные заявления. Но тут можно парировать словами классика о том, что ваши ожидания - ваши проблемы.
13 минут - это только первый раз после конвертации, пока не созданы кеши. В дальнейшем окна будет перекомпилироваться с подгрузкой из БД только при их изменении или зависимых библиотечных элементов.
5 минут - это первый раз после открытия. Обычно проект открывают и работают с ним, вот в ходе этой работы повторные запуски будут укладываться в минуту. В ходе проверки этого проекта были сделаны некоторые оптимизации, в 1.3.1 попадут также ориентировочно во вторник
Собственно, вопрос то простой. Почему два ядра используются в большинстве операций? Зачем Вы даете такие рекомендации по системным требованиям к среде разработки? Ведь по сути, в большинстве операций, мой компутер просто простаивает.
На моем видео видно, что во время компиляции окон загрузка доходит до 50% при 16 потоках (i7 11800H). Если бы в проекте было бы несколько узлов или несколько задач в узле, то параллельность была бы не только для мнемосхем.
Если честно, то уже нет никакого желания. Во-первых, потому что уже сложилось впечатление, что у Вас нет какой-то цели сделать продукт лучше, просто идете какой-то дорогой. Во-вторых, я решил остаться на 1.2.16, потому что я не вижу чего-то принципиально хорошего, что могло бы побудить меня обновиться до текущей версии. Да и технического сопровождения у меня нет, смысла платить за него я не вижу, да и слишком хлопотно (спасибо всяким ФЗ и прочему шлаку) стало в моей конторе приобретать разного рода продукцию.
Обращения об ошибках принимаются от всех пользователей, даже кто использует демо-версию или бесплатную
dreambelarus
11.03.2023, 11:28
Вот сижу читаю так как в недалеком будущем что то да приобрету MS4D уже чуть было не купил под проект под 4000 тегов... но решил посмотреть конкурентов как говорится чтобы не было мучительно больно... мне интересно в компании нет Бета тестировщиков???? что так после релиза быстро заплатки применяются...как то нехорошо в части имиджа...
....Если бы в проекте было бы несколько узлов или несколько задач в узле, то параллельность была бы не только для мнемосхем... а есть реальный пример данного подхода и насколько выигрыш в производительности... допустим планирую скаду второго уровня тогда каждую опрашиваемую скаду первого уровня сделать отдельным узлом???
И при выборе железа в виде отдельного компа может есть оптимальные рекомендации с учетом "прожорливости" при апгрейде и новых фитчах в будущем
( в финансах не ограничен не люблю тормознутые системы могу сломать нечаянно как я понял в 28 ядер смысла нет)
В Firebird выигрыш за счет кеширования результатов компиляции окон и многопоточной компиляции (Повторная компиляция - 1:08 (https://www.screencast.com/t/YOixL8t2iS)).
Что касается ресурсоемкости, то тут дело в том, что при наличия кеша окна не загружаются в память вообще, на видео 2 и 3 там видно, что память не превышает 6Гб, а при первой компиляции пока кеш не создан, расход был выше.
Выигрыш с Postgree будет на всех проектах, хотя бы за счет того, что процедура чтения из него выполняется в 4 раза быстрее. Также при работе происходит выгрузка неиспользуемых элементов, что снижает расход памяти. Позже напишем на данном проекте какие будут результаты.
Вы сейчас пытаетесь навязать то, что при каких-то определенных условиях, будь то повторная компиляция или кеширование элементов, редактор будет работать быстрее.
Я не знаю, как большинство пользователей пользуется и работает с Вашим редактором, но опишу свое видение, почему я вообще затрагиваю эту тему. У меня есть готовый проект, который работает уже не первый год. И в большинстве случаев мне требуется либо поменять что-то в настройках протокола (в связи с заменой оборудования), либо добавить какой-то новый объект дублированием другого и последующим исправлением. А после переоткрыть редактор, чтобы освободить ОЗУ, и экспортировать проект. То есть получаем случай из Вашего первого видео - ждем 6 минут. А Вам самому нравится ждать такое время?
Особенность этого проекта, что в нем никак не задействованы экземпляры, однотипные объекты с окнами просто продублированы много раз.
Да, я уже слышал от Ваших коллег, что мой проект сделан не совсем правильно, но я не вижу в этом ничего плохого.
Во-первых, с учетом того, сколько у Вас раньше было ошибок, я решил делать проект как можно проще, простота и надежность.
Во-вторых, все объекты у меня чем-то отличаются, поэтому делать кучу экземпляров на каждый уникальный элемент я не вижу смысла. То, что это как-то ускоряет разработку проекта - сомнительный аргумент. С учетом однотипной иерархии объектов и однотипным именованием элементов, дублированием я сделаю все гораздо быстрее, чем буду выискивать те самые "кирпичики", из которых мне требуется построить объект. В третьей версии Вашего продукта у меня был проект, который мне достался в наследство. Там все объекты были свалены в одну кучу, было много лишних элементов и связей, но почему-то все работало достаточно шустро.
В-третьих, переделывать такой большой проект, работа которого меня полностью устраивает, я не вижу смысла. Мое мнение в этом вопросе останется прежним - это не проект какой-то особенный, что он так долго экспортируется и тормозит, это редактор проектов такой особенный, что попросту не тянет.
13 минут - это только первый раз после конвертации, пока не созданы кеши. В дальнейшем окна будет перекомпилироваться с подгрузкой из БД только при их изменении или зависимых библиотечных элементов.
5 минут - это первый раз после открытия. Обычно проект открывают и работают с ним, вот в ходе этой работы повторные запуски будут укладываться в минуту. В ходе проверки этого проекта были сделаны некоторые оптимизации, в 1.3.1 попадут также ориентировочно во вторник
Несколько раз перечитал, но так и не понял. О какой минуте идет речь? При описанном выше сценарии моей работы будет также 5 минут.
На моем видео видно, что во время компиляции окон загрузка доходит до 50% при 16 потоках (i7 11800H). Если бы в проекте было бы несколько узлов или несколько задач в узле, то параллельность была бы не только для мнемосхем.
Давайте не будем передергивать. Во-первых, до 50% загрузка доходила на короткий промежуток времени; большую часть времени Ваш процессор, так же, как и мой, находился в простое, нагрузка в среднем была 10-20%. Во-вторых, ни на одном из Ваших видео я так и не увидел нагрузку по ядрам. Почему-то я уверен, что там также будет загружено два ядра из восьми. В чем такая проблема реализовать использование всех ресурсов процессора и диска? При чем независимо от того, сколько там у меня узлов в проекте и какую операцию я делаю.
Почему какой-то винрар при архивировании небольшого файла стабильно (без всяких скачков) грузит все ядра? Почему Ваш продукт так не может?
66441
Вот сижу читаю так как в недалеком будущем что то да приобрету MS4D уже чуть было не купил под проект под 4000 тегов... но решил посмотреть конкурентов как говорится чтобы не было мучительно больно... мне интересно в компании нет Бета тестировщиков???? что так после релиза быстро заплатки применяются...как то нехорошо в части имиджа...
На хх.ру висят вакансии тестировщиков. Может как раз и не хватает рук.
....Если бы в проекте было бы несколько узлов или несколько задач в узле, то параллельность была бы не только для мнемосхем... а есть реальный пример данного подхода и насколько выигрыш в производительности... допустим планирую скаду второго уровня тогда каждую опрашиваемую скаду первого уровня сделать отдельным узлом???
Узел - это реальное физическое устройство, в которое будет грузиться проект. Поэтому Ваш вопрос не совсем понятен)
Виктор Момотов
11.03.2023, 13:48
Надо разделять требования к исполнительной системе и среде разработки. В исполнительной системе все задачи, драйвера и внутренние службы работают в отдельных потоках, кроме того можно на одном сервере запускать несколько экземпляров системы с разными проектами или частями проектов. Так что тут все ядра легко задействовать.
Для среды разработки важен объем памяти (32+ для больших проектов), SSD диск. Дополнительные ядра могут ускорить процесс компиляции, как описано выше. В обсуждаемом выше проекте 5тыс внешних тегов, но из-за того что никак не используется типизация, получилось очень большое кол-во отдельных программ и окон, которые приводили к долгой компиляции (также при распаковке дискретных сигналов число реальных получается больше, чем внешних).
Для среды разработки важен объем памяти (32+ для больших проектов), SSD диск.
Я кстати не заметил, чтобы и SSD особо нагружался. Те средние показатели, которые выдает MS4D, вполне потянет обычный HDD.
Дополнительные ядра могут ускорить процесс компиляции, как описано выше.
Так не ускоряют же, Вы сами не видите что ли? Почему Вы не можете прямо ответить на вопрос? Почему два ядра используются из восьми? Из-за "особенностей" моего проекта? Если только из-за этого, то это полнейший бред, как мне кажется.
В обсуждаемом выше проекте 5тыс внешних тегов, но из-за того что никак не используется типизация, получилось очень большое кол-во отдельных программ и окон, которые приводили к долгой компиляции (также при распаковке дискретных сигналов число реальных получается больше, чем внешних).
Ну так сделайте для таких проектов многоядерную компиляцию. Что это за двойные стандарты? Тут мы сделаем поддержку многоядерности, а вот если пользователь решил по-другому принципу сделать свой проект, то пусть он мучается. Так получается? Ну смешно же.
Вот бы еще кто-то деньги вернул за этот продукт.
И сколько заплатили, если не секрет ?
И сколько заплатили, если не секрет ?
Если с нуля брать по тем лицензиям, которые у меня сейчас, то там сильно дорого будет. Больше полмульта. У меня обновление было с третьей версии на четвертую, по сути небольшие деньги были, тысяч сто может. Плюс саппорт (надо же обновляться из-за косяков!) для четырех ключей еще может около сотни.
dreambelarus если вам нужно распределение, когда Scada может быть элементом нижнего уровня посмотрите на другие...
100 тысяч за 5 тысяч тегов? и это не с нуля?, свят-свят.... :)
основная проблема крупных компаний - текучка кадров среди программистов. К сожалению... я тут 3-тью неделю от одних гавриков не могу получить ответы на простые вопросы...
Так же было достаточно сложно общаться в том числе и с Овен, когда делал драйвер для облака Овен на их API. Исходя из подходов было видно, что делалось это совершенно разными людьми...
И 2-я проблема, приходится общаться через менеджеров, а не непосредственно с разработчиками....
Если с нуля брать по тем лицензиям, которые у меня сейчас, то там сильно дорого будет. Больше полмульта. У меня обновление было с третьей версии на четвертую, по сути небольшие деньги были, тысяч сто может. Плюс саппорт (надо же обновляться из-за косяков!) для четырех ключей еще может около сотни.
А контроллер у вас какой ?
А контроллер у вас какой ?
Никакой. Все лицензии, которые есть, для ПК.
dreambelarus
13.03.2023, 05:10
dreambelarus если вам нужно распределение, когда Scada может быть элементом нижнего уровня посмотрите на другие.......
На нажних урoвнях у меня и MS3 и другие....будет тунеллер инсатовский для проброса DA со стороннего ОРС....мне больше нужен надежный функционал в части логических задач для контроля временых интервалов между процессами подсчет объемов...этакий а-ля MES...как в этой части оцениваете MS4D
И про вашу реализацию api с овеноблаком если есть в открытом доступе поподробнее пожайлуста...есть у меня одна задумка в такой связке контролировать пару тегов через их мобильное приложение используя готовый функционал груповых политик... может направите на путь истинный...
dreambelarus MS4D не оцениваю никак, так как терпения на нее не хватает. Пока ядро не перепишут, чтобы не ощущать себя в 2000-м году, я к этой системе не подойду...
Не совсем понял про облако? мой драйвер облака для RapidScada платный, + если надо перегонять данные из прибора в прибор, используя облако, потребуется еще Модуль автоуправления от разработчика Scada (тоже платный)
К их мобильному приложению не относится ни то ни другое. Вся инфа есть на сайте RapidScada. А, ссылку на драйвер тут тоже выкладывал в разделе про облако.
dreambelarus в плане туннелера или подобного, зависит что у вас там за оборудование опрашивается. в 6-й версии Rapid позволяет включить на опрашиваемые приборы OPC UA сервер.
И когда автор портирует на 6-ку Modbus slave тоже можно использовать, но он к сожалению платный и для мелких задач дороговат получается...
Особенность этого проекта, что в нем никак не задействованы экземпляры, однотипные объекты с окнами просто продублированы много раз.
Если вы считаете ошибкой не задействовать экземпляры, то уберите возможность использовать наследников. Сделайте только экземпляры.
Тем более, если в библиотечный объект добавить сообщения (Тревоги), то в экземплярах их использовать нельзя, они удаляются. Доступны только в наследниках.
Интересно, в 1.3.1 добавили возможность использовать TagPrefix? Было упоминание про некие ссылки на объекты.
Событие - "Открытие окна" добавили? :)
Событие - "Открытие окна" добавили? :)
В WhatsNew пишут что добавили. Но там вообще много чего пишут что потом обычно не работает, так что все нужно тестировать самостоятельно.
b_aleks2
13.03.2023, 11:02
Если вы считаете ошибкой не задействовать экземпляры, то уберите возможность использовать наследников. Сделайте только экземпляры.
Да, вот тоже этого не понимаю. То есть наследники вы можете использовать, но вы будете страдать. Круто :)
... но вы будете страдать. Круто :)
Спустя месяцы знакомства с MS4D кажется совершенно очевидным, что единственной целью разработчиков является сделать так, чтобы пользователи страдали от всего....
Larrrik зато вас избавляют от бесплатных страданий :)
b_aleks2
13.03.2023, 16:21
Спустя месяцы знакомства с MS4D кажется совершенно очевидным, что единственной целью разработчиков является сделать так, чтобы пользователи страдали от всего....
Ага, страдать и каяться...
b_aleks2
14.03.2023, 08:42
Особенность этого проекта, что в нем никак не задействованы экземпляры, однотипные объекты с окнами просто продублированы много раз.
Небольшой апдейт по поводу Вашей объектной модели. Вы сами вообще представляете, как использовать экземпляры, где каждое окно (даже если оно сильно похоже на такое же окно другого объекта) уникально? Такая же ситуация с программами. С учетом того, что экземпляры редактировать и видоизменять нельзя, то я слабо представляю, как их использовать в таком проекте. Каждое уникальное окно или программу кидать в библиотеку, а в дереве использовать их как экземпляры? Никакого выигрыша в скорости работы проекта в редакторе не будет.
И еще. Что значит "особенность" проекта? Вы сами везде заявляете, что Ваша платформа такая чудесная и прекрасная, что подходит под разработку проектов любого масштаба и сложности. Или как обычно, пользователи все не так поняли? В очередной раз убеждаюсь, что заявления Ваших менеджеров или кого-то еще абсолютно оторваны от реальности.
Виктор Момотов
15.03.2023, 23:50
Вы сейчас пытаетесь навязать то, что при каких-то определенных условиях, будь то повторная компиляция или кеширование элементов, редактор будет работать быстрее.
Я не знаю, как большинство пользователей пользуется и работает с Вашим редактором, но опишу свое видение, почему я вообще затрагиваю эту тему. У меня есть готовый проект, который работает уже не первый год. И в большинстве случаев мне требуется либо поменять что-то в настройках протокола (в связи с заменой оборудования), либо добавить какой-то новый объект дублированием другого и последующим исправлением. А после переоткрыть редактор, чтобы освободить ОЗУ, и экспортировать проект. То есть получаем случай из Вашего первого видео - ждем 6 минут. А Вам самому нравится ждать такое время?
В случае Firebird действительно так. Из 6 минут процесса компиляции 4:30 заняла загрузка элементов из БД (грузится все кроме кешированных окон).
Провел аналогичный тест после конвертации этого проекта в Postgre - https://www.screencast.com/t/ElWJztcAD
Весь процесс компиляции - 1:17, из этого этап загрузки элементов всего 15 сек. Даже если суммарно смотреть от старта приложения по конца компиляции 1:50, в случае Firebird - 6:43
Первая компиляция сразу после открытия проекта (кеш окон еще не создан) - это видео запишу позже, там тоже ускорение относительно Firebird. По работе с Postgre были сделаны некоторые оптимизации, которые пока в версии 1.3.2 Beta. На следующей неделе должны попасть в 1.3.1. Доработки по Firebird, о которых говорил ранее, включены в 1.3.1.31444(MPLCD_1_3_20230314.1)
Как говорил ранее, в Postgre был принципиально изменен механизм, вместо отдельного потока работы с БД, запросы чтения идут синхронно из запрашивающего потока. В этом режиме пришлось отказаться от некоторых оптимизаций на уровне БД, которые неприменимы в многопоточной среде, поэтому отдельные сценарии могли быть даже медленнее, чем в Firebird. Но за счет возможности распараллеливать процессы компиляции и большей скорости работы БД основные сценарии сильно ускорились.
b_aleks2
16.03.2023, 12:10
В случае Firebird действительно так. Из 6 минут процесса компиляции 4:30 заняла загрузка элементов из БД (грузится все кроме кешированных окон).
Провел аналогичный тест после конвертации этого проекта в Postgre - https://www.screencast.com/t/ElWJztcAD
Весь процесс компиляции - 1:17, из этого этап загрузки элементов всего 15 сек. Даже если суммарно смотреть от старта приложения по конца компиляции 1:50, в случае Firebird - 6:43
Первая компиляция сразу после открытия проекта (кеш окон еще не создан) - это видео запишу позже, там тоже ускорение относительно Firebird. По работе с Postgre были сделаны некоторые оптимизации, которые пока в версии 1.3.2 Beta. На следующей неделе должны попасть в 1.3.1. Доработки по Firebird, о которых говорил ранее, включены в 1.3.1.31444(MPLCD_1_3_20230314.1)
Как говорил ранее, в Postgre был принципиально изменен механизм, вместо отдельного потока работы с БД, запросы чтения идут синхронно из запрашивающего потока. В этом режиме пришлось отказаться от некоторых оптимизаций на уровне БД, которые неприменимы в многопоточной среде, поэтому отдельные сценарии могли быть даже медленнее, чем в Firebird. Но за счет возможности распараллеливать процессы компиляции и большей скорости работы БД основные сценарии сильно ускорились.
Так, я все-таки сконвертировал проект в Postgre. Ну что я могу сказать. 25 минут конвертации - это жесть, при этом все также два ядра из восьми нагружены MS4D, в то время как Postgree пашет на всех ядрах (на скрине это видно). После конвертации еще 20 минут ждал, пока проект закрывался, разрастаясь до 20 ГБ в ОЗУ.
66552 66553 66554
Да. То, о чем Вы пишете - экспорт проекта, теперь происходит за полторы минуты. Но и тут такая же ситуация с нагрузкой - MS4D грузит два ядра, Postgre грузит все восемь.
Теперь, что касается других моментов. Если сравнивать мой проект на Firebird с этим же проектом на Postgre, то я не заметил никакой разницы в скорости других операций:
проверку целостности проекта я вообще не смог сделать (ждал 20 минут);
большие окна, где выведены все вложенные объекты, открываются по несколько минут;
мнемосхемы объектов открываются по ~10 секунд;
программы периодически компилируются по ~10 секунд;
деревья раскрываются по несколько секунд;
все вышеописанные операции сопровождаются зависаниями и периодическими "Не отвечает"
И также во всех операциях MS4D нагружает только два ядра. То есть в общем и целом, разницы между Firebird и Postgree нет никакой, за исключением компиляции проекта. Поэтому Ваши слова о каком-то там выигрыше в скорости с Postgre мне не совсем понятны.
Также я замечу, что в процессе компиляции проекта у меня пару раз появлялись рандомные ошибки, которые пропадали после переоткрытия проекта. Также один раз после открытия проекта не подгрузилось дерево одного вложенного объекта, что также дало ошибки при компиляции. Ниже дам ссылку на длинное видео, где показывается все вышеописанное - ошибки компиляции, неподгруженное дерево объекта, зависания и медленная работа проекта.
https://dropmefiles.com/4vuuw
P.S. Вы так и не ответили на главный вопрос. Почему всегда грузятся два ядра в большинстве операций? В таком случае, те рекомендуемые системные требования, которые описаны в справке, не имеют никакого смысла, ведь ПК просто простаивает.
P.S. 2. Сделайте, чтобы при создании БД в Postgre ей сразу давалось нормальное название. А не "ms4d_project_2", в то время как этот проект в редакторе имеет осмысленное название.
Виктор Момотов
16.03.2023, 12:29
И также во всех операциях MS4D нагружает только два ядра. То есть в общем и целом, разницы между Firebird и Postgree нет никакой, за исключением компиляции проекта. Поэтому Ваши слова о каком-то там выигрыше в скорости с Postgre мне не совсем понятны.
Также я замечу, что в процессе компиляции проекта у меня пару раз появлялись рандомные ошибки, которые пропадали после переоткрытия проекта. Также один раз после открытия проекта не подгрузилось дерево одного вложенного объекта, что также дало ошибки при компиляции. Ниже дам ссылку на длинное видео, где показывается все вышеописанное - ошибки компиляции, неподгруженное дерево объекта, зависания и медленная работа проекта.
https://dropmefiles.com/4vuuw
P.S. Вы так и не ответили на главный вопрос. Почему всегда грузятся два ядра в большинстве операций? В таком случае, те рекомендуемые системные требования, которые описаны в справке, не имеют никакого смысла, ведь ПК просто простаивает.
На какой версии вы проверяли? На видео 1.3, но оптимизации по Postgre, как писал выше, пока только в сегодняшней бета версии. Так же в ней исправлены некоторые ошибки с многопоточной компиляцией.
Скорость открытия окон посмотрим также, но там могут быть уже тормоза из-за визуализации WPF а не БД.
По распараллеливанию процесса компиляции и загрузки проекта в Postgre еще есть идеи, как доработать. В ближайшее время постараемся сделать.
большие окна, где выведены все вложенные объекты, открываются по несколько минут;
Какое именно окно открывали? На видео не увидел.
b_aleks2
16.03.2023, 12:37
На какой версии вы проверяли?
Версия: 1.3.1.31444(MPLCD_1_3_20230314.1)
Какое именно окно открывали? На видео не увидел.
66556
Скорость открытия окон посмотрим также, но там могут быть уже тормоза из-за визуализации WPF а не БД.
Тормозят не только окна, но и программы, раскрытие деревьев и прочее. Смысл одни окна править, если наверняка это какая-то общая проблема, что весь редактор какой-то неповоротливый.
Виктор Момотов
19.03.2023, 20:30
Да. То, о чем Вы пишете - экспорт проекта, теперь происходит за полторы минуты. Но и тут такая же ситуация с нагрузкой - MS4D грузит два ядра, Postgre грузит все восемь.
После некоторых доработок Postgre провел новые тесты на бета версии 1.3.2 -
1. Компиляция после открытия проекта и сброса кеша - 3:03 https://www.screencast.com/t/j6Qb6bbA (начиная с этапа компиляции мнемосхем видно, что загружены все ядра, но в начале компиляции 1 минуту идет запрос элементов, пока это не параллелится, но попробуем в этом сценарии это также доработать)
2. Компиляция после открытия проекта - 1:08 https://www.screencast.com/t/FM1aAyS5PVBF
В сравнении аналогичные тесты на Firebird на этой же версии
1. Компиляция после открытия проекта и сброса кеша - 5:54 https://www.screencast.com/t/vxn2GC6B3dp
2. Компиляция после открытия проекта - 4:37 https://www.screencast.com/t/iIAzOZVp6
Ранее было 13:25 и 5:48 (https://owen.ru/forum/showthread.php?t=37553&p=403180&viewfull=1#post403180)
То есть доработки по параллельной компиляции окон также ускорили сценарий пересоздания кеша окон Firebird более чем в 2 раза.
большие окна, где выведены все вложенные объекты, открываются по несколько минут;
мнемосхемы объектов открываются по ~10 секунд;
программы периодически компилируются по ~10 секунд;
деревья раскрываются по несколько секунд;
Действительно в Postgre были неоптимальные запросы загрузки элементов по ссылкам из программ/окон. Поправили это, теперь выглядит так
https://www.screencast.com/t/geCfzz2JThU
Часть изменений будет перенесено в 1.3.1 на следующей неделе. Некоторые оптимизации скорее всего выйдут в рамках 1.3.2 в конце апреля.
Виктор Момотов
20.03.2023, 09:47
Небольшой апдейт по поводу Вашей объектной модели. Вы сами вообще представляете, как использовать экземпляры, где каждое окно (даже если оно сильно похоже на такое же окно другого объекта) уникально? Такая же ситуация с программами. С учетом того, что экземпляры редактировать и видоизменять нельзя, то я слабо представляю, как их использовать в таком проекте. Каждое уникальное окно или программу кидать в библиотеку, а в дереве использовать их как экземпляры? Никакого выигрыша в скорости работы проекта в редакторе не будет.
Если целиком типизировать объект не получается, можно типизировать его отдельные программы/окна, которые совпадают у всех объектов. Еще можно добавить в окно/программу настройки, по которым менять содержимое/поведение, использовать стековую панель/таблицу для отображение динамического набора элементов, привязанного к массиву структур.
b_aleks2
20.03.2023, 10:33
То есть доработки по параллельной компиляции окон также ускорили сценарий пересоздания кэша окон Firebird более чем в 2 раза.
Да, проверил на бета, действительно компиляция стала происходить быстрее. То есть то, о чем я писал изначально, а именно о многоядерной работе редактора, было не зря. Не будь этой темы, неизвестно когда бы Вы это начали исправлять.
Действительно в Postgre были неоптимальные запросы загрузки элементов по ссылкам из программ/окон. Поправили это, теперь выглядит так
https://www.screencast.com/t/geCfzz2JThU
Не совсем заметил разницу. Программы FBD также компилируются более чем 20 секунд (в Postgre вообще было полторы минуты), "тяжелые" окна по четыре минуты (почти две минуты в случае Postgree), окно узла открывается по две минуты (40 секунд в случае Postgre).
Видео с навигацией в проекте с Firebird: https://disk.yandex.ru/i/6u4braa0CNabfQ
Тоже самое, но с Postgre: https://disk.yandex.ru/i/b8ZYHi4FYAFQhQ
Также во время конвертации проекта и обновления библиотек загружены два ядра:
https://disk.yandex.ru/i/AxQGh4m1xj6piA
Как мне кажется, если загрузить все ядра, то может быть эти операции будут осуществляться быстрее. Это я к тому, что есть над чем работать. То есть сейчас, как мне кажется, оптимизирован только процесс компиляции проекта, а остальные операции - не очень.
b_aleks2
20.03.2023, 10:39
Если целиком типизировать объект не получается, можно типизировать его отдельные программы/окна, которые совпадают у всех объектов. Еще можно добавить в окно/программу настройки, по которым менять содержимое/поведение, использовать стековую панель/таблицу для отображение динамического набора элементов, привязанного к массиву структур.
Для примера. Как сделать библиотечное окно с трендом, использовать его с отношением "Ссылается" (ведь только такое отношение ускорит проект), но при этом надо сделать так, чтобы у каждого его экземпляра было разное количество перьев?
b_aleks2
07.04.2023, 14:50
В общем (и целом, конечно), чтобы внести ясность и закрыть эту тему. По заявлению техподдержки, какое-то подобие многопоточной работы (а значит и повышение быстродействия редактора) будет реализовано только в версии 1.3.3 (сейчас 1.3.1). На данный момент остается довольствоваться тем, что есть.
67097
В общем (и целом, конечно), чтобы внести ясность и закрыть эту тему. По заявлению техподдержки, какое-то подобие многопоточной работы (а значит и повышение быстродействия редактора) будет реализовано только в версии 1.3.3 (сейчас 1.3.1). На данный момент остается довольствоваться тем, что есть.
67097
Если не секрет, что там пообещали в пункте 6 ?
b_aleks2
07.04.2023, 16:58
Если не секрет, что там пообещали в пункте 6 ?
Да там вообще были ответы на мои небольшие пожелания к будущим версиям.
Сами пожелания:
67107
И ответ:
67108
Надеюсь саппорт не обидится, если я тут эти скрины выложу :)
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot