cnc-club.ru

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

Не важно где переключения режимов, кнопки нам все равно местами надо менять

тут дело вот в чем.
если использовать ladder, то конфигурация получается значительно боле гибкая на мой взгляд.
в gladevcp не надо делать тысячу разных кнопок и отображить/скрывать их а достаточно по одному ряду.
скриптом менять текст, который скорее всего можно брать из общего ини файла под каждую из кнопок.
да, сложности есть, но ладдер заточен как раз под подобную работу и отладка нагляднее, кроме того, делая через ладдер можно сделать обратную совместимость с любой из оболочек,
чтобы меняя режим не в gscreen, он в gscreen тоже менялся.
и еще. всем практически, кто строит станок надо знать classic ladder, но знять питон не обязательно.

примеркуска ини файла с текстом кнопок для gscreen
[GSCREEN]
button_v0.0 = текст0
button_v1.0 = текст1
button_v2.0 = текст2
button_v3.0 = текст3
итд
типа lable одной кнопки в режимах 0, 1, 2, и 3.
и в ладдере вся схема у всех будет одинаковая, за исключением выходов.

Давайте чтоб оород не городить особый сделаем вот что:
1) нарисуем в glade три кнопки и текстовую метку
2) накатаем скриптик, который в зависимости от режима будет менять текст на этих кнопках
3) свяжем это дело с halui
в прицепе форма glade и таблица - режим -текст на кнопках и метке
Кто-нть напишите, плз, скриптик, который будет менять текст в соответствии с таблицей.
пропишем это дело в ladder, что проще простого и вуаля.
Оценим трудозатраты.

заодно на реальном примере хоть посмотреть как питон работает

весь текст скрипта ручками пишется?
а можно разжевать как для тупых содержимое def __init__(self)
откуда взялось but1

Lexxa писал(а): def __init__(self)

Это стандартная функция объекта класса, которая вызывается при его создании. Т.е., например, есть класс
class Gscreen:
в нем задаем функцию def __init__(self):

тогда при создании объекта класса obj = Gscreen(),
создастся новый объект класса Gscreen()
вызовется функция __init__, которой в качестве параметра придет ссылка на новый созданный объект (self).
В этой функции можно задать какие-то поля объекта, выполнить инициализацию переменных и т.д.

например если мы напишем в inite
self.x = 10
в последствии наш объект будет иметь переменную x, которую можно получить путем obj.x.

self.gladefile = "1.glade" - просто переменная типа строка

self.builder = gtk.Builder() - это скорее всего специальная штука, которая строит интерфейсы по файлам glade

self.builder.add_from_file(self.gladefile) - собственно его вызываем функцию, которая добавит формочку

self.builder.connect_signals(self) - эта функия должна подключить сигналы, (обычно имена сигналов прописываются в glade)

Дальше просто находим объекты из формы glade с такими-то именами и сохраняем ссылки на них.
self.window = self.builder.get_object("window1")
self.lab = self.builder.get_object('label1')
self.but1 = self.builder.get_object('hal_button1')
self.but2 = self.builder.get_object('hal_button2')
self.but3 = self.builder.get_object('hal_button3')


Завтра на работе попробую со скритиком подсобить.

не понял. бывает не self?
просто я смотрю везде self, разве нельзя как нибудь сказать скрипту, что всё что тут есть это self? т.е. если везде self, то зачем он вообще или всё же бывает не self?
откуда узнать о всяких таких функциях типа connect_signals?
откуда узнать какие объекты есть и какие у них свойтва?

self.gladefile = "1.glade" # переменной gladefile присваевается значение 1.glade
self.builder = gtk.Builder() # типа наверное этот builder подгружается, фиг с ним, пока опустим
self.builder.add_from_file(self.gladefile) # теперь в это подгрузившееся нечто добавляем файлик с описанием интерфейса, сохраненный в переменной gladefile. self означает, что переменная gladefile принадлежет тому же класу внутри которого сейчас мы и пишем? т.е. если у нас несколько классов, например есть еще класс FGHJK, то там тоже может быть переменная gladefile, и если внутри текущего класса мы хотим к ней обратиться, то надо будетнаписать
FGHJK.gladefile = "1.glade" Так?
Builder прочитает файл 1.glade и что? Где написано - нарисуй окошко? или нарисуй окошко получится автоматом после прочтения 1.glade
что сигнал в понятии pygtk? кто источник, кто приемник?
какие сигналы self.builder.connect_signals создаются? кто источник, кто приемник?

p.s. Я понимаю, что это основа основ и она проста (видимо), поэтому и хочу въехать в понятия.

Lexxa писал(а):не понял. бывает не self?

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

Lexxa писал(а):откуда узнать о всяких таких функциях типа connect_signals?

