As reported at http://forum.lazarus.freepascal.org/index.php/topic,22202.msg215294.html#msg215294, GetPlcStatus() returns wrong result for running 414H and 417H CPUs. My Lazarus test code and your clientdemo application give the same result. Reading and writing DB data works without any problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I can help then please say so. I have lots of 417H and 414H. You can send me anything to test that does not write to plc or change their status (these are production PLCs). Reading is fine, and I can report test results if you prepare for me some test code. If you want me to change plc running status during testing then I can do that too but I will have to wait for first plant shutdown. Thank you very, very much for your work, time and effort you have put into this nice lib.
It looks like SF changes URL. If you have problems with accessing URL with screenshots from the first post then here is another try: lazforum (EDIT: Tested. URL works for me now)
Last edit: Zeljko Avramovic 2016-07-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, this is what I get with standard 0x0424 (copy/paste from ClientDemo SZL dump):
14 00 01 00 51 40 F8 09 00 00 00 00 00 00 00 00 ....Q...........
16 01 14 09 04 41 37 95 .....A7.
and this is what I get with 0x0071 (also for a running 417H):
10 00 01 00 00 12 10 11 00 00 00 00 00 09 00 09 ................
00 00 03 00 ....
s7sfc document from your link was very interesting to find info what are meanings of ID and INDEX and what is available with SFC 51 "RDSYSST", but I could not find info about meaning of bytes returned. Is there any? Or you have to play and guess?
btw. I am only interested if cpu I am communicating with is running or not, because if it is not running all data I read from DBs is frozen and therefore faulty. I need to detect this and switch to other CPU to try to read data from it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have found "34.20 SSL-ID W#16#xy74 - Status of the Module LEDs" where INDEX W#16#0004 should give status of RUN led. The problem is that I still don't know how to interprete the result. I am also not exactly sure if xy in xy74 should be 00 or 01. I am interested in CPU so I guess 00, but it returns a much more data then with 01, so I am suspicisous since I don't know how to interprete this data.
Here is what I get for 0x0074 and index 0x0004:
04 00 1A 00 F8 02 00 00 F8 03 00 00 F8 04 01 00 ................
F8 05 00 00 F8 06 00 00 F8 0B 00 00 F8 0C 00 00 ................
F8 0D 00 00 F8 0E 01 00 F8 0F 01 00 F8 10 00 00 ................
F8 12 00 00 F8 13 00 00 F1 02 00 00 F1 03 00 00 ................
F1 04 01 00 F1 05 00 00 F1 06 00 00 F1 0B 00 00 ................
F1 0C 00 00 F1 0D 00 00 F1 0E 00 00 F1 0F 00 00 ................
F1 10 01 00 F1 12 00 00 F1 13 00 00 ............
and here is what I get for 0x0174 and index 0x0004:
04 00 02 00 F8 04 01 00 F1 04 01 00 ............
Do those data dumps help?
Last edit: Zeljko Avramovic 2016-07-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Avra,
as you can see Siemens is not so much prolific of exposing its information :)
Much of Snap7 itself was written using Wireshark and a big block notes.
Yes, it should work.
But I suggest you to test also the 0x0071 ID when the plant is available, the SZL read is safe, there are not risks also if you request an inexistent ID.
Maybe with a single call you could get the whole status information.
In any case getting only the RUN Led status should be enough for your purpose.
Let me know....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Much of Snap7 itself was written using Wireshark and a big block notes.
Huh, I know how much time consuming is this. I did something similar for getting data from Osisoft Pi archiver to avoid using their proprietary DLL. It is mostly fun but can be hard at times.
> But I suggest you to test also the 0x0071 ID when the plant is available
I will, but I don't think that I will get a chance before my vacation. Testing will probably have to wait for a while. I will let you know how it goes so that you can update GetPlcStatus() if you want to. I do not have any non-redundant S7-4xx (without H), so I don't know yet for sure if old function is unusable for all S7-4xx or just redundant ones.
Thanks again for all your work and support!
Last edit: Zeljko Avramovic 2016-07-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It turned out that GetPlcStatus() returns good result even when running on redundant CPUs like 414H and 417H CPUs. However it is not #08 as expected. Instead #09 is returned and it is perfectly valid.
Everything is clear if we take a look at this table from Siemens:
I would like to give you a note that Pasettimino native pascal library is out. There are still things to do but it is mature enough to go public. As you might have already guessed it is based on your Settimino. I have greatly extended it and you might want to explore the code for some unique features like getting all plc leds and getting power supply battery status, and maybe use the idea to implement something similar in your libraries. Please take a look around, and please give me some feedback about license and original library credits representation. If there is something that you don't like, or something is not correct, or there is something that you think should be changed, please say so.
Set Job.ID as 0x0071 and set Job.Index as 0x0000 then read byte opData[6],the result could be 0x10 or 0x20 or else.
0x10 indicates H status of CPU in rack0 is master CPU,0x20 means rack1's CPU is master.
See the s7sfc_en-EN.pdf in page 730:
34.19 SSL-ID W#16#xy71 - H CPU Group Information
System Software for S7-300/400 System and Standard Functions Volume 2/2
730 Reference Manual, 05/2010, A5E02790053-01
Contents Length Meaning
Mwstat2 1 byte Status byte 2
Bit 0: Status of the synchronization link-up 01:
Synchronization between CPU 0 and CPU 1
=0: not possible
=1: possible
Bit 1: 0
Bit 2: 0
Bit 3: reserved
Bit 4: =0: CPU not inserted in rack 0
=1: CPU inserted in rack 0
(in redundant mode: bit 4 = 0)
Bit 5: =0: CPU not inserted in rack 1
=1: CPU inserted in rack 1
(in redundant mode: bit 5 = 0)
Bit 6: reserved
Bit 7: Standby-master switchover since last
Re-enable
=0: no
=1: yes
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As reported at http://forum.lazarus.freepascal.org/index.php/topic,22202.msg215294.html#msg215294, GetPlcStatus() returns wrong result for running 414H and 417H CPUs. My Lazarus test code and your clientdemo application give the same result. Reading and writing DB data works without any problems.
I forgot to say that running status of something like 317-2 is correctly reported.
I didn't test Snap7 with a 414H, I will investigate as soon as I find the hardware...
Thanks for reporting
If I can help then please say so. I have lots of 417H and 414H. You can send me anything to test that does not write to plc or change their status (these are production PLCs). Reading is fine, and I can report test results if you prepare for me some test code. If you want me to change plc running status during testing then I can do that too but I will have to wait for first plant shutdown. Thank you very, very much for your work, time and effort you have put into this nice lib.
It looks like SF changes URL. If you have problems with accessing URL with screenshots from the first post then here is another try: lazforum (EDIT: Tested. URL works for me now)
Last edit: Zeljko Avramovic 2016-07-08
To get the CPU status Snap7 internally uses ReadSZL() function passing 0x0424 as ID and 0 as Index. But seems that for S7400H this is not suitable.
To know the CPU H status, in accord to this:
https://support.industry.siemens.com/cs/document/19537149/how-do-you-read-out-the-operating-state-and-status-of-an-h-system?dti=0&lc=en-WW
You should call ReadSZL() function passing W#16#0071 as ID
You can test if it works using ClientDemo.
You can find further information about SZL here:
https://support.industry.siemens.com/cs/document/44240604/system-software-for-s7-300-400-system-and-standard-functions-volume-1-and-volume-2?dti=0&lc=en-WW
Let me know...
Regards
Ok, this is what I get with standard 0x0424 (copy/paste from ClientDemo SZL dump):
14 00 01 00 51 40 F8 09 00 00 00 00 00 00 00 00 ....Q...........
16 01 14 09 04 41 37 95 .....A7.
and this is what I get with 0x0071 (also for a running 417H):
10 00 01 00 00 12 10 11 00 00 00 00 00 09 00 09 ................
00 00 03 00 ....
s7sfc document from your link was very interesting to find info what are meanings of ID and INDEX and what is available with SFC 51 "RDSYSST", but I could not find info about meaning of bytes returned. Is there any? Or you have to play and guess?
btw. I am only interested if cpu I am communicating with is running or not, because if it is not running all data I read from DBs is frozen and therefore faulty. I need to detect this and switch to other CPU to try to read data from it.
I have found "34.20 SSL-ID W#16#xy74 - Status of the Module LEDs" where INDEX W#16#0004 should give status of RUN led. The problem is that I still don't know how to interprete the result. I am also not exactly sure if xy in xy74 should be 00 or 01. I am interested in CPU so I guess 00, but it returns a much more data then with 01, so I am suspicisous since I don't know how to interprete this data.
Here is what I get for 0x0074 and index 0x0004:
04 00 1A 00 F8 02 00 00 F8 03 00 00 F8 04 01 00 ................
F8 05 00 00 F8 06 00 00 F8 0B 00 00 F8 0C 00 00 ................
F8 0D 00 00 F8 0E 01 00 F8 0F 01 00 F8 10 00 00 ................
F8 12 00 00 F8 13 00 00 F1 02 00 00 F1 03 00 00 ................
F1 04 01 00 F1 05 00 00 F1 06 00 00 F1 0B 00 00 ................
F1 0C 00 00 F1 0D 00 00 F1 0E 00 00 F1 0F 00 00 ................
F1 10 01 00 F1 12 00 00 F1 13 00 00 ............
and here is what I get for 0x0174 and index 0x0004:
04 00 02 00 F8 04 01 00 F1 04 01 00 ............
Do those data dumps help?
Last edit: Zeljko Avramovic 2016-07-08
Hi Avra,
as you can see Siemens is not so much prolific of exposing its information :)
Much of Snap7 itself was written using Wireshark and a big block notes.
Yes, it should work.
But I suggest you to test also the 0x0071 ID when the plant is available, the SZL read is safe, there are not risks also if you request an inexistent ID.
Maybe with a single call you could get the whole status information.
In any case getting only the RUN Led status should be enough for your purpose.
Let me know....
> Much of Snap7 itself was written using Wireshark and a big block notes.
Huh, I know how much time consuming is this. I did something similar for getting data from Osisoft Pi archiver to avoid using their proprietary DLL. It is mostly fun but can be hard at times.
> But I suggest you to test also the 0x0071 ID when the plant is available
I will, but I don't think that I will get a chance before my vacation. Testing will probably have to wait for a while. I will let you know how it goes so that you can update GetPlcStatus() if you want to. I do not have any non-redundant S7-4xx (without H), so I don't know yet for sure if old function is unusable for all S7-4xx or just redundant ones.
Thanks again for all your work and support!
Last edit: Zeljko Avramovic 2016-07-12
It turned out that GetPlcStatus() returns good result even when running on redundant CPUs like 414H and 417H CPUs. However it is not #08 as expected. Instead #09 is returned and it is perfectly valid.
Everything is clear if we take a look at this table from Siemens:
W#16#0001: STOP (update)
W#16#0002: STOP (reset memory)
W#16#0003: STOP (self-initialization)
W#16#0004: STOP (internal)
W#16#0005: STARTUP (cold restart)
W#16#0006: STARTUP (warm restart)
W#16#0007: STARTUP (hot restart)
W#16#0008: RUN (solo mode)
W#16#0009: RUN-R (redundant mode)
W#16#000A: HOLD
W#16#000B: LINK-UP
W#16#000C: UPDATE
W#16#000D: DEFECTIVE
W#16#000E: SELFTEST
W#16#000F: NO POWER
Better late then never ;-)
I will, but I don't think that I will get a chance before my vacation
WOW what a big vacation, from 2016 to 2018, can I come to work with you? :D :D
Thanks for reporting Zeljko ;)
B-)
You are most welcome. At the end you are the one who did the hard work, so thank you!
Hello Davide,
I would like to give you a note that Pasettimino native pascal library is out. There are still things to do but it is mature enough to go public. As you might have already guessed it is based on your Settimino. I have greatly extended it and you might want to explore the code for some unique features like getting all plc leds and getting power supply battery status, and maybe use the idea to implement something similar in your libraries. Please take a look around, and please give me some feedback about license and original library credits representation. If there is something that you don't like, or something is not correct, or there is something that you think should be changed, please say so.
https://bitbucket.org/avra/pasettimino
Thank you once more for your great work!
Avra
Last edit: Zeljko Avramovic 2018-08-14
Ping?
Pong?
Alive?
Hi Avra, sorry for delay :(
I sent you a m.p.
34.19 SSL-ID W#16#xy71 - H CPU Group Information
System Software for S7-300/400 System and Standard Functions Volume 2/2
730 Reference Manual, 05/2010, A5E02790053-01
Contents Length Meaning
Mwstat2 1 byte Status byte 2
Bit 0: Status of the synchronization link-up 01:
Synchronization between CPU 0 and CPU 1
=0: not possible
=1: possible
Bit 1: 0
Bit 2: 0
Bit 3: reserved
Bit 4: =0: CPU not inserted in rack 0
=1: CPU inserted in rack 0
(in redundant mode: bit 4 = 0)
Bit 5: =0: CPU not inserted in rack 1
=1: CPU inserted in rack 1
(in redundant mode: bit 5 = 0)
Bit 6: reserved
Bit 7: Standby-master switchover since last
Re-enable
=0: no
=1: yes