Система сбора и отображения данных

[OKTA]

Да что вы накинулись на человека? Он же говорит, что пока не знает, как реализовать замуту с датчиками и сделает временно через функции, чтобы другую часть проекта сделать и протестировать. 

[8Observer8]

Вы хотите захардкодить все датчики в одном классе? А если нужно будет в процессе работы программы добавлять/удалять датчики?
Они могут выходить из строя....

Пока я сделаю датчики №1, №2 и т.д. Но ведь на самом деле они должны как-то называться? Ну, к примеру: ДатчикТемпературы, ДатчикДавления. А если делать что-то универсальное, то как клиент поймёт, что и куда выводить?

Если мы изменим датчик давления на датчик температуры, то как клиент это поймёт? Вот пример клиента:

Да что вы накинулись на человека? Он же говорит, что пока не знает, как реализовать замуту с датчиками и сделает временно через функции, чтобы другую часть проекта сделать и протестировать.  

Совершенно верно! Я хочу сделать черновой рабочий проект, чтобы он выполнял функциональность и чтобы я потратил меньше сил и времени на это. А потом я уже буду переделывать, как надо. Улучшать и улучшать.

[OKTA]

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

[Bepec]

Каждый датчик имеет определённый идентификатор. Не бывает безымянных датчиков А по идентификатору можно сделать словарь или карту. И уже по ней будет всё ясно пользователю.
А "черновые" проекты имеют свойство превращаться в постоянные, причем дальше человек уже идёт по накатанному (функциональное), а не делает по новому

PS главное начать, а так всё комом покатится и ООП станет легко и просто Ну и главное иметь бумагу и карандаш. Более продвинутая версия - планшет для водных маркеров, их и тряпочку

[Old]

Пока я сделаю датчики №1, №2 и т.д. Но ведь на самом деле они должны как-то называться? Ну, к примеру: ДатчикТемпературы, ДатчикДавления. А если делать что-то универсальное, то как клиент поймёт, что и куда выводить?

Например так:

Код

C++ (Qt)
class Sensor
{
    Sensor( const QString &name ) :
        m_name( name )
    {
    }
 
    QString name() const { return m_name; }
 
private:
    QString m_name;
};
 
class PressureSensor : public Sensor
{
    PressureSensor() : Sensor( trUtf8( "Датчик давления" ) ) {}
};
 
class TempSensor : public Sensor
{
    TempSensor() : Sensor( trUtf8( "Датчик температуры" ) ) {}
};
 

А можно вообще оставить оператору назвать их так, как ему будет понятно.

Совершенно верно! Я хочу сделать черновой рабочий проект, чтобы он выполнял функциональность и чтобы я потратил меньше сил и времени на это. А потом я уже буду переделывать, как надо. Улучшать и улучшать.

Вы изначально его хотите сделать не правильно, что бы потом выкинуть его и сделать правильно?

[Bepec]

Вот и пример с наследованием. Вот и практика в ООП. И следующей фразой будет "Я же уже так много сделал на функциях, зачем мне всё переделывать?"

[8Observer8]

Мне сейчас нужно будет уехать на выходные. Я буду без компа и интернета. Как вернусь, постараюсь сделать это задание достойно. Спасибо огромное всем, кто помогает!

[Igors]

Задача выглядит очень типовой, наверняка есть подходящие либы. Если же самому, я бы рассуждал примерно так:

- датчик есть класс который собирает данные и хранит их в контейнере. Что есть единица данных? Ну пусть float значение. Нужно ли хранить время когда получено новое значение? Может и да, но может и ограничиться предположением что "данные приходят с фиксированной частотой". В любом случае датчик может быть вкл/выкл, уметь накапливать данные в своем буфере и знать какому времени соответствует каждое значение. Емкость буфера ограничена/задается. В общем датчик - класс который умеет по запросу выдать N единиц данных в заданном интервале времени

[Old]

Задача выглядит очень типовой, наверняка есть подходящие либы. Если же самому, я бы рассуждал примерно так:

- датчик есть класс который собирает данные и хранит их в контейнере. Что есть единица данных? Ну пусть float значение. Нужно ли хранить время когда получено новое значение? Может и да, но может и ограничиться предположением что "данные приходят с фиксированной частотой". В любом случае датчик может быть вкл/выкл, уметь накапливать данные в своем буфере и знать какому времени соответствует каждое значение. Емкость буфера ограничена/задается. В общем датчик - класс который умеет по запросу выдать N единиц данных в заданном интервале времени

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

[lesav]

Слишком много задач возложено на простой датчик. По мне, так датчик должен только возвращать текущее значение

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

Датчики подключены к компьютеру с Unix подобной ОС, для обработки информации с каждого датчика запущен свой процесс или тред (в дальнейшем - "Драйвер Датчика").

Какая ось, QNX ?

[lesav]

Как подсоединены датчики ?
На каком интерфейсе ?
Используются дополнительные платы расширения pci или isa ?

[Old]

а если это датчики системы управления реактором то тут совсем другие требования.

Мы говорим про класс датчика учебного проекта.

[Igors]

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

Можно и так, но тогда надо создавать класс напр "контроллер" отвечающий за опрос и буферирование, а то "клиентский код" - неясно что это

[Old]

но тогда надо создавать класс напр "контроллер" отвечающий за опрос и буферирование

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

"клиентский код" - неясно что это

Клиентский код это код, который взаимодействует с объектом датчика.

[8Observer8]

Сделал сегодня небольшой набросок. Приложение IcebreakerViewer отправляет серверу (IcebreakerServer) запрос раз в секунду. Сервер, в ответ на запросы, передаёт текущие значения датчиков:





Исходники:
IcebreakerServer: https://github.com/8Observer8/IcebreakerServer
IcebreakerViewer: https://github.com/8Observer8/IcebreakerViewer

Датчики реализованы следующем образом:

Код

C++ (Qt)
int IcebreakerServer::sensor_01()
{
    return qrand() % 10 + 10;
}
 
int IcebreakerServer::sensor_02()
{
    return qrand() % 10 + 20;
}
 
int IcebreakerServer::sensor_03()
{
    return qrand() % 10 + 30;
}
 
int IcebreakerServer::sensor_04()
{
    return qrand() % 10 + 40;
}
 
int IcebreakerServer::sensor_05()
{
    return qrand() % 10 + 50;
}
 

Вот так Viewer принимает данные и парсит их для отображения на экране:

Код

C++ (Qt)
void MainWindow::readyRead()
{
    QTcpSocket* clientSocket = (QTcpSocket*)sender();
    QDataStream in(clientSocket);
    in.setVersion(QDataStream::Qt_4_7);
    for (;;) {
        if (!m_nextBlockSize) {
            if (clientSocket->bytesAvailable() < (int)sizeof(quint16)) {
                break;
            }
            in >> m_nextBlockSize;
        }
 
        if (clientSocket->bytesAvailable() < m_nextBlockSize) {
            break;
        }
 
        QString str;
        in >> str;
 
        QStringList stringList = str.split(',');
        if (stringList.size() == 5) {
            ui->sensor01LineEdit->setText(stringList[0]);
            ui->sensor02LineEdit->setText(stringList[1]);
            ui->sensor03LineEdit->setText(stringList[2]);
            ui->sensor04LineEdit->setText(stringList[3]);
            ui->sensor05LineEdit->setText(stringList[4]);
        } else {
            qWarning() << "stringList.size() != 5";
        }
 
        m_nextBlockSize = 0;
    }
}