Wago GSM Modem Verbindungsabbruch, keine automatische wiederkehr

[zernix]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Tag,
bei uns werden sehr viele Wagos verwendet
immer der selbe Controller mit gsm modem 750 8207 025-001 (wir verwenden das 104er fernwirkprotokoll)

wir wählen uns über das gsm modem auf ein apn ein bauen ein vpn auf und übertragen die daten funktioniert auch einwandfrei


hin und wieder (1 mal alle 1....2 Monate) fällt bei einer Station die Verbindung aus (Signal wird zu schlecht telekom abbruch dies ist noch in Klärung)



was jetzt das Problem darstellt :
bei wiederkehr der ausreichenden Signalstärke bzw der telekom Verbindung (wie gesagt in Klärung)
verbindet sich das modem nicht mehr automatisch es muss jemand zur Station fahren und einen "Kaltstart" durch spannungsausschaltung durchführen das kann ja keine dauerhafte lösung sein



kennt jemand dieses Problem und durch was wird es verursacht das diese automatische "wiederverbindung" nicht stattfindet wie gesagt von unseren 60 wagos (GSM Modellen) liegt das Problem bei lediglich 2 Stationen (telekom ist unser Provider für alle Internet Verbindungen also es gibt keine "Hersteller" Abweichung ….. )

für Diagnose lösungsansätze oder wie man zb das modem über das sps Programm neu anstößt bin ich dankbar

freundliche Grüße

 

[MFreiberger]

Moin zernix,

solange das Problem nicht gelöst ist, könnte man ein Workaround realisieren.

Dazu müsste das Modem der SPS melden können, ob die Signalstärke der Telekom ausreicht.

Dann könnte die SPS, wenn das Modem meldet, dass das Signal WIEDER da ist, ein Versorgungsrelais aus- und wieder einschalten.

Aber wenn das Modem die Signalstärke melden kann, müsste es doch auch eine Initialisierung antriggern können?

VG

MFreiberger

 

[zernix]

Zuviel Werbung?
-> Hier kostenlos registrieren

schonmal danke für die antwort

also um das ganze binär zu lösen strecke fällt aus (damit fallen ja auch werte weg) und nach zeit x zu sagen steuer ausgang y an um ein relai zu triggern
ist ja genau das was ich nicht als akzeptable lösung ansehe :-D ich will ja genau das vermeiden .. Spannung aus- einschalten...

es muss doch mit Sicherheit einen grund bzw fehler geben das sich die Verbindung nicht mehr automatisch aufbaut

 

[.:WAGO::0100153:.]

Hallo zernix,

wir bedauern sehr das du Probleme mit dem 750-8207 haben. Ich hätte ebenfalls noch ein Workaround und zwar könntest du die Signalstärke abfragen. Wenn diese zu gering ist, kannst du mit der configtool Bibliothek/Baustein das Modem einmal neu starten. Dieses kannst du wie folgt machen: Wenn du den callstring folgendes Commando 'mdmd -r' übergibst und anschließend den Trigger setzt.

Hier wird das Modem einmal neu gestartet und auch wieder neu eingewählt.

Ebenfalls würde ich die Firmware 12 Patch 1 auf dem Controller installieren, da hier ebenfalls etwas am Modem gemacht wurde.Viel Erfolg

 

[MFreiberger]

Moin zernix,

[..]also um das ganze binär zu lösen strecke fällt aus (damit fallen ja auch werte weg) und nach zeit x zu sagen steuer ausgang y an um ein relai zu triggern
ist ja genau das was ich nicht als akzeptable lösung ansehe :-D ich will ja genau das vermeiden .. Spannung aus- einschalten...[..]

Die Werte fallen doch nicht zwischen Modem und SPS aus, oder? Die Funkverbindung fällt doch aus. Die Frage ist ja, ob das Modem der SPS die Signalstärke melden kann. Erst unter diesen Voraussetzungen wäre mein Workaround sinnvoll, andernfalls ist es je eher ein Blindflug (mal sehen, ob es danach wieder geht).

Dass Du Spannung aus->ein vermeiden willst verstehe ich natürlich.
Ich konnte ja auch leider keine Lösung, sondern nur ein Workaround anbieten

VG

MFreiberger

 

[zernix]

Zuviel Werbung?
-> Hier kostenlos registrieren

schonmal danke jaein die wago kommuniziert ja mit anderen wagos
das heisst verbindugsabruch = Datenverlust der anderen wagos das Protokoll 104 hat ja eine meldevariable "Verbindung"

@ .:WAGO::0100153:.

