Добрый день, коллеги, ну подскажите когда полностью реализуете ST?
И ещё вопрос, когда же будет реализован ПР205 и будет ли?
Неудобно писать объёмные программы на FBD, столько уродливых и громоздких конструкций даже с учетом макросов.
Вид для печати
Добрый день, коллеги, ну подскажите когда полностью реализуете ST?
И ещё вопрос, когда же будет реализован ПР205 и будет ли?
Неудобно писать объёмные программы на FBD, столько уродливых и громоздких конструкций даже с учетом макросов.
Объемные программы пишутся на ПЛК где есть ST, ПР-ки тут не очень удобны в принципе, хоть с макросами, хоть без....
А голого ST думаю в них не будет
А спросить в теме по ST можно было? Зачем лишний мусор.
Выбор прибора определяют его функции, а не объем кода. Или уже уперлись, код больше не влазит?
Добрый день!Цитата:
Сообщение от Сема
Если вы имеете в виду функциональные блоки на ST, то да, такие планы у нас есть.
Планируем выпуск в течение года.
Какой еще функционал хотите видеть на ST?
ПР205 находится в разработке, но по срокам сейчас сказать определенно сложно. Делаем все возможное, чтобы прибор вышел в 2022 году.
Расскажите, пожалуйста, где планируете применять прибор?
В любом случае все закончится https://owen.ru/forum/showthread.php...ighlight=EFrol
У меня есть наработки на контроллере, который поддерживает ST.Цитата:
Сообщение от Ollema
Я не хочу заново, да еще и в неудобной среде их переписывать.
Функционально меня данный продукт устраивает. Выбор контроллера для данной задачи с поддержкой ST будет избыточным.
ST входит в IEC языки программирования.
ST является компилируемым языком, объем памяти не пропорционален коду.
Что не так?
А почему не VeriLog, например? Этот язык ближе к электронике, чем asm.Цитата:
Сообщение от EFrol
1. Чем выше уровень языка, тем больше там подводных камней, оставленных системщиками.Цитата:
Сообщение от keysansa
2. Чем выше уровень языка, тем больше программист отделен от железа за ширмой библиотек и драйверов, которые в силу п.1, иногда глючат.
3. Чем больше программирование превращается в конфигурирование или рисование схем, чтобы стало доступнее НЕ ПРОГРАММИСТУ, тем выше должен быть уровень знаний ПОСЛЕДНЕГО. (например, возьмите 1С8)
Вопрос:
Зачем издеваться над НЕ ПРОГРАММИСТОМ, когда его гораздо проще научить программировать на уровне железа (на низком уровне), не ограничивая возможностями языка и среды разработки?
Однажды я дал КИПовцу электрическую схему К580ВМ80, на следующий день он принес программу в машинных кодах и сказал, что ему так понятнее.:rolleyes:
Я так понял, Verilog вы считаете выше, чем asm?Цитата:
Сообщение от EFrol
Вы не из команды TraceMode случаем? Они долго троллили так разработчиков, типа наш язык для технологов, а не программистов. Однако, технологи так в TraceMode и не смогли, да и программисты тоже, хотя задумка (с каналами, их пред и пост обработкой) была интересная.Цитата:
Сообщение от EFrol
Не в машинных кодах, а на Verilog, скорее всего )Цитата:
Сообщение от EFrol
Вы путаете язык программирования с языком описания аппаратурыЦитата:
Сообщение от keysansa
Это разные вещи.
Как и язык VHDL его можно только симулировать или генерировать топологию СБИС.
или шить ПЛИС. В этих языках нет понятия "последовательное выполнение".:rolleyes:
Вы мне объясните, чем программирование ПЛИС на Verilog отличается от программирования, например PIC на ассемблере, тогда и поговорим.Цитата:
Сообщение от EFrol
Поговорим о чем?Цитата:
Сообщение от keysansa
Например о разнице, о которой я выше написал.
ЗЫ. Или про последовательное выполнение на обычных реле. Как захотите.
Это мне не интересно.:(
Но интересно вот что. Можно ли этот код на ST переписать на FBD?:confused:
Код:PROGRAM MHO
VAR
ItemTank: INT := 0;
ItemConsole: INT := 0;
TankItem: POINTER TO Tank;
ConsoleItem: POINTER TO Console;
PumpItem: POINTER TO Pump;
END_VAR
FOR ItemTank := 1 TO 12 DO
TankItem := ADR(Tank[ItemTank]);
IF TankItem^.IdPump > 0 THEN
PumpItem := ADR(Pump[TankItem^.IdPump]);
IF TankItem^.IdConsole > 0 THEN
ConsoleItem := ADR(Console[TankItem^.IdConsole]);
IF PumpItem^.OnTMR.Q THEN
ConsoleItem^.LampStart := 0.5;
ELSE
ConsoleItem^.LampStart := 1;
END_IF
IF TankItem^.Level1 AND NOT TankItem^.AlarmLevelD THEN
IF ConsoleItem^.KeyStart AND ConsoleItem^.KeyStop THEN
PumpItem^.State := TRUE;
END_IF
ELSE
PumpItem^.State := FALSE;
END_IF
IF NOT ConsoleItem^.KeyStop AND NOT ConsoleItem^.KeyStart THEN
PumpItem^.State := FALSE;
END_IF
END_IF
END_IF
END_FOR
Вы отказались ответить на мой вопрос. и задаете свой? Молодца, что сказать.
По вашему новому вопросу - попробуйте на asm этот алгоритм реализовать.
Если реализуете - то и на fbd сможете.
ЗЫ. Но к чему вы сюда приплели ST - не понятно, вы же сами говорили, что в истоках asm...Балабол?
EFrol правильный ответ на вопрос "можно ли?" - НЕ НУЖНО.
Я поступаю так же как Вы. Вопросом на вопрос.Цитата:
Сообщение от keysansa
Это кстати ответ на любой вопрос.Цитата:
Сообщение от melky
Может вернемся к теме?
А то нас в курилку отправят.
Где тут у вас вопрос? В том сообщении, на который вы попытались ответить - уже был вопрос от меня, но он саркастический. Раз вы не из TraceMode. Вы же не из него? )Цитата:
Сообщение от EFrol
Вот мой вопрос был:
Цитата:
Сообщение от keysansa
Но я отвечу. На VHDL я смогу, например, создать процессор, выполняющий asm. На asm - максимум - смогу эмулировать его.Цитата:
Сообщение от EFrol
Прикольно, самому выйти на asm, а потом призывать вернуться в тему, когда по asm нечего сказать...Цитата:
Сообщение от EFrol
А почему - не "надо подумать"? ))Цитата:
Сообщение от melky
Так Вы это хотели услышать от меня?Цитата:
Сообщение от keysansa
Зачем Вы приплели сюда VeriLog?Цитата:
Сообщение от keysansa
Ну и где я вышел на ASM?Цитата:
Сообщение от keysansa
Мой вопрос был:
Зачем издеваться над НЕ ПРОГРАММИСТОМ, когда его гораздо проще научить программировать на уровне железа (на низком уровне), не ограничивая возможностями языка и среды разработки?
И Вы ответили сарказмом.:rolleyes:
Мой ответ: Да VeriLog выше чем ASM.
Тезис заключается в том, что лучше КИПовца научить программировать на высоком ST, чем мучать его FBD.
Вы что-то путаете.Цитата:
Сообщение от EFrol
Я ответил на ваше утверждение, что все закончится <ссылка>, там говорилось про assembler. Я сказал, что изначальнее - язык описания схем.
Дальше новых вопросов не было.
Опять ложь?
Язык VerilLog появился в 1983г.
Язык Ассемблера появился в 1949г.
И я не буду с Вами спорить о том, что было изначально.
Да и в моей ссылке речь шла о том, зачем изобретать новые языки, когда и старые работаю неплохо.
Зачем создавать новые тяжелые неповоротливые среды (типа CDS 3.5) с многотомными описаниями и глюками,
когда ArduinoIDE справляется практически со всеми проблемами. Ассемблер брался, как альтернатива IL.
А Вы решили придраться на ровном месте?
А хотите я еще совру?! На предмет "курица или яйцо".
С начала был машинный код, на котором написали компилятор с Ассемблера.
На ассемблере написали компилятор с языка C. Далее написали - С++.
А уже потом написали компиляторы с VeriLog, который почему-то очень похож на C, и при этом не является алгоритмическим языком.
Я не имею ничего против VeriLog, но как выразился melky "НЕ НУЖНО". Есть УГО и принципиальные схемы - чем они не угодили то?
ЗЫ. Я знаю, что ответ будет "НЕ НУЖНО", но все равно спрошу?
Если в ArduinoIDE добавить поддержку ОВЕНовских ПЛК и проекты писать на C++ - дело бы пошло или нет?
Как думает сообщество электронщиков и программистов? Может кто-то уже реализовал такую идею? А я - ни сном ни духом.
Потому что в текущем состоянии ОЛ это костыли, переписывать надо с нуля, а не пытаться натягивать сову на глобус.Цитата:
Сообщение от keysansa
У меня есть знакомый киповец, с которым мы время от времени делаем общие проекты, в общем когда пишу на ST, он на это смотрит как на какую-то магию, однако, контактно-релейные схемы он понимает очень даже хорошо, и вот мы что-то делали на ПРках, он увидел программирование на FBD, и говорит, что это же просто схему надо нарисовать, так это же просто. В общем я ему за 5 минут объяснил принцип построения диаграмм, и он буквально на ходу самостоятельно накидал программу для ПР.Цитата:
Сообщение от EFrol
А на ST он также и смотрит, как на какое-то колдунство.
FBD по-моему отсюда и вырос из умения составления логических схем.
Лично мне проще писать на ST, но могу реализовать и на FBD без особых проблем.
Вот именно! А почему проще? Потому-что Вы разбираетесь в этой "магии".Цитата:
Сообщение от Parovoz
И по мере усложнения проекта Вы можете упрощать код используя эту "магию" (итерацию, рекурсию, указатели на объекты, массивы),
то что на FBD тоже можно сделать, но какой ценой.
Тут ОВЕНовцы спрашивают: что мы хотим от ST? Это говорит о том, что FBD уже не удовлетворяет.
Им хочется, чтобы проекты писали КИПовцы для решения несложных задач.
А так как задачи бывают и сложные, приходится привлекать программистов, которым ST подавай.
Я понимаю, что программисту легче понять КИПовца и переписать на FBD.
В итоге КИПовец уступает программисту, а программист недоволен потерянным временем.
Мне кажется проблема не имеет решения.
Легче потому что в университете было программирование на паскале, делфи, С, С#, С++, ассемблере, html. Поэтому мне был проще к восприятию ST.
А товарищ закончил электротехнический колледж, где он рисовал разные схемы и в глаза не видел программирование, поэтому ему проще FBD.
О чем сыр-бор? Кому на чем проще, на том и пишите! Никого никто не заставляет переучиваться или перепонимать :) Иначе смахивает на выбор обезьяны: банан или гранату?
Вот это вас прокатили по верхам :)Цитата:
в университете было программирование на паскале, делфи, С, С#, С++, ассемблере, html
Не рассчитал чуть чуть, объект большой, думали уложимся, просто хотели бы за относительно недорого что нибудь на си писать.Цитата:
Сообщение от Ollema
Для теплиц хочу, но ФБД неудобно в принципе писать. Даже простые программы пишутся громоздко. Нужно сделать миллион лишних действий, при отладке найти нужное соединение. Плохо переваривается ФБД.Цитата:
Сообщение от Мария Мильчакова