Во всяком случае, здесь все считается по ГОСТу Р 8.625-2006
И это радует!
ХЗ по каким полиномам и какими формулами это сделали бы буржуи

Не знаю, для FPP ГОСТ может и подойдет, но еще в ВУЗах преподают ЧМОИ (Численные Методы Обработки Информации), где подобного рода задачи рассматриваются чуть-ли не на первых лекциях ( по-крайней мере так было в 70-х годах ). Как быть с обработкой исключений ?
Интересно, а в Конграфе описано, КАК сделать САМОМУ отображаемый на мнемосхеме квадратик (прямоугольник)?

Косте Дж
Подобные задачи на мащинах со слабыми вычислительными возмможностями всегда решались методами, именуемыми "аппроксимация" и "интерполяция", выпускались даже микросхемы ПЗУ с зашитыми в них значениями основных функций (этакие электронные таблицы Брадиса). В данном случае хватило бы 5-6 значений на нужном отрезке параболы, чтобы получить результат с заданной точностью. Правда для этого надо мыслить категориями аппаратного программирования, а не больших квадратиков. Кстати одной из отрицательных сторон FBD заключается в том, что пользователи перестают понимать, что собственно происходит на аппаратном уровне, если при программировании под Windows это не страшно, то для разработчика устройств на контроллерах это признак деградации. Я вообще считаю, что язык FBD для контроллеров это ошибка природы, т.к. написание программы в несколько килобайт на C или st не представляет никаких затруднений (для специалиста конечно), а попытка внедрить такой высокий уровень абстракции в такие маленькие и зачастую узкоспециализированные программы ничего, кроме снижения качества не даёт.

to qqq___qqq
Создать свой квадратик в Конграфе можно, но очень муторно, т.к. процедуры от МЗТА не существует. Я это делал путем редактирования скриптов и добавления файлов с функциональными алгоритмами. У этого пути есть два серьёзных минуса
1) Алгоритм в принципе компилируется только на моей машине.
2) Нет возможности отладки, т.к. гении из МЗТА создали Simulator как программу, которая работает не на основе откомпелированного бинарника, как все приличные отладчики, а создает алгоритм на основе исходного скрипта из модулей для Win32, дублирующих модули для контроллера, так что результат работы симулятора и программы это не совсем одно и тоже. У меня даже был случай, когда программа компелировалась неправильно (из-за косяков в Конграфе), а на симуляторе все было чудно (если Kass думает, что я опять клевещу на МЗТА, то это не так, я написал им об этом случае, правда вместо извинений получил длинный список уже исправленных ими косяков, короче мужики работают).
Кстати по этой причине Kass может устать дожидаться версии Конграфа с возможностью написания кода на st, ведь тогда надо будет еще добавить прогу, которая будет что-то делать для симулятора.

to rsn1964
То, что можно вставить свой "квадратик" - это хорошо, а то что "муторно"- это плохо. Я и предлагаю делать так, чтобы добавление "квадратиков"
было ДОКУМЕНТИРОВАНО разработчиком. Тогда будет баланс "удобство-функциональность". Например, разговор с ТАС был коротким - на-х,
пользуйтесь тем, что дали. Дают, правда, библиотеку макросов (в виде квадратиков), и указывают честно, на основе какого алгоритма (документа)
сделана функция. Честные ребята....
Что касается симуляторов, то тут беда у многих производителей. В основном это касается СИНХРОНИЗАЦИИ прохождения сигнала (а я это стараюсь отладить в 99% случаев). Вообще-то нормальные ребята честно эмулируют проц контроллера (благо имеется куча симуляторов различных платформ и это не проблема). Эмуляция входов,выходов вообще не проблема, тут и заморачиваться нечего. Но в эмуль ОБЯЗАН грузиться ТОТ ЖЕ
самый код, что и в контроллер, иначе это - ГЛУПОСТЬ.

