Beiträge anzeigen

Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.


Nachrichten - stm

Seiten: [1] 2
1
BECKHOFF / Re: String via UDP-Message senden
« am: 03. Februar 2021, 14:08:14 »
hallo zusammen,

ich hätte Interesse an dem von Peewit im Thread erwähnten Beispiel zum Senden eines Strings.

... also das [gelöscht durch Administrator]

Bitte um Bereitstellung - Danke

2
ja im TWINCAT 3.0 ist es zu haben.

Da ist es wohl über ein separetes Programm auf dem Controller gelöst, das über ADS kommuniziert.

Leider soll es das für TWINCAT 2 wohl nicht geben (und von dem komme ich wg. meiner BUILDING Automation Lösung nicht weg)
never touch a running system without need...

3
Es war nicht der Zeilentrenner, Routine funktioniert auch mit $N

sorry - Anfängerfehler:
Aus dem Demo einen Baustein gemacht, der laufend auswerten sollte....
kam allerdings nicht über die erste Zeile hinaus

ein While DONE drum und er tut was er soll...

4
inkompatibel mit den Ansatz der in OSCAT gewählt wurde oder inkompatibel, so dass es auf der Beckhoff TCP/IP Bibliothek nicht zum Laufen zu bekommen ist?

Wenn letzteres: gibt es irgendwo einen Vergleich der Routinen der TCPIP Bibliothek von Beckhoff und WAGO?
(mit Google nichts gefunden...)

5
Hallo,

ich wollte den INI_PARSER_BUFFER verwenden, um das Resultat einer HTTP Abfrage auszuwerten.

Wenn ich die Werte der Abfrage in eine Datei schreibe, und mit dem Demo Programm einlese, funktioniert das Erkennen und Zuordnen der Werte.
die Variable OFFSET hat nach Programmlauf den Wert entsprechend Pufferfänge.

Wenn ich jedoch die gleiche Routine auf über HTTP_GET eingelesene Werte loslasse, hat OFFSET auch den Wert entsprechend Pufferlänge.
Erkennen von Werten (result=2) findet jedoch nicht statt.

Wenn ich mir die Puffer ansehe, habe ich im Falle des DEMO Programmes Zeilentrenner $R$N,
im Falle der über HTTP_GET als Zeilentrenner $N.

Kann es sein, dass dies die Ursache ist?
Wenn ja, wie kann ich im INI_PARSER_BUFFER den Zeilentrenner ändern ?

Schöne Grüße

6
Modulentwicklung / HTTP_PUT - Neuigkeiten?
« am: 05. Januar 2017, 16:57:57 »
Hallo,

vor einiger Zeit hatte ein Nutzer eine Frage nach HTTP_PUT, dies wohl selber gelöst und dann allerdings die Lösung nicht geteilt...

... weiß inzwischen irgend jemand im Forum mehr oder hat evtl eine Implementierung parat?

schönen Dank!

7
Hallo,

ich suche eine Baustein um Daten von der Beckhoff Steuerung auszusenden (und evtl auf empfangen Events zu reagieren)

Dazu gibt es in der IoT (Internet of Things) Welt das MQTT Protokoll.
https://de.wikipedia.org/wiki/MQTT

Ich möchte es verwenden, um verschiedene Geräte in Heimautomatisierung zu verbinden (da gibts vieles hin bis zu Sonos...)

Für das neue Twincat 3 scheint es eine Bibliothek von Beckhoff zu geben, leider nicht für Twincat 2.

Einen freien Baustein für Codesys habe ich gefunden, der ist allerdings für Wago.
https://github.com/FieldFox/Codesys-Mqtt-lib
(Als Zip Datei angehängt)

Ein MQTT-Client Baustein wäre sicher eine Bereicherung für die OSCAT, ich weiss allerdings nicht, ob die GNU Lizenz des obigen Bausteines eine Anpassung und Aufnahme in OSCAT erlaubt.

Daher erst mal die Frage, wer mit bitte mit einem Hinweis helfen kann, was ich an dem Baustein für Twincat 2 anpassen muss.

Schönen Dank.


[gelöscht durch Administrator]

8
Modulentwicklung / Re: Philips Hue
« am: 11. Juni 2016, 18:32:52 »
Hallo,

ich habe das Thema seinerzeit nicht weiter verfolgen können, kann evtl. noch von damals beitragen:

Die Hue Steuerung funktioniert über HTTP Kommandos an die Bridge:

HTTP_GET  für Stati
HTTP_PUT für Aktionen

und für Nebenfunktionen (Konfigurationsänderungen und andere "Nebenfunktionen" HTTP_POST, HTTP_DELETE).

Die Messages von und zu Bridge sind JSON Format.

Für Ein/Aus, Heller/Dunkler, und Szenenaufrufe sollten es HTTP_GET und HTTP_PUT tun.

Die Bridge hat ein Web-Interface mittels dem die Kommandos getestet werden können.

Von OSCAT Seite hatte mir seinerzeit ein HTTP_PUT Baustein gefehlt .....



9
Modulentwicklung / Philips Hue
« am: 26. Juli 2015, 18:07:34 »
Hallo,

kürzlich hab ich mir Philips Hue LED-Leuchten zugelegt.

Die Steuerbarkeit über App ist ganz nett - nun würde ich gern die Teile über die SPS ansteuern können - Das API ist Dokumentiert http://www.developers.meethue.com/documentation/getting-started

So wie ich das lese geht der Zugriff über HTTP Aufrufe, die Vorgaben und Antworten sind XML formatiert.

