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] 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 [email protected] > Gesendet: Donnerstag, 15. April 2021 16:58 > An: [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] 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]
