Разработка пультов

Посвящено созданию и совершенствованию динамического движка игры
Ответить
SITT
Сообщения: 7
Зарегистрирован: 02 сен 2019, 06:25
Город: Старый Оскол

Разработка пультов

Сообщение SITT » 02 сен 2019, 06:34

Планируется ли поддержка ввода (положения кранов, кнопок, контроллера) и вывода (значения манометров, амперметров, лампочек) для поддержки самодельных пультов например путём написания dll модулей?

Аватара пользователя
maisvendoo
Модератор
Сообщения: 339
Зарегистрирован: 13 авг 2019, 10:25
Город: Ростов-на-Дону
Настоящее имя: Дмитрий
VK: https://vk.com/maisvendoo
Контактная информация:

Re: Разработка пультов

Сообщение maisvendoo » 02 сен 2019, 08:28

SITT писал(а):
02 сен 2019, 06:34
Планируется ли поддержка ввода (положения кранов, кнопок, контроллера) и вывода...
Да, более того, вся необходимая программная обвязка уже написана и присутствует в текущей версии. Остается её протестировать. Планируется написание DLL с её дальнешим динамическим подключением к симу для любого интересующего протокола связи с аппаратурой. Видели в папке plugins/ модуль modbus.dll? Вот это оно, правда пока в тестовом варианте
Возврата к деспотии Ситхов не будет!

SITT
Сообщения: 7
Зарегистрирован: 02 сен 2019, 06:25
Город: Старый Оскол

Re: Разработка пультов

Сообщение SITT » 02 сен 2019, 09:37

Отлично, а есть где документация для написания dll? Какие функции надо экспортировать? Где взять *.h файлы?

Аватара пользователя
maisvendoo
Модератор
Сообщения: 339
Зарегистрирован: 13 авг 2019, 10:25
Город: Ростов-на-Дону
Настоящее имя: Дмитрий
VK: https://vk.com/maisvendoo
Контактная информация:

Re: Разработка пультов

Сообщение maisvendoo » 02 сен 2019, 10:45

SITT писал(а):
02 сен 2019, 09:37
Какие функции надо экспортировать? Где взять *.h файлы?
Пока публичного API нет - но он появится в ближайшее время. Но если хотите конкретики, то можно взглянуть на вот этот файл в дереве исходников

simulator/device/include/virtual-interface-device.h

Код: Выделить всё

#ifndef     VIRTUAL_INTERFACE_DEVICE_H
#define     VIRTUAL_INTERFACE_DEVICE_H

#include    <QObject>
#include    "device-export.h"

#include    "control-signals.h"
#include    "feedback-signals.h"

//------------------------------------------------------------------------------
//
//------------------------------------------------------------------------------
class DEVICE_EXPORT VirtualInterfaceDevice : public QObject
{
    Q_OBJECT

public:

    VirtualInterfaceDevice(QObject *parent = Q_NULLPTR);

    virtual ~VirtualInterfaceDevice();

    virtual bool init(QString cfg_path) = 0;

    virtual void process() = 0;

    signal_t getControlSignal(size_t id);

signals:

    void sendControlSignals(control_signals_t control_signals);

public slots:

    void receiveFeedback(feedback_signals_t feedback_signals);

protected:

    control_signals_t   control_signals;

    feedback_signals_t  feedback_signals;
};

//------------------------------------------------------------------------------
//
//------------------------------------------------------------------------------
typedef VirtualInterfaceDevice* (*GetInterfaceDevice)();

#define GET_INTERFACE_DEVICE(ClassName) \
    extern "C" Q_DECL_EXPORT VirtualInterfaceDevice *getInterfaceDevice() \
    { \
        return new (ClassName) (); \
    }

//------------------------------------------------------------------------------
//
//------------------------------------------------------------------------------
extern "C" Q_DECL_EXPORT VirtualInterfaceDevice *loadInterfaceDevice(QString lib_path);

#endif // VIRTUAL_INTERFACE_DEVICE_H
Этот класс экспортируется из модуля device.dll и будет предоставлять абстрактный интерфейс к аппаратному пульту. Принцип такой - в DLL, работающей с конкретным протоколом связи будет класс, наследуемый от класса VirtualInterfaceDevice. DLL - реализуя конкретный протокол (RS232, RS485 и т.п.) должна складывать сигналы с устройств ввода в структуру control_signals, и отправлять во внешние приборы сигналы из структуры feedback_signals. Симулятор будет взаимодействовать с этой DLL через публичные методы класса VirtualInterfaceDevice, ничего не зная о конкретной аппаратной реализации пульта. В API войдет именно этот ашник, ну и создаваемую Вами DLL надо будет компоновать с device.dll

