CLD Prüfungsängste, Timeout

Seit einiger Zeit bereite ich mich nun auf die CLD Prüfung vor und habe dabei viel gelernt. Allerdings macht mir eines am meisten Sorgen, nämlich die vorgegebenen 4h Zeit einzuhalten.
Zur Vorbereitung habe ich
- den Münzautomaten aus dem Buch "Einführung in LabView" umgesetzt
- mich durch den Core 3 Kurs gearbeitet und den "Theater Light Controller" nachprogrammiert
- das Success Package komplett durchgearbeitet
- einige der Beispielprüfungen programmiert: Car Wash (in beiden Versionen), Geldautomat und Sprinkler Controller(noch nicht ganz fertig).
Eigentlich sollte man denken, ich habe mich gut vorbereitet, allerdings komme ich immer wieder mit der Zeit in die Predouille.
Zuerst war das wohl daran geschuldet, dass ich durch den Core 3 auf Producer Consumer gepolt war und gedacht habe ich müsste es bei den
Beispielprüfungen auch so machen. Allerdings habe ich inzwischen eingesehen, dass das wohl einfach zu viel ist und bin auf den ereignisgesteuerten Zustandsautomaten
zurückgekommen.
Ich mag momentan etwas betriebsblind sein, aber mir fällt jetzt kein gravierender Unterschied zu den Musterlösungen auf. Ich benutze FGVs für Timer, Sequenzierung
und File I/O und versuche das Main VI nicht zu überfrachten. Die Doku ist in meine Zeitmessungen natürlich mit eingerechnet und war aber auch nicht wirklich maßgebend
für die Programmierdauer verantwortlich.
Ich poste mal meinen letzten Versuch mit dem Sprinkler Controller, vielleicht fällt einem ja was auf, wo ich es mir unnötig kompliziert mache.
Für den Stand des geposteten Codes habe ich 4h und 2min gebraucht.
Heute möchte ich gerne den Sprinkler Controller fertig stellen und nächste Woche möchte ich mich gerne noch an dem Traffic Controller, dem Boiler und an der Kaffeemaschine versuchen.
Was mir etwas Hoffnung macht ist, dass ich beim Car Wash in der zweiten Version (mit dedizierter Selektion des Waschprogramms) aufgrund der Vorerfahrung mit der ersten Variante (mit economy/deluxe wash) fast zwei Stunden schneller war. Aber es hat eben immernoch nicht gereicht.
Ich bin wegen der Prüfung total aufgeregt und meine Frau ist total fertig, weil sie mir mit den zwei kleinen Kindern den Rücken freihalten muss.
Entschuldigt bitte den nervösen Post, aber natürlich muss ich einfach diese Prüfung bestehen wegen der Fahrt- und Prüfungskosten und weil es mich einfach
vor organisatorische Schwierigkeiten stellen würde, wenn ich die Prüfung ein zweites mal versuchen müsste.

Ja, wegen der vorgegebenen Zeit hätte ich auch Angst. Denn mit der Zeit kommt man nur hin, wenn man von Anfang an das richtige Konzept hat. Aber ich z.B. fange praktisch immer ein Projekt noch mal von vorn an, weil mir während der Arbeit noch ein grundsätzlich besserer Lösungsansatz einfällt. Wenn man das während der Prüfung macht, hat man schon verloren.
Ich habe mal hier ein Ampelsteuerungs-VI gepostet, welches einfacher ist als andere Löungen im Internet.
Aber der Tip den ich eigentlich geben wollte: Da es sich bei den meisten Aufgaben um Zeitsteuerungen handelt, gibt NI irgendwo den ausdrücklichen Hinweis, dass man sich zur Prüfungsvorbereitung mit dem VI "verstrichene Zeit" befassen sollte. Damit kann man beim Programmieren viel Zeit sparen, es dauert aber ein Weile bis man dahingekommen ist, was mit der Funktion alles möglich ist und wie sie sich genau verhält
Es ist z.B. erwünscht daß ein Programm gegebenenfalls sofort beendet werden kann. Deshalb sollten Wait-Funktionen von mehreren Sekunden, die das blockieren, tunlichst vermieden werden.

