В сравнении модулей очень не хватает цены. Как всегда у наших производителей, это самая секретная информация. Вторая по секретности - это документация )))
Ну и как со всем этим работать?
Каждый раз писать разработчикам, заполнять анкеты и выпрашивать всю информацию?
Мы упираемся в саму систему. Либо она гарантирует выполнения в наших таймингах, либо нет.
А реализация Modbus в данном случае это совсем не реальное время, так как данные берутся не из физического канала, а из буфера UART. Или от какого-нибудь другого модуля ядра, но тоже из буфера.
В жестком реальном времени если время выполнения функции превысило установленное, то это считается сбоем системы.
Запланированное время может быть минуту, а может быть микросекунду. Суть от этого не меняется. Система реального времени должна обеспечить выполнение.
В микроконтроллерах за временем выполнения следят таймеры с аппаратными прерываниями. Не уложился - все, ошибка всей системы. Потому что в таких системах неопределенность в управлении хуже всего.
LINUX - система разделения ресурсов и не гарантирует времени выполнения задачи. Кроме того в любой момент времени диспетчер процессов может приостановить выполнения процессу и дать ресурс другому.
Ну а дальше все зависит от ваших задач. Если для вас не критично время выполнения той или иной задачи или время цикла настолько большое, что диспетчер процессов несколько раз сделает свой цикл, то тогда да.
Реальное время, это когда задача выполняется в строго установленное время и не может пропустить какое либо событие.
В RTOS я как то могу управлять всем этим. А вот в LINUX?
Приведу пример: Есть у меня счетчик импульсов. Аппаратное прерывание ведь мне не доступно, значит это пользовательский процесс. А в это время по UART/RS485 пошла передача. Пропустит он импульсы?
Да мало ли задач, где требуется жесткое реальное время - управление по прохождению фазой нуля, работа с энкодерами, выдача и расшифровка ШИМ сигнала.
Там, где с аналоговыми датчиками начинаются трудности, в игру вступают датчики цифровые. До магазина вы дойдете пешком, до почты доберетесь на велосипеде, а до соседнего города на машине. Аналогично и с передачей сигнала, аналоговые линии связи подвержены воздействию шумов, провода содержат омическое сопротивление, на каждый датчик нужна отдельная линия связи. Не лучше ли протянуть один провод 1-Wire и не беспокоиться о помехозащищенности при передаче показаний?
Тут все зависит от целей и задач
Если нужны быстрые "показометры" в домашних поделках, то цифровой датчик типа SHT20 вполне устроит.
Если нужен серьезные измерительные прибор, то лучше взять PT100 или PT1000, и подключить его по 3/4-х схеме. Или термопару с использованием специализированных проводов к АЦП . Но зато гарантированно получить заявленную точность 5%, 1%, 0.5%
p.s. Кстати шина OneWire очень любит ловить внешние помехи
Ну почему же сразу подделка. Просто аналоги. С те же 7qtek и UMW вполне можно работать. Там есть свои даташиты. Просто должно быть понимание, что это другие датчики, совместимые по протоколу и большинству функций с MAXIM
Если у вас станок имеет одну функцию - Стоп/Пуск то никакого преимущества.
Если станок имеет несколько функций настройки, причем электронной, то уже вполне себе панель рулит. Причем ту же кнопку старт/стоп вполне можно оставить аппаратной.
Но панель это в первую очередь средство отображения информации. Если уж так важно мониторить обороты, то почему бы не вывести тренд на экран вместе с цифрой большим шрифтом.
Это же DIY
Какую настроите
Для LoRa/Zigbee точно не ESP32 нужен с его гигантским потреблением и режимом сна через одно место
В принципе, попробовал ESP32C3 с SX1262 - можно достичь 5мкА в режиме сна, но пробуждение тоже так себе и GPIO мало. Зато цена получается отличная
Только элемент искусства напрочь убивается автоматизацией.
Это как рисунок кисточкой заменить печатью на струйном принтере
В сравнении модулей очень не хватает цены. Как всегда у наших производителей, это самая секретная информация. Вторая по секретности - это документация )))
Ну и как со всем этим работать?
Каждый раз писать разработчикам, заполнять анкеты и выпрашивать всю информацию?
Давайте говорить в рамках отраслевого ГОСТ Р МЭК 61069-4 2017. Там есть однозначное определение жесткого и мягкого реального времени.
А все эти рассуждения, что есть время, что есть мгновения оставим философам )))
Мы упираемся в саму систему. Либо она гарантирует выполнения в наших таймингах, либо нет.
А реализация Modbus в данном случае это совсем не реальное время, так как данные берутся не из физического канала, а из буфера UART. Или от какого-нибудь другого модуля ядра, но тоже из буфера.
В жестком реальном времени если время выполнения функции превысило установленное, то это считается сбоем системы.
Запланированное время может быть минуту, а может быть микросекунду. Суть от этого не меняется. Система реального времени должна обеспечить выполнение.
В микроконтроллерах за временем выполнения следят таймеры с аппаратными прерываниями. Не уложился - все, ошибка всей системы. Потому что в таких системах неопределенность в управлении хуже всего.
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. Очень много было написано на нем
Ну я бы сказал, что автор любитель теплого лампового света и большой мазохист )))
Если у вас станок имеет одну функцию - Стоп/Пуск то никакого преимущества.
Если станок имеет несколько функций настройки, причем электронной, то уже вполне себе панель рулит. Причем ту же кнопку старт/стоп вполне можно оставить аппаратной.
Но панель это в первую очередь средство отображения информации. Если уж так важно мониторить обороты, то почему бы не вывести тренд на экран вместе с цифрой большим шрифтом.