Что Вы подразумеваете под шестнадцатеричной системой, если вывод значения переменных в режиме симуляции, то реально, в свойствах симуляции выбирается.
Вид для печати
нет, систему адресов
а зачем ? есть же калькулятор, ставите в десятичной, смотрите что в шестнадцатиричной и все.
а другим дико видеть 16-ти ричные адреса в SCADA.
Как говорится давно занимаетесь, делайте свой ПР, свою SCADA и так далее
Точно, дико видеть десятичные цифры на купюрах :)
где, кроме ол есть десятичная адресация???
восьмеричную можно даже простить.
Вообще все цифровые устройства базируются на двоичной системе, далее шестнадцатеричная, как продолжение двоичной.
Десятичную никак не приспособить, она годится лишь для подсчёта овец и денег...
я написал вам где, возьмите любую SCADA систему, в большинстве случаев адресация десятичная.
Производители контроллеров и устройств часто в документации приводят регистры в 2-х вариантах, десятичном для подключения из SCADA и в 16-ти ричном для опроса например контроллером верхнего уровня. Кто-то только в одном виде предоставляет данные, что собственно не является недостатком.
А Вы не молчите!
zamnarzanom так никто и не молчит.
1. проблема с обратными связями
2. невозможно поставить значение по умолчанию для сетевой переменной
часть ошибок уже поправили... все это разрабы знают и обещают поправить...
1. Очень нужно дать возможность программе читать с системных переменных всё что допускается менять из системного меню ПР200.
2. Разделить на отдельные процедуры запись величин энергонезависимых переменных и самого проекта. При большом количестве всяких настроек, устанавливаемых в ходе эксплуатации и не всегда совпадающих с начальными в проекте, перезапись проекта в ПР200 сейчас заставляет их восстанавливать вручную.
3. Дать ФБ типа "Read from FB" чтобы читать текущее время из ФБ с таймированием, а не уставку. То что есть имеет сомнительную полезность.
Могут ли часы в ПР200 измерять время до миллисекунд? Если да, то нужно иметь еще регистр с миллисекундами. Иначе измерять короткие отрезки времени очень трудно (косвенно через подсчет циклов).
1) Лично я каждую задачу разбиваю на подзадачи. Подзадачи на еще позадачи. Для каждой подзадачи делается маленький и удобный макрос, после чего они все собираются вместе.
2) Лично я когда соединений много и они перепутываются, делаю переменные.
В результате даже очень сложные и объемные работы выглядят вот так:
Вложение 29595
Возможно сделать возможность ввода сетевого адреса ПР200 из переменной?
Смысл: есть несколько установок, абсолютно идентичных, от которых сигнал уйдёт в скаду.
Оборудование имеет свойство иногда ломаться, и замену нужно произвести в крайне сжатые сроки имеющимся персоналом.
По понятным причинам допускать в меню ПР200 не хочется, а во вторых на изучение мануала в 2 часа ночи уйдёт время, а его нет.
Просто прописать в комбобоксе "установка1", "установка2" и.т.д. В таком случае настройка сведётся к выбору нужного варианта из комбобокса.
И читать назначенный адрес тоже! Бывает что для разных адресов отличается функциональность и адрес стал бы маркером включения нужных операций. Сейчас приходится городить специальные опции, управляемые с экрана. Эти же рассуждения относятся и к задатчикам границ AI! Отсутствие этого не позволяет сделать универсальную программу, управляемую одним параметром.
Писал про назначение адреса с комбобокса. В программе жёстко забиты адреса по количеству установок, заодно и алгоритмы с настройками привязать можно к выходам демультиплексора.
(Алгоритмы уже таким образом задавал, всё нормально.)
Есть много установок работающих по однотипным алгоритмам, в таком случае можно.
А универсальность - она до определённой степени только возможна.
Среду дорабатывать не просим. Просим дать доступ к системным уставкам через соответствующие системные переменные, это не сложно. Бессилие какое-то когда из системного меню поменять переменную можно (тот же адрес в сети), но из программы этого не увидишь. К цене это совсем не имеет отношения, это вопросы оптимизации ОЛ, не более. Часто бывает что эти переменные должны быть жестко определенными и их нельзя менять, и если их не видишь нет возможности выполнять контроль или реагировать на эти изменения, а также возможности автоматического их задания при включении или по смене опции. Складывается впечатление что разработчикам жалко так баловать потребителя. Или просто ПР200 так оторвался в своих возможностях от ПР110, что ОЛ не поспевает за ними. Вспомните как долго выпрашивали дать часы в системные переменные. А то что мы хотим - даже проще.
Напротив, это имеет прямое отношение к цене, т.к.
1) Это может требовать доработку ОЛ -- зарплата программисту, тестировщику
2) Возможно, потребуется доработка прошивки ПР -- снова зарплата программисту, тестировщику
3) Описание в документации
4) Потом ответы на вопросы "у меня не работает" на форуме и т.п. Это снова затраты на зарплату кому-то типа Юрия Р.
Но это всё очевидные причины.
Есть и более долгоиграющее:
5) Чем больше возможностей, тем сложнее понимать как работает система. В итоге, будет что-нибудь в духе "добавят поддержку модулей ввода-вывода и случайно сломается обсуждаемся возможность смены переменных". Программисту придётся тратить время на то, чтобы починить "случайно сломанное".
Иными словами, поддерживать и дорабатывать софт/прошивку станет сложнее.
6) При выпуске новых версий ОЛ придётся тратить время на тестирование этой "новой возможности".
ОЛ впереди планеты всей.
Это нормально, когда все стремятся чтоб было лучше. У нас свои проблемы, а у Юрия Р. работа такая. А мы вынуждены кружным путем получать то, что можно было бы просто получить напрямую, просто может эволюционное время ещё не пришло. Вот вчера по поводу галочек укладки float в сетевую переменную он нам открыл глаза, но так и не указал что дальше: это ошибка или так и задумано и останется?
Кстати про часы: осталось без ответа можно ли добавить переменную "миллисекунды" или это в принципе невозможно?
Вы таки финансист или математик?:confused:
Скажу проще: Прибор с большими возможностями будет пользоваться большим спросом, и все эти единичные расходы "размажутся" по огромному количеству изделий.
Вот когда будет онлайн-режим, и запустят в производство большой спектр модулей расширения, тогда да.Цитата:
ОЛ впереди планеты всей.
А пока голову высоко подняли, а хвост ещё не вытащили. Рано на лаврах почивать.
о, один попался
Т.е. по существу возражений нет? От того финансист или математик лично я что-то изменится?
Цель любой коммерческой компании это извлечение прибыли (c) Капитан.
Подкину ещё аргументов:
7) ПР и сейчас дёшево стоит. Если же оно начнёт конкурировать с ПЛК, продажи ПЛК упадут и всего делов.
В итоге будем иметь "недо-ПЛК" под названием "ПР+" и сдохшую линейку ПЛК.
Кому это нужно?
Не выделяю в отдельный пункт (т.к. уже было в 4, 5, 6 ранее; и в 8,9 ниже), но подчеркну, что есть масса не единичных расходов, а непрерывных и постоянных.
Фонд оплаты труда это не единичный расход. Необходимость тестировать и поддерживать возможности, придуманные N лет назад это постоянный расход, а не единичный.
Например, с "сетевыми переменными" в ОЛ. Их постоянно латают. Думать "достаточно сделать 1 раз и оно не сломается" ошибочно, т.к. смежная функциональность может вызывать поломку (добавили "поддержку модулей" -- сломались "сетевые переменные").
Это не значит, что "невозможно по-нормальному сделать сетевые переменные". Это лишь пример к тому, что однажды добавленная возможность будет потреблять ресурсы в будущем.
Уже сейчас в планах две одновременно существующих версии ОЛ (1.8 и 1.9).
online? больше модулей? Добавится ещё пара версий?
8) Начнётся песнь "в версии 1.8 работает так-то, а в 2.0 так-то". Это всё непросто в разработке. Нашли ошибку -- исправлять нужно в 4х версиях. Вносим изменение -- нужно понять стоит ли его делать в остальных. Выпускаем версию -- тестируем ошибки, про которые в этой версии не говорили (изменения по которым пришли "из других версий").
9) Для разработки 4-х версий одновременно не достаточно просто взять и нанять 4х программистов. Лебедя, рака и программиста никто не отменял. Да и где взять тех самых программистов, которые понимают в пром безопасности?
Надеюсь, не нужно объяснять, что ОЛ-ПР это не поделка типа опа-опа-выпускаем?
Красиво излагает Владимир. Конечно нам надо, чтобы "и кузница, и житница, и здравница". Кто хоть пару лет с ОЛ поработал видят и прогресс, и неувеличение стоимости. В этом векторе и ждем продолжения.
А че Семену париться, если он сам планирует 300-х вывести с рынка и закрыть как класс
capzap обратитесь в Siemens, они сами это говорили что 300, 400 линейка будет еще производиться 5-7 лет, еще сколько то лет будет поддержка а потом все, аут.
Это было года 3-4 назад, когда посещал у них курсы по S7-300(400).
А еще забавнее будет, когда настанет 2068(или 69) год и вся их линейка S7-300(400), которая сохранится на производствах в живом виде станет по всему миру колом в режим СТОП.
Суть совершенно не в том через сколько пректратит существование линейка 300 у семена или сотка у овена, они кстати тоже делали объявление, что перейдут на КДС3 когда нибудь полностью. А суть в том что это не аргумент, упадут или нет продажи из-за появления более дешевого и из более низшей линейки продуктаЦитата:
"The new S7-1500 system supplements the existing S7-300/400 systems. S7-300, S7-400 and S7-1500 will be sold in parallel in the coming years. The S7-300/400 systems will not be phased out before the year 2020. Thereafter the components of both systems will be available for another 10 years on a spare part basis."
наверняка у них в продуктах линеек есть узлы, которые работают либо только с 1200, либо только с 300 и в зависимости от построения системы выбор будет всегда один.
Это нормально в принципе, чтобы оба продукта продолжали продаваться.
capzap ошибка в прошивке ПЛК, 2-х байтовая переменная, отвечающая за дни для ПЛК должна быть беззнаковой, однако он ее воспринимает как знаковое число.
При записи новой даты в ПЛК, когда количество дней больше 7FFF ПЛК уходит в СТОП, при переходе даты кажется тоже.
А заявлено по документации что до 2179 года от 1990, а это числа выше и он их воспринимает как отрицательные и валится.
Возможно исправили в новых прошивках, просто с тех пор мне не довелось живьем работать с Сименсом... 1ххх серию тоже не щупал.
вам самому то анегдотичной эта ситуация не кажется? Есть такой анекдот, руководитель заходит в кабинет к программистам и говорит вот познакомтесь ваш новый коллега, они ему так это же помидор, начальник не помидор, а сеньор помидор. это я к тому, что подобные ошибки могут начинать исправляться после наступления критической даты, только овощами
capzap если бы я работал сейчас с сименсом, я бы точно мог сказать, исправили или нет, но на тот момент на всех стендовых 300/400 ошибка была.
з.ы. я же сказал, понятия не имею исправлена эта ошибка или нет. Если у вас есть доступ к данным ПЛК можете проверить сами, запишите штатным средством дату выше 2069 года и узнаете.