Разработка пультов
Разработка пультов
Планируется ли поддержка ввода (положения кранов, кнопок, контроллера) и вывода (значения манометров, амперметров, лампочек) для поддержки самодельных пультов например путём написания dll модулей?
- maisvendoo
- Модератор
- Сообщения: 339
- Зарегистрирован: 13 авг 2019, 10:25
- Город: Ростов-на-Дону
- Настоящее имя: Дмитрий
- VK: https://vk.com/maisvendoo
- Контактная информация:
Re: Разработка пультов
Да, более того, вся необходимая программная обвязка уже написана и присутствует в текущей версии. Остается её протестировать. Планируется написание DLL с её дальнешим динамическим подключением к симу для любого интересующего протокола связи с аппаратурой. Видели в папке plugins/ модуль modbus.dll? Вот это оно, правда пока в тестовом варианте
Возврата к деспотии Ситхов не будет!
Re: Разработка пультов
Отлично, а есть где документация для написания dll? Какие функции надо экспортировать? Где взять *.h файлы?
- maisvendoo
- Модератор
- Сообщения: 339
- Зарегистрирован: 13 авг 2019, 10:25
- Город: Ростов-на-Дону
- Настоящее имя: Дмитрий
- VK: https://vk.com/maisvendoo
- Контактная информация:
Re: Разработка пультов
Пока публичного 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
В принципе, все необходимые ашники уже имеются в SDK, поставляемом с симом - каталог sdk/include. Технически ничего не мешает начать пробовать, только вот и DLL локомотива должна обрабатывать сигналы control_signalt_t и feedback_signals_t, и до ВЛ60пк они уже доходят, только пока не привязаны к элементам управления в схеме.
Давайте поступим так - скоро я отвяжу код ВЛ60пк от дерева сима и сделаю его отдельным дополнением, чтобы для его разработки не надо было таскать весь код симулятора за собой. Там, можно будет завязать для теста несколько сигналов на схему, и проведем эксперимент
Возврата к деспотии Ситхов не будет!
Re: Разработка пультов
Более-менее понятно. Структуры 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.
А нельзя ли попроще без наследования классов? Ну например:
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: Разработка пультов
Так и есть - внутри длл будут решаться все вопросы, касающиеся взаимодействия с конкретным железом пульта, а наружу будет торчать интерфейс в виде универсальных control_signals и feedback_signalsSITT писал(а):Наша dll будет просто посредником между пультом и RRS
Универсальные, но конфигурируемые для каждой конкретной серии ПС. Мне это видится так:SITT писал(а):Структуры control_signals и feedback_signals будут универсальные или разные под разный ПС?
- В DLL локомотива сигналы определенных номеров будут связаны с конкретными органами управления и выходными сигналами. Перечень этих номеров выносится в спецификацию на данное дополнение
- DLL пульта должна быть конфигурируемой. В конфигурационном файле, в формате удобном разработчику этой DLL сигналы ПС, в соответствии со спецификацией, связываются с дискретными сигналами и аналоговыми осями конкретной платы, которую эта DLL обслуживает.
Нет, весь проект написан в стиле ООП в силу того что концепции в нем используемые хорошо ложатся в канву задачи.SITT писал(а):А нельзя ли попроще без наследования классов?
Никаких винапи - код симулятора платформонезависимый, без привязки к конкретной ОС.SITT писал(а):WINAPI
По поводу данного API есть замечание. Касается оно того, что архитектурно, симулятор совершенно не знает о том, какие серии и типы подвижного состава в данный момент времени им симулируются. Он не имеет ни малейшего представления о внутренних алгоритмах, реализованных внутри DLL дополнения. Если Вы почитаете документацию разработчика на сайте, то там описано, что симулятор вызывает длл ПС с целью получить от неё ускорение, назад в длл ПС возвращая скорость кузова и колесных пар, а так же их положение. Вся остальная кухня варится внутри DLL.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); //получили состояние контрольных ламп
Что я вижу в этих вызовах? Указание на тип локомотива, на его номер, на конкретное оборудование - КрМ 395. То есть этот апи подразумевает, что сим знает, какие серии подвижного состава и с каким оборудованием им реализуются. А сим этого не знает, и знать не будет. Для него все равно, моделирует он движение тепловоза, электровоза или вагона. Все эти вопросы решает разработчик дополнения.
Отсюда и вытекает требование к ООП-реализации блоков игры - именно этот подход позволяет создать слои абстракции, необходимые для изоляции ядра игры и дополнений, с возможностью их независимой (зависимой через API) разработкой
Возврата к деспотии Ситхов не будет!