В принципе, все необходимые ашники уже имеются в SDK, поставляемом с симом - каталог sdk/include. Технически ничего не мешает начать пробовать, только вот и DLL локомотива должна обрабатывать сигналы control_signalt_t и feedback_signals_t, и до ВЛ60пк они уже доходят, только пока не привязаны к элементам управления в схеме.

Давайте поступим так - скоро я отвяжу код ВЛ60пк от дерева сима и сделаю его отдельным дополнением, чтобы для его разработки не надо было таскать весь код симулятора за собой. Там, можно будет завязать для теста несколько сигналов на схему, и проведем эксперимент
Возврата к деспотии Ситхов не будет!

SITT
Сообщения: 7
Зарегистрирован: 02 сен 2019, 06:25
Город: Старый Оскол

Re: Разработка пультов

Сообщение SITT » 03 сен 2019, 07:48

Более-менее понятно. Структуры control_signals и feedback_signals будут универсальные или разные под разный ПС?
А нельзя ли попроще без наследования классов? Ну например:
WINAPI _export VOID GetLocomotiveType(char *LocomotiveType, DWORD LocomotiveNum); //если пульт не подходит для управление текущим ПС то выводим ошибку
WINAPI _export BYTE Get395Valve(void); //получили текущее положение 395 крана из RRS (может пригодится для ламп ЭПТ)
WINAPI _export VOID Set395Valve(BYTE position); //передали новое положение крана с пульта в RRS
WINAPI _export VOID GetPressure(float *TM, float *UR, float *TC, float *NM); //получили показания манометров
WINAPI _export VOID GetLamps(struct *Lamps); //получили состояние контрольных ламп
Ну и так далее. Наша dll будет просто посредником между пультом и RRS.

Аватара пользователя
maisvendoo
Модератор
Сообщения: 339
Зарегистрирован: 13 авг 2019, 10:25
Город: Ростов-на-Дону
Настоящее имя: Дмитрий
VK: https://vk.com/maisvendoo
Контактная информация:

Re: Разработка пультов

Сообщение maisvendoo » 03 сен 2019, 08:32

SITT писал(а):Наша dll будет просто посредником между пультом и RRS
Так и есть - внутри длл будут решаться все вопросы, касающиеся взаимодействия с конкретным железом пульта, а наружу будет торчать интерфейс в виде универсальных control_signals и feedback_signals
SITT писал(а):Структуры control_signals и feedback_signals будут универсальные или разные под разный ПС?
Универсальные, но конфигурируемые для каждой конкретной серии ПС. Мне это видится так:
  • В DLL локомотива сигналы определенных номеров будут связаны с конкретными органами управления и выходными сигналами. Перечень этих номеров выносится в спецификацию на данное дополнение
  • DLL пульта должна быть конфигурируемой. В конфигурационном файле, в формате удобном разработчику этой DLL сигналы ПС, в соответствии со спецификацией, связываются с дискретными сигналами и аналоговыми осями конкретной платы, которую эта DLL обслуживает.
SITT писал(а):А нельзя ли попроще без наследования классов?
Нет, весь проект написан в стиле ООП в силу того что концепции в нем используемые хорошо ложатся в канву задачи.
SITT писал(а):WINAPI
Никаких винапи - код симулятора платформонезависимый, без привязки к конкретной ОС.
SITT писал(а): WINAPI _export VOID GetLocomotiveType(char *LocomotiveType, DWORD LocomotiveNum); //если пульт не подходит для управление текущим ПС то выводим ошибку
WINAPI _export BYTE Get395Valve(void); //получили текущее положение 395 крана из RRS (может пригодится для ламп ЭПТ)
WINAPI _export VOID Set395Valve(BYTE position); //передали новое положение крана с пульта в RRS
WINAPI _export VOID GetPressure(float *TM, float *UR, float *TC, float *NM); //получили показания манометров
WINAPI _export VOID GetLamps(struct *Lamps); //получили состояние контрольных ламп
По поводу данного API есть замечание. Касается оно того, что архитектурно, симулятор совершенно не знает о том, какие серии и типы подвижного состава в данный момент времени им симулируются. Он не имеет ни малейшего представления о внутренних алгоритмах, реализованных внутри DLL дополнения. Если Вы почитаете документацию разработчика на сайте, то там описано, что симулятор вызывает длл ПС с целью получить от неё ускорение, назад в длл ПС возвращая скорость кузова и колесных пар, а так же их положение. Вся остальная кухня варится внутри DLL.

Что я вижу в этих вызовах? Указание на тип локомотива, на его номер, на конкретное оборудование - КрМ 395. То есть этот апи подразумевает, что сим знает, какие серии подвижного состава и с каким оборудованием им реализуются. А сим этого не знает, и знать не будет. Для него все равно, моделирует он движение тепловоза, электровоза или вагона. Все эти вопросы решает разработчик дополнения.

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

Ответить

Вернуться в «Разработка динамического ядра (TrainEngine 2)»