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 - Tom

Seiten: [1] 2 3
1
BECKHOFF / Re: Push-Nachrichten an Android-Geräte
« am: 25. Dezember 2014, 19:15:22 »
Hallo Vicky,

das ist ja ein gaaanz alter Thread.  :o

Ich fang mal von vorn an: Auf dem CX muss der TCPIP-Server (kostenpflichtig) installiert sein. Im TwinCAT müssen die TCPIP-Lib von Beckhoff (gibts zum Server dazu, wenn ich nicht irre) und die OSCAT Network-Lib eingebunden sein. Auf dem Android-Gerät brauchst du Tasker (kostet was) und das Autoremote-Plugin dazu. Mit Installation des Plugins bekommst du eine URL zugewiesen. Wenn du die URL im Browser deines PC's aufrufst, kommst du auf eine Webseite, von der aus du Nachrichten auf dein Android-Gerät schicken kannst (man kann mit Tasker/Autoremote auch Nachrichten zw. Android-Geräten automatisiert austauschen). Damit erst mal rumspielen und die Doku dazu lesen. Die Eingabefelder sind mit Kommentaren versehen. Zudem sind die Parameter in den Bausteinen kommentiert, wobei ich meist den Text von der Webseite übernommen habe.

Wenn du weißt, was passiert, ist die Parametrierung der Bausteine kein großes Problem mehr, da ich lediglich die Funktion der Seite nachgebaut habe. Die Namen der Eingabefelder und der der Bausteinparameter sind größtenteils identisch. Im Prinzip wird nichts anderes gemacht, als die Parameter an die URL anzuhängen und an den Dienst zu schicken, der sie dann an das Android-Gerät weiterleitet. Du kannst also die Funktion mit der Seite bequem testen und die Parameter dann an dem Baustein übernehmen.

Du wirst auch oben auf der Seite 2 Buttons sehen: "Send Message" und "Send Notification" entsprechend habe ich 2 Bausteintypen gebastelt: FB_AutoRemoteMessage/FB_AutoRemoteMessageM und FB_AutoRemoteNotification/FB_AutoRemoteNotificationM. Die Versionen mit dem "M" hintendran können Nachrichten an mehrere Geräte schicken, die normalen nur an eins. Dafür ist die Paramtrierung etwas einfacher.

Als Nächstes musst du in der  SPS die Kommunikation einrichten. Dazu den IP-Control aus der Network-Lib einbinden und parametrieren. Ich habe für solche Bausteine einen eigenen Task mit 4 ms laufen, das normale Programm läuft mit 25 ms. Anschließend die Bausteine für das Senden von Nachrichten aufrufen und parametrieren und fertig. Die Bausteine mit dem "M" hintendran erwarten ein Array mit Namen/URL's, wobei nur die URL wichtig ist, der Name dient nur der leichteren Zuordung.

Ein Problem ist noch die Menge an Parametern, die man mit einem Baustein senden will. Irgendwo war eine Grenze und die URL wird einfach abgeschnitten. Was mir auch aufgefallen ist, ist die unterschiedliche Zeit, in der Benachrichtigungen ausgeliefert werden. Während auf meinem Handy die Nachrichten innerhalb weniger Sekunden ankommen, dauerts auf meinem Tablet manchmal bis zu 2 Minuten. Warum, konnte mir kein Entwickler sagen.



[gelöscht durch Administrator]

2
BECKHOFF / Push-Nachrichten an Android-Geräte
« am: 30. April 2013, 20:41:06 »
Hallo,
 
bin nicht sicher, ob das Thema hierhin gehört. Ich hab auf Basis der Network-Lib 1.21 ein paar Bausteine gebastelt, mit denen man Nachrichten an Android-Geräte schicken kann. Voraussetzung ist die Installation von Tasker sowie des Autoremote-Plugin's. Auf den Geräten lassen sich dann verschiedene Aktionen starten (Sprachausgabe, Popups etc.).

https://play.google.com/store/apps/details?id=net.dinglisch.android.taskerm
https://play.google.com/store/apps/details?id=com.joaomgcd.autoremote



[gelöscht durch Administrator]

3
Codesys 2 / Re: Kein Zugriff mit HTTP_GET
« am: 26. Februar 2013, 17:20:55 »
Ich würde mal sagen, du schmeißt die Protokolle durcheinander. Da willst mit einem HTTP-Get eine FTP-URL aufrufen. Anderes Protokoll, anderer Port. Ich würde es mal mit der FTP-Demo versuchen.

4
oscat.lib fuer TwinCAT/CoDeSys / Re: DIMM_1 SET RST
« am: 30. Oktober 2011, 23:01:12 »
So und was passiert wenn der VAL=0 ist und ich SET setze.

Dann ist OUT=0 und Q=1.

Sicher,  aber warum sollte jemand das tun? Laut Doku ist der SET-Eingang dazu gedacht, die Lampe auf einen Maximalwert zu setzen. 

Hier sollte doch auch MIN0/MAX255 abgefangen werden wie es bei IN=1 der Fall ist, oder?
Da man hier eher einen Festwert ansetzt, ist die Frage akademischer Natur. Außerdem ist man so flexibler, da man z.B. auch einen Maximalwert für Notfälle ansetzen kann, den man im normalen Dimmbetrieb nicht anfahren möchte.

