Nachrichten

46

Modulentwicklung / Re: OSCAT und SQL

« am: 04. August 2009, 08:31:22 »

Alles klar..

Das war die Frage.

Ist wohl so etwas angedacht, mal SQL-bezogene Funktionenn in die OSCAT.lib zu implementieren?



Gruss

McNugget

47

Modulentwicklung / Re: OSCAT und SQL

« am: 03. August 2009, 08:47:54 »

Danke peewit.

Interessant.
Nun kommt die nächste Frage, gibt es das auch offen, so dass man es Herstellerunabhängig einsetzen kann?

Gruss

McNugget

48

Modulentwicklung / OSCAT und SQL

« am: 29. Juli 2009, 14:36:12 »

Hallo allerseits.

Ich hätte grosses Interesse an Bausteinen, die SQL-Befehle und Funktionen integrieren würden.

Auf diese Weise könnte man zum Beispiel Daten aus Steuerungen per Ethernet in (MS- / Sybase- /My-)SQL-Datenbanken schreiben, bzw. auch lesend aus den Steuerungen auf Datenbanken (Rezepturen etc.) zugreifen.

Ich bin der Meinung das wäre nützlich.

Ist das für noch mehr Personen interessant?

Gibt es so was schon offen/proprietär?

Wo??

Gruss

McNugget

49

Bestehende Module / Existing Modules / Re: Widerstandsmessung Wago

« am: 22. April 2009, 16:45:17 »

Hallo.

So ähnlich mache ich es. Ich setze in meine PT100 Fühler Temperaturtransmitter ein die mir des Widerstandswert vor Ort in 4-20mA konvertieren.

Hat den Riesenvorteil, dass ich 4-fach 4-20mA Eingangsklemmen von Wago verwenden kann und so auf einer Einheit 4 Kanäle betrachten kann.

Ausserdem ist m. E. eine Stromschleife mit das Störunanfälligste und man kann damit probremlos mittlere bis weite Leitungsstrecken überbrücken.

Bei PT100 habe ich immer die Bauchschmerzen, dass JEDE Klemme, jeder Draht stören kann und mir den Messwert verfälscht.

Stromschleife läuft oder nicht.

Gruß

McNugget

50

Modulentwicklung / Module Development / Re: Einzeltaster Rolladensteuerung

« am: 04. März 2009, 08:39:32 »

Hallo.

Das gleiche Problem habe ich auch.

Ich springe mal auf den Zug auf.

Der Elektriker hat seinerzeit ein 5-adriges-NYM-Kabel von der Verteilung zu jedem Rolladenschalter vor Ort gezogen. Ab da geht der Rolladenanschluss an den jeweiligen Motor.

Nun habe ich, wenn ich aus der Verteilung heraus auf und ab steuern will, nur noch einen Ader frei. Laut VDE Vorschriften darf ich im selben Mantel nur die selbe Spannung (230V) verwenden.

Nun gibt es diverse Fragen:

1. Wenn ich die Drehschalter vor Ort auf Taster umrüste, wie lässt sich dann die intelligenteste Steuerung realisieren?

2. Gibt es irgendeine Möglichkeit über den einen freien Draht 2 Signal (auf UND ab) zu übertragen/codieren und diese dann in der Verteilung zu verarbteiten? Zum Beispiel, indem ich gegen Null schalte, und diesen elektrischen Durchgang dann in dem Controler auswerte?

3. Wie macht man es, dass der Drehschalter vor Ort keinen Kurzschluss auslöst, wenn der Bediener beim Automatiklauf der Rolläden manuell in die Gegenrichtung steuert?



Erschwerend kommt hinzu, dass alles unter Putz mit flachen Abzweigdosen ist.

Hat da jemand eine gute Idee?

Hatte schon überlegt, LCN-Module zu verteilen und um eine niedrige Einbautiefe zu erreichen, Mikroschalter zu verwenden.


Gruss

McNugget

51

Anwendungsbeispiele / Application Examples / Re: Gemittelte Aussentemperatur der letzten 24 Std.

« am: 29. Oktober 2008, 13:16:28 »

Grundsätzlich wirst Du dir hierfür die OSCAT.Lib direkt öffnen und etwas verändern müssen.
Die Begrenzung von FT_AVG auf 32 hat seinen Ursprung im Baustein Delay, der intern aufgerufen wird.

