LINUX.ORG.RU

Система управления испытательным стендом

 


0

1

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

Движением поршня управляет хардварный модуль, висящий на одном из COM портов ПК. С ПК мы говорим модулю с какой силой/амплитудой/скоростью тягать деталь. Этот же модуль пишет данные о силе/положении поршня.

К другому COM порту по RS485 подключены несколько контроллеров ввода-вывода (Тупейшие железяки с кучей реле и дискретных входов), датчики температуры и т.д.

К контроллерам ввода-вывода подключена куча всяких датчиков, клапанов, кнопок, педалей и сигнальных ламп.

Вся логика работы стенда реализована (должна быть реализована) в программе на ПК. Т. е. вплоть до: “Включить насос, подождать пока появиться давление, открыит клапан... сработал такой-то датчик - включить такой-то клапан... юзер нажал педаль - сделать чего-то еще ... и т.д.”

Внимание, вопрос: Где почитаь / подглядеть / у кого спросить как (с точки зрения архитектуры) пишутся такие программы? Как это все граматно спроэктировать? Где можно посмотреть на реализацию подобных систем?

Я четко себе представляю как опросить датчик, открыть клапан или получить и обработать данн.ые. Но я не могу понять как это все увязать в единое целое.

Ответ на: комментарий от Harald

конечный автомат?

юзер нажал педаль

интерактивщина же, состояний овер9000 будет

Stil ★★★★★
()

Что-то сомнительно, что программа нуждается в какой-то «архитектуре».

спроэктировать

Хотя...

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Что-то сомнительно, что программа нуждается в какой-то «архитектуре».

Зависит от количества обратных связей.

ebantrop
()

Ну это совсем просто: .NET Micro Framework + Reactive Extensions

anonymous
()

как (с точки зрения архитектуры) пишутся такие программы

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

Как это все граматно спроэктировать?

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

ArtSh ★★★
()

Я четко себе представляю как опросить датчик, открыть клапан или получить и обработать данные. Но я не могу понять как это все увязать в единое целое.

А я не представляю себе, как можно это не представлять.

Кстати, запускать управляющую программу на компьютере — неправильно. Компьютер должен лишь посылать управляющие сигналы и принимать отчеты. Т.е., скажем, надо нам поршень на 1см подвинуть — даем команду "вперед,10" и ждем отчета "вперед,готово". И т.п.

Ну, а для лентяев есть LabView. Лень делать — плати.

Anon
()

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

Vlad-76 ★★★★
()
Последнее исправление: Vlad-76 (всего исправлений: 1)

Но я не могу понять как это все увязать в единое целое.

Что конкретно непонятно? Судя по описанию система не особо быстрая (ну не ударное же сжатие измеряется). На стороне ПК строится модель. Входы от пользователя (редко) и от датчиков (макс. часто). Командами на модуль отправляются изменения, необходимые для приведения реального состояния к модели.

ziemin ★★
()

Не знаю как ответить сразу всем, поэтому отвечу себе. Короче, вектор движения я понял: «Дали мяч - х**чь!»

Буду писАть большой КА с кучей состояний и вложенных switch-case.

Я в этом деле новичек, поэтому думал что есть какие-то более хитроумные методы решения таких задач.

peroxydeacet0ne
() автор топика

Написать можно все что угодно. Но мне кажется, что COM-порты могут просто не справиться с таким объемом данных одновременно. А ведь управлять и считывать данные нужно своевременно. Как бы не пришлось рассмотреть вариант с платами ввода-вывода на PCI.

Deleted
()
Ответ на: комментарий от Deleted

Справятся. Уже справляются. И система управления уже написана. И даже иногда работает как надо.

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

Старая версия написана на Delphi в стиле «размажь логику по обработчикам нажатий на кнопки. И набросай на форму кучу таймеров в обработчиках которых выполняется какая-то магия».

И разобрать тот код никто не берется. Проще с нуля написать.

peroxydeacet0ne
() автор топика
Ответ на: комментарий от peroxydeacet0ne

Таки писать самому протокол типа CAN или modbus — геморрой тот еще. Лучше уж готовым воспользоваться, чем переписывать логику каждый раз, как понадобится что-нибудь небольшое добавить.

Anon
()
Ответ на: комментарий от Anon

1minute.pdf

Word'97 ... А вообще-то, я все больше склоняюсь к мысли использовать не Word, а Visio. Кстати, я узнал, что существует программа, преобразующая граф переходов, изображенный в Visio, в текст на языке Си, построенный в соответствии с принципами автоматного программирования

хотя да, правда жесть. лучше бы на LaTeX переписал, как белый человек :)

