PathMaster — разработка ЧПУ системы

[Serg]

Я не понимаю самых основ этого. Т.е. я не понимаю, что это вообще такое (X Window) — кусок линукса, который нужен для вывода чего-то на экран? Т.е. позволит мне в принципе использовать графический интерфейс, если я хочу написать что-то именно под Linux?

Попробуй начать с этого: https://www.google.com/search?q=X+window+что+такое

Я не понимаю, что такое "тулкиты", и что с ними делают. И Яндекс мне в этом не смог помочь.

Ну можно попробовать это слово в переводчик засунуть... Правда в русском переводе оно имеет более узкое значение.
Тулкитом (toolkit) можно назвать например набор из досок, гвоздей, пилы и молотка. С его помощью можно построить дом, сарай, лодку, да много чего...

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

Во первых я очень не люблю термины типа "среда для языка ХХХ". Есть сам язык, есть компилятор или интерпретатор для него, есть текстовый редактор для написание и редактирования текста программ. Всё это и составляет так называемую среду для некоего языка. Виндоюзеров приучили к мысли, что для каждой работы должен быть один универсальный инструмент, например дом надо строить с помощью хреновины, которой можно и пилить доски и забивать гвозди, да ещё и в строймагазин на ней ездить. В мире Unix (Linux там-же) идеология другая - для каждой работы нужно использовать свой, специально предназначенный для конкретной работы инструмент: для пиления пилу, для забивания гвоздей - молоток. Причём обычно можно выбирать гвозди разных размеров и молотки разной степени удобства. Так-же есть текстовые редакторы разной степени удобства, компиляторы и т.п. из них можно набрать удобный инструментарий и назвать его "средой для языка ХХХ".
Ну а если тебе надо, чтобы программа работала и под Windows и под Linux, то нужно выбирать соотв. "тулкит", например Tcl/Tk, Python+Tk, Python+GTK, Java, ...

Вы остановились на С, я так понял. Кросс платформенными окошками для вас на данный момент доступны только Qt.

Не только! Есть ещё GTK, Tk, wxWidget, FLTK, да и не упомнишь всех...

[sidor094]

А на каком уровне будет происходить разделение функций ПК-Контроллер?У меня система ЧПУ автономная на микроконтроллере. Я тоже думал над вопросом разнесения функций часть в пк часть в контроллер. К достоинствам ПК можно отнести возможность построения практически любого интерфейса с пользователем и высокую вычислительную мощность.К недостаткам- сложность построения системы реального времени для генерации движения и низкая надежность(возможность зависания и непонятных торможений).Соответственно можно использовать разные уровни при разделении функций.
1)ПК используется только как интерфейс с пользователем.Отображает координаты,траектории и позволяет вводить команды с клавиатуры или мыши.В таком случае для связи достаточно компорта. Из недостатков можно выделить требование к большой мощности микроконтроллера.Так как программа должна работать внутри его памяти требуется большой её объем.Ну и все расчеты тоже должен делать микроконтроллер.
2)Типа как в ГРБЛ .То есть микроконтроллер обрабатывает только каждую поступившую команду.В данном случае Компьютер может Взять на себя расчеты коррекции на радиус и скорости (для более чем 3 координат).Кроме того Нет требований к объему памяти микроконтроллера.Но остается требование к расчету разгонов- торможений.Ну и дуг.Тут тоже для связи годится компорт.Из недостатков - невозможность выполнения сложных команд (например переходов и вызовов подпрограмм так как если это делать на ПК то приведет к разрушению буфера команд микроконтроллера и соответственно притормаживанию на этих участках) и возможность зависания компьютера .
3)Все вычисления производятся на ПК и передаются в микроконтроллер в виде уже готовых команд с фиксированной частотой выдачи шагов внутри одной команды.Здесь микроконтроллер является только генератором шагов.Из недостатков только возможность зависания компьютера .

[michael-yurov]

при чем тут браузер ??? никто не предлагал вам браузер или в браузере что-то делать.

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

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

Нет, любую не позволяют. Давно ты последний раз пользовался CAD пакетом на удаленном сервере?
Если бы мне было нужно удаленное управление, или разделение одного интерфейса на несколько станков, или наоборот, управление одним станком с разных мест — можно было бы объяснить необходимость клиент-серверной технологии.

Я вообще не понимаю, как все это может касаться пользователя? Мне казалось, что назначение ЧПУ системы — управлять станком. А как именно это она будет делать — ее проблемы.

[michael-yurov]