2 rsn1964 и ggg__ggg
1. Во-первых, на 99% процентов уверен, что ответ ТАСа - на-х
повторят ВСЕ производители.
Ведь не смотря на ваши заверения в профессионализме,
никто не может гарантировать корректную работу ваших блоков.
Здесь надо, имхо, если вы хотите получить Open Sorce
идти в сторону альянсов, типа того же Кодесиса.
2. Зачем вы так настойчиво хотите оформить свои блоки квадратиками в ФБ ?
Ну пишите на си, в файлах, отлаживайте там же.
Зачем использовать нелюбимый конграф (xworks и т.п.) и еще более нелюбимый симулятор ?
Никому кроме вас эти дополнения радости не доставят, имхо.
3. 2 rsn1964
Вот тут и кроется непонимание. Если человек дорос до какого-то уровня, то он не будет "опускаться" вниз (ну это как... сисадмин не будет выполнять работу эникейщика... или врач работу медсестры и т.п.).
Если вы считаете, что Вы "выше" FBD, тогда зачем до него опускаться ?
При этом для других, тех кто "пониже", FBD - простой и действенный (всеже) путь приобщиться к программированию контроллеров
и выполнять поставленные задачи. А нехватка каких-либо знаний () выявится при наладке и "отрихтуется".

to lex
Полностью с Вами не согласен!
1) Профессионализм != отстутствию "косяков". Они есть ВЕЗДЕ, это-факт. Конечно, МОЖНО переписать имеющиеся блоки с помощью БАЗОВЫХ "некосячных" блоков. Только получится ГРОМОЗДКИЙ код. Про ограничение уровней вложения я писал. Далее, это будет on-line код, если что-то,
поменяется, то из ВСЕХ программ, содержащий данный блок придется его ВЫДЕРГИВАТь (или вносить изменения "по-месту"), что ОЧЕНЬ хлопотное
дело (связи, "красивость картинок" и прочее). Гораздо проще внести изменения в библиотеку или firmware, и просто пересобрать программы.
2) Производитель НЕ НЕСЕТ НИКАКОЙ ответственности за свое ПО. Прочитайте Лицензионное соглашение. Так что, если Вы "накосячите"- это Ваши проблемы.
3) НИКТО не спорит, что в виде FDB программы более понятны Службе эксплуатации. Для этого его собственно и придумывали. Иногда и мне проще что-то быстро сваять в FDB. Вопрос в том, из чего ваять?
4) Видел много программ, написанных людьми, понимающими как щелкает реле, но понятия не имеющих, как работает контроллер. Разгребал результаты, иногда смялся, чаще - охреневал от самонадеянности. Правда, денег зарабатывал.

2 ggg__ggg
1. При всем уважении к Вам (серьезно, уважение есть - сложилось такое мнение по постам),
профессионализм этот - самопровозглашенный.
Пока другой человек "через себя не пропустит" Ваш изменения - ничего они не стоят для него.
А блоки от производителя - они и есть блоки от производителя,
можно связаться с тех. поддержкой, послать баг репорт - исправят.
Если Вам прислать баг репорт - исправите или пошлете ?
2. Производитель несет ответственность за свою репутацию -
ему невыгодно, ели пойдет устойчивый слух, что у него проги косячные и к
баг репортам не прислушиваются.
3. Не столько службе эксплуатации, сколько все же разработчикам.
4. Все это имхо.
Ибо я видел программы (вернее результат), выполненные проектировщиками Си
(наверное хорошими проектировщиками Си), которые ни фига не понимали
как работает вентустановка или тепловой узел.
При этом они не хотели ничего менять в своих взглядах и в своей программе....
Они тоже самонадеяны... Еще бы - они ж программисты !

Lex'у
В очередной раз попытаюсь объяснить проблему программирования контаров на C.
Вместе с файлом Xann.bin, создаваемым Keil'ом из исходного текста (с этим нет проблем, проверено), утилиты из пакета Kongraf создают файл xdnn.bin и xpnn.bin (nn-сетевой номер контроллера). Файл xpnn.bin содержит информацию о параметрах
(переменных: название, смещение, точность) и списках. Способ формирования этих данных худо-бедно понятен, но у файла есть заголовок, зависящий от его содержымого черт его знает, каким образом. Назначение второго файла вообще не понятно. Потом из этих трех файлов делается один, тот который вы загружаете в контроллер. Это для MC5, для MC8 файлов больше. До тех пор, пока вы не узнаете алгоритм их формирования, про программирование в среде Keil можно не думать. Поэтому я и создавал квадратики, чтобы заставить конграф отработать их по заданному в его утилитах алгоритму. Я не собираюсь обвинять разработчиков в том, что они пытаются когото запутать или что-то замутить. Создание вспомогательных файлов это обычное явление, но каким бы примитивным не был механизм их формирования, его надо просто знать. Тут есть три пути 1) спросить на МЗТА: спрашивал, молчат как партизаны, 2) дезассемблировать соответствующие утилиты (удачи), 3) создать кучу проектов и вычислить методом научного тыка (еще более удачи).
К тому же, как я уже говорил, встает проблемма с отладкой. Без неё, даже такой неполноценной, как симулятор, както нехорошо.
О невозможности деградации:
Судя по тому примеру с термометром, который я приводил, разработчику было или всё по барабану, или о реальных процессах, происходящих в контроллере, он знает не более, чем об обратной стороне Луны.
Кстати действуя долгое время по шаблону люди забывают даже закон Ома.
О необходимости доступа к алгоритмам:
Делал один проект на MC5. всё было нормально, но для полного успеха нехватило буквально нескольких байт памяти. Пришлось кое-что выкинуть (не принципиальное, но желательное). Если бы была возможность немного оптимизировать кое-какие операции небыло-бы проблемм.