anonymous
()
Ответ на: комментарий от Anon

а какая разница? хотя лучше он бы любую простенькую RTOS в исходниках взял

anonymous
()

Товарищи диванные теоретики.

Вообще-то для таких целей обычно используется связка PLC + SCADA.

Но раз уж у ТС уже имеется что-то работающее и он запостил свой вопрос на на данный «линуксячий» ресурс, то тут уже сам Святой Патрик велел бы сделать все на OpenScada: http://oscada.org/ru/

Там даже не нужно быть программистом, а все собирается как конструктор.

Вот это будет - тру вэй! :)

kuzulis ★★
()
Ответ на: комментарий от kuzulis

Т.е. можно замутить всю логику на PC (раз нету PLC), т.е. создать неплохую такую рабочую станцию с мнемосхемами, трендами (графиками), БД и прочими плюшками. Глядишь, и начальство после этого повысит и будет уважительно глядеть и здороваться. :)

kuzulis ★★
()
Ответ на: комментарий от peroxydeacet0ne

И разобрать тот код никто не берется. Проще с нуля написать.

А в чем именно задача? Сделать программу с GUI под Linux?

Мы делали что-то отдаленно подобное, работающее через UART на C++. Использовали Boost, Qt, CORBA. Но если особая сложность и быстродействие не требуется, можно вообще на Python.

Deleted
()
Ответ на: комментарий от Anon

Таки писать самому протокол типа CAN или modbus — геморрой тот еще. Лучше уж готовым воспользоваться, чем переписывать логику каждый раз, как понадобится что-нибудь небольшое добавить.

А в чём, собственно, геморрой? Общая архитектура такая:

Нижний уровень - работа с шиной данных, BusController, обеспечивает приём/передачу пакетов от хоста к физическим устройствам и обратно. Количество устройств ограничивается только размерностью адреса и скоростью физической шины данных.

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

Верхний уровень - устройство, DeviceController. Включает в себя отдельный поток циклического опроса физического устройства и входную очередь команд, пересылаемых на устройство по мере вычитывания из очереди и независимо от цикла опроса. Для формирования командных пакетов и трансляции ответов использует ProtocolController. Так как опрос устройства и выполнение команд выполняются в разных потоках, для разрешения коллизий используется синхронизация на уровне команд устройства. Количество контроллеров устройств соответствует количеству физических устройств. Устройства могут иметь разный функционал и реализовывать разный набор команд поддерживаемого протокола.

Такая трёхуровневая модель позволяет использовать различные комбинации контроллеров устройств, контроллеров протоколов, шин и подключенных к ним устройств без геморроя с переписывванием логики. Можно, например, подключить 4 устройства, которые будут работать используя 2 разных (но совместимых по адресной сигнатуре) протокола, например, одно - первый протокол и 3 - второй и одну физическую шину. Или, например, по схеме 5-1-3, соответственно. Всё будет зависеть от того, какие протоколы поддерживаются устройствами и сколько физических шин есть в наличии. Все связи устройство-протокол-шина выполняются во время инициализации. Все коллизии разрешаются на соответствующем уровне автоматически, независимо от выбранной конфигурации и без какого-либо перепрограммирования логики. 5 устройств медленно работают на одной шине? Добавь ещё одну, перекинь на неё пару устройств и в конфиге укажи, какие устройства какую шину будут использовать. И всё. Надо поменять логику работы устройства? Унаследуйся от DeviceController, реализуй нужную логику и используй свой класс для экземпляра своего устройства. Это не затронет логику других устройств. Всё просто и логично.

alexku
()

«большой и сильный гидравлический поршень тягает туда-сюда испытуемую деталь»

Я меня встал.

qq6ka
()
Ответ на: комментарий от Deleted

А в чем именно задача? Сделать программу с GUI под Linux?

Да. Задача состоит именно в этом. Все это дело «должно быть написано на языке C» (прям цитата из ТЗ)

Хотя прототип на Python можно попробовать написать.

peroxydeacet0ne
() автор топика

Кстати, если тебе интересны велосипеды, то я когда-то писал систему управления оптоволоконным спектрографом (с веб-мордой). Там 8 железяк висели на общей RS-232. Работали на кривом самописном протоколе (использовался бит четности для определения направления передачи + три бита команды использовались для адресации). В ту же степь тестовый интерфейс для этих железяк.

Anon
()
Ответ на: комментарий от peroxydeacet0ne

На языке C можно писать с использованием библиотеки GTK, например. Для работы с COM-портом - штатные функции libc/linux: read, write, select... Отдельный pthread может только то и делать, что ждать поступления данных из COM-порта.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.