Op 18 februari 2023 10:38:44 schreef J.D:
Hallo,
Ik zit momenteel in het 6e jaar Elektrische Installatiemethoden en voor het vak automatisatie moeten we een Grafcet ontwikkelen om een kruispunt aan te sturen. De regeling om de lampen aan te sturen heb ik al getekend maar ik vindt maar niet hoe ik er voor zorg dat dit systeem vanzelf opstart en zich steeds blijft herhalen.
Weet iemand wat ik moet doen, aub?
Alvast bedankt!
Iedereen krijgt iets dergelijks op school. Een verkeerskruising of een koffieautomaat of iets soortgelijks. En op elke school moet je dat coderen of te wel omzetten in een of ander programma achtig iets. Ik hoor hier grafset, Tia portal enz. Ik ken eigenlijk geen van al deze programmeer omgevingen. Nu is het met programmeer omgevingen zo dat die nogal tijdelijk zijn. De (programmeer) generatie van nu weet ongetwijfeld alles van grafset maar over 10 jaar is er een andere generatie die absoluut noot iets heeft gehoord van grafset. En de carrière van de TS gaat veel langer duren dan die 10 jaar. Ik heb mijn verkeerskruising destijds gemaakt op een 6800 cpu in machinetaal. Mijn koffiemachine moest ik eerst met karnaugh uitpluizen en vervolgens omzetten in een statemachine voor een pld. De oude garde hier weet precies waar ik het over heb. De jongere generatie heeft hier waarschijnlijk nog nooit iets van gehoord.
Nu is dat allemaal niet erg zolang de basis er maar is. Dan kun je eigenlijk alles in in elke programmeeromgeving gooien die je wilt. En een echt ideale programmeer omgeving bestaat niet. Voor sommige doeleinden zijn sommige programmeeromgevingen echter handiger. Zoiets als een kleine auto rijdt net zo goed als een grote. Alleen is de grote een stuk handiger als je een hoop zooi moet meenemen.
Ik heb tijdens mijn opleiding een ding geleerd dat tot nog toe altijd is opgegaan. En dat is het het maken van een zeer exacte systeem beschrijving van het product dat gemaakt moet worden. In het geval van een klant moet de vraag van de klant worden omgezet in een zo'n beschrijving en laat je die beschrijving ook ondertekenen door de klant. Dit ten teken dat die het er mee eens is. Een klant komt er later altijd achter dat er nog wel een knopje of dingetje bij geprutst kan worden. Een oorzaak waardoor een project nooit helemaal gaat werken en nooit af komt en heel erg duur wordt. Iets waar volgens mij de belastingdienst over mee kan praten. Als je echter een ondertekende systeembeschrijving hebt, kun je voor dit soort zaken een meerprijs berekenen en dan denkt de klant eerst even na voordat hij met een eindeloze wensen lijst komt. Wat voor de klant een kleinigheid lijkt, kan voor de programmeur wel eens het helemaal opnieuw beginnen en anders inrichten van de software betekenen. De klant begrijpt niets van wat er onder motorkap gebeurt en kan zich de hoeveelheid werk die zoiets met zich kan meebrengen gewoon niet niet voorstellen.
Dus het eerste wat de TS zou moeten is die exacte systeembeschrijving maken, Daarin moet staan hoeveel verkeerslichten er moeten komen en exact wat die dingen in de verschillende verkeerssituaties moeten gaan doen. En ook alle mogelijke uitzonderingen moeten beschreven worden. En alles zal in een normale voor iedereen begrijpelijke taal gesteld moeten worden. In dit geval dus gewoon Nederlands. Hier zullen ook alle mogelijke fouten uit gehaald moeten worden. Na controle en goedkeuring kan pas begonnen worden met de volgende stap.
Die volgende stap is beginnen met coderen. Ik begon vroeger (en nog steeds) die systeem beschrijving om te zetten in iets dat vroeger een z.g. flowdiagram genoemd werd. Dat had maar drie symbolen. Een ovaal(het begin), een rechthoekig blokje als commando en een wiebertje(als beslissingsblok). Meer gebruik ik niet. Onze stagiaires zie ik veel meer symbolen gebruiken. Dat moeten allemaal IEC dingen zijn. Ik heb eigenlijk geen zin om dat allemaal te gebruiken omdat dit allemaal nogal tijdelijk is gebleken. Als ik in een oudere installatie of in een installatie in een aziatisch of ander deel van de wereld bezig ben zijn de schema's heel erg anders. Ook schema's van bijvoorbeeld een buizenradio uit 1930 zijn best heel erg anders dan de moderne schema's van apparatuur.
Vanwege deze tekening evolutie houd ik alles zelf zo eenvoudig mogelijk. Dan kan iedereen het nl "ook over vijftig jaar en ook in andere taal en cultuurgebieden " begrijpen. Maar ik heb die keuze vrijheid. De TS niet, die zal zich uiteraard aan alle richtlijnen van die school moeten houden.
Dus aan de TS: Maak eerst die systeembeschrijving en daarna iets als een flowdiagram. En zet dat uiteindelijk om in code. Whatever dat mag zijn. En hoe je terug gaat naar het begin dat zul je in de handboeken en manuals van je programmeertaal moeten vinden. In machinetaal was het gewoon een jump naat het begin adress. Soms was dat adres #0000. maar bij andere cpu's weer niet. In basic was dat: #regel veel# GOTO 10. In pascal was dat gewoon een end van de mainloop. Zo heeft Fortran, cobol, C, Dephi, Phython enz. dus elk zijn eigen methoden en manieren. Maar uiteidelijk komt alles wel op het zelfde neer.
Er bestaat vast wel ergens een voorbeeldprogramma van dat grafset waarin je vinden kunt hoe e.e.a. moet.
Overigens was die systeembeschrijving bij mij op school ongeveer een halszaak. Was die niet goed of afwezig dan werd je naar huis gestuurd en was het einde schoolopleiding.