2 rsn1964
развернуто, поэтому понятно
ну чтож...
посоветую все же искать выходы на производителя,
например через С-Пб или бывших сотрудников

К сожалению на МЗТА не очень охотно идут на контакты по таким вопросам, а устанавливать личные контакты с сотрудниками живя в Новосибирске затруднительно.
Кстати, чтобы не прослыть ворчуном хочу дать совет по теме. Случайно наткнулся на совет Kass'а от 19.12.2007,19:24 (это дата), как задействовать диф. датчик в алгоритме. Рекомендую в качестве признака того, что вентилятор включен использовать не состояние выхода контроллера, а заведенный на контроллер сигнал состояния пускателя (доп. контакт). Был такой казус: сдали объект, где шкафы и совт разрабатывал один гений со стороны. Он поступил так, как нарисованно у Kass'а. Всё хорошо, но периодически случаются просадки, или кратковременные отключения напряжения (как правило почему-то в выходной ночью). Контроллер, имея резервированное питание их не видит, думает, что вентилятор включен, а давления нет. Вывод: обрыв приводного ремня. Останавливает установку и выдаёт такую ошибку. Обслуга разбирает вентилятор, видит, что он исправен, и будучи не обремененной избытком интеллекта впадает в ступор. Заказчик необремененный избытком чувства юмора впадает в ярость. Так продолжалось, пока вышеназванного гения не заставили переделать всё по правильной схеме.

Признак того, что вентилятор включен - показание диф. датчика. Контроллер пытается запустить вентилятор и вентилятор не пускается (не важно по какой причине) это типовая аварийная ситуация. Имхо "гений со стороны" прав.

Так цепь питания катушки пускателя зачем на UPS сажать? Есть команда, но нет ОС по питанию - сигнал аварии по питанию.
Хотя сам в случае питания мозгов от бесперебойника предусматриваю мониторинг ввода контроллером.

Показания диф. датчика - признак того, что вращается ротор вентилятора. Причиной его остановки может быть как обрыв привода, так и авария двигателя (или проподание напряжения, короче остановка двигателя). Это две разные аварии и неплохо если контроллер сообщает истинную причину (это правило такое), а также различная реакция на них: в первом случае установка останавливается без всяких вариантов, а во втором возможен перезапуск при появлении напряжения. Да и вообще, знаете как трудно объяснить электрикам, что надпись "Авария ротора" на дисплее это необязательно авария ротора, а кое-что ещё.

P.S.
Похоже со схемотехникой у вас ,господа, не намного лучше, чем с программированием.

2 rsn1964
Дык сразу написали бы, что из Новосиба!
Очно бы и пообщались. Мож че полезное скажу
А мож и нет . Бывает и так.

P.S.P.S.
Только-что прочитал San tecnik'а, отвечаю. Пускатель был как раз не на UPS, он через реле подключался к силовой цепи, как обычно. Проблемма в том, что контроллер не знал о состоянии пускателя и думал, что вентилятор постоянно включен.

Уважаемый схемотехник, вентилятор работает тогда, когда он вертица (такая вот страшная тайна), а посему единсвенный признак работы вентилятора - наличие перепада давления на нем. Если Вы желаете отследить массу вариантов "почему встал вентилятор", то лично Вам я рекомендую снять еще и состояние автоматического выключателя и состояние ввода питания, тогда Вы сможете отследить даже "закипевший" пускатель. "Авария ротора" это уже что-то и вовсе страшное.