So wie ich es sehe, könnte das Array im Innern von Delay (da es ja ein INT Wert ist) auf einen höheren Wert umstellen.
Zu beachten wäre dabei, dass dann auch die Werte-Kontrollen im Innern von FT_AVG angepasst werden müssen.

Ich hoffe, das war so richtig... Hugo?? Habe ich es verstanden??

Gruss

McNugget

52

SPS-Programmierung / Re: Temperaturwerte und andere Sachen auf dem Controller Loggen

« am: 24. Oktober 2008, 09:16:04 »

Moin.

Mit der gleichen Problematik setze ich mich auch gerade auseinander.

Noch interessanter wäre es, einer CSV. Datei auf einem entfernten Rechner immer wieder eine Datenzeile anhängen zu können.

Der Link zum Thema bei Wago:
http://www.wago.com/wagoweb/documentation/app_note/a1141/a114100e_f.htm

Ich hoffe, das hat etwas geholfen.

Ich verstehe das Ganze noch nicht so (untalentierter Einsteiger).

Gruss

McNugget

53

Modulentwicklung / Module Development / Re: asynchroner Taktgeber

« am: 29. September 2008, 08:34:28 »

Super.
Vielen Dank.
Ich denke ein Asynchroner Taktgeber mit (mindestens 2) Zeitprofilen dürfe auch für viele andere User interessant sein und ist ja auch noch recht universell.

wenn ich das noch anregen darf: ich fände es klasse, wenn so ziemlich alle Bausteine, in denen Zeitfunktionenn ablaufen, einen Ausgang für die Elapsed Time hätten. Ob der dann in der Praxis verwendet wird, bleibt ja jedem selber überlassen.

So könnte man in der Online-Ansicht gerade bei längeren Zeiten sehen, was gerade im Controller abläuft.

Freue mich schon auf die 277er Version.

McNugget

54

Modulentwicklung / Module Development / Re: asynchroner Taktgeber

« am: 25. September 2008, 18:04:57 »

Hallo Hugo,

vielleicht hätte ich meine Anfrage besser im Bereich "bestehende Module" stellen sollen, als hier.

Ich brauche einen solchen Baustein, um einem Taktgeber mit zwei Zeitprofilen zu realisieren. Zum Beispiel bei einer Kühlung mit 1-Punkt-Regelung. In Profil 1 (normale Kühlanforderung) soll die Lüfter mit einem Verhältnis von 5 Minuten Ruhezeit und 20 Sekunden Einschaltzeit laufen.

Ist der Raum kühl, sollen die Lüfter nur umwälzen und zwar mit 90 Minuten Ruhezeit und 1 Minute Einschaltzeit.

Die Zeiten im einzelnen sind ja auch relativ egal.

Ich wollte das Ganze in einem Baustein realisieren, an dem ich auch anhand der jeweils ablaufenden Zeit direkt erkennen kann, welcher Eingang aktiviert ist.

Den Baustein gen_dc habe ich nicht gefunden, dafür aber GEN_PULSE. Der wäre klasse, müsste mit aber für High und Low die jeweiligen Elapsed Time Werte ausgeben.

Oder wie meintest Du das?

(Ich weiss, meine Fragen mögen echt doof klingen, sollen sie aber nicht. Ich bin leider auch nach langer Zeit noch blutiger Anfänger. Das stört mich aktuell mehr als es jeden von Euch hier nerven könnte..Ich bin aktuell ziemlich angefressen davon, dass ich solche Probleme habe, mir selber das umzusetzen, was ich mir vorstelle.)


McNugget

55

Modulentwicklung / Module Development / asynchroner Taktgeber

« am: 22. September 2008, 14:39:43 »

Hallo. Ich bin auf der Suche nach einem asynchronen Taktgeber.

Habe bereits den Baustein gen_pulse angeschaut, aber der macht nicht ganz das, was ich möchte.
Ich benötige zusätzlich zu den Funktionen auch jeweils für das High und den Low-Zeitraum eine Ausgabe elapsed Time.
Sonst ist es schwer zu sehen, was der Baustein tut (und ob er aktiv ist), wenn man zum Beispiel längere Zeiten als eine Stunde vorgibt.

