Error reading message!

[CyaNn]

Markus Pointner wrote:

The WinCC OA Manager API is strictly single-threaded. In your own TCP communcation stuff you can use as many threads as you like, but basically everything that the WinCC OA API provides should only be used from a single thread.

Well.... Ok I understand my mistake.
I will implement the sync message queue manager I described.

Thanks a lot for you all to have taking time around my problem.

I wishe you a nice evening.
Yann

[CyaNn]

Well, a lots of workarounds, I come back with my unresolvable problem.

I have used a mutex to guaranty the unicity of message storing :

Code: Select all

HWObject* TCPCommHWService::storeToDB(QString address, PVSSchar *value) {
		TCPCommHWService::mutex.lock();

		HWObject obj;
		obj.setOrgTime(TimeVar());  // current time
		obj.setTimeOfPeriphFlag();
		obj.setDlen(sizeof(value));

		obj.setAddress(address.toStdString().data());
		obj.setData(value);

		HWObject *addrObj = DrvManager::getHWMapperPtr()->findHWObject(&obj);

		if ( addrObj ) {
			DEBUG_DRV_USR1("Message stored to DB " getAddress()

[mpoint]

These four "ff" bytes in the message dump are very strange. I wonder what happens there. As I mentioned above, I think these bytes are usually the message length. Maybe the length is -1 for some reason?

EDIT: Yes, it really seems to be -1.

When sending a message, it first writes the length as -1, then serializes the message, and then replaces the -1 with the real length. But if there is an error during serialization, the length will not be replaced. I think this is what is happening here.

One of your error messages even says "Failed to serialize message to (SYS: 1 Event -num 0 CONN: 1): Code = 0, errno = 0", but the error codes should not be 0.

[mpoint]

And I can't download your attachment.

[CyaNn]

Sorry, well I try to send it again in my personnal ftp server. :dry: :dry: :dry: :dry:

THE FILE !

Thanks

[Gertjan van Schijndel]

Caron Yann wrote:

...

Code: Select all

HWObject* TCPCommHWService::storeToDB(QString address, PVSSchar *value) {
		TCPCommHWService::mutex.lock();

		HWObject obj;

		// The HWObject has the current time by default, so you do not need to set it explicitly
		//obj.setOrgTime(TimeVar());  // current time
		// The time is from the wincc oa server, not from a device. So you should not set this flag
		//obj.setTimeOfPeriphFlag();
		obj.setDlen(sizeof(value));

		obj.setAddress(address.toStdString().data());
		obj.setData(value);

		HWObject *addrObj = DrvManager::getHWMapperPtr()->findHWObject(&obj);

		if ( addrObj ) {
			DEBUG_DRV_USR1("Message stored to DB " getAddress()

[CyaNn]

Thanks a lot.
It works better (about 3 hours), but I should have another problem, because after this time, it cash again.
Without any explanation.

Can you tell me where I can find more information about exception ?
Is it exists a hidden log ?

Thanks again to take time for my problem.

[leoknipp]

Hello,

sometimes the log-message "Error reading message! Msg dump follows" occurs when the process is using too much memory and therefore the message gets corrupted.
Please check the memory usage for the event-manager and your own API-process while the processes are running.

Best Regards
Leopold Knipp
Senior Support Specialist

[CyaNn]

Thanks for your reply.

Ok ! I am actually checking it.
But everything looks stable in memory.
About 30'900K for the event manager
and 12'320K for my driver.

And how message can be corrupted ? My Driver run on the same machine than event. And messages are the sames (circled by simulator)

I think about a concurent message in another method. But I don't know were to seek. :dry: :dry: :dry:
Or a too much amount of logs ???? :dry: :dry: :dry: :dry:

[CyaNn]

Hello,

Now I have juste the following error.


Is the heartbeat should be managed by myswelf ? Or is it a already managed by the driver layer ?
Best regards