Ну и выскажусь по части оптимальности "квадратиков" контроллеров контар, PXC, BMR и т.д. и т.п.
Эти контроллеры деланы не для Вас, госпада программисты, они деланы для людей с программированием не знакомых. Большая часть их стоимости - это цена оболочки программирования позволяющей создать работоспособную систему не нанимая профессионального программиста (дорого стоят такие люди в мире, в отличии от стран бывшего СССР). Не нравятся Вам эти устройства - не покупайте их, Ваших навыков хватит для программирования разного рода одноплатных ОЕМ устройств.

Сергей, есть конечно масса различных причин остановки вентилятора, вплоть до атаки инопланетян. Но все-таки их можно поделить на две основные группы: электрическия (пропадание питания, перегрузка двигателя и т.п.) и механические (оборвало ремень, сорвался ротор и пр.),
о первых сигнализирует состояние пускателя, о вторых состояние диф.датчика. Подходы к устранению аварий так-же различные. А вообще хотел бы я посмотреть, как вы будете объяснять заказчику, что "авария ротора" (извените, но так автор программы её назвал, если хотите, назовите остановкой ротора или хоть невращением вентилятора) это на самом деле пропадание питания. Это раз.
Во вторых живем мы как-раз на территории бывшего СССР, может вас от этого коробит, но с этим тоже надо считаться. Надо исходить из реалий а не из того, как принито "во всём цивилизованном мире".
И наконец в третьих не мы одни так живем. Тут неподалеку, можно сказать за огородами есть страна, которая кое-что у нас переняла, и развивается так, что скоро будет актуален вопрос об изучении китайского. Отсюда это неплохо заметно.

Каким образом об электрической аварии сигнализирует пускатель? Скорее всего у нас различные схемы подключения вентиляторов, в моих схемах пропадание питания не вызовет отключение пускателя получающего питание 24В постоянного тока от контроллера. Кроме того, на мой взгляд, ловить аварии по питающему напряжению следует на вводе к группе установок, а не для каждого вентилятора в отдельности.


Если бы меня коробило мое местоположение я бы его сменил. Реалии состоят в том, что Вы уподобляетесь коту лежащиму на горящем бычке (помните такой анекдот о самом ленивом?) не нравится Вам оборудование - покупайте другое. Если же Вы желаете изменить это конкретное устройство - идите на работу в МЗТА, они достаточно часто набирают людей на работу.

Сергею Долганову.
Во первых.
Низковольтные пускатели стараюсь не применять (точнее сказать не применяю).
Причины две.
1) Отсутствие обратной связи.
2) Отсутствие экономического смысла: мощность катушки пускателя порядка 10 Вт. Пусковая еще больше. Контроль необходим только за пускателями включения вентиляторов (их на одном контроллере 1 или 2), так что прирост цены трансформатора из-за низковольтных пускателей практически съедает экономию от одного или двух промреле. Зачем за практически те-же деньги ухудшать унформативность системы управления.
Во вторых.
Возвращаюсь к приведенному выше примеру. Заказчик предъявил притензию по поводу того, что контроллер выдает неверную информацию о системе (на мой взгляд притензия вполне справедливая) и заявил, что не будет платить до устранения этого отклонения. Конечно можно в духе нынешнего времени включить дурака и промести какую-нибудь пургу о новейших тенденциях и течениях в цивилизованном мире, но я для этого слишком совковый и решать технические проблеммы привык техническими средствами, а не болтовней.

Не понял

Тут у нас с Вами явное непонимание. Мой конроллер весь 24-х вольтовый (трансформаторов ему не требуется как понимаете) пускателей в шкафу обычно 8 - 14 штук ("нагрузочная способность" по входам\выходам у моего контроллера несколько выше)


Ряд решений проблемы я предложил выше. Ваше решение считаю не оптимальным, о чем и написал впрочем.

