C компилатор за S7! който прави със страница 3

Опции за темата
Търсене на тема
дисплей

Ако всичко това е толкова безсмислено, аз се питам защо има толкова много езици за програмиране на компютъра.

компилатор

Ако седя пред даден проблем, винаги бих могъл да кажа, че мога да го реша с единия или другия, защо другите са все още наоколо? Мисля, че колкото повече избор, толкова по-добре. Може да е, че компилаторът c може да реши задача много по-лесно, отколкото как би работил с някой от съществуващите.

Мисля, че трябва просто да се осмелите да направите тази стъпка, не е нужно да я използвате. а в случай на проблеми, при които употребата е разумна, тя вече ще бъде използвана.

Светът извън S5/S7 не е толкова патентован, така че има много пътища, по които може да се извърви там, въпреки че изборът на средства винаги трябва да се основава на целта. Дали Pascal, C или C ++, за да назовем само няколко, съответства на развитието в този сектор. В света на Windoof обаче човек вече е на път да позволи на BG да попречи, без Microsoft Foundation Club няма почти нищо и три пъти можете да предположите на каква основа работят OPC сървърите на Siemens. За много кучки не остава почти нищо друго, освен да се поклонят пред диктовката.

Има няколко неща, които не могат да бъдат направени в SCL, но които много добре могат да бъдат формулирани добре и безопасно в STL. Това е напр. стремеж да мислите за други решения. Фактът, че IL не може да се мълчи и че IL използва езикови елементи от C, е друга мотивация за мен. Това, което също ме дразни, е постоянната нотация в SCL, която се различава значително от синтаксисните правила на Паскал (вече очаквам възражението на пуристите от S7).

Така беше и от теб. но беше добре

Все още познавам LSB много добре, защото съм от доста време.
Как си представяте процеса.

Ако се интересувате, регистрирайте се и ми напишете PM. Досега (уикенд) не очаквах подобен отговор. Ще водим дискусии по темата демократично в екип в лична атмосфера.

Някой опитвал ли е някога за S5, имаше такъв
книга от Францис-Верлаг:

Управление на машината с компютър. Реализирайте успешно контролните задачи на PLC с компютъра.
Автор: HOFER, Йоханес,
ISBN 3772348211.
Предлага се само в книжарници втора ръка.

По това време това не представляваше по-малък интерес за хората.

С най-добри пожелания Герхард Бдърле
_________________________________________________________________

Опитът не означава нищо. Можете да правите нещата си лошо в продължение на 35 години. Кърт Тухолзки

Включва ли това и стандартната C библиотека? Като имам предвид само частите, които имат смисъл в този контекст. Под смислен имам предвид напр. всичко, в което може да се намери.

Кодът на Zottel вече е използван в няколко нишки като пример за "ужасните условия" в C. Единственият проблем е, че източниците на libnodave не са добър пример за това, защото според мен Zottel се е придържал към „добрите нрави“ при програмиране. Придобих опита си с C/C ++ преди 14+ години и оттогава той ръждясва. И все пак се разбирам много добре с кода на Zottel !

Проблемът, който много хора имат с C (аз също), е, че C поглъща почти всичко, което е поставено пред него, и някои програмисти пишат съответно нечетлив код. Но това всъщност не е грешка в C, това е на този програмист. Единствената грешка на C е, че изобщо допуска подобни ексцесии.

Затова съм критичен и към приемането на C като език за програмиране в PLC, но кой знае, C е може би най-разпространеният език на компютъра въпреки описаните проблеми.

Така че за специални функции мога да си представя да ги програмирам в C или VB, а не в STL!
Ако в напр. е ясно програмиран в "C", кодът може да се чете по-лесно и бързо, отколкото в STL.

Не познавам повечето от работните зони тук на дъската, нашата област е специална машинна конструкция (трансферна линия, обработващи центрове, монтажни линии и т.н.). Днес тук се използват много приложения на трети страни като видеонаблюдение, моби и много други. а също и административни задачи в PLC.
Напр. управление на палет или инструмент в обработващ център.
Програмирането на тези неща в C би било много полезно, тъй като напр. Използва се ProTool Pro и там се използват и части от изображенията.

Когато „ноу-хау“ е налице, клиентът може да разгледа и STL или FBD блок. Клиент или обслужващият персонал не трябва да прави промени във всички модули. Никой не се оплаква, че напр. с NCU57x.x в основната програма или с Hi-Graph или с TL2000 блокове са блокирани. Така че производителят може също да заключи модули с ноу-хау.

Със сигурност търсенето на C за Step7 не беше толкова голямо в миналото, но възможностите, функциите и изискванията нараснаха много през последните години. От друга страна, не е толкова лесно за Siemens да се развива на различни нива. Забелязвате това много силно, когато използвате различните инженерни инструменти на Siemens заедно. Това винаги е така при проектите в автомобилната индустрия, където ръководствата за проекти идват от A&D Siemens и в началото много често има проблеми с комбинацията от отделните инструменти!

Вече обсъждахме тази тема няколко пъти, защото вече има някои случаи, в които човек би искал да прикачи алгоритъм, в който конверторът C-to-IL да свърши много работа.

Въпросът сега е колко сериозен е въпросът и на каква основа градиш. GCC би бил възможен вариант. Проблемът става отстраняването на грешки!

По отношение на съществуващия компилатор с отворен код C: GCC е създаден повече за 32-битови архитектури. S7 може да прави 32-битова аритметика, но оскъдната памет е по-добре разпределена байт по байт. Затова разгледайте SDCC, C компилатор за различни микроконтролери. Трябва само да добавите нов гръб (генератор на код), ако не се лъжа.