Виндоюзеров приучили к мысли, что для каждой работы должен быть один универсальный инструмент, например дом надо строить с помощью хреновины, которой можно и пилить доски и забивать гвозди, да ещё и в строймагазин на ней ездить. В мире Unix (Linux там-же) идеология другая - для каждой работы нужно использовать свой, специально предназначенный для конкретной работы инструмент: для пиления пилу, для забивания гвоздей - молоток. Причём обычно можно выбирать гвозди разных размеров и молотки разной степени удобства. Так-же есть текстовые редакторы разной степени удобства, компиляторы и т.п. из них можно набрать удобный инструментарий и назвать его "средой для языка ХХХ".

Кажется я понимаю... Когда windows-пользователю нужно пилить бревна — он покупает бензопилу. А когда Linux-пользователю нужно пилить бревна — он собирает бензопилу из запчастей, или готовых блоков, таких как мотор, редуктор, пильная шина и т.п. от разных производителей.

Не только! Есть ещё GTK, Tk, wxWidget, FLTK, да и не упомнишь всех...

Посмотрел, как выглядят программы, созданные с помощью этого... Все это морально устарело лет 20 назад. И проблема не в программисте, а в инструменте, который не позволяет реализовать интерфейс более удобно.
Может быть я не туда смотрел.

[michael-yurov]

А на каком уровне будет происходить разделение функций ПК-Контроллер?

Сложно однозначно сказать. Где будет удобно для той или иной задачи — там и будет разделение.
Точно не 1 вариант, и, не 2.
Скорее, ближе к третьему. Основная часть вычислений будет, скорее всего, на стороне компьютера. Посмотрю, может быть и микроконтроллер справится, и, тогда, возможно, большую часть распределенных по времени вычислений возьмет на себя он.

[SVP]

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

Зависит от амбиций. Чем больше проект, тем больше выгода.
Де-факто, если хочется легко модифицировать интерфейс, то html+css могут дать неимоверное облегчение.
Могут, потому, что я лично в больших и сложных проектах пока его не использовал.
Но его точно не дадут wpf/swing/javafx/qt, потому что их я использовал и осознаю все ограничения технологии и решений.
Qt кстати неплохой, но со своими заморочками..

В целом-же, разделять всё-равно придется. Нынешние парадигмы программирования так или иначе подразумевают подобное деление.
Да и с точки зрения здравого смысла это очень даже имеет смысл...
Яб предпочел чтобы система управления ЧПУ не была никак завязана на фронтэнд.
Для аварийных случаев есть физическая кнопка останова, всё остальное для работы не нужно.

[Serg]

Нет, любую не позволяют. Давно ты последний раз пользовался CAD пакетом на удаленном сервере?

Я вот таким часто пользуюсь: https://upverter.com

Кажется я понимаю... Когда windows-пользователю нужно пилить бревна — он покупает бензопилу. А когда Linux-пользователю нужно пилить бревна — он собирает бензопилу из запчастей, или готовых блоков, таких как мотор, редуктор, пильная шина и т.п. от разных производителей.

Это обычное мнение тех, кто не в теме. Как правило навязанное со стороны...
Когда Linux-пользователю нужно пилить бревна он не покупает для этого бензопилу, он просто берёт имеющуюся, которой пилил доски и лишь заменяет в ней шину и цепь на более длинные и производительные.
Или более жизненный пример: практически в любом нормальном Linux-дистрибутиве уже имеются редактор Eclipse, компилятор gcc, отладчик gdb и они из коробки уже настроены для написания программ на C (и не только) под Linux. Если-же надо писать например под STM32, то достаточно лишь доустановить gcc-arm, софтинку для программатора и из репозитария Eclipse установить соотв. "настройки" и сразу получаем удобную "среду" для работы с STM32 со всеми прибамбасами как у фирменных коммерческих продуктов.
Ну да ты уже взрослый - не мне тебя переубеждать.

Посмотрел, как выглядят программы, созданные с помощью этого... Все это морально устарело лет 20 назад.

GTK, Qt морально устарели?.. А зачем-же их тогда портируют на винду и маки?.. Ты явно куда-то не туда смотрел...

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

Где-то я это уже слышал... Там было что-то про танцора, которому всё время что-то мешало...

[SVP]

и сразу получаем удобную "среду" для работы

