Abbrüche zwischen RoboPro Programm und TXT Controller (4.6.6)

[jomifa]

Hallo zusammen,
ich bin auf der Suche nach der Lösung für folgendes Problem:

- 2 TXT Controller verbunden über den EXT Anschluss für Erweiterungen
- Teil-Nutzung der Ausgänge M1– M4 bzw. O1– O8, der Eingänge C1– C4 und der Universal-Eingänge I1– I8

Es kommt ab und zu vor, dass nach dem Start des RoboPro Programms es in der Ausführung stehen bleibt. Parallel kann man auf der TXT Konsole über Putty Fehlermeldungen sehen, die zeitlich mit diesem Verhalten korrelieren.

Anbei die letzten Zuckungen der Verbindung zum TXT Controller:

Code: Alles auswählen

IOs/s DL=91 OL=91, Cam DL=0 OL=0, I2C tr=0 by=0
IOs/s DL=93 OL=93, Cam DL=0 OL=0, I2C tr=0 by=0
IOs/s DL=90 OL=90, Cam DL=0 OL=0, I2C tr=0 by=0
IOModuleReceiveData-Error: Cnt: 1000 - uTO: 1000 - InBuf: 81  - Len: 82
SerIoTransfer-Error:      1923
Closing connection from 192.168.178.81
RoboProToTxt_ProgramInfoCallback_c : Set sRoboPro.caNameDownloadRpp to
ROBOPROSTATE_IDLE
UpdateProgramNameRoboPro RoboProStop
UpdateProgramNameRoboPro ScratchStop
UpdateProgramNameRoboPro PythonStop
GetRoboProProgName:
sFileRun.u16NrFileTyp = FILE_TYPE_NO_FILE
**Info von ROBOPro  Name=, Action=Online stop
ERROR calling read
Closing I2C server connection from 192.168.178.81
I2C Server Thread terminated

Mir geht es hier um die Fehlermeldung:

IOModuleReceiveData-Error: Cnt: 1000 - uTO: 1000 - InBuf: 81 - Len: 82
SerIoTransfer-Error: 1923

Leider kann ich nichts mit diesen Meldungen anfangen. Meine Hoffnung besteht darin, dass einer von Euch diese Problematik kennt bzw. weiss wo man eine Beschreibung dieser Art von Fehlermeldungen finden könnte.

Wenn ihr mehr Informationen zu meinem Problem benötigt, lasst es mich wissen.

Grüße und kommt gut durch die heissen Tage,
Joachim

[vleeuwen]

I tried to reproduce this error.
So I took 2 TXT (A master and a slave). But I was not able to reproduce it.

A small question: do both TXT have the same version of the firmware, 4.6.6 (not the pre-release 4.6.6.)?
Do both TXT's run as master with ROBOPro 4.6.6 without errors?


=====================================================================
The Putty log directly after ending the RoboPro Program

Code: Alles auswählen

IOs/s DL=64 OL=64, Cam DL=0 OL=0, I2C tr=0 by=0

ERROR received illegal I2C command packet (length 0<4, id=00000000)
Closing I2C server connection from 192.168.10.136
I2C Server Thread terminated
Received stop online command
Microphone closed
RoboProToTxt_ProgramInfoCallback_c : Set sRoboPro.caNameDownloadRpp to
ROBOPROSTATE_IDLE
UpdateProgramNameRoboPro RoboProStop
UpdateProgramNameRoboPro ScratchStop
UpdateProgramNameRoboPro PythonStop
GetRoboProProgName:
sFileRun.u16NrFileTyp = FILE_TYPE_NO_FILE
**Info von ROBOPro  Name=, Action=Online stop
ERROR received illegal command packet (length<4)
Closing connection from 192.168.10.136

****************** Google translate****************************************************************

Ich habe versucht, diesen Fehler zu reproduzieren.
Also nahm ich 2 TXT (einen Master und einen Slave). Aber ich konnte es nicht reproduzieren.

Eine kleine Frage: Haben beide TXT dieselbe Firmware-Version 4.6.6 (nicht die Vorabversion 4.6.6)?
Führen beide TXTs mit ROBOPro 4.6.6 fehlerfrei als Master aus?

[jomifa]

Hi, Carel,
you are, as always, relentlessly open to questions.

To your questions:

do both TXT have the same version of the firmware, 4.6.6 (not the pre-release 4.6.6.)?

yes

Do both TXT's run as master with ROBOPro 4.6.6 without errors?

Before I connected the two TXT controllers together, they worked to my satisfaction.

Kind regards,
Joachim

[vleeuwen]

Hi Joachim,
I found a way to reproduce this message:

IOModuleReceiveData-Error: Cnt: 1000 - uTO: 1000 - InBuf: 81 - Len: 82
SerIoTransfer-Error: 1923

It looks like a time-out issue when the slave master communication is idle.

[jomifa]

Hi Carel,
after your tip

It looks like a time-out issue when the slave master communication is idle

I looked at the behavior between the two TXT controllers.

Scenario one:

The Master TXT is powered up and ready to operate. The slave is switched off. The RoboPro program that wants to access the slave ports is started.

Result:

Since the ports are not available, the program waits forever for the feedback from the sensors. No error messages or timeouts occurred between the two TXTs.

Scenario 2:

Switching on the Slave TXT Controller

Result:

No change in the program. The program continues to wait for the status changes of the sensors. There is obviously no synchronization between the two TXT controllers.

Scenario 3:

Exit and start RoboPro program

Result:
The program has control over the resources of both TXTs.

Kind regards,
Joachim

[vleeuwen]

Like with the Robo-interface and the TX-C, the TXT knows an is-slave alive mechanism.
This suggests that the slave could be (de)activated dynamically.

But this is not the reason for the error message.
If I start both TXT master and slave, I activate Putty console and I start in RoboPro the Test interface only and wait.
I will see that error message arriving after a while.

[jomifa]

I don't understand that at all. Why are you getting this error message?

I will see that error message arriving after a while.

My examples were not meant to illustrate the error message, but only the strange behavior between the RoboPro program and the TXT Master, which obviously does not realize that it has no connection to the slave, even though the program requires slave resources.
On the other hand, he complains and terminates when he notices that he has communication problems. So, is there a working protocol between the master and slave or not. And if so, why doesn't he notice the missing connection? I think there's something wrong here.

Translated with www.DeepL.com/Translator (free version)

[vleeuwen]

Why the TXT firmware 4.6.6. is generating that message in that M+S setup is unknow to me.
I my case the message arrived with only having the "Test interface" active.
It has something to do with the use of a slave. In my case the slave was always connected and active.
Differents between an USB and a IP connection?
A lot of questions about this instable situation.