First of all the question: Does Snap7 support Windows Server 2012 r2? Because it is not mentioned on the list of supported OS.
I have got the problem that my c++ application crashes while writing data with “WriteMultiVars” or with “WriteArea”. This only happens on a Windows Server 2012 r2 machine. On my Windows 7 machine the application seems to run without problems.
Details:
Windows Server 2012 (Hyper-V virtual machine)
.net Framework 4.5
Build with MS Visual Studio 2010 SP1
connection to a Siemens S7 400
Thanks for your help!
Last edit: kreberh 2016-06-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I don't know, I never tested Snap7 on WS2012.
Just for test, try to execute Clientdemo (Win32 or Win64 version) that you can find into \rich-demos\i386-win32\bin (or x86_64-win64\bin). With it you can perform anything. What's happen ?
Did you rebuild snap7 library ? or are you using that into release folder ?
Is your App 32 or 64 bit ?
Let me know, Snap7 only uses standard socket and thread layer, the same code is good for Raspberry ans Solaris, imho it must work under WS2012. We will find the solution ;)
Last edit: Davide Nardella 2016-06-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just tested Snap7 under Microsoft Windows Server 2012 R2 Standard and works without problems.
It is not necessary to rebuild the library or the demos.
Tested both 32 and 64 C++ demos and the precompiled Clientdemo.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
so I did some further testing. I installed a Visual Studio on the Win Server 2012 machine where the problem occurs. I created a debug version of the snap7.dll. So I was able to debug into.
It looks like there is a threading problem. Why this only happens on my machine, I don’t know. Maybe the reason is that I’m running the Windows in a virtual box. Maybe the behavior is different to a physical machine? Maybe the thread handling is different. I started also whit only one cpu-core, but the problem occurred also.
The application always crashes at the same point. It’s in the
static void _callthreadstartex(void) (threadex.c)
/* must always exist at this point */
ptd=_getptd();/* * Guard call to user code with a _try - _except statement to * implement runtime errors and signal support */
__try{_endthreadex(((unsigned(__CLR_OR_STD_CALL*)(void*))(((_ptiddata)ptd)->_initaddr))(((_ptiddata)ptd)->_initarg));***************crashedhere*************************************}
__except(_XcptFilter(GetExceptionCode(),GetExceptionInformation())){/* * Should never reach here */_exit(GetExceptionCode());}/* end of _try - _except */
}
Sometimes it happens while writing sometimes while reading areas. I have seen that resources are accessed that are not available anymore/yet.
Sometimes the “Job“ in AsReadArea(…) or AsWriteArea(…) (=>s7_client.cpp) is not there sometimes it’s the “PDUH_out“ in opReadArea(…) or opWriteArea(…) (=>s7_micro_client.cpp)
It looks like the resources are destroyed before the using thread is stopped. Or resources are not created before starting the thread.
I have also connected to a Siemens Logo. There it looks like the problem does not occur. I don’t know if it is because I read/write much more data from the S7 than from the Logo. Or is the mechanism behind reading/writing to a Logo another one?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I forgot this Info:
It is a win32 application. And I tried both. The dll that comes with snap7 and I build my own one. Both have the same problem.
The Demo-Client runs fine. But I think the problem occurs when you call the read or write very fast one after the other.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally, the function static void callthreadstartex(void) is not part of Snap7 source.
Are you completely sure that you are not messing with thread/snap7 creation/destruction in your code?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello
I know, that "callthreadstartex" is not a part of Snap7. It was only the location where the debugger sopped, after crashing.
Meanwhile I have found out, what is the problem. One of the generated payload data (pdata) was NULL. The problem was that the application did not crash on this invalid item but one the item after that. So after the crashing the item inclusive the payload looked. I did not search for the mistake in the list of items.
Thank you very much for your support.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
First of all the question: Does Snap7 support Windows Server 2012 r2? Because it is not mentioned on the list of supported OS.
I have got the problem that my c++ application crashes while writing data with “WriteMultiVars” or with “WriteArea”. This only happens on a Windows Server 2012 r2 machine. On my Windows 7 machine the application seems to run without problems.
Details:
Windows Server 2012 (Hyper-V virtual machine)
.net Framework 4.5
Build with MS Visual Studio 2010 SP1
connection to a Siemens S7 400
Thanks for your help!
Last edit: kreberh 2016-06-13
Hi,
I don't know, I never tested Snap7 on WS2012.
Just for test, try to execute Clientdemo (Win32 or Win64 version) that you can find into \rich-demos\i386-win32\bin (or x86_64-win64\bin). With it you can perform anything. What's happen ?
Did you rebuild snap7 library ? or are you using that into release folder ?
Is your App 32 or 64 bit ?
Let me know, Snap7 only uses standard socket and thread layer, the same code is good for Raspberry ans Solaris, imho it must work under WS2012. We will find the solution ;)
Last edit: Davide Nardella 2016-06-13
Just tested Snap7 under Microsoft Windows Server 2012 R2 Standard and works without problems.
It is not necessary to rebuild the library or the demos.
Tested both 32 and 64 C++ demos and the precompiled Clientdemo.
Hello,
so I did some further testing. I installed a Visual Studio on the Win Server 2012 machine where the problem occurs. I created a debug version of the snap7.dll. So I was able to debug into.
It looks like there is a threading problem. Why this only happens on my machine, I don’t know. Maybe the reason is that I’m running the Windows in a virtual box. Maybe the behavior is different to a physical machine? Maybe the thread handling is different. I started also whit only one cpu-core, but the problem occurred also.
The application always crashes at the same point. It’s in the
static void _callthreadstartex(void) (threadex.c)
static void _callthreadstartex(void)
{
_ptiddata ptd; / pointer to thread's _tiddata struct /
}
Sometimes it happens while writing sometimes while reading areas. I have seen that resources are accessed that are not available anymore/yet.
Sometimes the “Job“ in AsReadArea(…) or AsWriteArea(…) (=>s7_client.cpp) is not there sometimes it’s the “PDUH_out“ in opReadArea(…) or opWriteArea(…) (=>s7_micro_client.cpp)
It looks like the resources are destroyed before the using thread is stopped. Or resources are not created before starting the thread.
I have also connected to a Siemens Logo. There it looks like the problem does not occur. I don’t know if it is because I read/write much more data from the S7 than from the Logo. Or is the mechanism behind reading/writing to a Logo another one?
I forgot this Info:
It is a win32 application. And I tried both. The dll that comes with snap7 and I build my own one. Both have the same problem.
The Demo-Client runs fine. But I think the problem occurs when you call the read or write very fast one after the other.
Some more tests with „WriteArea“ and “ReadArea” instead of “AsWriteArea” and “AsReadArea”:
It crashes again in the _callthreadstartex(void) (threadex.c)
Here the “PDUH_out” is not available in the opWriteArea(…) and opReadArea(…) (=>s7_micro_client.cpp)
I tested Snap7 in a virtual machine WS2012R2.
Be aware that Snap7 Client must be locked, i.e. you cannot access the same client from different threads.
See here:
https://sourceforge.net/p/snap7/discussion/general/thread/f1455ac4/?limit=25#468f
The speed of your calls and the data amount don't matter.
Since your are programming in c++ you could embed Snap7 MicroClient into your application, you need of only few files.
See here (Embedding Snap7 MicroClient):
http://snap7.sourceforge.net/snap7_source.html#embed_mc
Finally, the function static void callthreadstartex(void) is not part of Snap7 source.
Are you completely sure that you are not messing with thread/snap7 creation/destruction in your code?
Hello
I know, that "callthreadstartex" is not a part of Snap7. It was only the location where the debugger sopped, after crashing.
Meanwhile I have found out, what is the problem. One of the generated payload data (pdata) was NULL. The problem was that the application did not crash on this invalid item but one the item after that. So after the crashing the item inclusive the payload looked. I did not search for the mistake in the list of items.
Thank you very much for your support.