Hi Julian,
I would opt for creating the parser/regular expression in a way that the
{width-identifier} is optional.
This way users can simply copy+paste addresses.
As we also said that we want the system to also treat the {type} as optional
and do a best effort at guessing types, if none are provided, this could be
some important information to help better guessing.
If someone copy+pastes an address and provides a {type} that doesn't match the
{width-identifier}, then we could also give feedback, that he is obviously
doing something wrong.
What do you think?
Chris
Am 11.08.18, 15:38 schrieb "Julian Feinauer" <[email protected]>:
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:
%DB{db-number}.DB{width-identifier}{byte-offset}(.{bit-offset})?:{plcType}
How is it for the other "Special" Memory regions?
Could we extend it to
%{memory-region}{db-number}.DB{width-identifier}{byte-offset}(.{bit-offset})?:{plcType}
or is there another syntax used in TIA for Markers, Inputs, Outputs, ... ?
To question 2:
Although it is redundant I tend for
%DB3.DBDx:DINT
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
%DB3.DBDx:INT
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?
Julian
Am 11.08.18, 11:08 schrieb "Julian Feinauer" <[email protected]>:
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.
Best
Julian
Am 11.08.18, 10:58 schrieb "Christofer Dutz"
<[email protected]>:
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"
Chris
Outlook for Android<https://aka.ms/ghei36> herunterladen
________________________________
From: Julian Feinauer <[email protected]>
Sent: Saturday, August 11, 2018 10:34:17 AM
To: [email protected]
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?
Julian
Am 07.08.18, 13:06 schrieb "Julian Feinauer"
<[email protected]>:
Hi,
Looks good to me.
Best
Julian
Am 07.08.18, 12:53 schrieb "Christofer Dutz"
<[email protected]>:
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:
#2#1#5:INT
Which means:
#{classId}#{instanceId}#{propertyId}:{type}
Chris
Am 07.08.18, 12:39 schrieb "Julian Feinauer"
<[email protected]>:
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.
Julian
Am 07.08.18, 11:25 schrieb "Christofer Dutz"
<[email protected]>:
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)+
Chris
Am 03.08.18, 15:53 schrieb "Julian Feinauer"
<[email protected]>:
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.
Julian
Am 03.08.18, 15:42 schrieb "Christofer Dutz"
<[email protected]>:
This is the Discussion thread, so please
perform any form of discussion here to keep the vote thread clean and readable.
Chris