Нет ребяты, тут уже "через край", увы не получаем.
Ну т.е. если мы умеем это делать и делали 3 раза до того - получаем.
А если нет - нет. Получае 100500 часов чтения манов и прочей чухни.
Оказывается, что версии всего чего только можно не совместимы друг с другом, а после
установки всё что только можно требует конфигурации всего чего только можно путем
написания магических фраз в неочевидно находимые места.
Оказывается, что последующие версии интерпретаторов не способны исполнять код,
который исполняли предыдущие. Оказывается, что чтобы получить рабочии версии этих
предыдущих интерпретаторов надо собирать из их исходников. итд итп.
И даже gcc они регулярно "меняют", и это приводит к неэфемерным проблемам.

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

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

[Predator]

Яб предпочел чтобы система управления ЧПУ не была никак завязана на фронтэнд.

Я Мише, об этом уже говорил, такие системы, как Синумерик, Окума именно так и работают! Интерфейс юзера и морда на винде, а контроллер занимается своими делами и ему глубоко пох, зависла морда или нет, он свои функции выполняет независимо.

[Chili]

т.е если зависла морда .то править уже живьем работу станка никак не получится

[Predator]

Не, она потом оживает... Только на работе станка и выполнении заданной траектории, это никак не сказывается, потому и разделяют.

[Chili]

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

[Predator]

я не могу вмешаться

Можешь!
Ну, по крайней мере на вышеописанных системах.

[Mamont]

Э.... а не пробовали писать проги так, чтоб морда (и все остальное) не зависало?

[michael-yurov]

GTK, Qt морально устарели?.. А зачем-же их тогда портируют на винду и маки?.. Ты явно куда-то не туда смотрел...

Приложения на GTK, вроде бы неплохо выглядят.
Попытался проверить вживую... Зашел на сайт:

Почему он так ужасен? Как можно было использовать такой шрифт? Его невозможно читать! Почему разработчик такого серьезного продукта не способен сделать простой сайт?
Ладно, зажмурился, чтобы не смотреть и решил скачать и установить. Нажимаю на ссылку для скачивания дистрибутива под windows... и ничерта не скачивается, а вместо этого мне предлагается добить свой мозг и глаза портянкой на две страницы с инструкцией по скачиванию и установке!
Да, что блин, с этой штукой не так? Почему нельзя сделать один исполняемый файл с вопросом "Установить GTK ?" и двумя кнопками Да / Нет?

GTK, Qt морально устарели?.. А зачем-же их тогда портируют на винду и маки?.. Ты явно куда-то не туда смотрел...

На счет Qt... 400 000 руб. ежегодно за одного пользователя! Серьезно? Ты всерьез считаешь, что это хороший подходящий вариант для меня?
Не, ну сайт у них, конечно, очень прилично и современно выглядит. Тут без вопросов. Но 400 000... ладно бы один раз, но каждый год!..

Нет, любую не позволяют. Давно ты последний раз пользовался CAD пакетом на удаленном сервере?

Я вот таким часто пользуюсь: https://upverter.com

И, как?.. в нем реально комфортно работать, например, с проектом размером в 1 GB?
Да, кстати, у меня этот редактор работает некорректно. Только при 96 DPI он правильно отображается.

[michael-yurov]

Ну да ты уже взрослый - не мне тебя переубеждать.

Я же не прошу меня переубеждать! Я лишь написал о том, что честно пытался сделать программу с поддержкой Linux, но не смог. Потратил на это почти год, и, вроде бы, что-то даже заработало, но насобирал такое огромное количество проблем, нерешаемых в linux, что дальнейшие мучения с линуксом счел нецелесообразными. Потому "выбросил" предыдущий проект и начал заново но лишь под windows. От Win XP, кстати, тоже отказался, т.к. его поддержка привносит слишком много недостатков в ПО.
UAVpilot, ты вот мне пишешь, что в линуксе все можно реализовать, было бы желание (посвятить этому свою жизнь).
Я не сомневаюсь, что все можно... Можно и Виндоус в Линуксе написать.
Но пока что результаты всех советов здесь и моих попыток разобраться привели только к огромным затратам времени, и ни одного реально удачного решения для своей задачи я не увидел. Даже близко не подобрался к чему-то приемлемому.

[michael-yurov]

Не, она потом оживает... Только на работе станка и выполнении заданной траектории, это никак не сказывается, потому и разделяют.

А почему у них интерфейс зависает? Почему не сервер?
Если я открою огромный файл — кто будет его обрабатывать — интерфейс или сервер? И кто зависнет, например, при нехватке памяти? Сервер? И в чем же тогда польза от разделения?
Если у меня внутри одного исполняемого файла интерфейс будет трак же взаимодействовать с вычислительной частью, как у клиент-серверного приложения, и выполняться будет в своем потоке — чем это будет отличаться в работе от разделенной на клиент и сервер программы.
Тем, что я смогу закрыть и снова запустить клиентскую часть без перезагрузки сервера? А зачем это делать, если интерфейс не будет зависать?
Ну, в крайнем случае остановится станок на пол минуту, пока компьютер перезагружаешь (ну если очень уж хочется)... Не вижу в этом большой проблемы.
В конце концов часть серверного функционала можно разместить внутри контроллера. Он все равно будет, и, более того, будет имет независимое питание и независимую аппаратно-вычислительную часть и память.

