Макросы изначально подразумевались как автономные единицы, которые не зависят от пресетов. Поэтому у них свои настройки кодировки строки и формата чисел типа float.
Я предполагал появление подобной проблемы, и думал ее решить с помощью создания пресетов макросов по аналогии с пресетами настроек.
Но ваше предложение весьма интересное. Я подумаю над этим.
Плохо понимаю, зачем нужен адрес по умолчанию. Возможно это удобно, когда работаешь с Modbus TCP, т.к. там чаще всего адрес устройства один и тот же. Вы могли бы описать случаи, когда необходим адрес устройства по умолчанию?
А насчет пунктов 3 и 4 я и сам уже думаю. Скорее всего в будущем появится возможность собирать макрос из команд. А между командами можно будет ставить задержки.
А CAN вообще сильно распространен в промышленной автоматике? Честно говоря, я с ним и не сталкивался в живую) Даже при подборе комплектующих для разработки нового оборудования у различных исполнительных модулей редко бывает поддержка CAN протокола.
Обычно у большинства устройств есть поддержка Modbus или на худой конец какого-нибуть простенького собственного протокола.
Юзерфрендли и общий дизайн приложения это были одни из основных причин, почему я когда-то начал писать это приложение) Интересно будет услышать ваши предложения.
Используйте макросы. Например, можно создать макрос для каждого режима, дать каждому из них какое-то название, и во время работы при необходимости нажимать на соответствующие макросы. Окно макросов можно скрыть или закрыть вовсе, если оно сейчас не нужно.
В случае на картинке есть проблема, что нужно записать два регистра, которые располагаются непоследовательно в памяти.
Но я вижу несколько вариантов:
1. Использовать макрос Modbus и функцию 0х10 Запись нескольких регистров. Регистрам, которые находятся между 0х64 и 0х70, можно задать нулевое значение. Убедитесь, что это не критично.
2. Использовать несколько макросов Modbus. В каждом макросе используется функция 0х06, которая записывает в один регистр. Чтобы не запутаться, их можно назвать, например так: "Режим Х 1", "Режим Х 2", "Режим Y 1", "Режим Y 2" и т.д. Для переключения режима придется понажимать пару кнопок.
3. (Костыль, костыль) Использовать макрос режима "Без протокола". Записать последовательно байты для каждой посылки. Попробовать отправить. Скорее всего устройство это проигнорирует, из-за отсутствия служебных полей UART между посылками и из-за отсутствия паузы между сообщениями. Если так произошло, то можно попробовать сымитировать старт и стоп биты, с помощью байтовых значений, а паузу между посылками - нулевыми значениями. Для отладки всего этого неплохо бы воспользоваться осциллографом или логическим анализатором.
Поддержка работы с числами типа float и с битовыми масками добавлена в приложение начиная с версии 3.0.0. Причем при работе с float числами можно использовать различные форматы комбинации байт этого числа.
К сожалению, под FreeBSD собрать не получится. Ни Avalonia, ни .NET официально не поддерживают эту ОС. И при разработке я все же ориентировался на версии только для Windows/Linux.
Но вы можете попробовать это сделать сами :) Код лежит в свободном доступе.
Посмотрите в "Диспетчер устройств - Порты (СОМ и LPT)". Если в этом списке нет портов, значит у меня в программе их тоже не будет)
Также может быть проблема с USB драйверами, в таком случае в Диспетчере устройств будет предупреждение об этом, а моя программа также не отобразит эти порты.
Если в Диспетчере устройств порты отображаются, а в терминале нет, то в окне настроек нажмите на кнопку "Поиск СОМ портов". Список с доступными портами должен обновиться.
Проблема с правами (фантастично, но почему бы и нет). Попробуйте запустить программу от имени администратора.
Если развернуть приложение в глобальной сети, то появится проблема с доступом к портам на конкретном ПК. Плюс скорее всего там используется терминальный интернет, что вообще лишает приложение смысла.
А если развернуть браузерную версию локально и использовать любой браузер для взаимодействия с пользователем, то получится то же самое что и при использовании обычного приложения) А вариант с WebView по мне больше на костыль похож в данном случае.
А вообще будет интересно посмотреть как произойдет отказ от винды. Слишком много софта под нее написано. Плюс пользователи к ней привыкли.
Спасибо за замечания, но хотелось бы пояснений к некоторым пунктам.
Пункт 4:
Как думайте, было бы удобно видеть содержимое регистра одновременно во всех трех представлениях (шестнадцатеричное, десятичное и двоичное с разделителем между байтами)? Или же лучше переключаться между представлениями?
Пункт 5:
Вы имейте ввиду режим Modbus сервера (которого пока нет)? А если нет, то зачем клиенту такой функционал?
Пункт 7:
Вы имейте ввиду задержку между отправкой / приемом слов? Напишите, пожалуйста, в каких случаях может пригодиться такой функционал.
Над таким вариантом не думал) Как мне кажется, эта программа чаще всего будет использоваться на закрытых предприятиях и заводах. Из за внутренних ограничений, там нет смысла в браузерной версии.
Макросы изначально подразумевались как автономные единицы, которые не зависят от пресетов. Поэтому у них свои настройки кодировки строки и формата чисел типа float.
Я предполагал появление подобной проблемы, и думал ее решить с помощью создания пресетов макросов по аналогии с пресетами настроек.
Но ваше предложение весьма интересное. Я подумаю над этим.
Плохо понимаю, зачем нужен адрес по умолчанию. Возможно это удобно, когда работаешь с Modbus TCP, т.к. там чаще всего адрес устройства один и тот же.
Вы могли бы описать случаи, когда необходим адрес устройства по умолчанию?
А насчет пунктов 3 и 4 я и сам уже думаю. Скорее всего в будущем появится возможность собирать макрос из команд. А между командами можно будет ставить задержки.
А CAN вообще сильно распространен в промышленной автоматике? Честно говоря, я с ним и не сталкивался в живую) Даже при подборе комплектующих для разработки нового оборудования у различных исполнительных модулей редко бывает поддержка CAN протокола.
Обычно у большинства устройств есть поддержка Modbus или на худой конец какого-нибуть простенького собственного протокола.
Юзерфрендли и общий дизайн приложения это были одни из основных причин, почему я когда-то начал писать это приложение) Интересно будет услышать ваши предложения.
Нет. Сейчас опрашивать можно только по одному.
А реализации пресетов как таковых сейчас нет. Это было бы самым удобным вариантом для случая на картинке. Возможно, они появятся в будущем)
Используйте макросы. Например, можно создать макрос для каждого режима, дать каждому из них какое-то название, и во время работы при необходимости нажимать на соответствующие макросы. Окно макросов можно скрыть или закрыть вовсе, если оно сейчас не нужно.
В случае на картинке есть проблема, что нужно записать два регистра, которые располагаются непоследовательно в памяти.
Но я вижу несколько вариантов:
1. Использовать макрос Modbus и функцию 0х10 Запись нескольких регистров. Регистрам, которые находятся между 0х64 и 0х70, можно задать нулевое значение. Убедитесь, что это не критично.
2. Использовать несколько макросов Modbus. В каждом макросе используется функция 0х06, которая записывает в один регистр. Чтобы не запутаться, их можно назвать, например так: "Режим Х 1", "Режим Х 2", "Режим Y 1", "Режим Y 2" и т.д.
Для переключения режима придется понажимать пару кнопок.
3. (Костыль, костыль) Использовать макрос режима "Без протокола". Записать последовательно байты для каждой посылки. Попробовать отправить. Скорее всего устройство это проигнорирует, из-за отсутствия служебных полей UART между посылками и из-за отсутствия паузы между сообщениями. Если так произошло, то можно попробовать сымитировать старт и стоп биты, с помощью байтовых значений, а паузу между посылками - нулевыми значениями. Для отладки всего этого неплохо бы воспользоваться осциллографом или логическим анализатором.
Поддержка работы с числами типа float и с битовыми масками добавлена в приложение начиная с версии 3.0.0. Причем при работе с float числами можно использовать различные форматы комбинации байт этого числа.
Этот функционал был добавлен тут.
Кроссплатформенный терминал Modbus TCP / RTU / ASCII с открытым исходным кодом: Часть 2
Также сейчас доступна более продвинутая версия приложения. Смотрите последнюю статью из этого цикла.
Да, в приложении есть возможность работы с последовательным портом.
А почему нельзя? Если у вас на рабочих компах нет прав на установку приложений, то вы можете воспользоваться версией portable.
К сожалению, под FreeBSD собрать не получится. Ни Avalonia, ни .NET официально не поддерживают эту ОС. И при разработке я все же ориентировался на версии только для Windows/Linux.
Но вы можете попробовать это сделать сами :) Код лежит в свободном доступе.
Нет, не пробовал) Я проектировал дизайн под десктоп. На мобильных устройствах будет мелковато.
Это версия работает под Windows и Linux.
Кроссплатформенный терминал Modbus TCP / RTU / ASCII с открытым исходным кодом: Часть 2
Возможно проблема с СОМ портами.
Есть несколько вариантов:
Посмотрите в "Диспетчер устройств - Порты (СОМ и LPT)". Если в этом списке нет портов, значит у меня в программе их тоже не будет)
Также может быть проблема с USB драйверами, в таком случае в Диспетчере устройств будет предупреждение об этом, а моя программа также не отобразит эти порты.
Если в Диспетчере устройств порты отображаются, а в терминале нет, то в окне настроек нажмите на кнопку "Поиск СОМ портов". Список с доступными портами должен обновиться.
Проблема с правами (фантастично, но почему бы и нет). Попробуйте запустить программу от имени администратора.
Как будто про себя прочитал)) Занимался тем же самым на одной из работ и в последствии тоже ушел перекладывать json-ы)
Вам не было скучно в первое время после перехода из инженерной сферы в веб?
На производстве чаще всего результат работы более очевиден, и проекты меньше и понятнее. Поэтому и вовлечённость больше.
Поэтому я и думаю о переходе на Avalonia UI.
Если развернуть приложение в глобальной сети, то появится проблема с доступом к портам на конкретном ПК. Плюс скорее всего там используется терминальный интернет, что вообще лишает приложение смысла.
А если развернуть браузерную версию локально и использовать любой браузер для взаимодействия с пользователем, то получится то же самое что и при использовании обычного приложения) А вариант с WebView по мне больше на костыль похож в данном случае.
А вообще будет интересно посмотреть как произойдет отказ от винды. Слишком много софта под нее написано. Плюс пользователи к ней привыкли.
Спасибо за замечания, но хотелось бы пояснений к некоторым пунктам.
Пункт 4:
Как думайте, было бы удобно видеть содержимое регистра одновременно во всех трех представлениях (шестнадцатеричное, десятичное и двоичное с разделителем между байтами)? Или же лучше переключаться между представлениями?
Пункт 5:
Вы имейте ввиду режим Modbus сервера (которого пока нет)? А если нет, то зачем клиенту такой функционал?
Пункт 7:
Вы имейте ввиду задержку между отправкой / приемом слов? Напишите, пожалуйста, в каких случаях может пригодиться такой функционал.
Над таким вариантом не думал) Как мне кажется, эта программа чаще всего будет использоваться на закрытых предприятиях и заводах. Из за внутренних ограничений, там нет смысла в браузерной версии.
Интересный сценарий. Спасибо за идею)
Напишите в чем была проблема?
У меня на двух разных ПК с Windows 11 программа работает без проблем.