Вот в том то и дело, что кирпичики используются во всех языках, кроме ассемблера. В С вы пишите инклуд и лепите кучу библиотек, которые хрен знает кто писал и в каком состоянии. Разумеется вы можете писать свои библиотеки, но на это надо потратить не мало времени, которое врят ли кто оценит. Поэтому всегда приходится прибегать к компромисам: использовать проверенные кирпичики, а если что не устраивает, то лепить свои кирпичики. Это применимо к любой среде программирования, и к тому же Конграфу. Там в качесте ассемблера есть основные логические элементы (кстати все микросхемы от простейших до самых сложных процессоров по сути построены на их базе) и различные математические действия. Это по сути схематехнический ассемблер. Делайте что угодно. Я довольно много использую собственно написанных кирпичиков. А чужие кирпичики я элементарно проверяю. Схематехники и радиолюбители меня поймут: подключаешь генераторы на вход и смотришь осциллограммы в нужных точках. Все элементарно видно.


Я соглашусь с вами. В Конграфе ФБД максимум отражает схемотехнический подход к проектированию АСУТП. Мне очень много экономит времени.
Мне в Конграфе не хватает только одного: возможности реализации собственными силами новых протоколов по сети. Каждый раз отправляю на МЗТА. Но в честь им берутся и делают.

Уж как то вы совсем запутались. Приведу конкретные примеры. На одном из объектов пришлось выбрасывать контроллеры Джонсон Контролл и модернизировать систему. Датчики стояли так же Дж. Контр. Менять датчики было в лом, но как оказалось, их характеристика не подпадает ни под один из мировых стандартов. Чисто своя кривая. Ну и какие пролемы?

На первом рисунке вы можете видеть ФБ А99, которых не найдете в библиотеке Конграфа. Кстати слева можете видеть в библиотеке кучу "кирпичиков", слепленных из других более мелких моих "крпичиков", и это только в последней версии Конграфа. В предыдущих еще больше. Просто не все сразу перекидываю, а только по необходимости.

На втором рисунке содержимое того самого А99. Ну ведь ничего сверхестественно, как раз апроксимация по множеству значений. Работает прекрасно. Поэтому и не понятны проблемы, о которых вы пишите.

То о чем вы пишите, простая ошибка в проектировании АСУ ТП. Контроллер не может незнать об отключении питания. У меня везде это прописано. Более того, он получает сигнал АВР, если питание приходит от генератора или резервной линии, и если мощности не достатоно, не даст включить прописанные не по 1 категории венсистемы. Это банально просто. И сигнал ОС от пускателя тоже ошибка. У вас банально пропал контакт или кабель отгорел, или автомат выбило... просто море вариантов, когда пускатель будет замкнут, а вентилятор не работает. Так что вернее сигнала, чем от датчика перепада давления нет.


Друзья, да банальный сигнал АВР надо заводить. Конет Контара в диспетчеризации. Как можно не вывести на диспетчеризацию сигнал о пропадания питания??? Как это не учесть в алгоритме? Во всех примерах, что я вешал тут могли видеть индикаторы "Сеть", "Связь" и тому подобное. Как без этого то?

Я выше отписал уже по соответствующим темам. У вас просто банальные ошибки в проектировании систем АСУ ТП. Вы в алгоритмах не прописываете очень важные вещи, отсюда и непонимание. Возможно вы слишком много уделяете времени непосредственно программированию и недостаточно составлению непосредственно алгоритмов. А алгоритмы в нашем деле на первом месте. От них зависит правильность работы систем и интерпретеции ситуаций. А реализовать готовый алгоритм можно на множестве языков программирования.

ЗЫ. Попробуйте просматривать ваши посты и ответы на них выше. После модернизации форума стало несколько неудобно, т.к. ответы остаются по дереву в верху.

Силовая сеть, к которой подключены вентиляторы и сеть с бесперебойным питанием существуют параллельно и какая связь между пропаданием напряжения в силовой сети и сигналом АВР известно только Kass'у.
И всё таки ситуация: питание контроллера есть, команда на включение выставлена, а силового питания нет, вентилятор стоит, давления нет, на дисплее "Обрыв ремня" ("Нет давления" или как вам еще угодно). Заказчик требует, чтобы контроллер выдавл истинную аварию. Что ответить?
К тому-же при аварии "Обрыв ремня" установка должна быть остановлена и запускаться только вручную, а при аварийной остановке двигателя у меня происходит автоматический перезапуск при появлении напряжения питания. Как это реализовать только на основании сигнала от диф. датчика?

Это известно любому электрику со средним образованием. Есть такая штука на вводе, как ВРУ. Там есть такой пускатель, который фидеры переключает. Если у вас пропало питание с основного ввода, то основной пускатель отбрасывается. С него и снимается сигнал АВР. Если у вас на резервный ввод подключен резервный фидер, или дизель-генератор, то питание пойдет с него. Если на резервном вводе нет ничего, то питания не будет.


