A/D-Wandler ADAM 6017 und Anbindung an IP-Symcon

vorab: wen die Story nicht interessiert und gleich ans Eingemachte will sollte gleich zum Nachspiel übergehen

Das Vorspiel

zunächst hatte ich geplant, alle Sensoren mit analoger Schnittstelle (Thies UVB Silicium Sensor, Thies Niederschlagdetektor, Optris-IR Thermometer) via 1-Wire A/D-Wandler auf Basis des DS2450 an IP-Symcon zu koppeln. Da die Aufzeichnung und Auswertung der Daten 7*24h ununterbrochen laufen soll, war Stabilität ein wesentliches Kriterium. Netterweise hatte mir Helmut (aus dem IPS-Forum) sehr schnell eine sehr schlanke Lösung des A/D-Wandlers vorgeschlagen und auch gebaut. Nach 2 Wochen hatte ich die kleinen Kerlchen (ca 3x7cm große Platine) zu Hause in der Post, ein 1Wire USB-Adapter war auch rechtzeitig geordert. Die Verbindung zum Server wurde temporär über eine freifliegende Verkabelung mittels aktivem USB-Kabel realisiert (Kabel-Gesamtlänge 15m!). Das Ganze war natürlich ein Provisorium, am Ende sollte die Kommunikation 1Wire-Wandler Server via LAN erfolgen. Aber das hatte noch Zeit, erstmal die Sensoren an IPS anbinden und in Betrieb nehmen!

Die Anbindung des 1Wire USB-Wandlers gestaltete sich schon zickig, ich weis bis heute nicht so genau wie und warum ich das Teil ins Betriebssystem (Server 2008R2) bekommen habe. Nicht schön. Weiter im Text: Anbindung des DS2450 ans IP-Symcon. Hatte hier zunächst reichlich CRC-Fehler (liest man aktuell auch häufig im IPS-Forum), aber hier hatte ich noch den USB-Wandler über einen SILEX SX 3000GB an den Server gebracht. Scheinbar hat 1Wire damit ein echtes Problem (mit dem SILEX hatte ich bisher nie Probleme). Also die freifliegende, aktive 15m USB-Verkabelung. Nun gings auch ohne CRC-Fehler. Ab und zu war der DS2450 aus dem IPS-Modul nicht ansprechbar (weis nicht warum), irgendwann lief es dann. Abfragen im 3-Sekundentakt waren kein Problem. Spannende Technik, dieses 1Wire-Zeugs!

Was dann aber weniger schön war (zu dem Zeitpunkt dachte ich, es wäre systembedingt), war das nicht unerhebliche Rauschen auf dem analogen Signal. gerade beim Niederschlagdeketor war das eine unschöne Sache, der ich softwareseitig durch Tricksereien und dem Tiefpassfilter von Schablone (natürlich wieder aus dem IPS-Forum) zu Leibe gerückt bin. Der Filter hat einen wirklich guten Job gemacht, der Scaler von Schablone auch. Allerdings hat mich dieses Signalrauschen schon etwas genervt.

Der Streß ging los, als ich den 3. A/D-.Wandler an den 1Wire/USB-Wandler anklemmen wollte: mal war der eine A/D-Wandler nicht erreichbar, mal der andere. Dann traf auch ein 1Wire-LAN-Adapter ein, ich dachte mir: sch*** auf dem USB-Adapter, nimmste halt den LAN-Adapter. Allerdings hab ich zwar den LAN-Adapter ins netz bekommen, aber alles was dahinter lag (also die 3 1Wire-A/D-Wandler): nix. Support von qualifizierten 1Wire-Usern aus dem Forum geholt: nix zu machen.

Langsam nervte es, alternativ habe ich deshalb nach einer anderen A/D-Wandler-Lösung gesucht. Möglichst eine mit mehreren analogen Eingängen und via LAN anbindbar.  Ich hab wirklich lange gesucht, aber das einzig brauchbare (was zudem noch deutlich über meiner Schmerzgrenze bezgl,. des Preises lag) war ein Advantech ADAM 6017. 8 Analog-Ports, wahlweise als konfigurierbarer Spannungs- oder Stromeingang, 1 LAN-Port, 2 Digital-Ausgänge machten mir das Ding schmackhaft. Der (scheinbar) hohe Preis des anderen Kandidaten für diesen Job (ADAM 6017) begann, sich (auf Grund der o.g. Probleme) zu relativieren. Also bestellt (zurückschicken kann man es ja immer noch).

Der Haupt-Akt

Nach 1-2 Tagen hatte ich das Kerlchen ausgepackt (nein, nicht das Auspacken dauerte 1-.2 Tage, die Lieferung!), Strom und LAN angeschlossen, Laptop aufgeklappt, Management-Software installiert – und mal sehen was geht. Zunächst IP-Adresse neu konfiguriert (ist fest auf 10er Netz konfiguriert, kein DHCP) – Konfiguration ist etwas umständlich wegen fehlendem DHCP – geht aber.

