Hi all,

For the implementation of the feature discussed I see two open questions:

 *  How are Markers, In/Outs adressed in TIA?

 *  If we have the {width-identifier} it would be sufficient to use only INT, 
UNIT, REAL, ... because a LINT is just an INT with width D. Is it  easier for 
the user this way or is it easier to enter just the datatype TIA prints?

To question 1:

The planned Syntax for DBs is:


How is it for the other "Special" Memory regions?

Could we extend it to


or is there another syntax used in TIA for Markers, Inputs, Outputs, ... ?

To question 2:

Although it is redundant I tend for


which is redundant because the "width-indicator" already indicates that it is a 
double word, i.e., 32 bit.

Thus, one could in theory also write


allowing the user to skip redundant information.

But, this seems error prone for me and such a "wrong" input as in the second 
example should lead to an exception instead of an automatic adaption.

The first solution especially emphasizes that the connection / address String 
is really what an S7 programmer sees in his TIA program.

What do you think?


´╗┐Am 11.08.18, 11:08 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>:

    Hi Chris,




    thanks for the clarification, as you see I've never been that deeply 
involved with an apache project, yet (up to now just small fixes and commits).


    And in that case I agree with you to keep "conceptual" discussions here.










    Am 11.08.18, 10:58 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:




        Hi all,




        Well the thing is, that if we take discussions to the issue, people on 
the list aren't included in this. So if there are usage aspects, they should be 
discussed here, I think. Otherwise we would require folks to automatically 
monitor other sources too. However I'm fine with implementation details being 
discussed there.




        After all, the Apache mantra is: "if it didn't happen on the list, it 
didn't happen"








        Outlook for Android<https://aka.ms/ghei36> herunterladen






        From: Julian Feinauer <j.feina...@pragmaticminds.de>


        Sent: Saturday, August 11, 2018 10:34:17 AM


        To: dev@plc4x.apache.org


        Subject: Re: [DISCUSS] Change the format of the S7 Adresses




        Hi all,








        as it seems like everybody agreed on the proposed API Change / 
extension I allowed myself to create an Issue for this to coordinate the work 
on that under https://issues.apache.org/jira/projects/PLC4X/issues/PLC4X-43




        I suggest that we move further discussion there.








        Is this okay for all of you?












        Am 07.08.18, 13:06 schrieb "Julian Feinauer" 
























            Looks good to me.








































            Am 07.08.18, 12:53 schrieb "Christofer Dutz" 
















                Hi Julian,
































                well I would propose to add the type suffix with ":{typename}" 
but unfortunately every system has its own types and interpretations.
































                So our current S7 address would look like this:
































                DATA_BLOCKS/1/0 --[would be changed to]--> DATA_BLOCKS/1/0:INT
































                One universal notation for addresses in all drivers will 
probably not work. For example with Modbus the memory block (Coils or 
Registers) for example determins the datatype and with Ethernet/IP for example 
the address will probably look more like:
































































                Which means:
































































































                Am 07.08.18, 12:39 schrieb "Julian Feinauer" 
































                    Hi Chris,
































































                    I guess I'm fine with everything but perhaps we should try 
to find a syntax which goes well for all drivers where this feature is needed.
































                    Could you post an example string for such a suffix?
































































                    And I'm definetly for a "guessing" feature to keep support 
for the current API.
































































































































                    Am 07.08.18, 11:25 schrieb "Christofer Dutz" 
































































                        Yeah ... I guess you are right (
































































































































                        And regarding Sebastian's suggestion to keep the "it 
friendly" format. I think this shouldn't be a problem.
































































                        All we need are more pattern matchers. What we do need 
however is an extension of the existing format to add the type ...
































































                        Not quite sure if we should prefix the existing strings 
with a type or add them with a suffix.
































































                        I think I would prefer a suffix ... If we make it a 
suffix, we could make it optional and guess a fitting default type if omitted 
(same behavior as now)+
































































































































































































































































                        Am 03.08.18, 15:53 schrieb "Julian Feinauer" 
































































































































                            Just a small note to your example, in case of the 
"DOUBLE" we should write LREAL und relly stick to  the TIA naming.
































































































































                            Just stating that to avoid confusion.
































































































































































































































































































































































































































































































































                            Am 03.08.18, 15:42 schrieb "Christofer Dutz" 
































































































































































































































































                                This is the Discussion thread, so please 
perform any form of discussion here to keep the vote thread clean and readable.






























































































































































































































































































































































































































































































































































































































































































































































































Reply via email to