Hi Chris,
If it's ok, I would feel better about splitting the FieldHandler changes
into a separate PR. It looks as though that would be a decent PR in itself
as well as probably a change to the build utils package.
For this PR I'll update the Big Integer issue and add additional PLCValue
types. As well as add documentation to the Modbus section. this should take
me about a week or so.
I should also have the extended register write code ready as well in the
next week.
Kind Regards
Ben
On Mon, Sep 14, 2020 at 5:45 AM Christofer Dutz <christofer.d...@c-ware.de>
wrote:
> Hi Ben,
>
> as long as we keep everything as open as possible (not tie it to Java or
> any other specific language) and it simplifies things: I'm all +1 to that.
>
> I guess you have a concrete idea ... how about you update your PR and then
> we'll merge all in one go as soon as we have your ICLA on file.
>
> Then we could even get this in for the 0.8.0 release which we will be
> doing soon.
>
> Chris
>
>
>
>
> Am 14.09.20, 11:36 schrieb "Ben Hutcheson" <ben.hut...@gmail.com>:
>
> Hi,
>
> Thanks for the feedback Chris, means a lot. :)
>
> Otto, I hadn't put that together that the mspec was language
> independent
> definitely makes sense. We could use the pseudo types like we do in the
> spec already, uint 16, int 32, etc...?
>
> Chris, the aim of having the FileHandler class automatically built was
> to
> minimize the work needed to create the encodeBoolean, encodeInteger,
> encodeFloat methods as all of these are going to have the same format,
> which works out what datatype it is and whether it is a list or not.
>
> @Override
> public PlcValue encodeInteger(PlcField field, Object[] values) {
> ModbusField modbusField = (ModbusField) field;
> switch (modbusField.getDataType()) {
> case "INT":
> if(values.length == 1) {
> return new PlcINT((Integer) values[0]);
> } else {
> List<PlcINT> plcINTValues = new LinkedList<>();
> for (int i = 0; i < values.length; i++) {
> plcINTValues.add(new PlcINT((Integer) values[i]));
> }
> return new PlcList(plcINTValues);
> }
> case "UINT":
> if(values.length == 1) {
> return new PlcUINT((Integer) values[0]);
> } else {
> List<PlcUINT> plcUINTValues = new LinkedList<>();
> for (int i = 0; i < values.length; i++) {
> plcUINTValues.add(new PlcUINT((Integer)
> values[i]));
> }
> return new PlcList(plcUINTValues);
> }
> case "REAL" etc.....
>
> The only difference is going to be from what language datatype we
> allow to
> be mapped to what PLCValue class. Having this in the mspec document
> something like:-
>
> [field uint 8 'ModbusFieldHandler' [array uint 8 'plcType']
> ['00' Integer ['INT', 'UINT', 'REAL']]
> ['01' Float ['REAL']]
> ['02' Short ['INT', 'UINT', 'REAL']]
>
> Another option is to make the encodeInteger type functions more
> generic,
> possibly having a single encode method that handles this but I'm not
> sure
> how we could handle that across multiple languages.
>
> I signed and sent away the ICLA just then, having PLC4X notified.
>
> Kind Regards
>
> Ben
>
>
>
> On Mon, Sep 14, 2020 at 4:36 AM Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > And @Ben,
> >
> > I am not sure if you have already done that, but if you haven't it
> would
> > be cool if you could fill out, sign and send to secret...@apache.org
> your
> > ICLA.
> > Cause your PR is a little more than I would consider a minor
> contribution.
> >
> > https://www.apache.org/licenses/icla.pdf
> >
> > Chris
> >
> > Am 14.09.20, 09:53 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
> >
> > Hi Ben,
> >
> > thanks for that PR ... Just had a look at it and it looks really
> good
> > to me.
> >
> > I think this way we would simplify the whole PlcValue handling
> quite a
> > bit and we'll reduce the risk of having it right in one driver and
> wrong in
> > another.
> >
> > But I have to admit that I don't quite understand your question
> about
> > the Java datatypes ... don't the PlcValues have accessors that map
> the
> > PlcValue to a given Java type? Why would we need such an extension.
> >
> > Please excuse if this is a stupid question ... I'm currently
> running
> > my brain in C-mode ...
> >
> > Chris
> >
> >
> >
> > Am 11.09.20, 23:05 schrieb "Ben Hutcheson" <ben.hut...@gmail.com
> >:
> >
> > Hi,
> >
> > After creating a PR for the modbus data types and moving the
> > max/min checks
> > and data conversion tasks to the individual PLCValue
> classes, the
> > ModbusFieldHandler class has been reduced to a bunch of cases
> > which map a
> > Java Datatype to a PLC Datatype. Looking at the
> S7FieldHandler
> > class it
> > seems to be doing the same.
> >
> > What are your thoughts on creating a new section within the
> mspec
> > file to
> > allow mapping Java datatypes to PlcValue types and then
> > automatically
> > creating the FieldHander class for each protocol? The mspec
> > section would
> > list all the Fields available for the protocol as well as
> > datatypes e.g.
> > Modbus would have the coil/discrete/input/holding/extended
> fields
> > and map
> > the Java Integer to INT,UINT,DINT,REAL, map Floats to REAL
> types,
> > etc..
> >
> > This would allow protocols to override mappings to PLCValue
> > classes when
> > needed as well.
> >
> > Kind Regards
> >
> > Ben
> >
> > On Tue, Sep 8, 2020 at 7:52 PM Ben Hutcheson <
> ben.hut...@gmail.com>
> > wrote:
> >
> > > Hi Chris,
> > >
> > > I'm not sure I follow your last email,
> > >
> > > I have pushed a commit to *hutcheb:Feature/ModbusDataType
> > > <
> https://github.com/hutcheb/plc4x/tree/Feature/ModbusDataType>,
> > *which
> > > includes some of the changes I've proposed.
> > >
> > > 1) Within
> > >
> >
> build-utils/language-java/src/main/resources/templates/java/data-io-template.ftlh,
> > > I've added a cast to the PLCValue so that we can use
> methods
> > specific to
> > > the PLCValue types to decode input from th PLC not just the
> > methods defined
> > > in the interface.
> > > 2) I've added the initial framework for adding Modbus
> datatypes
> > within the
> > > address string. This is able to support the INT (r/w) and
> UINT
> > (w)
> > > datatypes when parsing a Java String (I have to clean it
> up and
> > fix up
> > > handling of PLCList types)
> > > 3) I've updated the Modbus.mspec to include the INT
> datatype
> > within the
> > > dataio section, I would have to add the rest of the
> datatypes in
> > the same
> > > section.
> > > 4) I've added PlcINT and PlcUINT classes and have moved the
> > handling of
> > > parsing different Java Datatypes into these, as well as
> some
> > handling of
> > > decoding within the PlcINT classes. Along with the last
> point
> > this allows
> > > us to decode the INT datatype within the DataItemIO.java
> file.
> > >
> > > Let me know what you think?
> > >
> > > Kind Regards
> > >
> > > Ben
> > >
> > > On Tue, Sep 8, 2020 at 11:44 AM Christofer Dutz <
> > christofer.d...@c-ware.de>
> > > wrote:
> > >
> > >> Hi Ben,
> > >>
> > >> well the PlcValue types are based on the types used in the
> > language they
> > >> are used in. In PLC4C, which supports signed and unsigned
> > types, I
> > >> implemented them differently.
> > >> Initially I thought that if the PlcValues would simply
> have a
> > byte-array
> > >> and a type, then it would be universal ... but I thought
> > accessing the
> > >> values would require more cpu and memory.
> > >>
> > >> But given the fact that if we had such generic PlcValues,
> we
> > could use
> > >> them in all drivers ... sort of makes them more
> interesting.
> > >>
> > >> We could have multiple implementations of them ... so we
> could
> > have these
> > >> DefaultPlcValue implementation for the normal 61131
> datatypes
> > but give
> > >> drivers the opportunity to provide customizations for
> special
> > types.
> > >>
> > >> What do you think?
> > >>
> > >> Chris
> > >>
> > >>
> > >>
> > >> Am 08.09.20, 14:44 schrieb "Ben Hutcheson" <
> > ben.hut...@gmail.com>:
> > >>
> > >> Hi Chris,
> > >>
> > >> The case where PLC data types are mapped to 16 bit
> > registers isn't a
> > >> special case, as the Modbus protocol only supports 16
> bit
> > registers
> > >> but it
> > >> doesn't specify what format the data should be in,any
> PLC
> > data type
> > >> can be
> > >> mapped to these and then passed over Modbus. It would
> > definitely be
> > >> handy
> > >> to be able to convert any of the PLC datatypes back
> from
> > Modbus 16-bit
> > >> registers to whatever datatype they should be. I've
> done
> > some work
> > >> already
> > >> on the specific case of mapping a Java String to the
> > >> PLCInteger/PLCShort
> > >> classes and can expand it basing it off the S7
> functions
> > that do the
> > >> same.
> > >> We can then look at the differences and consolidate
> them if
> > possible?
> > >>
> > >> However it would be great to be able to add
> unambiguous
> > classes to
> > >>
> plc4j/api/src/main/java/org/apache/plc4x/java/api/value for
> > each of
> > >> the IEC
> > >> datatypes instead of these being based off Java types.
> > >>
> > >> Using the same format as the S7 protocol the address
> string
> > would be
> > >> holding-register:1000:REAL[10] instead though, I don't
> > think this will
> > >> cause issues if we make it optional and default to
> INT or
> > BOOL as
> > >> required.
> > >>
> > >> Kind Regards
> > >>
> > >> Ben
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Tue, Sep 8, 2020 at 8:10 AM Christofer Dutz <
> > >> christofer.d...@c-ware.de>
> > >> wrote:
> > >>
> > >> > Hi Ben ...
> > >> >
> > >> > Sorry for my email... I should really finish reading
> > before
> > >> replying :-(
> > >> >
> > >> > About your suggestion to add it to the type to the
> > ModbusField ... I
> > >> > agree. But I would simply extend the Address string
> the
> > same way
> > >> the TIA
> > >> > addresses were extended.
> > >> > Cause the problem I'm seeing is that for the 61131
> > datatypes we can
> > >> > provide an enum, but not for any custom types the
> driver
> > might be
> > >> > supporting. With a String we can keep it simple ...
> check
> > if the
> > >> type is a
> > >> > 61131 type -> if yes: do the default handling. If
> it's
> > not, use
> > >> some driver
> > >> > specific encoding/decoding.
> > >> >
> > >> > In my particular case the Float values were also 4
> byte
> > values ... I
> > >> > manually solved it by requesting 2 element arrays
> for
> > every float
> > >> address
> > >> > (The map of reigsters only used only even register
> > numbers, so that
> > >> > worked). Then I manually converted the 2 x 2bytes
> into a
> > 4byte
> > >> float with
> > >> > this code:
> > >> >
> > >> > // Decode the first 10 shorts as 32bit
> floats
> > ...
> > >> > StringBuilder sb = new StringBuilder();
> > >> > for(int i = 0; i < 10; i++) {
> > >> > int short1 = value.getIndex(i *
> > 2).getInteger();
> > >> > int short2 = value.getIndex((i * 2)
> +
> > >> 1).getInteger();
> > >> > WriteBuffer wb = new WriteBuffer(4);
> > >> > wb.writeInt(16, short1);
> > >> > wb.writeInt(16, short2);
> > >> > final byte[] data = wb.getData();
> > >> > int intVal = (data[3] & 0xFF) |
> ((data[2]
> > & 0xFF)
> > >> << 8) |
> > >> > ((data[1] & 0xFF) << 16) | ((data[0] & 0xFF) << 24);
> > >> > final float v1 =
> > Float.intBitsToFloat(intVal);
> > >> > sb.append(v1).append(", ");
> > >> > }
> > >> >
> > >> > Ok in this case I read 10 floats by reading an
> array of 20
> > >> registers.
> > >> > Guess it should be even simpler with 32bit integers
> > >> >
> > >> > But I guess it does the job ... not pretty, but it
> works
> > and I would
> > >> > definitely love to have something similar in the
> drivers
> > to handle
> > >> this if
> > >> > I said "holding-register:1000[10]:REAL"
> > >> >
> > >> > Chris
> > >> >
> > >> >
> > >> > Am 08.09.20, 13:59 schrieb "Christofer Dutz" <
> > >> christofer.d...@c-ware.de>:
> > >> >
> > >> > Hi Ben,
> > >> >
> > >> > if you have followed the latest discussions
> here ...
> > currently
> > >> the
> > >> > modbus protocol supports 16bit integer values for
> > registers and
> > >> Boolean
> > >> > values for coils.
> > >> > The protocol doesn't directly support anything
> else.
> > However I
> > >> have
> > >> > seen that vendors use arrays of registers to support
> > higher level
> > >> types. In
> > >> > my special case the PLC vendor used two 16bit
> integers to
> > provide
> > >> 32bit
> > >> > float values.
> > >> >
> > >> > We will probably start adding support for the
> basic
> > IEC 61131
> > >> > datatypes (
> https://en.wikipedia.org/wiki/IEC_61131-3)
> > but I think
> > >> this
> > >> > will only apply for the Bool, Bit-String, Signed and
> > Unsigned
> > >> Integers as
> > >> > well as Real values. Durations, Times, Dates and
> > especially Strings
> > >> will be
> > >> > problematic as it seems every vendor uses a
> different
> > encoding of
> > >> these.
> > >> >
> > >> > Chris
> > >> >
> > >> >
> > >> > Am 08.09.20, 13:52 schrieb "Ben Hutcheson" <
> > >> ben.hut...@gmail.com>:
> > >> >
> > >> > Hi,
> > >> >
> > >> > Looking at the example I had with the
> > hello-world-write
> > >> example
> > >> > trying to
> > >> > write a String to the Modbus protocol.
> > >> >
> > >> > ava -jar
> > >> plc4j-hello-world-plc4x-write-0.8.0-SNAPSHOT-uber-jar.jar
> > >> > --connection-string modbus://127.0.0.1:5467
> > >> --field-addresses
> > >> > 40010
> > >> > -field-values 32000
> > >> >
> > >> > The value 32000 then gets cast as a String
> and is
> > passed to
> > >> the
> > >> > encodeString function in
> ModbusFieldHandler. (It
> > doesn't
> > >> have one
> > >> > it gets
> > >> > passed to the DefaultFieldHandler). To get
> this
> > to work
> > >> properly
> > >> > we would
> > >> > need to define a datatype to cast the
> String to,
> > S7 does
> > >> this
> > >> > already and
> > >> > with the consensus that IEC 61131 data
> types be
> > used where
> > >> > possible then I
> > >> > see no reason we shouldn't add the datatype
> field
> > to the
> > >> > ModbusField. If we
> > >> > are doing this for these protocols, then why
> > don't we add
> > >> the
> > >> > datatype
> > >> > field to the PLCField interface, this would
> allow
> > us to use
> > >> the
> > >> > same
> > >> > default encodeString (We may have to map the
> > protocol
> > >> specific
> > >> > datatypes to
> > >> > IEC 61131 here, the same
> internalEncodeString
> > might be
> > >> better)
> > >> > functions
> > >> > for S7 and Modbus by casting the input to a
> > PLCField
> > >> instead of a
> > >> > S7Field
> > >> > or ModbusField.
> > >> >
> > >> > When encodeString is then called we can use
> the
> > datatype
> > >> that is
> > >> > passed to
> > >> > it to encode it to a
> PLCInteger/PLCFloat/etc..,
> > the same
> > >> way the S7
> > >> > protocol does it. S7 however only allows
> Strings
> > to be
> > >> passed as
> > >> > string
> > >> > related variables (CHAR, WCHAR, STRING and
> > WSTRING), I
> > >> don't see
> > >> > any reason
> > >> > we can't expand this to be able to pass any
> PLC
> > datatype
> > >> from a
> > >> > string.
> > >> >
> > >> > The next problem I had was to then be able
> to
> > parse the
> > >> PLCInteger
> > >> > class to
> > >> > a byte array within the fromPLCValue
> function.
> > For the UINT
> > >> > datatype for
> > >> > the Modbus protocol, this is a 2 byte array
> > however the
> > >> PLCInteger
> > >> > class
> > >> > contains it as a 4 byte array. in the
> > fromPLCValue function
> > >> there
> > >> > doesn't
> > >> > seem to be a way to test to see if it is an
> UINT
> > or a 4 byte
> > >> > integer such
> > >> > as a DINT. If we were to change the classes
> in
> > >> >
> > plc4j/api/src/main/java/org/apache/plc4x/java/api/value to
> > >> match
> > >> > the IEC
> > >> > 61131 datatypes then we should be able to
> parse
> > them
> > >> correctly in
> > >> > Modbus
> > >> > fromPLCValue function.
> > >> >
> > >> > I have probably missed a few things out,
> like how
> > the
> > >> > TransportSize class
> > >> > for the S7 protocol works, and we may have
> to
> > settle for
> > >> mapping
> > >> > protocol
> > >> > specific types to IEC61131 types in the
> encode
> > functions in
> > >> each
> > >> > protocol,
> > >> > what are your thoughts?
> > >> >
> > >> > Kind Regards
> > >> >
> > >> > Ben
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Sun, Sep 6, 2020 at 11:25 AM Christofer
> Dutz <
> > >> > christofer.d...@c-ware.de>
> > >> > wrote:
> > >> >
> > >> > > Hi all,
> > >> > >
> > >> > > well I doubt that we could really
> centrally
> > handle this.
> > >> > > If you have an idea how to unify this,
> I'd be
> > happy for a
> > >> > suggestion.
> > >> > > I guess most will have to be handled in
> the
> > individual
> > >> drivers
> > >> > themselves.
> > >> > >
> > >> > > But I really would like all drivers to
> support
> > the same
> > >> base-set
> > >> > of
> > >> > > datatypes.
> > >> > >
> > >> > > Chris
> > >> > >
> > >> > >
> > >> > >
> > >> > > Am 06.09.20, 17:02 schrieb "Cesar Garcia"
> <
> > >> > cesar.gar...@ceos.com.ve>:
> > >> > >
> > >> > > Hello,
> > >> > >
> > >> > > I think it can be applied from several
> > points of
> > >> view, the
> > >> > one
> > >> > > typified as
> > >> > > you indicate (HREGISTER: REAL) or
> > (HREGISTER [2]),
> > >> each one
> > >> > has its
> > >> > > advantage.
> > >> > >
> > >> > > To be able to handle the types
> indifferently
> > >> (specifically
> > >> > between
> > >> > > Modbus
> > >> > > and S7), I modify the field of the
> Modbus
> > driver so
> > >> that it
> > >> > strictly
> > >> > > adapts
> > >> > > to the PLC4X API. This prevents the
> user's
> > App from
> > >> having
> > >> > to implement
> > >> > > code to interpret the content of the
> > records.
> > >> > >
> > >> > > This is implemented in version 0.6.1
> of
> > PLC4X, but
> > >> the new
> > >> > version is
> > >> > > something else.
> > >> > >
> > >> > > Best regards,
> > >> > >
> > >> > > El dom., 6 sept. 2020 a las 10:03, Ben
> > Hutcheson (<
> > >> > > ben.hut...@gmail.com>)
> > >> > > escribió:
> > >> > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > I ran into this issue this morning
> when
> > using the
> > >> > hello-world-write
> > >> > > example
> > >> > > > and trying to write to a Modbus
> > connection. It
> > >> looks like
> > >> > it assumed
> > >> > > the
> > >> > > > input value is a string whereas the
> > Modbus protocol
> > >> > doesn't have
> > >> > > support
> > >> > > > for it yet.
> > >> > > >
> > >> > > > I was thinking about expanding
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> github/plc4x/plc4j/spi/src/main/java/org/apache/plc4x/java/spi/connection/DefaultPlcFieldHandler.java
> > >> > > > to include default handlers for the
> > various IEEE
> > >> 61131
> > >> > data types,
> > >> > > the
> > >> > > > specific protocols can then
> override them
> > as
> > >> necessary?
> > >> > > >
> > >> > > > Kind Regards
> > >> > > >
> > >> > > > Ben
> > >> > > >
> > >> > > > On Wed, Sep 2, 2020 at 9:36 AM
> Christofer
> > Dutz <
> > >> > > christofer.d...@c-ware.de>
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Hi Julian,
> > >> > > > >
> > >> > > > > I agree ... if one driver would
> define
> > an "INT"
> > >> as 32bit
> > >> > integer
> > >> > > and the
> > >> > > > > others would treat it as 16bit
> ... that
> > could be a
> > >> > problem.
> > >> > > > > Perhaps having a statement of the
> > project that we
> > >> use
> > >> > the IEC
> > >> > > 61131 types
> > >> > > > > as a basis and if you want to use
> a
> > given
> > >> protocols
> > >> > different
> > >> > > types, that
> > >> > > > > you can prefix them ..
> > >> > > > >
> > >> > > > > Assuming a driver for the famous
> "HURZ"
> > protocol
> > >> would
> > >> > use 32bit
> > >> > > INTs,
> > >> > > > > then an "INT" could reference the
> 16bit
> > version
> > >> and a
> > >> > "HURZ_INT"
> > >> > > could be
> > >> > > > > the 32bit version?
> > >> > > > >
> > >> > > > > Chris
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > Am 02.09.20, 15:26 schrieb "Julian
> > Feinauer" <
> > >> > > > > j.feina...@pragmaticminds.de>:
> > >> > > > >
> > >> > > > > Hi,
> > >> > > > >
> > >> > > > > agree with your suggestion!
> > >> > > > > Although we have to be
> careful to
> > not mix it
> > >> up with
> > >> > specific
> > >> > > > > implementations of datatypes in
> some
> > drivers.
> > >> > > > >
> > >> > > > > Julian
> > >> > > > >
> > >> > > > > Am 02.09.20, 15:21 schrieb
> > "Christofer Dutz" <
> > >> > > > > christofer.d...@c-ware.de>:
> > >> > > > >
> > >> > > > > Hi all,
> > >> > > > >
> > >> > > > > today I was at a
> customer’s
> > site and used
> > >> the
> > >> > Modbus
> > >> > > driver to
> > >> > > > get
> > >> > > > > data. This generally worked fine.
> > >> > > > > The thing however I found
> a
> > little
> > >> complicated,
> > >> > was that
> > >> > > the PLC
> > >> > > > > seemed to offer all values as
> 32Bit
> > Floating point
> > >> > values.
> > >> > > > > So in order to correctly
> read
> > them, I had
> > >> to
> > >> > read an array
> > >> > > of two
> > >> > > > > consecutive shorts and then
> manually
> > convert them
> > >> into a
> > >> > float.
> > >> > > > >
> > >> > > > > I bet we can do this
> better.
> > >> > > > >
> > >> > > > > So I thought … how about
> we use
> > the same
> > >> > > > >
> > https://en.wikipedia.org/wiki/IEC_61131-3
> > >> datatypes we
> > >> > are
> > >> > > already using
> > >> > > > > in other drivers and for example
> if you
> > write:
> > >> > > > >
> > >> > > > > holding-register:1:REAL
> > >> > > > >
> > >> > > > > it would automatically use
> > modbus to read
> > >> an
> > >> > array of two
> > >> > > shorts
> > >> > > > > and to internally convert these
> to one
> > REAL/float.
> > >> > > > >
> > >> > > > > What do you think? I
> think we
> > could
> > >> probably do
> > >> > this in
> > >> > > most
> > >> > > > > drivers.
> > >> > > > >
> > >> > > > > Chris
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > *CEOS Automatización, C.A.*
> > >> > > *GALPON SERVICIO INDUSTRIALES Y
> NAVALES FA,
> > C.A.,*
> > >> > > *PISO 1, OFICINA 2, AV. RAUL LEONI,
> SECTOR
> > >> GUAMACHITO,*
> > >> > >
> > >> > > *FRENTE A LA ASOCIACION DE
> > GANADEROS,BARCELONA,EDO.
> > >> > ANZOATEGUI*
> > >> > > *Ing. César García*
> > >> > >
> > >> > > *Cel: +58 414-760.98.95*
> > >> > >
> > >> > > *Hotline Técnica SIEMENS: 0800
> 1005080*
> > >> > >
> > >> > > *Email:
> support.aan.automat...@siemens.com
> > >> > > <support.aan.automat...@siemens.com>*
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> >
> >
> >
>
>