Вы неисправимы. Если у вас нет АВР, или вы не знаете, что это такое, то поставьте банально в щит автоматики три релюшки, по одной на фазу, а контакты их соберите последовательно и заведите на контроллер. Тогда ваш контроллер мало того, что не будет выдавать сигнал на включение вентилятора и вообще вентустановки, но и сможет сообщить на АРМ про отключение электропитания.
Судя по таким вашим ошибкам можно с уверенность предположить, что у вас нет никакой защиты и от пропадания фазы, и от перекоса фаз... Вместо того, что бы исправить все в корне, вы хотите избавиться еще и от датчика перепада давления.

Ответ Kass'у
АВР и сила всегда питается от разных фидеров и в описанной мною ситуации питание контроллера было, а питания вентилятора не было. И вообще мне надоело объяснять вам азы. Кроме того, чтобы облаивать меня со всех сторон вы, кажется, не на что ни способны. Так-что всех благ и прощайте.

2 rsn1964
Не, не, не уходите !
К тому же, как я понял, это ошибка не Ваша, а другого человека.

Мне вобщем тоже показалось, что Вы способны только на "доморощеный гуризм", всех благ.

Немного оффтопа .
Коллега rsn1964 поднял очень важную тему - взаимодействие (именно в такой формулировке) между разработчиками библиотек и конечными пользователями. Очевидно, такое взаимодействие идет на пользу обеим сторонам, но очень болезненно воспринимается производителями.
Вообще, кто пишет эти библиотеки - вопрос не праздный. Вот почему. Кто, собственно, является потребителем продукта?
Инженеры-схемотехники, программисты или некий УНИВЕРСАЛЬНЫЙ потребитель, одинаково хорошо разбирающийся в "железе" контроллера, принципах его работы, в программировании, сетевых протоколах, математике, физике, да еще и в автоматизации "рубящий не по-детски". Думаю, таких ох как мало. Очевидно, что "автоматчиками" становятся либо программисты, либо инженеры.
Вторые, в лучшем случае "уверенные пользователи ПК", искренне принимают на веру СИСТЕМНЫЕ библиотеки, у них другая задача - "прикладнуху" бы одолеть. И столкнувшись с "косяком от производителя" , впадают в "легкий транс". Особенно печально, когда это происходит на "горящем объекте", вдали от техподдержки. Пипец - это наиболее точное опеределение. Кстати, о техподдержке. Тема "избитая" и обсуждать ее нет желания. Именно для этих случаев и нужны ПРОГРАММИСТЫ, не боящиеся слов firmware, syslib. Возможно, не особо "рубя" в автоматизации, они могут помочь ИНЖЕНЕРАМ по автоматизации.
Теперь о программистах, решивших стать "автоматчиками". Нутро быстро не меняется, подход идет от бит и байт. Азам и "Хитрым фокусам" автоматизации приходится учится у "ламеров", сиречь от инженеров. Трудно это, по себе знаю - самолюбие просто трещит от нагрузки.
Форум - это место, где человек рассчитывает на помощь коллег, причем иногда обращение за помощью - это уже ПОСТУПОК.
Теперь о тех, кто пишет библиотеки. Очевидно, это должны:
1) быть системными программистами для контроллеров
2) мастерами автоматизации
3) прекрасно знать нужды конечного пользователя ЛЮБОЙ квалификации
4) хорошо знать физику, математику
Реальность несколько другая. Поэтому и предлагается открыть интерфейс для тех кому это НАДО. Ну не полезет обычный инженер в эти дебри, он попросит
программиста помочь. Выигрывают все.
По поводу дифф. датчика. Да вентилятор СКОРЕЕ ВСЕГО крутится, если сть перепад. Датчики имею тенденцию "залипать". Диагностика состояния - 90% программы. Как насчет аппаратной ошибки контроллера, сигнала "пожар", "летящего пуска" при кратковременном пропадании питания (силы), потери связи с модулем (если управление висит на модуле). Вообщем - смесь подхода программиста и инженера.

2 rsn1964. ИМХО у вас заведомо не правильный подход к проблеме. Если у человека что то не получается, он приходит сюда с вопросом, ему подсказывают, в чем проблема, он исправляет и все в порядке. Вы же вместо вопросов начинаете хаять оборорудование, инструменты, руки в конце концов. Такой подход не поможет ни вам, ни другим. Попробуйте сменить подход.