wie heisst der Baustein der Bibliothek? diese Workaround Idee langt ja völlig aus das Hauptziel gilt der Vermeidung mit dem "spannungschalten" und das eben keiner extra hin fahren muss
somit wäre ,wenn erfolgreich, ein modenneustart "warm" ja schon eine super lösung

 

[Lars Weiß]

configToolFB aus der WagoConfigToolLIB

 

[Vertipper]

Hallo zernix,

hat diese Lösung bei Dir funktioniert ?

Ich habe ein ähnliches Problem, das unsere 8207 ab und an offline gehen eine erneute Einwahl nur über Neustart möglich ist.

Unter e!cockpit rufe ich die WagoAppConfigTool.FbConfigTool auf mit dem Kommandostring 'config_mdmd -r' (bei "mdm -r " passiert nichts).
Die Funktion meldet IO zurück, danach startet das Modem neu aber eine APN Einwahl funktioniert trotzdem nicht.
Die Empfangsanzeige bleibt rot, selbst wenn vor dem Modemrestart bester Empfang war.

Controller FW: 03.00.39 (12)
Modem FW: UC20GQBR04A07E1G

 

[zernix]

Zuviel Werbung?
-> Hier kostenlos registrieren

hi
ja bei mir hat es funktioniert allerdings habe ich codesys 2.3 (keine Ahnung ob es da einen unterschied in der Methode gibt)

ich habe eine txt Datei erstellt und dort den Linux funktionscode hinterlegt

#!/bin/bashcd /etc/config-tools./config_mdmd --reset echo -e "Modem Reset"

diese txt Datei habe ich per FileZilla in den etc config Tools ordner der wago Steuerung hochgeladen

dem funkltionscode in codesys / bei dir ecockpit habe ich dann per configtool fb
den namen der txt Datei welche ich eben in ect config Tools gespeichert habe übergeben

mir ist auch aufgefallen als ich testweise direkt über ssh auf die Linux console zugegriffen habe und dort direkt den befehl ausführe das sich das System aufhaengt
vllt ist es das selbe Problem wie wenn du diesen befhel '"direkt" dem fb config tool übergibts


die Methode mit der txt Datei hat dann einwandfrei funktioniert


aber mach einfach ein Firmware update auf die wagos drauf glaube 12.x ist aktuell? dann erledigt sich das Problem auch und du musst nicht überall die Bausteine einspielen


hoffe konnte etwas helfen

 

[Vertipper]

Hallo danke für Deine ausführliche Antwort.
FW 12 habe ich bereits drauf (siehe oben). Problem ist, dass nach Verbindungsabbruch das Modem sich nicht wieder neu einloggt.
Mit Aufruf des config_mdmd macht das Modem zwar irgeneinen Reset aber neu verbinden tut es erst nach Spannung aus-ein.
Wir haben das derzeit quick and dirty hardwaretechnisch gelöst -> nicht schön !!

Aufruf des mdmd über die Konsole funktioniert bei mir, muss nur mit Strg-C wieder aus dem Programm raus.

WAGO wirbt mit der Modem-Funktionalität, bleibt mir wohl nur der Telefonsupport...

Danke Dir

 

[Dennis2004]

Hello eweryone also having problem with modem functionality)
I'm also having problems with modem and I'm here to share my investigations.

1. Be sure to use one of the latest firmwares:
-Fw11Sp2(02.08.35)+FW11_Patch_ModemUpdate_2.1.7_hotfix_02.08.35 (If you have Fw<02.08.35 - please update as soon as possible!)
-Fw12.1(03.00.39) (Fw12 (<03.00.39) is not acceptable)
-Fw13(03.01.07?) - I have not tested this, I'm not even sure it is already available as a prebuit image, but you can get sourcet at github and build Fw using provided instructions.