Wie würde man eine ET-Anzeige im vorhandenen Quellcode zu gen_pulse integrieren?



Es ginge sogar noch weiter: ich will letztendlich einen Baustein haben in dem ich zwei asnychrone Tatgeber, über zwei digitale Eingänge (IN1 und IN2) selektieren kann, und so aus den vier Zeiten (High1, Low1, High2 und Low2), je nachdem ob IN1 oder IN2 angesteuert sind, das Ausgangssignal geschaltet wird.
Genau deswegen möchte ich auch immer sehen können, welche Zeit gerade abläuft.



Vielen Dank schon mal

McNugget2000

56

Bestehende Module / Existing Modules / Re: Ausgang ONTIME

« am: 03. März 2008, 10:57:39 »

OK.. Ich habe jetzt mal den Baustein in der 270er Lib verändert.

Nun haben die Augänge von Ontime keine "Retain Persistent" Funktionalität mehr.

es sind doch "nur" 18 (Instanzen) mal 2 (Aufrufe des Bausteins pro Instanz) mal 3 Ausgangswerte (des einzelnen Ontime-Bausteins).

Sind 90 Ausgangswerte "schon" zu viel?

Wie kann ich es denn lösen, wenn ich größere Datenhaltung erreichen möchte?

Sollte ich die Werte dann per Netzwerk auslagern, oder in eine Datei auf dem lokalen Sytsem des Controllers schreiben?
Laut PLC-Browser habe ich noch über 900 kB  im Filesystem frei.

Gruss

McNugget

57

Bestehende Module / Existing Modules / Ausgang ONTIME

« am: 29. Februar 2008, 09:56:27 »

Hallo allerseits.

Ich verwende einen WAgo 750-841.

In diesem rufe ich ein Programm in 18 Instanzen auf.

In jeder Instanz verwende ich zweimal den Baustein ONTIME auf.

An allen Bausteinen ONTIME habe ich hinter den Ausgang "ontime" ein "REAL_TO_TIME" gelegt.
nehme ich diese Konvertierung bei nur einem der beiden Ontime-Aufrufe weg, erhalte ich beim Übersetzen die Meldung:
Speicher für Retainvariable aufgebraucht.

Warum ist das so?




Gruss

McNugget

58

SPS-Programmierung / Re: maximale Anzahl von Bausteinen Ãœberschritten

« am: 28. Januar 2008, 14:35:45 »

Hallo Hugo,
nur zur Info habe ich mal zu obigem "Problem" den 3S-Support befragt.

Etwas gehetzt wirkend erreichte mich einige Zeit später eine Mail mit folgendem Inhalt:


Sehr geehrter Herr ...,

Das Projekt muss korrekt übersetzt sein. In diesem Fall können Sie mit diesem Button alle beim Letzten Übersetzungslauf nicht benötigten Bausteine auf Knopfdruck ausschließen.

Er ist gegrayt, wenn nicht korrekt (oder nicht) oder seit der letzten Änderung nicht wurde .

Mit freundlichen Grüßen


Nun wissen wir´s. ;-)

Mein Projekt war wohl wegen der OSCAT-Lib-Aktualisierung nicht mehr korrekt.

Mittlerweile klappt das auch.

Gruss

McNugget

59

oscat.lib fuer TwinCAT/CoDeSys / Re: Verbesserungsvorschläge für die Bechreibung

« am: 28. Januar 2008, 14:28:15 »

Hallo allerseits.

Ein winzig kleiner Bug in der Beschreibung ist mir aufgefallen.
Der Eingang  LAST_ON am Baustein ONTIME wird noch als vom Typ Time beschrieben.

Tatsächlich richtig ist aber auch hier der Typ REAL, wie ich in der Lib ersehen konnte.
Da es nur so ein kleiner Fehler ist, habe ich es mal an diesen Thread gehängt.
Hoffe, das ist OK so.


OSCAT ist super. Immwer schön, so tolle Tools an die Hand zu bekommen.

Gruss

McNugget

60

SPS-Programmierung / Re: maximale Anzahl von Bausteinen Ãœberschritten

« am: 04. Januar 2008, 11:17:35 »

Frohes neues Jahr Hugo.

Dazu habe ich mal eine Frage: Was mache ich, wenn die Taste "unbenutzte auschliessen" ausgegraut ist?

McNugget2000