Я не знаю как еще ответить. Уже и примеры приводил... Напуске последнй котельной выяснилось, что один из ФБ не сбрасывается, как написано в хелпе. Ну и чего рогом то упираться? Минут за 20 был написан свой блок, который прекрасно и по сей день работает. Не могу понять, в чем тут сложность то?


Вот в этом то я думаю корень проблемы. А еще есть вариант, когда "автоматчики" (которые до того не занимались написанием прошивок) решили стать программистами. Причем в обоих случаях ключевым считаю слово "РЕШИЛИ". Если бы поменьше самоуверенности и побольше желания разобраться, то все бы получилось. Безвыходных ситуаций не бывает.

to Kass
Суть проблемы не в том, чтобы средствами FDB сваять блок, а в том, сделать его средствами БАЗОВОГО языка и включить его в СТАНДАРТНУЮ библиотеку. Другой важный момент - возможность оперативно ИСПРАВИТЬ пойманный "косяк" в стандартной библиотеке, не ожидая ответа от техподдержки или новой версии библиотеки / firmware.
Более того, многие возможности ОС контроллера не вытащены в стандартные блоки, что сильно затрудняет правильную диагностику состояния системы. Причины такой "скупости" совершенно непонятны, но это-факт. Приходится как-то выкручиваться, а это глупо, т.к. данные-то где-то уже есть.

Как много можно сделать на обычной автомойке портального типа.

Господин Павленко, спешу Вам сообщить об еще одном косяке, обнаруженном в продукции Вашей компании. При выводе на дисплей (по крайней мере в контроллере MC5) все целые числа интерпретируются как "целые беззнаковые" (unsigned int), хотя в программе они фигурируют как "целые знаковые" (int). В силу обстоятельств мне пришлось использовать этот тип для задания параметров. Наладчики были слегка ошарашены, когда вместо -40 увидели 65496. Конечно такие господа как Kass скажут, что надо ипользовать float или не использовать вообще ничего, но все-таки согласитесь это косяк.

Товарищ rsn1964. Спасибо за сообщение, сегодня обязательно проверим. Что касается целых, иногда это необходимо, например, когда этот параметр транслируется в Modbas.

Хочу подкинуть еще пару тем.
1. В Конграфе уже разработан ФБ BacNet. Ожидаем в ближайшем релизе.
2. у ZuXEL появился шлюз PowerLine в Ethernet. У кого есть опыт применения. Кто видел такие промышленные? http://zyxel.ru/content/catalogue/classifier/67/73/825

Да, ошибка подтверждена.
Исправили. Скиньте в личку свой e-mail

Я не понимаю, почему ФБД для вас не может являться базовым языком? Какая разница, на чем делать библиотеку? Давайте вернемся к мотивации? Для чего нужны библиотеки? Наверное для ускорения процесса создания алгоритма. Не так ли? Так вот ФБД как никакой другой язык сокращает время разработки. А создание блоков на самом ФБД позволяет очень быстро изменить блок под новые задачи или условия. Лично мне абсолютно не нужны блоки на С. Если мне в таком блоке что то потребуется изменить под новые ТЗ, то я потрачу времени гораздо больше, чем с блоками на ФБД. Т.е. переход на блоки на С входит в противоречие со смыслом создания библиотек, как экономия времени.

Наверное надо говорить более предметно. Приведите конкретный пример, когда без блока в библиотеке на С вам никак не решить поставленную задачу. Тогда возможно разговор будет более предметным.

1.Это исправленная прошивка для пульта.
2.На тему программирования FBD. К январю планируется выпустить версию Конграфа который поддерживает в том числе программирование скриптами.

Вот пусть кто то приведет такое время реакции среди зарубежных производителей. Вот так вот за день врятли кто бы исправил ошибку.

К сожалению, так не всегда бывает.

Пару строчек кода поправили, не надо шуметь. Ошибка, судя по описанию, дибильная и в других изделиях я вообще такого не встречал. Может говорить только о низком профессиональном качестве разработчиков/тестировщиков Контара (видимо еще и пользователей) если она всплыла только сейчас после стольких лет выпуска изделия.

