Сьогодні допилив чорнову версію опису каркасу для ПЛК. Сам каркас (в першій робочій редакції) доробив ще на початку року для Unity PRO + Zenon. Крім того він ліг в основу з певними змінами в новий проект на TIA13. Деякі зміни були принциповими, але я їх не запам'ятав. Щоб не забути все інше вирішив добити хоча б якусь чорнову версію, бо не знаю коли наступного разу до нього доберуся.
Посилання та короткий опис тут http://asu.in.ua/viewtopic.php?f=7&t=1755
Ідея каркасу вже вітає давно, та і вона не нова. Тим не менше, реальні роботи почалися з замовлення "Саутком", яке я так і не доробив з причин "нахватався робіт більше, ніж міг виконати". Сподіваюся, що я їх не підвів, принаймні вони нічого з цього приводу не казали. Їм треба було дещо інше, але дуже близько до цього.
У той же час розробка програм для ГРС потребувала багато функціональності стосовно сервісних функцій. З кожною функцією шанхай ріс, і розробка каркасу для передбачення усіх можливих типових функцій - це була нагайна потреба. Плинний каркас добре ліг з однієї платформи (Юніті) на іншу (ТІА), практично копіпастом. Це суперперрезультат, враховуючи що реальної серйозної перевірки юнітьовський каркас не проходив. Головне не код, а ідеологія. Ті речі, за які переживав, що щось не врахував - практично усі заробили. Так, були ньюанси, але вони не порушують загальної працездатності основних приницпів.
Оба базові рівні "канали" і "змінні" запрацювали. Рівень виконавчих механізмів сильно відрізнявся від демо-проекту (бачки) і реального (ГРС). У останньому використовуються крани, які в наших переробних процесах практично відсутні. Тому ці крани прийшлося допилювати серйозно в ТІАшному проекті. Вилізла необхідність додаткової змінної керування краном CMDPRG яка паралельно йде з CMDHMI, оскільки постійне забивання одного і того ж CMD з програми не давало шансів ЛМІ-шному. Це характерно тільки для обєктів цього левела та вище.
Далі планую, як тільки з'явиться трохи часу (хоча він, собака, вже років десять не з'являється) описати каркас в ппт та і можливо зняти якесь відео. У будь якому випадку, буду намагатися зробити його нашим (кафедральним) корпоративним стандартом. Потрібно перетворювати написання базового рівня програм в трудовий процес а не експерементально-творчий. Тоді можна буде братися за велику об'єкти. Маю на це сподівання.
Посилання та короткий опис тут http://asu.in.ua/viewtopic.php?f=7&t=1755
Ідея каркасу вже вітає давно, та і вона не нова. Тим не менше, реальні роботи почалися з замовлення "Саутком", яке я так і не доробив з причин "нахватався робіт більше, ніж міг виконати". Сподіваюся, що я їх не підвів, принаймні вони нічого з цього приводу не казали. Їм треба було дещо інше, але дуже близько до цього.
У той же час розробка програм для ГРС потребувала багато функціональності стосовно сервісних функцій. З кожною функцією шанхай ріс, і розробка каркасу для передбачення усіх можливих типових функцій - це була нагайна потреба. Плинний каркас добре ліг з однієї платформи (Юніті) на іншу (ТІА), практично копіпастом. Це суперперрезультат, враховуючи що реальної серйозної перевірки юнітьовський каркас не проходив. Головне не код, а ідеологія. Ті речі, за які переживав, що щось не врахував - практично усі заробили. Так, були ньюанси, але вони не порушують загальної працездатності основних приницпів.
Оба базові рівні "канали" і "змінні" запрацювали. Рівень виконавчих механізмів сильно відрізнявся від демо-проекту (бачки) і реального (ГРС). У останньому використовуються крани, які в наших переробних процесах практично відсутні. Тому ці крани прийшлося допилювати серйозно в ТІАшному проекті. Вилізла необхідність додаткової змінної керування краном CMDPRG яка паралельно йде з CMDHMI, оскільки постійне забивання одного і того ж CMD з програми не давало шансів ЛМІ-шному. Це характерно тільки для обєктів цього левела та вище.
Далі планую, як тільки з'явиться трохи часу (хоча він, собака, вже років десять не з'являється) описати каркас в ппт та і можливо зняти якесь відео. У будь якому випадку, буду намагатися зробити його нашим (кафедральним) корпоративним стандартом. Потрібно перетворювати написання базового рівня програм в трудовий процес а не експерементально-творчий. Тоді можна буде братися за велику об'єкти. Маю на це сподівання.
Комментариев нет:
Отправить комментарий