Hi Thomas, I just had a look at your changes and they looked great.
I did need to tweak the main CMakeLists.txt however to make unity work with Maven. I think we should probably set a flag to indicate that the build is using Maven and then to conditionally do stuff. With the commented out import we would have required people to install Unity, with the import at least the maven folks can just build. I also stumbled over the fact that the modbus driver was no longer working, but this had nothing to do with your changes ... it just appears that Linux gives you a segfault if you try to change a string you initialize with "somestring" ... it seems in Windows you can do that, but on Linux I got segfaults :-( ... so I fixed that too and now the Modbus and the S7 were both showing the desired behavior. So thanks a lot for your hard work on this ... I definitely have to try out the write support for S7 :-) Chris On 16.04.21 10:27, Thomas wrote: Hi Chris, Thanks. Changes to generated-sources where trivial and commited before I read the parent folders name. I reverted them once I noticed. On the itemCount question are you sure? I'm going off wireshark and http://gmiru.com/article/s7comm-part2/ which are not in total agreement in terms of nomenclature or descriptions. Setting itemCount to uint16 (i.e. only changing @s7_var_payload_data_item.c:68) works fine and allows me to read bigger arrays correctly, nothing explodes. In the s7 parameter item there is an "itemCount" (& I guess this is numItems in your code snippet) referring to the amount of data items (used correctly @s7_payload.c:75) , but the itemCount used in the data item itself (@s7_var_payload_data_item.c:68) is different. In the latter case it refers to the size (in bytes) of the data part of the current data item (currently set from a downcast [uint16->uint8] of dataLenght or dataLenght/8). As is we are limited to 255B for any one data item. I think there is some variable name clash. Cheers, Thomas Sent with ProtonMail<https://protonmail.com> Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, 15 April 2021 17:14, Christofer Dutz [email protected]<mailto:[email protected]> wrote: Hi Thomas, I've been watching the awesome stuff you've been doing. Finally getting my rookie C code into shape ... thanks a lot for this and a very warm welcome here on the list. If you want, I could give you a video-call introduction to our code generation. I have to admit, I was a bit worried as I saw in your PR that there were generated files updated (If we don't yet generate that comment Jetbrains IDEs react on, we definitely need to do that) ... we need to find a way to get these changes back into the code generation templates. Bur regarding your question: No, we can't change that to uint 16 as in the S7 protocol this size is defined as a uint 8 (one byte unsigned int) ['0x04','0x03' S7ParameterReadVarResponse [simple uint 8 'numItems'] ] So, if we would increase that to uint 16 the drivers wouldn't work anymore. However this means that you can never request more than 255 elements of an array anyway. Hope this helps, Chris -----Ursprüngliche Nachricht----- Von: Thomas frost.tj<http://frost.tj>@protonmail.com.INVALID Gesendet: Donnerstag, 15. April 2021 16:58 An: [email protected]<mailto:[email protected]> Betreff: Re: PLC4c: What I'm up to in PR#233 Hi all, In PLC4c generated sources s7_var_payload_data_item.c:68 can we change the uint8_t itemCount variable to a uint16_t. This becomes a problem when we read reasonably big items (256B but still within PDU limits). I ask as I'm not sure how the generated sources are actually generated. Maybe there is some documentation on it? Thanks, Thomas Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, 13 April 2021 11:49, Thomas [email protected]<mailto:[email protected]> wrote: Hi all, Re PR233. I aim to use PLC4c with digital twins (codegen'd Simulink models) for metal industry and have it talk to Siemens S7 PLCs. Currently use a customized version of libnodave but PLC4x is interesting as it (eventually) works with multiple PLCs & has a C implementation. In PR233 I have added a loopback test (write values->read them back -> check they match). That's all I need for above use case. To do this I will/did: * Added write functionality (as in PR) this took a fair bit of time, mostly getting to understand the existing code/datatypes/debugging slowly * this morning added error checking to the write responses. * I see the read responses are not really checked so I will add this * Will check/chase any memory leaks That's all. After that a few tests in MATLAB/Simulink. If that goes well I can probably help on other protocols in PLC4c. Cheers, Thomas /[email protected]