Как-то по моему двухстариничному описанию товарищи из фирмы Stulz прошивку переписывали, Nick таких знает. Ничего, справились по-моему дней за 5. Изменений там хватало, поскольку идеология работы их оборудования в принципе была неправильной.

Абусмо, Поправили всего одно слово, убрали unsigned. По высказывание видно, что вы не имеете опыта разработки и программирования. Сложнее всего искать простые ошибки, их не ожидаешь. Выдавать черное за белое и белое за черное не стоит ->. (мол ошибка в концепции - фигня, парни молодцы а вот элементарная ошибка - это да!)
Так же будучи не знакомым с тестировщиками, разработчиками, пользователями - их хаять не надо - не красиво!
По поводу стольких лет Выпуска изделия. Это не изделие, а целый ПТК. Он динамично развивается, дополняясь новыми приборами (MC12, ME20, MC8.3...) и функциями (LonWork, BACNet, Конфигураторы, загрузка удаленного объекта, генератор отчетов, контроль IP связи и т.д......) при этом сохраняя полную поддержку старых версий ПО и приборов.
Далее, не надо превращать ветку в помойку, высказывайтесь только конструктивно по теме. Если Вам не нравится КОНТАР, не заходите сюда и не раздражайтесь.

За Ваше уважение к Контару — спасибо. Не забываете писать с заглавной буквы.

Вспомнилось, как в 80-х шутили программисты, что если программа откомпилировалась без ошибок, то значит не работает компилятор.

To Kass по поводу FDB и базового языка.
Несколькими постами выше приведена СИТУАЦИЯ. Не думаю, что ее просто было разрешить с помощью FDB
Аналогично, если проблемы с коммуникацией, обработкой ошибок или прочего, что касается "внутренних дел контроллера" или правильности работы "кирпичиков" FDB. Очевидно, что "прикладнуху" удобней писать на FDB (но не тем, кто изначально учился на С, PASCAL и прочих языках).

qqq и Kass, Ваша тема вечна. Возможно qqq прав в том, что иногда необходимо вмешательство в на языке более нижнего уровня, Kass в том, что выгоднее и быстрее использовать готовые блоки. Компромисс -
1. Конграф (среда разработки алгоритмов для ПТК) поставляется с исходниками FB на С.
2. Сейчас ведется работа над новой версией Конграфа которая будет содержать уже и ОС контроллеров.
3. Как я и говорил разрабатывается возможность программирования скриптами.
Возможно, эта информация немного охладит спор.

Как такового спора нет . Есть обмен мнениями, основанными на личном опыте. Прогресс Контара налицо - респект.

С первого моего знакомства с Контаром (~ 4 года), много ошибок исправлено, и сколько еще будет исправлено. Господин KASS, как всегда хотел отличиться, что вот какие молодцы быстро ответили. А таких ошибок бывало по 10 ять в день, сейчас меньше. Это связано с тем, что продукт еще сыроват, и дорабатывается на коленке. У Европейцев, подход другой, они вкладывают знания и средства (у нас только знания), с выходом нового контроллера у K&P, корректировки тоже были, но они в основном связаны с переводом, а технически и программно проблем не возникало. Соответственно у них и тех. поддержка уходит в положенные 17.00, а не как у нас пашем до 21.00.


Сейчас есть новая поговорка у программистов: Либо руки кривые, либо железо!
Обычно первое, но у МС8 и МС5, кривое было и железо.

Олег не в обиду, было же!?



Прогресс на лицо, тут согласен - это радует. Годика через 2-3, вообще не узнать будет.

Николай, Настаиваю еще раз не превращать ветку в ПОМОЙКУ, с засовыванием своего - k&p. Если это так необходимо - создай ветку "О Великий К&P", у Вас это хорошо получается.
Темы 4 года назад, на коленках, как у европейцев - так же к ветке отношения не имеют возможны ветки "О Великие Европейцы", «НОСТАЛЬГИЯ по КОНТАР (или КОНТАР 4 года назад)».

Наверное, все кроется в том, что Вы не являетесь заинтересованным лицом в изучении изменений за столь длительный периуд.

Вы пытаетесь спикулировать когда-то давнишним отношением к продвижению КОНТАР.
Я никогда не скрывал своего непосредственного отношения к продвижению и развитию КОНТАР.
Вы - являетесь продвиженцем K&P.
Поэтому, предлагаю в дальнейшем избегать со своей стороны таких мелких чернопиарных выпадов — некрасиво.