[SVP]

Не, она потом оживает... Только на работе станка и выполнении заданной траектории, это никак не сказывается, потому и разделяют.

А почему у них интерфейс зависает? Почему не сервер?

Если сделано по-нормальному, то сервер зависает гораздо реже.
Потому как из него убраны все лишние функции.
Тупо проще отладить. Проще покрыть тестами, итд итп.

Если я открою огромный файл — кто будет его обрабатывать — интерфейс или сервер?

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

И кто зависнет, например, при нехватке памяти? Сервер? И в чем же тогда польза от разделения?

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

Если у меня внутри одного исполняемого файла интерфейс будет трак же взаимодействовать с вычислительной частью, как у клиент-серверного приложения, и выполняться будет в своем потоке — чем это будет отличаться в работе от разделенной на клиент и сервер программы.

Надежностью, расширяемостью и многими другими вещами.
Например тем, что в принципе, если апи клиент-сервер простое, то кто угодно сможет написать для вашего сервера клиента.
Такого клиента, как ему удобно. Такого, какого вы себе и вообразить не можете...

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

А зачем внутри контроллера ?
Ведь можно и его внутри одного исполняемого файла держать, правда ведь ?
Вообще без контроллера ?


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

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

[michael-yurov]

Если сделано по-нормальному, то сервер зависает гораздо реже.
Потому как из него убраны все лишние функции.
Тупо проще отладить. Проще покрыть тестами, итд итп.

Что же нужно такое сделать, чтобы интерфейс без вычислительной части завис? Это насколько же нужно накосячить!

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

В моем случае взаимодействие интерфейса с сервером получается очень сложным. По простому мои хотелки в интерфейсе не получится реализовать.

Разумеется, поддерживать апи, делить на части итп - это работа.
Но если проект "серьезный и надолго", то это окупится стократ.

Моя задача — максимально упростить разработку. Иначе я вообще ничего не сделаю. Я сам по себе обладаю очень скромными ресурсами.

В этом смысле в серверной части можно сосредоточится на алгоритмах, а "свистелки" дописывать уже потом на том инструментарии на каком захотите.
Сделать первый прототип при этом можно хоть с командной строкой, хоть еще как, т.е. вообще интерфейса не имея.
И будет работать...

Таких проектов уже много наделали. mach, linuxcnc, kflop,.. "свистелки" за много лет в итоге так никто до конца и не дописал ни на каком инструментарии.
Мне нужно, сделать качественный и удобный полноценный продукт. А чтобы в принципе работало — есть много других вариантов. Можно и не делать вообще ничего, а взять, например, отвечающий за это кусок linuxcnc (многие разработчики ЧПУ систем так и поступили).

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

Ну, вот простой пример — пользователь загрузил УП размером в гигабайт. Может быть вообще открыл файл с удаленного компьютера. Отбросим тот факт, что всю траекторию нужно отобразить в 3d окне. Возьмем простейшую ситуацию — пользователь взял ползунок полосы прокрутки и проматывает файл УП вниз. Как интерфейс будет отображать просматриваемый текст? Кто будет искать в файле строку с номером 10 000 000? Серверная часть ПО? Интерфейсная? Кто-то должен будет зависнуть? Или как вообще? Нельзя перейти к нужной строке не просмотрев все данные в файле до нее. Т.е. нельзя прочитать нужную строку файла, по ее номеру. Нужно или его весь просматривать, или предварительно проиндексирвоать. Такие вещи достаточно сложно реализуются в api взаимодействия интерфейса с сервером. Обычно, разработчики предпочитают существенно сократить функционал интерфейса в угоду более простой реализации взаимодействия.

[Dimka]

Мне кажется, Михаил, если взяли курс на какую-то идеологию построения системы и есть чувство, что с задачей справитесь, то надо делать именно так. Всё-таки, удачный опыт разработки и продажи электроники для ЧПУ у Вас, несомненно, есть (Степмастер). Желаю, чтобы в 2019 году станки зажужжали уже на PathMaster'е.
П.С. Символично с названиями получилось. Говорят ведь, что большой путь (path) начинается с маленького шага (step) .