Как искать информацию, смотрим на функцию
self.builder.connect_signals(self)
она пренадлежит builder, а builder
это
self.builder = gtk.Builder()
т.е. ищем ман по pyGTK.
http://developer.gnome.org/pygtk/stable/
А вот по самой функции http://developer.gnome.org/pygtk/stable ... ct-signals
А если поставишь пакет python-gtk-doc и еще devhelp то все эти маны будут у тебя на компе.

PS (http://pygtk.ru/category/Руководства/)

Lexxa писал(а):откуда узнать какие объекты есть и какие у них свойтва?

Есть такая функция dir, она выводит все поля объекта... я обычно по ней что-нибудь ищу, т.е. будет dir(self.builder).

Lexxa писал(а):self.builder.add_from_file(self.gladefile) # теперь в это подгрузившееся нечто добавляем файлик с описанием интерфейса, сохраненный в переменной gladefile. self означает, что переменная gladefile принадлежет тому же класу внутри которого сейчас мы и пишем? т.е. если у нас несколько классов, например есть еще класс FGHJK, то там тоже может быть переменная gladefile, и если внутри текущего класса мы хотим к ней обратиться, то надо будетнаписать

Да, только переменные принадлежат не классу а объекту, класс это просто описание типов объектов, сам по себе он ничего не умеет.

Lexxa писал(а):Builder прочитает файл 1.glade и что? Где написано - нарисуй окошко? или нарисуй окошко получится автоматом после прочтения 1.glade

Скорее всего он просто создаст окошки и всю структуру, чтобы его нарисовать надо будет выполнить
self.window = self.builder.get_object("window1")
self.window. show_all()
Т.е. объекту окошко скажем нарисовать себя и нарисовать все что внутри него.

Lexxa писал(а):что сигнал в понятии pygtk? кто источник, кто приемник?

Насколько я понимаю, например есть сигнал "Нажата кнопка", источник кнопка. К нему можно подключить обработчик - какую-то функцию для этого
button = gtk.Button()
button.connect("clicked", callback, "классная кнопка")
т.е. по нажатии кнопки вызовется функция callback с доп. параметром "классная кнопка"
http://pygtk.ru/pygtk2tutorial/ch-Advan ... dling.html

еще вопрос,
в 1.glade для hal_radiobutton1 есть сигнал GtkToggleButton и есть обработчик on_haradiobuttonl_1_toggled
Откуда взялся этот обработчик? это штатное средство?
здесь вызывается этот обработчик.
Т.е. я могу в таблицу сигналов в Glade записать GtkToggleButton - MyFunc1
а потом в скрипте описать функцию MyFunc1 и когда GtkToggleButton будет true то сама собой вызовется функция MyFunc1?

Lexxa писал(а):MyFunc1

точно
только условились писать с прописной буквы-с заглавной пишем классы(это не ошибка - просто стиль)

ну я образно. суть просто чтоб уловить

вот папка конфигурации с вкладкой Test: скрипт там немного переделан под вкладку

запускается без емс: (c CL)

Lexxa, как ты структурно видишь коммутацию ж.кнопок?
Кнопка =>вход ладдера =>вых ладд => исполн механизм + пин в GUI
Если так - каждой кнопке в коде нужно "назначить" пин
или есть другие соображения?

nkp,
кнопка - вход ладдера - выход ладдера - исп механизм + вход.пин в halui
выход.пин в halui (типа halui.mode.is-auto) - вход ладдера - выход ладдера - результат в gscreen (режимы и прочая фигня) хотя это не обязательно, но ихмо так красивее будет и читабельнее в итоге при конфигурировании под себя.

т.е. типа так

gscreen_on тумблер_mode_auto halui.mode.auto
-------| |--------------| |-------------------+----------( )-------
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$| gscreen.mode.auto
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$|------( )-----------

p.s. доллар вместо пробелов.
nkp, да, каждая кнопка в коде будет иметь пин типа
sw-xpb1
sw-xpb2

ну например в режиме jogging

gscreen_on halui.mode is-auto sw-xpb1 halui.jogging.plus
-------| |--------| |-------------------------| |-------------------+----------( )-------

типа того

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

в halui есть абсолютно всё, для нормального управления. Достаточно разрулить софт-кнопки ладдером.
плюсом сюда давай обсудим хардовые тумблеры и хардовые кнопки.

и определися с понятиями.
Хардовые кнопки - это внешняя кнопки с жестко привязанными функциями независимо от режимов и прочего - cycle start, feed-hold, coolant-off, плюс, минус, быстро.
Софтовые кнопки это кнопки вокруг дисплея.


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

Пины в gscreen нужны для софтовых кнопок и для выбранных режимов, т.е. в итоге
18 кнопок + 6 режимов + несколько текущих состояний (типа программа выполняется, ну иль еще чтонить)

Lexxa писал(а):Пины в gscreen нужны для софтовых кнопок и для выбранных режимов, т.е. в итоге18 кнопок + 6 режимов + несколько текущих состояний (типа программа выполняется, ну иль еще чтонить)

ну вот так я и мыслил