Hallo Houston – was geht? das Ding war sofort und problemlos erreichbar, hab alle Analogeingänge via Konfig-Tool (Adam.NET Utility) auf 4-20mA-Eingang konfiguriert (Vorsicht: zunächst muss das Gerät aufgeschraubt werden und jeder Port per Jumper auf Stromeingang umgestellt werden! Das ist etwas frickelig und man sollte hinterher genau checken, ob die Jumper richtig gesteckt sind!). Vorsichtig mal einen der Sensoren angeschlossen und geschaut, ob und was im Management-Tool zu sehen ist: es war was zu sehen, und wie! Ich hatte den Niederschlagsensor angeschlossen, es regnete gerade nicht, der Graph des entsprechenden Analog-Eingangs war präzise auf der 4ma-Linie, nicht ein Ausreißer. Um sicher zu gehen, das auch wirklich ein Signal anliegt, hatte ich kurz für Regen gesorgt: siehe da, eine saubere Meßkurve. Funktionierte perfekt, kein Rauschen, NULL! Wow, ich war begeistern.

Nun der nächste Schritt: Den ADAM 6017 dazu bringen, mit IP-Symcon zu reden. In der Doku stand was von Mod-Bus. Ein bischen im Forum rumgefragt: ja, ModBus funktioniert so und so, isnatlliert man so….. Gut, ich habs versucht, im Forum recherchiert, mir dann direkten Support vom IP-Symcon-Hersteller geholt (dafür nochmals herzlich DANKE!), nach 2-3 Stunden Kundenbetreuung via Skype war klar: via ModBus redet das Kerlchen nicht mit IP-Symcon. Zwar kommen sid Daten in IPS exakt genau so an, wie in der Doku des ADAM 6017 beschrieben (bis auf die eigentlichen Meßdaten), auch IPS schickt die Datentelegramme exakt gemäß Doku raus, es kommen aber keine Meßdaten rüber! Mist.

Also weiter recherchiert: plötzlich sah ich den Begriffe „UDP“ und „ASCII-Commands“ in der Doku, nochmal RWN (aus dem IPS-Forum, der weis einfach alles!) gefragt. Inzwischen hatte ich mich fast selbst an die Lösung rangerobbt, die sah dann so aus:

• UDP-Socket in IP-Symcon angelegt und konfiguriert (hierüber sendet IPS die Abfrage-Kommandos an den ADAM 6017), Sendescript mit zyklischem Auslöser darunter
• Cutter  in  IP-Symcon angelegt und konfiguriert, eine Register-Variable unten dran geklebt, darunter dann ein Auswerte-Script (welches die ankommenden Daten verarbeitet und in Ziel-Variablen schreibt).
  
  

  3.Zeile: Daten-Abfragebefehl, 4. Zeile: Meßdaten-Telegramm

• Test-Script angelegt, einen Sendebefehl gemäß ADAM 6017-Doku im Script zusammengeschraubt und Schuss!
• in den Debugging-Fenstern des UDP-Sockets sowie der RegisterVariable geschaut, was an Daten ausgetauscht wird: BINGO! es kamen genau die Datentelagramme (und diesmal mit Meßdaten) an, die ich brauchte. Jipppieee, endlich ne Lösung (die Kosten waren mir mittlerweile sch***egal)

Das Nachspiel

wie sieht nun eine funktionierende IPS-Anbindung aus?

In Stichpunkten:

• Nun, zunächst wird der UDP-Socket installiert und konfiguriert („Host-IP“ ist die des ADAM 6017, Port 1025, „Adresse“ ist die des IPS-Servers, Port irgendwas über 1025, ich hab 1026 genommen) .
• Script mit den Abfragebefehlen darunter kleben („$return = USCK_SendText(20394, ‚#01‘.chr(13));“)
• unter dem Script ein zyklisches Ereignis (bei mir werden die Daten alle 3 Sekunden abgeholt -> also wird das Ereignis auf täglich, 3 sec eingestellt) anlegen 

• Cutter anlegen, Konfiguration des Cutters leer lassen
• Unterhalb des Cutters eine Register-Variable anlegen, übergeordnetes Objekt auf den Cutter einstellen
• Unterhalb der Register-Variable ein Daten-Auswertescript anlegen (Scriptinhalt siehe unten “ Datenverarbeitungsscript“)
• in der Register-Variable als „Auslösescript“ das  Datenverarbeitungsscript einstellen
• die Variablen im Objektbaum anlegen, in die die Messdaten geschrieben werden sollen
• im  Datenverarbeitungsscript die Variablen-ID’s entsprechend anpassen

Danksagung

• Helmut für seine schnellen,unkomplizierten und ingenieurstechnisch hochwertigen Lösungsvorschläge und deren Umsetzung
• der Geschäftsführung von IP-Symcon für den ad-hoc-Support via Skype (ich glaube sogar mich zu erinnern, dass es am Sonntag war, paresy?)