Pull to refresh
11
0
Mikhail Kozlov @MikeKozlovAVR

Разработчик ПО встраиваемых систем, инженер АСУ ТП

Send message

Было дело, я как то писал простого планировщика под ардуино с похожим принципом работы, только задачам при их создании не задавался интервал времени, а задавался только приоритет. Частота вызова задачи зависит от неё самой, то есть от вызова sleep() или yield() и т.д.. Также можно в процессе работы задачи изменить её приоритет. А планировщик раскидывает очередь выполнения задач в зависимости от их состояния и приоритетов.

https://github.com/MikeKozlovAVR/Arduino_MultiTasker

Смотря про какой уровень идет речь, если в промышленности либо на крупных объектах то однозначно крупные системы с экосистемами, которые отлажены со временем. Если дома, для условной теплицы - то вполне что то из самоделкиных сгодится. Я, проработав несколько лет в атомной промышленности, никогда в жизни не стал бы использовать что то самодельное, даже если бы был в нем уверен так как ответственность огромная.

Даже из крупнейших систем на рынке приходилось выбирать очень тщательно. И за обилием минусов в виде тяжести, стоимости и частичной монопольности системы я считаю одними из лучших это Siemens, так как надежность иногда просто поражала.

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

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

Кстати да, на момент создания этого софта я еще не знал про Nextion (возможно их тогда и не было, либо были не популярны), но позже когда для очередной поделки решил воспользоваться их дисплеем, то тоже подумал что есть большое сходство, особенно в плане протокола обмена. Видимо, ребята тоже старались сделать чтобы было максимально просто. Но всё же у них направление на "гуи" для дисплейного модуля, а не для работы на ПК. Для Modbus RTU и Modbus TCP предусмотрен такой элемент как "девайс", в котором можно настроить какой регистр с какого адреса привязать к тегу и прочие вещи как байт-свап и т.д. На счет автозапуска по TCP, если память не изменяет, то я такого не делал. То есть нужно будет вручную нажать "Connect all devices".

Всё, я понял что вы имели в виду. Смотрите, если конкретная реализация кода на микроконтроллере позволяет на ходу добавлять/удалять какой либо сигнал из системы не останавливая ее - то есть не хардкодом, а конфигурацией то да, так сделать можно. Ведь данный софт не прикладной всё таки, а скорее как конструктор системы. Но в самой ASCADA на горячую изменить тег не получится, придется перезапускать HMI-проект. Как возможный вариант - это зарезервировать заранее в проекте какое нибудь количество тегов и добавлять удалять сигналы путем создания отдельного экрана с текстовыми/числовыми полями и кнопками из разряда: поле номер клеммы, поле ID тега, поле имя сигнала, кнопка добавить/удалить. Но всю механику этих процессов всё равно нужно будет предусматривать в ПО на микроконтроллере.

На счет web согласен, в тот момент когда писалась эта программа были даже мысли создавать что то вроде сервера с вэб-мордой на которой было бы такое же отображение объектов как и в обычной реализации, чтобы можно было с любого устройства в сети выйти на страницу. Но кроме мыслей это никуда ее пошло, ни времени на это не было да и знаний, думаю, тоже

Да, "протокол" абсолютно идентичный на ввод и на вывод данных. При перемещении слайдера будет вызываться событие, которое в системе организует передачу текущего значения слайдера по ID тега, который привязан к этому слайдеру.

Если честно, уже и не помню причину, вроде бы связано было с передачей string в которой мне нужен был символ '=', а '&' не использовался вообще нигде

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

Если я правильно понял суть вопроса, то - да. Со стороны контроллера необходимо передать какое-то значение на указанный ID тега, а в проекте привязать этот тег к любому объекту, чтобы этот объект выводил переданное в тег значение.

Этот нюанс лежит на стороне разработчика со стороны МК, ведь тип тега определяет то как он будет парситься в ASCADA. Ведь так или иначе значение отсылается в символьном виде. Ну а вообще, вопрос вполне справедливый, мне на тот момент показалось удачной идея написать библиотеку для МК внутренностями которой и будет проверяться корректность значения

Information

Rating
Does not participate
Date of birth
Registered
Activity

Specialization

Embedded Software Engineer, System Software Engineer
Middle
From 3,000 $
C++
C#
Git
Bash
Linux
C
Visual Studio
.NET
QNX
Programming microcontrollers