В жестком реальном времени если время выполнения функции превысило установленное, то это считается сбоем системы.
Запланированное время может быть минуту, а может быть микросекунду. Суть от этого не меняется. Система реального времени должна обеспечить выполнение.
В микроконтроллерах за временем выполнения следят таймеры с аппаратными прерываниями. Не уложился - все, ошибка всей системы. Потому что в таких системах неопределенность в управлении хуже всего.
LINUX - система разделения ресурсов и не гарантирует времени выполнения задачи. Кроме того в любой момент времени диспетчер процессов может приостановить выполнения процессу и дать ресурс другому.
Ну а дальше все зависит от ваших задач. Если для вас не критично время выполнения той или иной задачи или время цикла настолько большое, что диспетчер процессов несколько раз сделает свой цикл, то тогда да.
Реальное время, это когда задача выполняется в строго установленное время и не может пропустить какое либо событие.
В RTOS я как то могу управлять всем этим. А вот в LINUX?
Приведу пример: Есть у меня счетчик импульсов. Аппаратное прерывание ведь мне не доступно, значит это пользовательский процесс. А в это время по UART/RS485 пошла передача. Пропустит он импульсы?
Да мало ли задач, где требуется жесткое реальное время - управление по прохождению фазой нуля, работа с энкодерами, выдача и расшифровка ШИМ сигнала.
Там, где с аналоговыми датчиками начинаются трудности, в игру вступают датчики цифровые. До магазина вы дойдете пешком, до почты доберетесь на велосипеде, а до соседнего города на машине. Аналогично и с передачей сигнала, аналоговые линии связи подвержены воздействию шумов, провода содержат омическое сопротивление, на каждый датчик нужна отдельная линия связи. Не лучше ли протянуть один провод 1-Wire и не беспокоиться о помехозащищенности при передаче показаний?
Тут все зависит от целей и задач
Если нужны быстрые "показометры" в домашних поделках, то цифровой датчик типа SHT20 вполне устроит.
Если нужен серьезные измерительные прибор, то лучше взять PT100 или PT1000, и подключить его по 3/4-х схеме. Или термопару с использованием специализированных проводов к АЦП . Но зато гарантированно получить заявленную точность 5%, 1%, 0.5%
p.s. Кстати шина OneWire очень любит ловить внешние помехи
Ну почему же сразу подделка. Просто аналоги. С те же 7qtek и UMW вполне можно работать. Там есть свои даташиты. Просто должно быть понимание, что это другие датчики, совместимые по протоколу и большинству функций с MAXIM
Если у вас станок имеет одну функцию - Стоп/Пуск то никакого преимущества.
Если станок имеет несколько функций настройки, причем электронной, то уже вполне себе панель рулит. Причем ту же кнопку старт/стоп вполне можно оставить аппаратной.
Но панель это в первую очередь средство отображения информации. Если уж так важно мониторить обороты, то почему бы не вывести тренд на экран вместе с цифрой большим шрифтом.
В жестком реальном времени если время выполнения функции превысило установленное, то это считается сбоем системы.
Запланированное время может быть минуту, а может быть микросекунду. Суть от этого не меняется. Система реального времени должна обеспечить выполнение.
В микроконтроллерах за временем выполнения следят таймеры с аппаратными прерываниями. Не уложился - все, ошибка всей системы. Потому что в таких системах неопределенность в управлении хуже всего.
LINUX - система разделения ресурсов и не гарантирует времени выполнения задачи. Кроме того в любой момент времени диспетчер процессов может приостановить выполнения процессу и дать ресурс другому.
Ну а дальше все зависит от ваших задач. Если для вас не критично время выполнения той или иной задачи или время цикла настолько большое, что диспетчер процессов несколько раз сделает свой цикл, то тогда да.
Да что вы говорите?
RTOS, FreRTOS, MBED, QNX и даже LinuxRT вполне обеспечиваю жесткое реальное время
А причем здесь S7 и LINUX ?
Реальное время, это когда задача выполняется в строго установленное время и не может пропустить какое либо событие.
В RTOS я как то могу управлять всем этим. А вот в LINUX?
Приведу пример: Есть у меня счетчик импульсов. Аппаратное прерывание ведь мне не доступно, значит это пользовательский процесс.
А в это время по UART/RS485 пошла передача. Пропустит он импульсы?
Да мало ли задач, где требуется жесткое реальное время - управление по прохождению фазой нуля, работа с энкодерами, выдача и расшифровка ШИМ сигнала.
А как вы обеспечиваете выполнение задач, то биш процессов, в реальном времени?
Что это было?
Разве на 100% ноутбуков и прочих устройств на X64 не работают под LINUX?
И цены там более скромные.
Тут все зависит от целей и задач
Если нужны быстрые "показометры" в домашних поделках, то цифровой датчик типа SHT20 вполне устроит.
Если нужен серьезные измерительные прибор, то лучше взять PT100 или PT1000, и подключить его по 3/4-х схеме. Или термопару с использованием специализированных проводов к АЦП . Но зато гарантированно получить заявленную точность 5%, 1%, 0.5%
p.s. Кстати шина OneWire очень любит ловить внешние помехи
Ну почему же сразу подделка. Просто аналоги. С те же 7qtek и UMW вполне можно работать. Там есть свои даташиты. Просто должно быть понимание, что это другие датчики, совместимые по протоколу и большинству функций с MAXIM
Оригинальные DS18B20 можно купить в том же ЧиД
https://www.chipdip.ru/product/ds18b20
Подскажите, на алишке такте сенсоры еще не продаются?
Где вообще его можно купить в наше время?
(Кроме как в ЧиД за 50к рублей)
Ну до сих пор есть RAD Studio
Для визуальной разработки интерфейсов очень неплохо даже
2.0 под DOS
Потом, когда Microsoft его купила, как всегда убила продукт
Я бы сюда обязательно добавил бы FoxPro. Очень много было написано на нем
Ну я бы сказал, что автор любитель теплого лампового света и большой мазохист )))
Если у вас станок имеет одну функцию - Стоп/Пуск то никакого преимущества.
Если станок имеет несколько функций настройки, причем электронной, то уже вполне себе панель рулит. Причем ту же кнопку старт/стоп вполне можно оставить аппаратной.
Но панель это в первую очередь средство отображения информации. Если уж так важно мониторить обороты, то почему бы не вывести тренд на экран вместе с цифрой большим шрифтом.
Ну как-то токарный станок в 21 первом веке я вижу такой
.
Основные кнопки могут быть механикой.
А вот отображение на дискретной логике - тот еще трэш
Кстати, на заводах пульты управления вполне себе переходят с кнопок на панели. Так же как и управление двигателями с контакторов на частотные приводы
Каким то каменным веком попахивает
Не проще в 21 веке использовать сенсорные панели? Во всех 3Д принтерах и ЧПУ станках DIY уже давно ставят графические сенсорные экранчики 2.4-3.2"
Если мало, то вполне доступны по ценам экраны 5-7"
Для защиты экрана можно приклеивать пленки или стекла от планшетов
Совершенно верно
Только SDK там обычно довольно закрытое и разбираться с ним так себе.
Если нужно ESP32 + LTE то у LiLyGo есть много разных
Например, с тем же SIM7600
https://aliexpress.ru/item/1005003154792763.html
С библиотекой TinyGSM можно поднять стандартные библиотеки HTTP-client, MQTT и пр.
А что непонятного с 4G модемами?
Там AT-команды. У SIMCOM они вообще на 90% похожие у разных модулей. Может немного подшаманить с wvdial.conf придется
А то что здоровый кирпич, так у меня и PI-ZERO+модем+блок питания и в корпусе IP57 тоже кирпич получился )))
Очень даже делают:
https://aliexpress.ru/item/1005005443282180.html
4G/WiFi роутер с поддержкой OpenWRT или другим открытым ПО
Просто не хотелось тратить лишние 4000+ денег. Собрал из того что было