amusin

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

Вам туда -> http://www.smtu.ru/rus/elemcom/educ_R.html Не стесняйтесь позвонить - отличные спецы.

Вот еще Classic Ladder. http://membres.lycos.fr/mavati/classicladder/ А как было бы здорово, если бы был открытый проект runtime + среда программирования! В ПЛК - javaVM + специализированные классы. Среда программирования: ввод - Beremiz, сохранение проекта в XML (OpenPLC дает фррмат - см. вложенный файл), XML to java - некий компилятор генерит исходный файл java (Beremiz делает в Си, к сожалению, что, имхо, направление в никуда из-за требования наличия Си-компиляторов, которые почти всегда платные для большинства платформ). Дальше подсовываем исходник компилятору java из JDK, например, и имеем на выходе процессорно-независимый байт-код. Плюсы - мейнстримовский тулчейн, royalty-free система исполнения. Итого - платить нужно только разработчику ПЛК за компилятор. Юзеры не платят ни прямо, ни косвенно (roylaty-то нет). Самое интересное, что поиск в инете дает слабую корреляцию между Java/JRE и PLC. Только IsaGRAF отметился. Хотя, по-моему, все должно идти к стандартизации системы исполнения, будь она хоть на java, хоть еще на чем (LUA и пр.) TC6_XML_V101.pdf

К сожалению, я не уверен, что не подставлю его.

Они толковые ребята. Я разговаривал с Пастушенковым Дмитрием, который лично адаптировал CoDeSys на ПЛК на базе C16x. То, что они делают, они делают хорошо. В итоге про возможность адаптации на ARM7 мне рассказал инженер службы поддержки другой фирмы-экспонента в частном разговоре. Правда, у них в ПЛК ОЗУ больше 1М, так что на вопрос по мин. требованиям и он не смог ответить.

Забавно. Когда я повторно подошел к ним, чтобы скинуть подготовленную ими инфу на флешку, Петров сказал, что это они "сгоряча" и, мол, все это недоразумение, дал свою визитку. Да еще раньше книжку подарил! :) Они пояснили, какую именно конфиденциальную информацию я хотел получить? Только не надо про исходники, я говорил про хидеры платформенно зависимой части, которую надо написать МНЕ. Меня интересовали: - требования к ПЗУ и ОЗУ для платформы на ARM7, - объем и содержание работы по адаптации системы исполнения, - возможность загружать МЭК-программы по своему протоколу. Аргументированного ответа на первую часть я от них не получил, причем они копались для ответа в доках, которые отказались предоставить. ARM7 от ARM9 они не отличали, к сожалению. На вторую часть вопроса ответили общими фразами, типа за 2 дня управитесь. На третий сказали - да, но тоже без аргументов. В итоге в выцыганенном файле Test adaptation... только краткое описание, как "завести" plc и связать со средой программирования, а также ссылки на доки, в которых они и копались. Понятно, что они боятся предоставить инфу, которая может помочь их конкурентам. Но, на мой взгляд, они переборщили с закрытостью и не дают достаточно инфы для принятия решения в пользу CoDeSys. Не смешно было бы потратить 10кЕвро + лицензии, чтобы убедиться, что runtime просто не влезет в мою контроллер и надо ставить внешнее ОЗУ, а может даже переходить на более "жирную" платформу!

Это не очень хороший вариант. т.к. вдобавок к калибратору вольтметров постоянного тока дополнительно придется иметь калибратор вольтметров переменного тока, который вкупе с усилителем (для напряжений свыше 100В) - 2 таких приличных гробика.

Попробую поддержать. На эту тему меня натолкнуло обсуждение http://electronix.ru:80/forum/index.php?showtopic=13407 Также по запросу "61131" на этом форуме много топиков. Теперь результаты моих поисков. 1. Коммерческие среды программирования: CoDeSys - http://www.codesys.ru/ 3S Software (royalty, 100 лицензий - по 110евро, 1000 - по 42, для 32-разрядных платформ, для 8/16 разрядных - в 2 раза меньше). Лучший саппорт в России и обилие информации. DevKit - 10кЕвро. Все без НДС. Icon-L - http://www.pro-sign.de Блестящая статья Александра Елисеева aly.projektas.lt/Projects/OpenPLC/VisualIDE.pdf Нет поддержки языков МЭК 61131-3. Straton - http://www.copalp.com/ Мало инфы OpenPCS - www.infoteam.de (royalty-free на год) Мало инфы. 2. Полу-коммерческие. ORF http://www.o-r-f.org/ Среда исполнения (runtime) бесплатна и open source , но среда программирования (Coryo) - за деньги, http://www.yellowstone-soft.de/engl/yscoryo.htm 3. Бесплатные (free, open source). Beremiz - www.beremiz.org. Сырой проект. Нет коммьюнити. Буквально сегодня был на выставке ПТА (Е-бург), общался с ребятами из Пролога, продвигающего CoDeSys в России. В т.ч. с Игорем Петровым. Вышеупомянутые цены - от них. Уровень поддержки по среде программирования хороший. А вот для разработчика контроллеров до покупки девкита объем инфы очень урезан, и при применении out-of-list платформы нет четкой уверенности, что CoDeSys на ней "пойдет". Все же, после моих уверений, что я им не конкурент, они дали мне кое-какую информацию, но пока не было времени прочитать. PS. В рамках выставки они организуют семинар по CoDeSys (завтра и послезавтра). Кто хочет - узнавайте подробности у них на стенде. Выставка, напоминаю, в КОСК "Россия".