Jetzt hab ich versucht, die notwendigen Bausteine zusammenzuklauben, scheitere allerdings bereits daran, dass ich in der OSCAT nur ein HTTP_GET finde, nicht allerdings das notwendige HTTP_PUT (und das wohl weniger notwendige HTTP_POST und HTTP_DELETE)

Jetzt frage ich, ob es hier im Forum jemanden gibt, der die Hues an der SPS am Laufen hat.

Mit meinen Kenntnissen ist der Weg zu weit - wenn ich nichts finde , muss ich an einem Plan B tüfteln - irgendwas das auf eine der auf der Hue Developer Seite als Library angegebenen Libraries aufbaut und als unabhängiges EXE mit den Hues "redet" und der SPS über einen TCP Port oder ADS zur Verfügung steht....

Bin gespannt .....

Danke einstweilen!

10
So jetzt verwende ich den Mode 3.

Habe aber wohl noch ein größeres Problem: Ich möchte einen Baustein bauen, der mit Flankenwechsel aufgerufen wird. Und dann eine einzige Abfrage durchführt.

Wahrscheinlich habe ich noch nicht verstanden, wie das HTTP_GET funktioniert, da sich mein Code nicht verhält wie geplant.

Frisch geladen und gestartet:
Erster Durchlauf:
      Wireshark sieht den Paketverkehr wie oben angehängt
      HTTP_GET Aufruf, bringt OK 200, Body ist leer

Zweiter Durchlauf:
      Wireshark sieht keinen Paketverkehr
      HTTP_GET Aufruf, bringt OK 200, Body enthält
            $R$N1$R$N<$R$N25$R$N?xml version="1.0" encoding="UTF-8"?>$R$N1$R$N$N$R$Ne$R$N<e2powerstate>$R$N1$R$N$N
      jedenfalls bringt das ein BUFFER_TO_STRING()- allerdings sollten da 181 Zeichen drin sein (body_end - body_end)


Irgendwas habe ich da wohl ziemlich vermurkst....



[gelöscht durch Administrator]

11
Vorhin war ein Filter zuviel drin - jetzt nur die Adresse

und die Dumps von Mode=0 Mode=2 und Mode=3

Sorry, jetzt fange ich langsam an Aufwand zu machen: Wollte ich nicht, für mich reicht die Funktion so, dachte nur, die Lib wird durch meinen Input besser/fehlerfreier.

[gelöscht durch Administrator]

12
Jetzt habe ich den Wireshark-Trace hinbekommen:
- Erste Anfrage vom Browser, zweite vom PLC Programm.

[gelöscht durch Administrator]

13
Da die Adresse bei mir im Netz ist musste ich mit Wireshark ran. (Angehängt Trace des HTTP Aufrufes im Firefox)
Eigenartigerweise "sieht" der Wireshark die Kommunikation des Beckhoff TCP-Servers nicht - bekomme keine Aufzeichnung :-(

Also sehe ich nur was HTTP_GET liefert:
Im HTTP_GET kommt zwischen Start und Ende Body nur
                  $R$N<?xml version="1.0" encoding="UTF-8"?>$N<e2powerstate>$N$T<e2instandby>false$N$T</e
an.

Wo kann ich weitersuchen?

[gelöscht durch Administrator]

14
Danke für Deine schnelle Antwort! Das hilft mir weiter !

... wenn ich mir dann noch vorstelle, was in und hinter den Routinen steckt ...

Bin beeindruckt!

Doch noch zum Verständnis eine Frage: Das IP_CONTROL muss ich einmal im ganzen Programm an einer Stelle zyklisch aufrufen, oder einmal pro Funktionsblock?

Was anderes ist mir noch aufgefallen ist: Ich bekomme in den Empfanspuffer nicht die gesamte Antwort des Webservers.

Hintergrund: Ich will über HTTP einen Satellitenreceiver abschalten und per HTTP kann ich sowohl den Betriebszustand bekommen, als auch schalten. Wenn ich den Betriebszustand abfrage, kommt eine XML Struktur - im Browser komplett, beim HTTP_GET in der letzten der Zeilen abgeschnitten. (Kein Unterschied, welchen MODE Parameter ich gewählt habe.)

PS: Ich plane kommenden Di einen Besuch auf der SPS in Nürnberg, bist Du auch dort ? (Habe sowas dunkel in Erinnerung - würde mich freuen dem Genius mal die Hand zu schütteln...)


15
Hallo,

ich habe ein Gerät, das ich per HTTP Kommando steuern kann. (URL mit Aufrufparametern steuert aktiviert Gerätefunktion)
Dieses soll in meine Steuerung eingebunden werden.

Am HTTP_GET Bespiel bin ich dran, und versuche abzustrippen (feste IP Adresse, einmaliger aufruf, evtl ein zweites mal abhängig Rückgabeparameter.

Meine Fragen:
1) Muss ich IP_Control aufrufen? (wenn ja, wie oft? In jedem Funktionsblock, in dem ich eine Netwerkfunktion wie HTTP_GET habe ß Einmal pro Steuerung? Jedes mal, bevor ich eine andere IP Adressse verwende?)

2) Ich möchte testen, ob das Gerät aktiv ist, also suche ich einen FB, der dem PING Kommando entspricht

3) Wo gebe ich Timeouts für den HTTP_GET an?

4) Was bedeutet die Eingangsvariable UNLOCK_BUF ? reicht es nicht aus, den Vorgang über GET zu starten? Dem Beispiel nach wird UNLOCK_BUF gesetz, damit DONE zurück gesetzt, was wiederum über die DNS Abfrage einen neuen HTTP_GET erzeugt ...

Gibts dzu evtl ein Timing Diagramm?

Viele Fragen...

Lieben Dank

Seiten: [1] 2