Ja, danke für das Verständnis und ebenfalls für das Ampel-VI.
Ich hab den Sprinkler inzwischen fertig und habe 4 1/2h gebraucht.
Ich habe viel Zeit verloren, weil ich im FGV ein Input statt mit dem Schieberegister mit
dem Funktionsparameter verbunden hatte und die Fallunterscheidung einmalig/kontinuierlich und Abfragen der Array Position
beim Wechsel der Sprinkler Parameter dreimals falsch programmiert habe. Das passiert mir wohl nicht nochmal.
Weiterhin hatte ich die Funktionsparameter standardmäßig auf "erforderlich" geschaltet, was für die FGV nur beim Enum Parameter Sinn macht.
Das hat dazu geführt, dass ich mehrmals zurück in die SubVIs musste um den Eingang zu ändern.
Meine Taktik ist zur Zeit alle mir bekannten Prüfungsbeispiele zu verstehen um in der Prüfung nicht alles von vorne durchdenken zu müssen
und möglichst viele Fehler vorher zu machen und daraus zu lernen.

Meine Empfehlungen zum CLD:

1) Aufgabenstellung genau durchlesen - nimm dir dafür die notwendige Zeit, ruhig 15 min.
2) Programmierkonzept so einfach wie möglich, und das ist eine State-Machine. Im Extremfall sogar ohne Event-Struktur, dafür mit gutem altmodischen Polling der Bedienelemente. Keine aufwändige Programm-Struktur anfangen, nicht mal Producer-Consumer oder ähnliches. Sowohl die Beispiel-Prüfungen als auch meine CLD-Prüfung waren mit diesem Konzept lösbar.
3) Was du auf jeden Fall direkt hinprogrammieren können musst, ist ein Timing-VI. Also ein FGV, welches eine verstrichene Zeit misst (mglw. mit Unterbrechungen), diese mglw. zurückmeldet usw. usw., alternativ musst du dich mit den Timing-Express-VIs sehr gut auskennen.
4) Doku hatten wir ja schon, kann auch kurz und knapp sein. Selbst wenn in der VI Beschreibung nur steht "hier kommt die Doku rein", bringt dir das schon Plus-Punkte.
5) Sieh zu, dass dein Programm am Ende ausführbar ist, selbst wenn es nicht ganz korrekt ist. Das ist besser als andersrum
6) Enums IMMER typdefinieren!
7) Fehlerbehandlung nicht vergessen. Es kann nützlich sein, sich am Anfang ein leeres VIT-Dummy mit "Error-In", "Error-Out", Case-Struktur, und Anordnung "DATA-IN", "DATA-OUT" im FP anzulegen (s. Anhang).
8) Keyboard-Shortcuts und Quick-Drop können dir das Leben extrem vereinfachen.
9) Die VI-Icons nicht auf Standard lassen. Vorschlag: Am Anfang ein einfaches Template erstellen (Header mit weißer Restfläche), auf das weitere Design keinen zu großen Aufwand legen. Schon ein Text langt aus. Maximal nach einem passenden Icon in der Icon-Lib suchen, aber nicht selber anfangen, etwas zu designen.
10) VIs aufräumen. Ctrl-U kann bei einfachen Sub-VIs (und die Sub-VIs sollten beim CLD eher einfach sein) durchaus eine Hilfe sein!

So, das war es erstmal.
Und nicht vergessen, du brauchst "nur" 70% zum Bestehen, nicht 100%. Es muss nicht alles perfekt sein.

Gruß, Jens

Ich finde die Idee mit dem Dummy VI für die Fehlercluster, case Struktur Data in/out, Enum, VI Icon etc. total klasse!
Das spart nämlich richtig Zeit, wenn man die FGVs schreibt.
Zur Aufgabenstellung habe ich mir zur Übung immer ein Flussdiagramm gemacht (ca. 20min), wobei ich aber inzwischen denke,
dass es wegen der linearen Abläufe auch ausreicht die wichtigen Stichpunkte rauszuschreiben.
Hat man bei der Prüfung eigentlich nen Block und nen Kuli für Notizen oder ähnliches, wobei ich natürlich LEERES Papier und einen LEEREN KULI meine?

(29.03.2016 11:36 )HasteMalNeMark schrieb:  Hat man bei der Prüfung eigentlich nen Block und nen Kuli für Notizen oder ähnliches, wobei ich natürlich LEERES Papier und einen LEEREN KULI meine?

Ja, kriegst du. Musst du aber mit abgeben (also das beschriebene Papier). Außerdem erhältst du vor der Prüfung Zeit, die LabVIEW-Entwicklungsumgebung deinen Bedürfnissen anzupassen (also Paletten abändern, Shortcuts etc. pp.). Aber nicht vergessen, auf nicht NI-Toolkits (OpenG o.ä.) hast du keinen Zugriff. Nur das, was mit LabVIEW mitkommt. Im Extremfall kannst du dir also per Projekt-Assi auch ein Leer-Projekt mit Actor Framework anlegen lassen. Bloß dann wirst du wahrscheinlich nicht in 4 Stunden fertig.

