Nachrichten

1

Codesys 2 / Re: TimeOut Fehler SQL Express Server

« am: 31. Juli 2020, 22:14:43 »

momentan sieht es ja so aus als ob in richtung sps nicht durchkommt
Wird blockiert oder gar nichts gesendet

kannst du mal den datenverkehr mit wireshark aufzeichnen
Am einfachsten mal am rechner wo die Datenbank läuft


dann sehen wir sofort was kommuniziert wird und wo der haken ist

2

Codesys 2 / Re: IP_CONTROL Frage zum Verbindungsabbau

« am: 27. Juli 2020, 19:56:06 »

hallo

natürlich gibt es noch mehr fehler...

       S_BUF.BUFFER[1] := 16#00;
        S_BUF.BUFFER[2] := 16#0B;
        S_BUF.BUFFER[3] := 16#BC;
        S_BUF.SIZE := 4;


        IPClient(IP_C := IP_C, S_BUF := S_BUF, R_BUF := R_BUF);
        R_BUF.SIZE := 0;

1. vor dem senden solltest R_BUF_SIZE := 0 machen und nicht nach dem IP_Client aufruf denn nach dem Aufruf könnten theoretisch schon daten empfangen werden und dann knallst du R_BUF_SIZE := 0 drüber

Aber das ist nicht das hauptproblem

der Baustein IP_CONTROL arbeitet azyklisch - der baustein muss unabhängig deiner schritte zyklisch immer aufgerufen werden
sonst würde deine sps ja sofort abstürzen wenn der ip_control solange warten würde bis eine antwort kommt

schau dir doch die diversen demo bausteine an dort ist es auch immer so der der ip_control am baustein ende immer zyklisch durchlaufen wird
 
kurz gesagt deine konstruktion wirfst du am besten weg und schau dir die vorhandenen bausteine mal in ruhe an

3

Codesys 2 / Re: IP_CONTROL Frage zum Verbindungsabbau

« am: 27. Juli 2020, 07:19:31 »

ja deine statemaschine ist etwas wackelig


der xSend schritt ist nicht teil der schrittkette
wenn die schrittkette läuft kann xsend alles übersteuern

du wartest auch nie das die daten gesendet worden sind 0
erst wenn S_BUF.SIZE = 0 ist sind die daten sicher versendet
 
wenn es einen fehler gibt was durchaus sein kann das es normal ist musst du die verbindung wieder neu initialisiernen

das beste wäre es also wenn der xsend block schon teil der echten schrittkette ist somit muss alles der reihe nach ablaufen
und immer am anfang und nach fehler die verbindung neu initialisieren

4

Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION

« am: 27. Juli 2020, 07:03:52 »

hallo

das zippyshare in DE blockiert wird wusste ich nicht

alternativer download-link
https://drive.google.com/file/d/13yhqqiLaM7E74wRxIVF76SLRpFP6AkvG/view?usp=sharing

5

Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION

« am: 24. Juli 2020, 15:19:57 »

welchen link meinst du denn genau

kann kein problem feststellen

6

Codesys 2 / Re: TimeOut Fehler SQL Express Server

« am: 23. Juli 2020, 13:00:07 »

schau dir doch mal in der netwrok lib im ordner demo die programme an
dort sollte es auch einen beispiel für mysql geben

es kann aber auch sein das die sps sich wegen firewall oder portregeln nicht verbinden kann

7

Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION

« am: 22. Juli 2020, 18:53:54 »

oscat network lib 1.35 download

es gibt aktuell schwierigkeiten mit den anhängen bei alten beiträgen

dort ist nun extra eine externe downloadquelle hinterlegt

http://www.oscat.de/community/index.php/topic,2546.msg13223.html#msg13223

8

Codesys 2 / Re: TimeOut Fehler SQL Express Server

« am: 22. Juli 2020, 18:46:17 »

wenn eine namenauflösung notwendig ist dann musst du das vorher selber machen

in der url wird nur die reale ip-adresse des mysql server angegeben

9

oscat.lib fuer Step 7 / Re: MD5 hash in S7-1200

« am: 18. Juni 2020, 08:31:02 »

hallo

die oscat network lib gibt es für s7 nicht
aber du kannst dir den quellcode des bausteins nehmen und auf die s7 portieren
die module selber sind soweit hardwareunabhängig

10