2. If you use SMS features in your CoDeSys program (e.g. SIMPLE_SMS_8207 Functional Block) - you MUST modify default(t#2s) poll timer to be more than t#10s (I use t#14s). Mdmd uses a period of t#10 internally to poll current modem state and perform any needed actions, every time CoDeSys's FB asks for incoming SMS this timer is restarted and mdmd never performs periodic polls and nothing actually works.

3."/sbin/ifdown wwan0; /sbin/ifup wwan0"
-try to run this command. If this helps to reestablish connection - seems that you have ignored paragraphs 1. and/or 2. Or you have caught some bug I don't know about.

4."/etc/config-tools/config_mdmd --get --network-list"
-Seems strange how this can help... but, this command never works as expected when Network Package Service is enabled - it always returns error (due to insufficent delay in mdmd). As a side effect this command temporarily detaches Packet Service. This will help if you have a buggy GSM provider.

5."/etc/config_tools/config_mdmd -r"
-sometimes this call results in mdmd segmentation fault
-sometimes, without any error, the USB-HUB is reattached, but modem remains off (no tty devices, modem led not lit) (this hapenned with me only once, but when happened - only direct gpio method worked to poweron modem)

6."/etc/config_tools/config_mdmd --reset-all"
-sometimes after this you will have wwan0 interface down and mdmd tries to start wwan0 - this results in dhcp client running on stopped interface = no connection
-well, this command also failed to poweron modem witout any visible errors (this was the same single time that happened with me - only direct gpio method worked to poweron modem)

7."/etc/init.d/mdmd stop; ifdown wwan0; echo 132 > /sys/class/gpio/export; echo out > /sys/class/gpio/gpio132/direction; echo 1 > /sys/class/gpio/gpio132/value; sleep 2; echo 0 > /sys/class/gpio/gpio132/value; echo 132 > /sys/class/gpio/unexport;/etc/init.d/mdmd start"
-this is the most robust set of commands I found. It works even when mdmd is not running and it has a doubled delay for modem powercycle(I'not sure 2sec is always enough - when I had a problem with powering modem on, I have executed these commands by typing them one-by-one in console). Putting wwan0 DOWN helps mdmd to bring it UP properly later.

If you use SMS functionality:
-when you run any command that involves mdmd restart the mdm_cuse is also affected. This mdm_cuse is responsible for virtual serial port and AT-commands simulation needed by SIMPLE_SMS_8207 (and others) to work. After such a restart, please also restart any SMS-related functional block you use by setting xEnable to FALSE, wait for SerialInterface to close and then set xEnable to TRUE again (on a real pfc the command from paragraph 7. takes approximately 9 seconds to execute - no sense to set xEnable to TRUE earlier).

Some clues can be found inside /var/log folder. Especially in files "messages", "modem.log", sometimes in "kernel.log".

A good set of commands that can give some more clues:
"ifconfig wwan0;route -n;ps -wef|grep dhcp;ps -wef|grep mdm;ls /dev/ttyM*"

I have sent a request to wago support two weeks ago - seems that they have lost it.

 

[Vertipper]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hello Dennis2004,
thank you very much for these many hints.

After some tests I have found a solution for me:
Some time before I also had a problem to restart the ipsec from plc program so I use a cronjob to check and restark this vpn every 10 min.
8207 VPN Verbindung
In the same cronjob I also restart now the whole modem if there is no wwan. For this i use your "7."

Unfortunately after this I can not send any sms (you wrote this) but it is not possible to restart the FbSimpleSms_8207 because there is no xEnable.
So I think I have to use the normal SMS fb.

!

 

[Dennis2004]

... it is not possible to restart the FbSimpleSms_8207...So I think I have to use the normal SMS fb.

In CoDeSys2.3 SIMPLE_SMS_8207 Functional uses standart SMS fb with this parameters:
xConnect := TRUE,
bComPortNr := 66,
eBaudrate := BAUD_19200,
eParity := PARITY_NO,
eStopBits := STOPBITS_1,
eFlowControl := NO_FLOW_CONTROL,
All others are default. xConnect is a var that should be used to reconnect with mdm_cuse.

And don't forget to modify poll interval
tPollInterval := t#14s
Your connection problems should go away after modifying tPollInterval.

Again, in CoDeSys2.3, you can do this with SIMPLE_SMS_8207 and a pointer:

VAR
SIMPLE_SMS_8207: SIMPLE_SMS_8207;
ptime: POINTER TO TIME;
END_VAR

ptime := ADR(SIMPLE_SMS_8207.FbGsmSms.tPollInterval); ptime^ := t#14s;
SIMPLE_SMS_8207(
sNumber:= , (*Fill*)
xInternational:= , (*Fill*)
sMessage:= , (*Fill*)
sPin:= ,
xTxTrigger:= xTxTrigger,
xRxNewSms:= xRxNewSms,
utRxSms=> utRxSms,
iSignalQuality=> ,
eFbStatus=> ,
eLastSendState=> ,
iTxMsgRefNo=> );


UPDATE: Today I have tested newer firmware FW13(03.01.07) from GitHub. You still need to increase PollInterval with this FW in SMS Fb - problem is not fixed.

UPDATE1: WAGO support answered that developers are preparing fix for this and it will be included in next FW release.