Две программы работают в связке.
1. Первая программа (Flownex) проводит расчет. Результаты расчета (Output) сохраняются в текстовый файл ASCII с названием Output.txt.
2. Вторая программа оптимизатор (modeFRONTIER) считывает переменные из этого файла ASCII, анализирует их. На основании своих внутренних алгоритмов «придумывает» новые Input данные для нового расчета для первой программы Flownex.
3. Дальше вторая программа (modeFRONTIER) сохраняет эти «придуманные» новые Input данные в текстовый файл ASCII с названием Input.txt .
4. Теперь снова первая программа (Flownex) вступает в действие - считывает Input.txt. И проводит расчет.
И так в цикле много тысяч раз.
Проблема. В оптимизаторе (modeFRONTIER) написаны прямые интерфейсы со многими программами. В этом случае расчеты и обмены данными происходят практически мгновенно.
Но к сожалению для Flownex нет прямого интерфейса. Сам расчет во Flownex (Solver Time) от 5 до 10 миллисекунд (то есть 0,05 – 0,1 секунды). Расчет в modeFRONTIER еще меньше. При универсальном стандартном способе обмена через ASCII файл (без прямого интерфейса) идет каждый раз перезапуск, то есть новый старт Flownex. А это пару минут.
Мой коллега (не программист – инженер) написал сам небольшой макрос, и теперь эта связка работает без перезапуска Flownex. Время расчета сократилось с 2 минут до 30-40 секунд. Но это все равно очень много.
Мы увидели следующее:
1. Сам расчет во Flownex (Solver Time) от 5 до 10 миллисекунд (то есть 0,05 – 0,1 секунды). Это я писал выше.
2. Практически мгновенно эти результаты появляются в окошке Flownex. Эти результаты сразу доступны. Можно выделить их мышкой, а также Ctrl+C и Ctrl+V. То есть можно сразу работать с этими данными.
3. Дальше Flownex начинает чтото сканировать. Показывать количество итераций. Может показывать предупреждения или просто информацию.
4. В общем затягивает время. И пока modeFRONTIER считает Output.txt пройде 30 секунд.
Нужно написать макрос, чтобы ждал окончания расчета Flownex (5-10 милисекунд), считывал бы результаты расчета и также быстро бы передавал эти данные в modeFRONTIER. Какие образом? Как быстрее – или тоже через ASCII файл или напрямую через оболочку modeFRONTIER или может быть можно организовать, как-то непрерывными «потоками».
Языки программирования:
Во Flownex можно программировать помощью: CSharp (C#) и Python.
В modeFRONTIER можно программировать с помощью Java
Или же альтернатива внешнее программирование: «Быстрые языки» типа С++, может что-то типа Assembler или в этом направлении.
( сами программы modeFRONTIER Flownex достать не сложно. Как это все конкретно взаимодействует и туториал я предоставлю и покажу).
-
50 2 0 Здравствуйте.
Многое зависит от самих программ, с которыми прийдется работать.
Нужно внимательно рассмотреть их возможности по автоматизации, а в случае неудачи - реализовать через буфер обмена.
В особо запущенных случаях - приходится переписывать функционал программы, но это крайняя мера.
-
68 1 0 Здравствуйте!
Заинтересовала задача. Есть идея как решить без написания макроса. Можно и попробовать с макросом. Пишите в ЛС, обсудим.
-
В личку написал. Жду Вашего ответа.
-
Current freelance projects in the category C#
Refinement of 1C UT 11 for Zebra TSD (RDP): different sound signals when scanning
22 USD
Configuration: 1C UT 11 Address warehouse Zebra TC26 TSD Work via RDP Product scanning is performed in receiving, placement, picking documents, and other warehouse operations. Current problem: Warehouse workers operate through the Zebra TSD. When scanning, they do not always… C#, Databases & SQL ∙ 5 days 5 hours back ∙ 6 proposals |