Hi Chris,

I would really love to help you with this but my understanding of the S7 
communication is too bad for this.

And as a side note... Moka7 is the main reason we are now switching to PLC4J... 
: >

Julian

Am 16.08.18, 10:19 schrieb "Christofer Dutz" <[email protected]>:

    Hi Julian,
    
    Jeah ... Moka7 ... that was the code I usually mention when I talk about 
old driver NOT being able to run safely on multi-core machines ;-)
    Also I wouldn't like to "borrow" code from that project, as it's GPL. 
    
    But I think I know how I could setup a testcase that might be able to pull 
out the information we need.
    
    Let's concentrate on finding out the type of S7 on the other side:
    Ok ... SZL = Systemzustandsliste ... really interesting how official naming 
does show the German origin ... was looking for an English acronym.
    
    So it seems to be a IsoTP(DATA) packet with a S7(USER_DATA) payload. This 
contains a parameter of type CPU_SERVICES ... 
    
    I'll whip something up (hopefully today) ... shouldn't be that difficult.
    
    Chris
    
    
    Am 16.08.18, 09:36 schrieb "Julian Feinauer" <[email protected]>:
    
        Hey Chris,
        
        thanks for your reply.
        Unfortunately I cannot help you with gathering the types based on the 
protocol messages (we also have only one type here so reverse engineering is 
kind of... difficould).
        But what I "know" is how to read it from the SPS via request (we could 
send this request directly after establishing connection?).
        The necessary telegrams to send are here
        
https://github.com/xtrinch/moka7-live/blob/master/src/com/sourceforge/snap7/moka7/S7Client.java
        (Labelled as S7_SZL_FIRST and S7_SZL_NEXT)
        and the structure of the response is here
        
https://github.com/xtrinch/moka7-live/blob/master/src/com/sourceforge/snap7/moka7/S7CpuInfo.java
        I don't know if this helps you and how easy this can be adopted to the 
Structure in PLC4J as the github code is really... well... nevermind ; )
        
        But as I understand you correctly we need to have a logic that does 
unmarshalling of byte[] to some Class based on (possibly) several conditions 
and then in the unmarshal logic we do the unmarshalling based on the enum you 
create, right?
        
        Julian
             
            
            
        
        
    
    

Reply via email to