Gruß, Jens

Anzeige

Gehe eigentlich nur davon aus, das Quick Drop verwenden zu können und evtl. die Vorlage für "SubVi mit Fehlerbehandlung" um die für die eigene FGV Vorlage zu verwenden.
Ist das eigentlich zu dreist, als Alternative zum Leerprojekt mit Actor-Framework(?) eine allgemeine Vorlage für FGVs nach vorher besprochenem schon vor Beginn der Prüfung anzulegen, denn...
- ich habe sie ja dann nicht von zu Hause mitgebracht und
- sie ist ja im Prüfungsraum entstanden und
- sie ist nicht geklaut
(Also ich meine nach dem Motto, alles was nicht explizit verboten ist ist erlaubt)

(29.03.2016 14:19 )HasteMalNeMark schrieb:  Gehe eigentlich nur davon aus, das Quick Drop verwenden zu können und evtl. die Vorlage für "SubVi mit Fehlerbehandlung" um die für die eigene FGV Vorlage zu verwenden.
Ist das eigentlich zu dreist, als Alternative zum Leerprojekt mit Actor-Framework(?) eine allgemeine Vorlage für FGVs nach vorher besprochenem schon vor Beginn der Prüfung anzulegen, denn...
- ich habe sie ja dann nicht von zu Hause mitgebracht und
- sie ist ja im Prüfungsraum entstanden und
- sie ist nicht geklaut
(Also ich meine nach dem Motto, alles was nicht explizit verboten ist ist erlaubt)

Wenn Du mit Quickdrop Erfahrung hast unbedingt bei der Vorbereitung mit konfigurieren wie Du es gewöhnt bist, das kann einiges an Zeit gewinnen.
Ich habe meine eigene Vorlage mit Fehlerbehandlung gleich zu Beginn erstellt, allerdings nicht in den Vorlagen installiert sondern einfach mit .vit Endung abgespeichert und wenn man die dann öffnet erstellt LabVIEW automatisch eine neue Kopie, die man dann abspeichern kann.

Grundsätzlich dürfte die Zeit die Du erhälst um LabVIEW vor Beginn zu konfigurieren nicht ausreichen um solche Tricks zu machen. Bei mir waren das mal 5 Minuten oder so, daher würde ich mich nicht zuviel darauf konzentrieren.

Aber die wichtigsten Regeln:

1) Keine Panik!!! Wenn Du zu aufgeregt wirst, ein paar mal tief durchatmen und Dir bewusst machen, dass keine Leben davon abhängen!
2) Die Aufgabe gut durchlesen. Lieber einmal zuviel dann einmal zu wenig
3) Dokumentiere die VIs. Schreibe kurze Texte sowohl im Diagramm als auch in der VI Beschreibung. Mache ein VI Icon für jedes VI. Eventuel reicht die Vorbereitungszeit aus um ein Icon Template zu erstellen und abzuspeichern. Das sollte einfach ein farbiger Kopfbalken sein mit dem Rest leer. Wenn Du dann ein neues VI abspeicherst selektierst Du im Icon Editor dieses Template und fügst einen kurzen Text in den Kopfbalken, der der Funktion des Subsystems entspricht (ERR für Error handling VIs, LOG für Logging Funktionen, etc) und einen kurzen Text im Body der etwas spezifischer ist. Niemand kontrolliert das auf Rechtschreibung, also keine wertvolle Zeit an Details verschwenden. Die automatische Bewertung kontrolliert, dass ein Icon gesetzt ist und Dokumentationstext im VI und Diagram vorhanden ist und der Bewerter schaut es sich auch Stichprobenweise an, aber der Umstand, dass etwas dort steht (solange es nicht völliger Humbug ist) ist schon mal etliche Punkte wert.
4) Versuche die Applikation so zu machen dass es am Ende funktioniert. Besser eine oder zwei Funktionen nicht oder nicht korrekt implementiert dann alles perfekt aber nicht ausführbar.
5) Du musst 70% der Punkte holen, Dokumentation ist da ein wichtiger Bestandteil davon, ein funktionsfähiges Programm ebenfalls, auch wenn nicht alles gemäss Aufgabenstellung funktioniert.

Mit der Vorbereitung die Du gemacht hast, solltest Du das locker schaffen, wenn Du Deine Nerven nicht verlierst!!!