Modulentwicklung / Re: Bei Codesys 3.5 Wetterstation über TCP auslesen

« am: 16. Mai 2020, 08:45:33 »

der ip_control bzw ip_control2 kann das alles

kontrolle der verbindung , daten senden und empfangen

schau dir mal die baustein dokumenation an und wie die beispielbausteine funktionieren !

11

Bestehende Module / Existing Modules / Re: Problem mit CALENDAR_CALC

« am: 10. Mai 2020, 11:36:50 »

ok

hast du bei UTC dann dein LOKAL-DATE angegeben ?

kannst du auch deine änderung-vorschlag posten

12

BECKHOFF / Re: DLOG_STORE_FILE_CSV ... Spalten

« am: 10. Mai 2020, 11:30:46 »

hallo

ohne Programmcode kann man deinen Test nicht bewerten (warum funktioniert es nicht ....)

4. Versuch Dateinamen problem
nach einen neuladen oder reset deines Programmes kann es sein das deine sps die datei als belegt bzw. offen hält
und dann kann man mitunter nicht mehr drauf zugreifen

wenn die prinzipielle probleme hast dann solltest du dir vorab mal die beispiele im DEMO-Ordner ansehen

13

Modulentwicklung / VERSCHOBEN: TIMER_1

« am: 26. April 2020, 09:56:52 »

Dieses Thema wurde verschoben nach oscat.lib für Step 7.

http://www.oscat.de/community/index.php?topic=5791.0

14

Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION

« am: 26. April 2020, 09:54:19 »

ohne das ich den baustein inhaltlich nun mir angesehen habe

aber des deutet daraufhin das der Baustein IP_CONTROL beim Datenempfang meldet das er mehr daten zum empfang hat als in den vorgesehen datenbuffer reinpassen.

vermutlich war es immer schon ziemlich knapp mit der buffer-datenreserve

Entweder du kannst bei deiner datenabfrage etwas ändern so dass weniger daten empfangen werden oder du änderst innerhalb der bibliothek die groesse des standard datenbuffers R_BUF bzw. S_BUF ab (Datentyp  NETWORK_BUFFER)

15

BECKHOFF / Re: DLOG_STORE_FILE_CSV für Hochfrequente Daten

« am: 24. April 2020, 13:15:32 »

Hallo

Für das was du machen möchtest benötigst du eine hochperformante Steuerung
Was verwendest du denn überhaupt für eine ?

Ein Grundproblem ist das alles unter 1ms mal prinzipiell nicht vorgesehen ist
Das Problem mit TRIG_M - Positive Flanke ist real keines denn damit du so etwas machen kannst benötigst du so wieso eine Steuerung die weit unter ms arbeitet
du kannst auch theoretisch den datalog baustein einfach zweimal hintereinander aufrufen mit TRIG_M 0 / 1

Wenn du wirklich im 1ms takt loggen möchtest musst du sowieso einen task wählen der ein vielfaches schneller aufgerufen wird als 1ms

Was hinzukommt ist das der datenlogger beim daten speichern und beim schreiben des datenbuffers in eine Datei asynchron arbeitet
und diese vorgänge viele zyklen benötigen

bei den meisten steuerungen ist das Dateisystem relativ langsam angebunden sodass du mehr daten produzierst als überhaupt schnell genug gespeichert werden können

 
Das was du programmiert hast ist so nicht funktionsfähig

Für jeden Wert den du loggen willst benötigst du einen eigene Bausteininstant
du hast jedoch in deinem Code den  fb_DLOG_REAL zweimal drinnen mit der gleichen Instant
somit wird auch die anzahl der datenspalten korrekt erkannt

Auch das mit den beiden for schleifen kann ich nicht nach vollziehen

du solltest mal beginnen mit einen normalen sauberen programm das mal prinzipiell funktioniert und vorab mal nur alle 10 sekunden etwas loggt
er wenn das korrekt funktioniert solltest du an die optimierungen machen und die zeiten herabzusetzen
irgendwann wist du vermutlich merken das die sps die daten nicht schnell genug speichern kann und es zu fehlern dadurch kommt


schau dir doch mal die vorhandenen datalogg demo bausteine in (FUP geschrieben) an


Für das loggen in ms takt benötigst du wie gesagt eine hochperformante sps oder eine log-funktion innerhalb der steuerung
Hast du mal ausgerechnet wieviele bytes du pro sekunde im log-file produzierst ?