
Bitte wählen Sie die Bereiche, die Sie exportieren möchten:

Schulung LabVIEW Aufbau: Design Patterns und professionelle Programmierung
State Machine, Producer/Consumer, Queued Message Handler und Error Handling:
Schulungsformen
Offene Schulung
- 3 Tage
- 5 gesicherte Termine
- Köln / Online
- 2.030,00 p. P. zzgl. MwSt.
- Dritter Mitarbeitende kostenfrei
- Learning & Networking in einem. Garantierte Durchführung ab 1 Teilnehmenden.
Inhouse-/Firmenschulung
- 3 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Individualschulung
- 3 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Beschreibung
Das muss nicht so sein. LabVIEW hat Design Patterns - bewährte Architekturmuster, die Code strukturieren, wartbar machen und für andere verständlich halten. Eine State Machine macht Abläufe transparent. Ein Producer/Consumer trennt Datenerfassung von Verarbeitung. Ein Queued Message Handler gibt der gesamten Applikation eine klare Nachrichtenstruktur. Functional Global Variables eliminieren Race Conditions. Und der VI Analyzer misst objektiv, wo der Code Qualitätsprobleme hat.
Dieses dreitägige Seminar ist der Schritt vom LabVIEW-Anfänger zum LabVIEW-Profi. Nicht mehr Grundlagen, aber auch nicht gleich Prüfstandsarchitektur - sondern das handwerkliche Fundament , das jede professionelle LabVIEW-Entwicklung braucht.
Finden Sie weitere für Sie passende Labview Trainings.
Schulungsziel
Jede teilnehmende Person verlässt das Seminar mit der Fähigkeit, die drei wichtigsten LabVIEW Design Patterns anzuwenden (State Machine, Producer/Consumer, QMH), durchgängigem Error Handling als Standardpraxis, Alternativen zu globalen Variablen (FGV, Queue, Notifier, DVR) im Werkzeugkasten, einer QMH-Referenzapplikation als Vorlage für eigene Projekte, messbarer Code-Qualität (VI Analyzer, Code Review, Style Guide), einer professionellen Projektstruktur (Projekte, Libraries, Git) und einem priorisierten Verbesserungsplan für den eigenen Code.
Details
Inhalt
- Ziele und Erwartungen der Teilnehmenden
- Klärung individueller Lernziele und Erwartungen für ein praxisnahes und relevantes Seminar
- SubVI-Anatomie: Icon (aussagekräftig, nicht Default), Connector Pane (Standard-Layout: Error In links unten, Error Out rechts unten, Inputs links, Outputs rechts), Dokumentation (VI Description, Terminal Description, Tip Strips). Warum Icon-Design wichtig ist: SubVIs sind die „Funktionsnamen" in LabVIEW - ein schlechtes Icon ist wie ein Funktionsname doStuff().
- Polymorphe VIs: Ein SubVI, mehrere Datentypen - z.B. „Write to File" für String, Waveform und Cluster. Wann sinnvoll: universelle Utility-VIs.
- Type Definitions (Typedefs): Cluster und Enums als Typedef - Änderung an einer Stelle propagiert überall. Strict Typedefs vs. normale Typedefs. Regel: Jeder Cluster und jedes Enum, das in mehr als einem VI vorkommt, muss ein Typedef sein.
- VI Properties: Reentrancy (Non-Reentrant, Shared Clone, Preallocated Clone - wann welches?), Execution Priority (für zeitkritische VIs), Preferred Execution System (für UI-Zugriff).
- Praxis-Übung: 5 bestehende VIs refaktorieren: Icons redesignen, Connector Panes standardisieren, Dokumentation hinzufügen. 2 Cluster als Typedefs extrahieren. Ein polymorphes „Log Message"-VI erstellen (String-Log und Cluster-Log).
- Das Error-Cluster-Prinzip: Error In -> SubVI -> Error Out - durchgängig durch die gesamte Kette. Wenn Error In bereits einen Fehler enthält, macht das SubVI nichts (Early Exit Pattern). Jedes SubVI, das mit Hardware oder Dateien arbeitet, MUSS den Error Cluster durchfädeln.
- Fehlerquellen und -typen: LabVIEW-interne Fehler (File I/O, DAQ, VISA - haben Error Codes), benutzerdefinierte Fehler (eigene Error Codes mit Error Code Ranges registrieren), unerwartete Fehler (Division by Zero, Array Index out of bounds - LabVIEW bricht nicht ab, liefert Default-Werte -> gefährlich).
- Error Handler VIs: Simple Error Handler (zeigt Dialog und stoppt), General Error Handler (konfigurierbares Verhalten), Custom Error Handler (eigene Logik: loggen, Cleanup, Retry, Benachrichtigung).
- Cleanup bei Fehler: Case Structure mit Error-Wire als Selector - im Error-Fall: Instrumente schließen, Dateien schließen, Benutzer informieren, sichere Zustände herstellen. Vergleichbar mit try-catch-finally in textbasierten Sprachen.
- Fehler-Logging: Fehler mit Timestamp, VI-Name, Error Code, Error Description in Log-Datei schreiben. Nicht nur anzeigen - dokumentieren.
- Praxis-Übung: Eine Applikation ohne Error Handling (vorbereitetes „Bad Example") mit durchgängigem Error Handling versehen: Error Cluster durch alle SubVIs fädeln, Custom Error Handler bauen (Fehler loggen + Cleanup), 3 benutzerdefinierte Error Codes registrieren (z.B. 5000: „Instrument nicht verbunden", 5001: „Grenzwert überschritten", 5002: „Kalibrierung abgelaufen").
- Das Problem mit globalen Variablen: Race Conditions (zwei Loops schreiben gleichzeitig), unklare Datenflüsse (wer liest, wer schreibt?), schwer testbar, nicht Thread-sicher. In kleinen Programmen bequem, in mittelgroßen gefährlich, in großen fatal.
- Functional Global Variable (FGV / Action Engine): Non-Reentrant SubVI mit Shift Register als Speicher + Enum als Action (Initialize, Read, Write, Increment, ...). Thread-sicher (Non-Reentrant = nur ein Aufrufer gleichzeitig), klar definierte Schnittstelle, testbar.
- Queues für Producer/Consumer-Kommunikation: Thread-sichere FIFO-Datenübertragung zwischen parallelen Loops. Obtain Queue -> Enqueue (Sender) -> Dequeue (Empfänger) -> Release Queue. Timeout für Dequeue (nicht endlos blockieren).
- Notifier für One-to-Many: Ein Sender, mehrere Empfänger - alle bekommen den gleichen Wert. Ideal für Broadcast-Events (z.B. „Stop All Loops").
- Data Value References (DVR): In-Place-Zugriff auf gemeinsame Daten - vergleichbar mit Mutex-geschütztem Shared Memory. Für Szenarien, in denen FGV zu viel Overhead hat.
- Entscheidungshilfe: Nur ein Consumer -> FGV. FIFO-Übertragung -> Queue. Broadcast -> Notifier. High-Performance-Shared-State -> DVR.
- Praxis-Übung: Alle 5 globalen Variablen in einer Beispielapplikation ersetzen: 2× durch FGV (Konfigurationsdaten, Zähler), 2× durch Queue (Messdaten von DAQ-Loop an Processing-Loop, Befehle von UI-Loop an Control-Loop), 1× durch Notifier (Stop-Signal an alle Loops).
4. State Machine: Sequenzielle Abläufe transparent machen
- Warum State Machine? Flat Sequences und Stacked Sequences sind starr - keine Verzweigungen, keine Fehlerbehandlung, kein Rücksprung. State Machine: While-Loop + Case Structure + Shift Register (aktueller State als Enum). Jeder Case ist ein Zustand, der den nächsten Zustand bestimmt.
- State Machine aufbauen: Enum-Typedef für States (Initialize, Idle, Acquire, Process, Error, Shutdown), Case Structure mit einem Case pro State, State-Transitions als Logik im Case (nächster State = Ergebnis der aktuellen Aktion).
- Erweiterte State Machines: State Machine mit Event Structure im Idle-State (Event-driven State Machine: wartet auf Benutzer-Events, reagiert erst bei Aktion statt zu pollen). State Queue (mehrere States in einer Queue für komplexere Abläufe).
- Antipatterns: Zu viele States (>20 = Redesign-Signal), State-Transitions unklar (Spaghetti-States), zu viel Logik pro State (jeder State sollte genau eine Aufgabe haben).
- Praxis-Übung: State Machine für einen Messablauf bauen: Initialize (Instrument verbinden) -> Idle (warten auf Start-Button) -> Configure (Parameter setzen) -> Measure (Messung durchführen) -> Evaluate (Grenzwerte prüfen) -> Display Results -> Idle. Error-State für Instrumentenfehler mit Cleanup und Rückkehr zu Idle.
- Das Problem: DAQ mit 10 kHz Abtastrate UND UI-Update UND Datenlogging in einer Schleife -> Abtastrate bricht ein, UI friert ein, Daten gehen verloren. Lösung: separate Loops für separate Aufgaben, verbunden durch Queues.
- Standard Producer/Consumer: Producer-Loop (erzeugt Daten - z.B. DAQ-Messwerte) -> Queue -> Consumer-Loop (verarbeitet Daten - z.B. Analyse, Display, Logging). Jeder Loop läuft mit eigener Geschwindigkeit. Queue puffert Differenzen.
- Multi-Consumer: Ein Producer, mehrere Consumer (Fan-Out) - z.B. Messdaten gleichzeitig an Display-Loop, Logging-Loop und Analyse-Loop. Implementierung: mehrere Queues oder Notifier + Queue-Kombination.
- Queue-Sizing: Zu kleine Queue -> Overflow (Daten gehen verloren). Zu große Queue -> Memory-Verbrauch. Monitoring: Queue-Status prüfen (Get Queue Status), bei Füllstand > 80 % warnen.
- Fehlerbehandlung in parallelen Loops: Jeder Loop hat eigenes Error Handling. Kritischer Fehler in einem Loop -> Notifier an alle Loops -> geordnetes Herunterfahren.
- Praxis-Übung: Drei-Loop-Applikation bauen: Loop 1 (Producer: simulierte DAQ-Daten, 100 Hz), Loop 2 (Consumer 1: Waveform Chart aktualisieren), Loop 3 (Consumer 2: Daten in TDMS loggen). Queue-Status monitoren. Stop-Mechanismus mit Notifier implementieren.
- QMH als Kombination: Event-Handling-Loop (Producer: UI-Events und Timer -> Messages in Queue) + Message-Handling-Loop (Consumer: Messages aus Queue -> Aktionen ausführen). Messages als Cluster (Enum Command + Variant Data).
- QMH-Vorteile: Klar definierte Schnittstelle (alle Kommunikation über Messages), erweiterbar (neue Message = neuer Case im Consumer), testbar (Messages programmatisch senden), entkoppelt (UI-Events beeinflussen nicht die Verarbeitungsgeschwindigkeit).
- QMH erweitern: Zusätzliche parallele Loops (DAQ-Loop, Regelungs-Loop) per eigener Queue an den Message-Handler anbinden. Helper Loops für asynchrone Aufgaben (File I/O, Netzwerk-Kommunikation).
- DQMH (Delacor Queued Message Handler): Community-Framework mit Code-Generierung, standardisierten Request/Reply-Patterns, Tester-VIs, Event-based Communication. Für Teams: einheitliche Architektur ohne individuelle QMH-Varianten.
- QMH vs. Actor Framework: QMH für 80 % der Applikationen ausreichend (bis ~10 Module). Actor Framework für hochparallele Systeme mit vielen unabhängigen Akteuren (>10 Module, verteilte Systeme). Empfehlung: mit QMH starten, bei Bedarf auf Actor Framework migrieren.
- Praxis-Übung: Vollständige QMH-Applikation bauen: Event-Handling-Loop erfasst UI-Events (Start, Stop, Configure, Exit) und Timer-Events -> Messages in Queue. Message-Handling-Loop verarbeitet: Initialize (Instrumente verbinden), Start Acquisition (DAQ-Loop starten), Stop Acquisition, Update Display, Log Data, Shutdown. Helper-Loop für DAQ mit eigener Queue.
7. Code-Qualität messen und verbessern
- VI Analyzer: Automatisierte Code-Qualitätsprüfung. Vordefinierte Tests: Broken Wires, Default Error Cluster, Coercion Dots, Missing Error Handling, SubVI Icon not Default, Block Diagram Size, Commented-Out Code, Unreachable Code. Severity-Levels: Failure, Warning, Information.
- Custom VI Analyzer Tests: Unternehmensspezifische Regeln (z.B. „Jedes SubVI muss VI Description haben", „Keine Property Nodes im DAQ-Loop", „Alle Enums müssen Typedefs sein") als Custom Tests konfigurieren.
- Code Review für LabVIEW: Strukturierte Reviews mit Checkliste (Error Handling vorhanden? Typedefs verwendet? Connector Pane standardisiert? Icon aussagekräftig? Dokumentation aktuell?). Peer Review als Team-Praxis etablieren.
- Style Guide: NI LabVIEW Style Guide als Basis, angepasst an Unternehmensstandards. Wire Routing (keine kreuzenden Drähte, keine Tunnel-Loops), Block Diagram Size (max. ein Bildschirm, sonst SubVI extrahieren), Naming Conventions (Control Names = sprechend, SubVI Names = Verb + Objekt).
- Praxis-Übung: VI Analyzer gegen die QMH-Applikation aus Topic 6 und gegen eigene mitgebrachte VIs ausführen. Top-5-Findings beheben. 2 Custom VI Analyzer Tests konfigurieren. Code Review einer anderen teilnehmenden Person (mit Checkliste).
- LabVIEW-Projekt (.lvproj): Alle VIs, Typedefs, Libraries, Build Specifications an einem Ort. Virtual Folders für logische Ordnung (UI, DAQ, Processing, Utilities, Tests). My Computer vs. RT Target vs. FPGA Target.
- Libraries (.lvlib): Gruppierung zusammengehöriger VIs mit Namespace (z.B. DAQ.lvlib:Initialize.vi, DAQ.lvlib:Read.vi). Access Scope: Public (von außen aufrufbar), Private (nur innerhalb der Library), Community (nur für Friend-Libraries). Libraries als API-Grenze: Public VIs = Interface, Private VIs = Implementierung.
- Packed Project Libraries (.lvlibp): Kompilierte, versionierte Libraries - das LabVIEW-Äquivalent zu DLLs/NuGet-Packages. Für Wiederverwendung über Projekte hinweg, für Team-Entwicklung (jedes Team liefert eine PPL), für Deployment (keine Source-VIs auf dem Zielsystem).
- Source Code Control: Git-Integration (LVCompare, LVMerge in .gitconfig), SCC-API in LabVIEW Project. .gitignore für LabVIEW-Projekte. Branching-Strategie: kurze Feature-Branches, regelmäßige Merges.
- Application Builder: Executable (.exe) oder Installer aus dem Projekt bauen. Build Specifications, Dependencies, Runtime Engine, Konfigurationsdateien.
- Praxis-Übung: Die QMH-Applikation in Projekt-Struktur überführen: 3 Libraries erstellen (DAQ.lvlib, UI.lvlib, Core.lvlib), Access Scope korrekt setzen (Public für API-VIs, Private für interne VIs), Virtual Folders für Ordnung. Git-Repository initialisieren, .gitignore konfigurieren, 3 Commits durchführen. Build Specification für Executable erstellen und bauen.
Phase 1 - Eigenen Code analysieren (20 Min):
- Eigene mitgebrachte VIs (oder Seminar-Applikation) analysieren: VI Analyzer ausführen, Architektur-Pattern identifizieren (oder Fehlen davon), Error Handling bewerten, globale Variablen zählen, SubVI-Qualität prüfen.
- Architektur-Smell-Checkliste durchgehen: Monolithisches Haupt-VI? Globale Variablen? Fehlendes Error Handling? Keine Typedefs? Kein Projekt?
- Top-5-Verbesserungen priorisieren (Quick Wins: Error Handling, Typedefs, Icons -> mittelfristig: State Machine, FGVs -> langfristig: QMH-Architektur, Libraries, Git).
- Für jede Verbesserung: Aufwand schätzen, Risiko bewerten, Reihenfolge festlegen.
- Architektur-Ziel definieren: QMH, DQMH oder Actor Framework - welches Pattern passt?
- Code einer anderen teilnehmenden Person reviewen (mit Checkliste). Feedback geben: Was ist gut? Was muss dringend verbessert werden? Welches Design Pattern würde am meisten helfen?
- Stresstest: „Ein neuer Kollege soll deinen Code in einer Woche verstehen - kann er das?" „Ein zweites Instrument soll integriert werden - wie viel Aufwand?" „Der Kunde will den Ablauf ändern - musst du Code ändern oder nur Konfiguration?"
Zielgruppe & Vorkenntnisse
- LabVIEW-Entwickler mit Grundlagenerfahrung: Die über „es funktioniert" hinauskommen und wartbaren, skalierbaren Code schreiben wollen.
- Ingenieure in Mess- und Prüftechnik: Die bestehende LabVIEW-Applikationen professionalisieren und für Teamarbeit vorbereiten.
- Prüfstands- und Testingenieure: Die Architekturkompetenz für mittelgroße bis große LabVIEW-Projekte aufbauen.
- LabVIEW-Anwender, die allein entwickeln: Die Best Practices lernen wollen, die in Teamumgebungen Standard sind.
Ihre Schulung
In Präsenz | Online |
|---|---|
| Lernmethode | |
Ausgewogene Mischung aus Theorie und praktischen Übungen auf persönlichem Schulungs-PC. | Wie auch bei unseren Präsenz-Seminaren: Ausgewogene Mischung aus Theorie und praktischen Übungen. Trainer durchgehend präsent. |
| Unterlagen | |
Seminarunterlagen oder Fachbuch inklusive. Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. | Seminarunterlagen oder Fachbuch inklusive (via DHL). Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. |
| Arbeitsmaterialien | |
DIN A4 Block, Notizblock, Kugelschreiber, USB-Stick, Textmarker, Post-its | |
| Teilnahmezertifikat | |
Nach Abschluss des Seminars erhalten Sie das Teilnahmezertifikat inkl. Inhaltsverzeichnis per E-Mail als PDF. | |
Organisation
In Präsenz | Online | |
|---|---|---|
| Teilnehmendenzahl | ||
min. 1, max. 8 Personen | ||
| Garantierte Durchführung | ||
Ab 1 Teilnehmenden* | ||
| Schulungszeiten | ||
| ||
| Ort der Schulung | ||
GFU SchulungszentrumAm Grauen Stein 27 51105 Köln-Deutz oder online im Virtual Classroom oder europaweit bei Ihnen als Inhouse-Schulung Um ein optimales Raumklima zu gewährleisten, haben wir das Schulungszentrum mit 17 hochmodernen Trotec TAC V+ Luftreinigern ausgestattet. Diese innovative Filtertechnologie (H14 zertifiziert nach DIN EN1822) sorgt dafür, dass die Raumluft mehrfach pro Stunde umgewälzt wird und Schadstoffe zu 99.995% im HEPA-Filter abgeschieden und infektiöse Aerosole abgetötet werden. Zusätzlich sind alle Räume mit CO2-Ampeln ausgestattet, um jederzeit eine hervorragende Luftqualität sicherzustellen. | ||
| Räumlichkeiten | ||
Helle und modern ausgestattete Räume mit perfekter Infrastruktur | Bequem aus dem Homeoffice von überall | |
| Preisvorteil | ||
Dritter Mitarbeitende nimmt kostenfrei teil. Eventuell anfallende Prüfungskosten für den dritten Teilnehmenden werden zusätzlich berechnet. Hinweis: Um den Erfolg der Schulung zu gewährleisten, sollte auch der dritte Teilnehmende die erwarteten Vorkenntnisse mitbringen. | ||
| KOMPASS — Förderung für Solo-Selbstständige | ||
Solo-Selbstständige können für dieses Seminar eine Förderung via KOMPASS beantragen. | ||
| All-Inclusive | ||
Gebäck, Snacks und Getränke ganztägig, Mittagessen im eigenen Restaurant, täglich 6 Menüs, auch vegetarisch | Eine Auswahl unserer Frühstücks-Snacks und Nervennahrungs-Highlights senden wir Ihnen mit den Seminarunterlagen via DHL zu. | |
| Barrierefreiheit | ||
Das GFU-Schulungszentrum (Am Grauen Stein 27) ist barrierefrei | - | |
Buchen ohne Risiko
| Rechnungsstellung |
Erst nach dem erfolgreichen Seminar. Keine Vorkasse. |
| Stornierung |
Kostenfrei bis zum Vortag des Seminars |
| Vormerken statt buchen |
Sichern Sie sich unverbindlich Ihren Seminarplatz schon vor der Buchung - auch wenn Sie selbst nicht berechtigt sind zu buchen |
Kostenfreie Services
In Präsenz | Online |
|---|---|
|
|
Buchungsmöglichkeiten
Online oder in Präsenz teilnehmen
Sie können sowohl Online als auch in Präsenz am Seminar teilnehmen. Klicken Sie bei Ihrer Buchung oder Anfrage einfach die entsprechende Option an.
Gesicherte offene Termine
| Termin | Ort | Preis | ||
|---|---|---|---|---|
| 03.08.-05.08.2026 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
| 12.10.-14.10.2026 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
| 14.12.-16.12.2026 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
| 2027 | ||||
| 19.04.-21.04.2027 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
| 21.06.-23.06.2027 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Unterstützung nach der Schulung durch
individuelle Nachbetreuung
- Alle folgenden Schulungsformen können auch Online als Virtual Classroom durchgeführt werden.
- Eine Offene Schulung findet zu einem festgelegten Zeitpunkt im voll ausgestatteten Schulungszentrum oder Online/Remote statt. Sie treffen auf Teilnehmende anderer Unternehmen und profitieren vom direkten Wissensaustausch.
- Eine Inhouse-/Firmen-Schulung geht auf die individuellen Bedürfnisse Ihres Unternehmens ein. Sie erhalten eine kostenfreie Beratung von Ihrem Seminarleiter und können Inhalte und Dauer auf Ihren Schulungsbedarf anpassen. Inhouse-Schulungen können Europaweit durchgeführt werden.
- Bei einer Individual-Schulung erhalten Sie eine 1-zu-1 Betreuung und bestimmen Inhalt, Zeit und Lerntempo. Der Dozent passt sich Ihren Wünschen und Bedürfnissen an.
Sie können unsere Schulungen auch als Remote Schulung im Virtual Classroom anfragen.
In drei Schritten zum Online Seminar im Virtual Classroom:
- Seminar auswählen und auf "Buchen" klicken
- Wählen Sie bei "Wie möchten Sie teilnehmen?" einfach "Online" aus.
- Formular ausfüllen und über den Button "Jetzt buchen" absenden.
Unser Kundenservice meldet sich bei Ihnen mit der Buchungsbestätigung.
Unsere Online Schulungen finden im Virtual Classroom statt. Ein Virtual Classroom bündelt mehrere Werkzeuge, wie Audio-Konferenz, Text-Chat, Interaktives Whiteboard, oder Application Sharing.
Vorteile von Virtual Classroom:
- Sie erhalten 1 zu 1 die gleiche Lernumgebung, die Sie auch vor Ort bei uns vorfinden
- Die technische Vorbereitung wird von den GFU-Technikern vorgenommen
- Sie erhalten remote Zugriff auf Ihren persönlichen Schulungs-PC im GFU-Seminarraum
- Die Virtual Classroom Lösung lässt sich auch im Browser betreiben
- Die GFU-Technik leistet wie gewohnt Soforthilfe bei Problemen
- Die Schulungsunterlagen bekommen Sie via DHL zugeschickt
- Sie sparen Reisekosten und Zeit
- 03. Aug. - 05. Aug. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 12. Okt. - 14. Okt. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 14. Dez. - 16. Dez. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 19. Apr. - 21. Apr. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 21. Jun. - 23. Jun. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- Auch als Inhouse-Schulung, bundesweit mit Termin nach Wunsch und individuellen Inhalten
- Buchen ohne Risiko! Kostenfreie Stornierung bis zum Vortag des Seminars
Die Seminare der GFU finden in angenehmer Atmosphäre statt und sind perfekt organisiert. Profitieren Sie von dem Rundum-Service der GFU!
Machen Sie sich keinen Kopf um die Anreise! Unser Shuttle fährt Sie. Oder Sie parken einfach auf einem extra für Sie reservierten Parkplatz.
Hotelzimmer gesucht? Wir organisieren Ihnen eins. Ihr Vorteil: Sie sparen Zeit und Geld!
Stornierung bei offenen Seminaren kostenfrei bis einen Tag vor Schulungsbeginn.
Unsere Techniker sind immer zur Stelle, egal ob online oder vor Ort.
GFU Schulungszentrum