cnc-club.ru

Имеем: программу управления инвертором через modbus в LinuxCNC
и программу настройки инвертора - естественно, тоже через модбас
Первая регулярно сканирует инвертор, считывая данные.
Как ей сказать "подожди, закрой порт, я хочу пообщаться с инвертором"?
Нужен какой-то флаг межпрограммного обмена. Как его организовать в Linux?

Serg-tmn писал(а):Как ей сказать "подожди, закрой порт, я хочу пообщаться с инвертором"?

закрываешь программу, настраиваешь и запускаешь вновь ЕМС

aftaev писал(а):закрываешь программу, настраиваешь и запускаешь вновь ЕМС

...и когда мне эта процедура надоела, я написал сей пост

обе программы общаются с устройством через один порт ...
для начала работы мастер (программа на компе) инициализирует порт а потом открывает его (на чтение -запись)(mb_param->fd = open(mb_param->device);)
чтоб другая программа нормально могла провести обмен с устройством ,первая наверно должна закрыть порт(close(mb_param->fd))
если все так - то опрос состояния флага добавлять в сами скрипты - если флаг true - то закрываем порт , "передаем" порт другой программе...
(потом опять нужна будет инициализация и открытие - на случай изменения параметров)
а по какому действию должна происходить "смена " программ?
как в работе возникает такая необходимость?

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

Покаж свою программу.
Кстати, если под linuxCNC, можешь добаваить ей пин enable, и потом смотришь, если enable == 1 и порт не открыт - то открываешь, если enable == 0 и порт открыт - закрываешь.

Serg-tmn писал(а):Нужен какой-то флаг межпрограммного обмена. Как его организовать в Linux?

Можно послать сигнал процессу командой/функцией kill.

А вообще непонятно, неужели программа настройки не умеет запускать шпиндель? Настройка ведь не каждый день делается - можно временно оторвать от linuxcnc управление и порулить прогой настройки.

nkp писал(а):обе программы общаются с устройством через один порт ...
для начала работы мастер (программа на компе) инициализирует порт а потом открывает его (на чтение -запись)(mb_param->fd = open(mb_param->device);)
чтоб другая программа нормально могла провести обмен с устройством ,первая наверно должна закрыть порт(close(mb_param->fd))
если все так - то опрос состояния флага добавлять в сами скрипты - если флаг true - то закрываем порт , "передаем" порт другой программе...
(потом опять нужна будет инициализация и открытие - на случай изменения параметров)
а по какому действию должна происходить "смена " программ?
как в работе возникает такая необходимость?

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

UAVpilot писал(а):А вообще непонятно, неужели программа настройки не умеет запускать шпиндель?

Дык, твоя программа-то я только ее подправил под свой инвертор.
И даже кнопки "Start" и "Stop" приладил.
А вот организовать регулярный опрос/отображение параметров было тяжко - плохо у меня с Tcl/Tk
Поэтому подумал, что проще запустить LCNC и vfd.tcl одновременно, а на время выполнения команд Load и Save притормаживать сканирование и освобождать порт. А потом возобновлять и смотреть, что получается.

Serg-tmn писал(а):Только я не знаю, как в линуксе организуются подобные "семафоры".

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

Покаж ссылку на программу!

Ну вот программа настройки (в процессе, так сказать, но работает).

nkp писал(а):мне кажется линукс тут "не нужен" ...
просто сделать передачу в самих программах...

Но как? Где взять "общую площадку" для разных программ?

Serg-tmn писал(а):Дык, твоя программа-то я только ее подправил под свой инвертор.
И даже кнопки "Start" и "Stop" приладил.
А вот организовать регулярный опрос/отображение параметров было тяжко - плохо у меня с Tcl/Tk
Поэтому подумал, что проще запустить LCNC и vfd.tcl одновременно, а на время выполнения команд Load и Save притормаживать сканирование и освобождать порт. А потом возобновлять и смотреть, что получается.

Я уже почти сам догадался.
Регулярный опрос не делал принципиально - довольно долгий процесс.
Можно попробовать встроить vfdctl в прогу...
Изначально так не делал т.к. настройки на модель инвертора сильно по разному делаются.

nkp писал(а):мне кажется линукс тут "не нужен" ...
просто сделать передачу в самих программах.

Средства межпроцессного/межпрограммного общения - это функция ОС.

Как один из вариантов - сокеты. В программе, которой всегда надо управлять движком, стартует серверная часть, и все время слушает сокет. ПРограмма настройки посылает в сокет запрос на доступ к порту для настройки. Если первая прога может отдать контроль порта для настройки, то закрывает на своей стороне порт, и посылает ответ "Все ок. НАстривай". И ждет пока прога настройки сообщит, что настройка закончена. После этого продолжает свою работу.

mhael писал(а):Как один из вариантов - сокеты. В программе, которой всегда надо управлять движком, стартует серверная часть, и все время слушает сокет. ПРограмма настройки посылает в сокет запрос на доступ к порту для настройки. Если первая прога может отдать контроль порта для настройки, то закрывает на своей стороне порт, и посылает ответ "Все ок. НАстривай". И ждет пока прога настройки сообщит, что настройка закончена. После этого продолжает свою работу.

Общий алгоритм я вполне себе представляю. Интересует конкретная реализация. Что такое "сокеты" в линуксе?

Serg-tmn писал(а):Что такое "сокеты" в линуксе?

Они не в линуксе, а в сети. http://www.opennet.ru/docs/RUS/tcltk/tc ... B%F3%E9%F3

mhael писал(а):Как один из вариантов - сокеты. В программе, которой всегда надо управлять движком, стартует серверная часть, и все время слушает сокет. ПРограмма настройки посылает в сокет запрос на доступ к порту для настройки. Если первая прога может отдать контроль порта для настройки, то закрывает на своей стороне порт, и посылает ответ "Все ок. НАстривай". И ждет пока прога настройки сообщит, что настройка закончена. После этого продолжает свою работу.

Чем это лучше сигналов? Тем, что подтягивает библиотеки для работы с сетью?

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

UAVpilot писал(а):Чем это лучше сигналов?

А где хоть слово про "лучше"? Я как программист вообще бы изначально закладывался бы на технологии типа IPC или подобной. Но топикстартеру не стал об этом писать, ибо хорошим советом вряд-ли помогу, а зачем тогда советывать

mhael писал(а):А где хоть слово про "лучше"?

Поясню почему я так спросил:
Сокеты предложены после того, как я предложил сигналы. Просто сокеты и сигналы нет смысла сравнивать - это совсем разные вещи. Но тут сокеты предложены только как средство передачи дискретной информации занято/свободно, что легко реализуется и сигналами. Отсюда и возник такой вопрос.

IPC тоже можно применить (семафоры), но это тоже несколько избыточно и накладно - нужно решать вопросы создания/уничтожения семафоров и т.п.