5
Ich hatte auch das Problem und hab bei mir die maximale Bausteinanzahl auf 4096 erhöht.

Im Ordner "\TwinCat\PLC" in der Datei "TwinCAT PLC Control.ini" den Eintrag MaxNumOfPOUs suchen und anpassen.





6
oscat.lib fuer CoDeSys 3 / Re:Entwicklungsumgebung unter Linux
« am: 11. April 2011, 09:36:32 »
Ich hab Mint auf meinem Schleppi und nutze TwinCat auf XP mit Virtual Box. Hat auch den Vorteil, dass man die komplette Umgebung sichern und schnell mal auf einen anderen Rechner umziehen kann. Frisst aber sicher mehr Leistung als Wine. Werde mal testen, ob TwinCat auch mit Wine läuft.

7
SPS-Hardware / Re:Beckhoff KL2722
« am: 12. Februar 2011, 07:18:37 »
@Wu Fu: Hattest du bei der KL2722 eine Umschaltpause programmiert? Die muss nämlich unbedingt rein, damit die Kondensatoren im Antrieb vorm Umschalten entladen können. Reine Verriegelung reicht nicht. Bei meinen Antrieben waren 500ms vorgegeben, ich hab vorsichtshalber 1s eingestellt.

8
ich habe aber inzwischen schon eine oscat_network.lib für beckhoff fertig
diese wird mit der nächsten oscat_base.lib release mit dabei sein

Das klingt ja super! Kanns kaum erwarten.  :) 8)

9
Bei einer Anwendung in der Automobilherstellung würde er dann den Roboterarm einfach in die frischlackierte Haube der S-Klasse brettern!
So ähnlich kommt das schon mal vor.  ;D

Ich glaube, meine gute alte S5 hätte das noch anders abgehandelt.
Naja, ich hab noch täglich damit zu tun und die hat auch ihre Macken, erst recht, wenn die Baugruppen ins Alter kommen. Da kommen lustige Fehlerbilder zum Vorschein.

10
Da bis jetzt alles funktioniert hat und das Verhalten recht kurios ist, würde ich von einem Hardware-Problem ausgehen. Kannst du die BX mal gegeneinander tauschen?

11
Bestehende Module / Existing Modules / Re:Fehler im TIMER_P4
« am: 08. Dezember 2010, 07:37:53 »
Ich hab grad noch mal in den Baustein reingeschaut. Da dort mit TOD gearbeitet wird, sind tagesübergreifende Zeiten ein Problem. Z.B. 23:00 + 8 h ergibt TOD#31:00. Klingt komisch, ist aber so. Damit kann das nicht funktionieren. Ab 00:00 wird der Ausgang false, da 00:00 nicht zwischen 23:00 und 31:00 liegt. Das Problem hatte ich bei meiner Schaltuhr auch und hab die interne Berechnung auf DT umgstellt.

Das kommt zu dem Problem bei mehreren Ereignissen pro Kanal hinzu.

12
Bestehende Module / Existing Modules / Fehler im TIMER_P4
« am: 07. Dezember 2010, 12:51:06 »
Hallo,

ich hatte letztens in einem anderen Thread gepostet http://www.oscat.de/community/index.php/topic,1030.15.html und bin nicht sicher, ob das Problem untergegangen ist. Der TIMER_P4 scheint nicht richtig zu funktionieren, wenn mehrere Ereignisse pro Kanal definiert sind. Kann das jemand bestätigen?

13
SPS-Programmierung / Re:Objektorientiert Programmieren
« am: 30. November 2010, 15:09:44 »
Ich weiß nicht, ob's dir hilft, aber ich habe hier ein paar interessante Beiträge gefunden:

http://de.wordpress.com/tag/codesys-v3/

14
Ich glaube, du hast da was falsch verstanden. Der Timer_P4 ist fehlerhaft, der Code ist ein Teil vom TIMER_P4 intern und für die Leute von OSCAT gedacht.

15
Ich hab mal dein Programm mit dem Timer_P4 auf TwinCat umgerubelt und es scheint tatsächlich ein Problem mit dem TIMER_P4 zu geben. Wenn man mehrere Ereignisse pro Kanal definiert, ist nur das letzte relevant. Wenn ich mir die Programmierung des Bausteins anschaue, ist das auch logisch, da beim Durchlauf des Arrays der jeweilige Kanal immer wieder überschrieben wird. Für den jeweiligen Kanal müsste eine ODER-Verknüpfung mit sich selbst programmiert werden, um den vorherigen Zustand zu berücksichtigen.

Lösung wäre z.B. vor der Schleife alle Ausgänge rücksetzen

ELSIF dtime <> last_execute THEN
(* prepare the logical input mask to be used later *)
qn[0] := FALSE;
qn[1] := FALSE;
qn[2] := FALSE;
qn[3] := FALSE;
mask := 255;
mask.0 := L0;
mask.1 := L1;
mask.2 := L2;

und dann

43: (* event on workdays Mo-FR and no holiday *)
qn[channel] := qn[channel] OR (DT_TO_TOD(dtime) >= event.START) AND (DT_TO_TOD(dtime) < event.START + event.DURATION) AND (NOT Holy) AND (DAY_OF_WEEK(DT_TO_DATE(dtime)) < 6);
prog[pos].LAST := current_day;

Muss natürlich für jeden Event-Typ gemacht werden.


Seiten: [1] 2 3