Reading SZLs with S7NetPlus?

[Hefaistos68]

Sorry to ask that here but havent found any resource so far to help me out with this: how can I read SZLs with the S7NetPlus library? Am pretty fresh to S7 development and didnt yet grasp all the concepts, so bear with me. The Sharp7 lib provides some useful functions for reading and parsing some SZLs contents, is there any way to do the same with this library?

[mycroes]

Hi @Hefaistos68, There currently is no such support. I wouldn't mind adding them, but as long as I've been a maintainer for S7NetPlus I've been struggling to devote enough time to the issues and PR's in the first place. Also, I don't have permanent PLC access so I can't easily test features like these, which makes it even harder to add support.

If you have C# experience you could try to port the support from another library yourself, I'd be happy to review PR's for this.

[FalcoGoodbody]

Hi @Hefaistos68 , Hi @mycroes ,

SZL are only available for S7-300/400. They are no longer supportet for S7-1200/1500. With the new S7-1200/1500 SIEMENS changed the way how the module and device-states can be read-out of the CPU and they substituted the SZL. If some want to have this information in the plc, one need to read out these information first with the blocks "ModuleStates" and "DeviceStates". You can then copy these information into an DB and read them out with S7Net+.

Due to the fact that the S7-300/400 are no longer produced anymore, I am not sure if it necessary to implement this into S7Net+.

[Hefaistos68]

@FalcoGoodbody Thanks, this is important information. Didnt know that. In this case, it might be interesting to add support for the Module and Device States. While I do have permanent access to various Siemens PLCs, I dont know s*** about them. Just have to use them.

[scamille]

Thanks for writing this down. I was wondering why the newer PLC regressed the amount of information one can get through the S7 protocol. If those Module and Device stats are not directly accessible through the S7;protocol it might still not sense to integrate them into S7NetPlus.

I guess someone could write a struct for it, but it would need to come with a lot of documentation so that people using it first ensure the data is copied correctly to a DB.

[FalcoGoodbody]

You can also have a look into #119.

I think that the Module and Devices states are not directly accessible through the S7-protocol. To get the information you really need to read them out on plc-level first and store them into a DB.

I will have a look into these 2 blocks tomorrow and will see how much information will be stored then

[FalcoGoodbody]

I checked the amount of data and the way one can read out Device State, Module State, Identification and Maintenance Data and the Status LED the S7-1200/1500 series offer. The amount of data is not sooo much but one need to do some programming effort on plc-side. For example: you can read out the device states of an I/O-system, lets say one PROFINET system. On plc-side you have to call the function block "DeviceStates" and give it the neccessary parameters:

• LADDR (input)
• MODE (input) -RET_VAL (Return) -STATE (InOut)

With "MODE" one can choose between 5 types of information to be read:

1. IO-devices configured
2. IO-devices malfunction
3. IO-devices deactivated
4. IO-devices present
5. IO-devices which have had a problem

The data will be stored in a BoolArray[1024] (when PROFINET IO-system) on plc-side. According to the mode you choose, the first 3 bits will have different meanings. The array then represents the devices for example which are present or which have a malfunction, that depends on mode.

With the function block "ModuleState" one can read out the status of a single module of a device. So you can read out the status of DI16-card located in a IM151. You can have severall cards inside a IM151 and you also can have several IM151 in your IO-system. It all depends on the hardware-configuration of your project.

With the function block "Get_IM_Data" one can read some basic info from a device like Order-Id, Serial-Number, Hardware-Revision, Software-Revision.

With the function block "LED" one can read out the actual status of the system leds of a device. With that one can read out if a plc is running or has an error. But you have the step through up to 6 possible LEDs with each can have 10 states.

So it is not so easy to make it useable. For the different function blocks you have to create the data storage within a data block which can be read out with S7Net+. You could also write the neccessary parameters for the function blocks like MODE to the PLC and then read out the data. You then also need to evaluate the return-variables of the different function block to check if your request was ok, which is usually done inside the plc program. But without knowing anything about the hardware configuration these data is useless or you have to use the function blocks in combination. For example:

1. check the status LED of the plc
2. check if there is IO-system
3. check if there are IO-devices
4. check the status of the devices
5. get Identification and Maintenance data from the device
6. check each module of a device if there is a overall device error

One could implement this routine to check the whole system but still needs assistance on plc-side. But I am not sure if this is a task for a library....

But maybe a first little step which can be usefull is to read out the information about the built-in system LEDs. The return value is only an integer and you can easily step through the 5 possible LEDs with 10 possible states.

ID of LED:

1. STOP/RUN
2. ERROR
3. MAINTENANCE
4. Redudant
5. Link (green)
6. Rx/Tx (green)

STATE of LED:

0 = LED does not exist or status information not available 1 = permanent OFF 2 = colour 1 permanent ON (STOP/RUN: green) 3 = colour 2 permanent ON (STOP/RUN: orange) 4 = colour 1 is blinking with 2 Hz 5 = colour 2 is blinking with 2 Hz 6 = colour 1 and 2 are blinking alternately with 2 Hz 7 = LED is active, colour 1 8 = LED is activ, colour 2 9 = LED does not exist or status information not available 8086 = R/H system is not in state Run-Redudant, data from partner-plc not available 8091 = hardware component with LADDR does not exist 8092 = hardware component with LADDR can not delivere the requested information 8093 = id on parameter LED is not defined 80Bx = plc with LADDR does not support the function block "LED".

So on plc-side it would be the easiest way to only say the user to call the function block, address the LADDR (most common is 50) and provide the function block input and output with 2 values from a data block which is accessible with S7Net+. All other coding could be done in S7Net+ (loop through the LEDs and read the states). Be aware that writing and reading to and from the plc takes some time, maybe.

If one only wants to know if the plc is running and ok, one only needs to check LED 1 and 2.

       private enum LED : ushort
        {
            STOP_RUN = 1,
            ERROR = 2,
            MAINT = 3,
            REDUDANT = 4,
            Link = 5,
            Rx_Tx = 6
        }

        private enum LED_STATE : ushort
        {
            DOES_NOT_EXIST = 0,
            OFF = 1,
            COLOUR1_ON = 2,
            COLOUR2_ON = 3,
            COLOUR1_BLINKING = 4,
            COLOUR2_BLINKING = 5,
            BOTH_BLINKING = 6,
            LED1_ACTIVE = 7,
            LED2_ACTIVE =8,
            DOES_NOT_EXIST2 = 9,
            R_H_SYSTEM_NOT_IN_RUN = 8086,
            COMPONENT_DOES_NOT_EXIST = 8091,
            INFO_NOT_AVAILABLE = 8092,
            LED_ID_WRONG = 8093,
            CPU_DOES_NOT_SUPPORT_LED = 8081
        }      

[Hefaistos68]

I am only wondering, what are the Siemens Engineers drinking/smoking when they design a system?

[KarloX2]

@FalcoGoodbody thanks for your comment about how one can access status information of the S7-1200/1500 on the PLC side.

Does that really mean that there's no way, using the S7comm-plus protocol, to read information like the CPU model, S/N and firmware version without programming on the PLC side? With S7comm (S7-300/400) that was possible by reading SZLs.