Так ST и для меня истинный кайф в ПР.
Недавно пришлось старый проект переделывать. Открыл функциональный блок и закрыл испугавшись. Удалил нафиг и все описал строчками кода. А входов там 450 штук, да и выходов не на много меньше. Excel здорово помогла автоматизировать набор переменных.
Как Excel помогла автоматизировать набор переменных ?Сообщение от Ollema
Excel вообще весьма универсальный инструмент. Я в последнее время почти любую программу начинаю с заполнения самодельного генератора регистров, который:
1. Позволяет собрать по шаблонам группы объектов управления (насосы, датчики, фильтры и т.д.)
2. Составить шаблонно связанные регистры - с автоматическим назначением адреса/номера бита/единиц измерений и т.п.
3. На выходе - готовые таблицы для импорта в панель Weintek (как регистров так и журналов событий/аварий)
4. На выходе - готовые таблица с json для импорта в OwenCloud (вот прям 300-800 регистров/тегов/битов с текстовым описанием/текстовым подстановкой/единицами/коэффициентами и т.п., разложенными по подпапкам)
5. На выходе - готовая таблица регистров управления/диспетчеризации в приложения к шкафу / заказчику/подрядчику.
6. Жду импорта переменных для ПР205/103 чтоб и туда сразу махом все подтягивать. Но пока разработчики OL завтраками кормят.
7. Разбираюсь (но это не точно) как в MasterScada подтянуть, но чую, что сходу не получится.
Есть замысел эту таблицу таки превратить в отдельную программу со встроенной БД и... но пока это только замысел
C экспортом в МастерСкаду (4D) тоже можно такое провернуть - не сложнее, чем в вайнтек.
С модбасом это так выглядит - в дерево скады добавляется протокол и устройство, потом двойным кликом на устройстве открывается окно импорта-экспорта. Формат файлов - Excel.
изображение_2024-12-12_223245085.png
На других протоколах думаю аналогично должно быть
kaftanati Молодец! Отлично! Я ща такое решение встраиваю в свою базу 1Ски. Будет генерить:
* Расчёт мощностей блоков питания
* Список синалов IO и код для них по шаблонам
* Карты регистров и код для них по шаблонам
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте. © Steve McConnell
Мой рабочий блог со статьями про щиты и автоматику ОВЕН - Cs-Cs.Net | Почта: Info@Cs-Cs.Net | Канал в ТГ @CsCsNetLab
После обновления OWEN Logic при редактировании ST постоянно вываливается ошибка, даже когда просто правишь комментарии 1.jpg Не подскажете как исправить?
Только меня смущает качество отображения чисел с плавающей точкой в среде Owen Logic?
Если там используются стандартные float, то точность отображения должна быть порядка 6 знаков (пример: 123.456, 1.00000). Сейчас же если число не выводится в формате 1 или 1.0, то сразу начинает выводиться в научном формате: 8.33E+00. Вопрос, зачем?!? Вы так показываете округление? Предлагаю или сделать на галочке, или просто сразу отображать нормально: если число в обычном десятичном формате занимает не более 8 символов (с учетом десятичной точки/запятой), то в нем и выводить. При таком алгоритме возможны проблемы с числами по модулю меньше 1, но тут можно просто до E-03 выводить в обычной форме.
А то отлаживаешь, а у тебя все цифры скачут в разные стороны.
b-s-a Меня на смущает. Меня БЕСИТ просто, потому что мне непривычен формат с E+xx. Я его видел в начале 00ых годов в институте и сейчас в OwenLogic.
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте. © Steve McConnell
Мой рабочий блог со статьями про щиты и автоматику ОВЕН - Cs-Cs.Net | Почта: Info@Cs-Cs.Net | Канал в ТГ @CsCsNetLab
Ничего не имею против него. Это научный формат. Мы в институте, обычно, писали 0,1234*10^-6, но 0.1234e-6 несколько лаконичней. Этот формат очень удобен для сохранения необходимой точности вычислений: нельзя написать 10*9.8*3.1415926=307.8760748 - надо писать 0.31e+3, так как исходные данные имеют минимальную точность 2 знака. В науке это важно...
Но вся эта херня не имеет отношения к OwenLogic, так как здесь ограничения по точности накладывает только битовая разрядность переменных. Я посмотрел представление OL - в научном формате число занимает 8 символов: 3 значащих знака, десятичная запятая, буква E, знак степени и две цифры степени. Поэтому можно спокойно писать числа до миллиона в нормальном виде, более миллиона в научном, с шагом экспоненты 3: 1.23, 12.3, 123, 1230, 12300, 123000, 1.23е+06, 12.3е+06, 123е+06, 1.23е+09... Аналогично для чисел меньше 1: 0.123, 0.0123, 0.00123, 123е-06, 12.3е-06, 1.23е-06, 123е-09... Почему так? Во-первых, близкие числа не будут так часто скакать между экспонентами - а то смотришь, параметр должен расти, а он на первый взгляд в 10 раз уменьшается, это только потом, если успеваешь, можно разобрать изменение экспоненты. Во-вторых, наиболее популярные значения будут в интуитивно понятном виде. В-третьих, когда присутствует экспонента, она сразу совместима со стандартными размерностными приставками (микро, мега...).
Если так нельзя, то хотя бы всегда отображать float в научном формате с шагом экспоненты 3: 0.123e+03, 1.23e+03, 12.3e+03, 0.123e+06... и 12.3e+00, 1.23e+00, 0.123e+00, 12.3e-03, 1.23e-03...
Последний раз редактировалось b-s-a; 01.01.2025 в 15:41.
В науке - пусть. Меня бесит, когда я пишу числовую константу типа 4294967295 (0xFFFFFFFF) и вижу там этот формат.
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте. © Steve McConnell
Мой рабочий блог со статьями про щиты и автоматику ОВЕН - Cs-Cs.Net | Почта: Info@Cs-Cs.Net | Канал в ТГ @CsCsNetLab
Ваши права
Ответить с цитированием