Приемлемый вариант. Непонятно, откуда возникло условие "если Вы поверяете свой прибор сейчас на синусе"? Дело в том, что в свое время мы предложили метрологам (институт метрологии) вписать в МП поверку только на постоянке, аргументируя тем, что после регулировки (тоже по постоянке) мы можем измерять синус с той же погрешностью. После проведения серт. испытаний метрологи убедились, что погрешность измерения в заданных пределах, и они утвердили наше подтверждение.

Вот я и пытаюсь понять - это наша недоработка или метрологов, которые писали нам ПМ испытаний. В любом случае, спасибо за наводку на принцип измерения, а также ваши сообщения в соседней теме. http://electronix.ru/forum/index.php?showt...=40061&st=0 Понятно. Хотя по-доброму надо переписывать изм. часть на измерение срв.:( Тогда убил бы 2 зайцев: и сертификат есть, и соответствие результатов измерений "штатному" прибору. Есть такая мысль. Но тогда нужно проходить испытания заново. Что деньги и, главное, время. Тоже вариант :)

У сертификата есть приложение "Описание типа...", в котором написано "...измерения действующего значения напряжения переменного тока частотой 25, 50 Гц +-1%..." По вашему мнению, что-то сделано неправильно? Есссно, как вариант, Uэф синуса можно было бы измерять и пиковым детектором - умножив результат на 0,707, получить скв. Но реальные сигналы неидеальны, поэтому так и сяк приходится интегрировать (будь то скв или срв). Мой прибор измеряет и выдает скв, т.е. честно вычисляет корень из суммы взвешенных квадратов отсчетов. Да, есть ФНЧ, но без него я споткнусь об алиасы.

В яблочко! Оказывается, он просто выпрямляет переменку... Пожалуй это один из факторов, наравне с моим ФНЧ. Нет, у нас не было требования по доп. погрешности, вызванной Кф.

Ок, скажите частоту меандра с периодом 20 мс :)

CoDeSys я назвал не столько из-за мощи, сколько из-за универсальности - возможности сделать адаптацию под любую платформу. Обзор делаю для проекта. Есть много немцев, французы есть, чехи. А про наших не попадалось. При прочих равных почему не купить российское? Какие среды разработки вы можете назвать? Интересуют именно универсальные продукты независиых фирм-разработчиков.

Пока речь о 50 Гц. Промышленный - Ц4380М. Мой измеряет среднеквадратическое значение, перед измерением сигнал проходит через программный ФНЧ с полосой 250 Гц. Прибор имеет сертификат об утв.типа СИ. Но в программе испытаний мы подавали только "чистые" воздействия с соответствующих калибраторов (DC и AC). Подробности: погрешность до 2,5%, реально около 1%. На меандре результат измерения ниже, чем у "цешки". Зависимость погрешности от формы не снимали. Диапазоны разные, например, 10...30В. Как измеряю - написал выше. Регулирую (калибрую) только на постоянке.

АндрейХ, Непонятно, что вы имеете в виду под "полным комплектом ПО", но вряд ли это исходные файлы адаптации миллениума для меги128. У меня встречный вопрос. Есть ли российское ПО, аналог CoDeSys'а? Можно даже без строгого следования МЭКу 61131-3.

Есть 2 вольтметра: собственной разработки (цифровой) и промышленный (стрелочный). DC и sin измеряют одинаково, в пределах погрешности. При наличии же гармоник, либо сложной форме сигнала (меандре) показания начинают существенно различаться. Технологи ставят задачу - показания должны совпадать на всех реальных сигналах. С какой стороны подбираться к задаче?

Если нужен один самописец, то купите demo-board'у с датчиком и внешний модуль АЦП с интерфейсом USB, например, http://www.lcard.ru/ext.php3 Софт для ПК - у них же, бесплатно. Модули АЦП Можно посмотреть других производителей: http://www.rudshel.ru/shop/index.html www.ni.com (есть пред-во, дорого).

http://aly.projektas.lt/Projects/ARMDomina...RMDominator.htm

спасибо! Тяжеловесно, конечно, а что делать.

Вообще-то мешает упомянутый ГОСТ, хотя я и сделал, пока, в нарушение, 1R1, 1R2 и т.д.

В ГОСТ 2.702-75 (новее не нашел) есть указание "3.22. На схеме изделия, в состав которого входят функциональные группы, позиционные обозначения элементам присваивают по правилам, установленным в пп.3.17-3.19, при этом вначале присваивают позиционные обозначения элементам, не входящим в функциональные группы, и затем элементам, входящим в функциональные группы. При наличии в изделии нескольких одинаковых функциональных групп позиционные обозначения элементов, присвоенные в одной из этих групп, следует повторять во всех последующих группах." Последний абзац вступает в противоречие с существующей практикой - не может быть двух элементов с одним поз.обозначением.

Как стоит именовать элементы в каналах? Пока останавливаюсь на варианте $Component, а на плате уже нанести номер канала. Правда, в этом случае будет один референс для элемента (R2, например) во всех каналах.

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

ПИКи не знаю. Обычно в МК из более глубокого сна можно выйти по внешнему прерыванию. Для этого линию RXD замкните на EXT_INT и настройте последнюю на спадающий срез. При этом возможна потеря первого байта, но не факт.