the MSPEC is supposed to be multi-language, so I don’t think java specific
types would go into the file definition, but there might be another way to
do something and have it generated correctly
On September 11, 2020 at 17:05:06, Ben Hutcheson (ben.hut...@gmail.com)
wrote:
Hi,
After creating a
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
hutcheb commented on pull request #186:
URL: https://github.com/apache/plc4x/pull/186#issuecomment-691032464
Hi Niclas,
The plan is to add support for as many IEC 61131 data types as possible.
I've added DINT as an example for what it would take to add additional data
types but
Hmm ... I usually always hit reply ... but I have seen some times the email
just goes to the sender ... strange ...
This time it didn't ...
Am 11.09.20, 09:30 schrieb "Julian Feinauer" :
Forwarding it tot he list (i think chris simply hit reply...) : )
Am 11.09.20, 09:27 schrieb
Forwarding it tot he list (i think chris simply hit reply...) : )
Am 11.09.20, 09:27 schrieb "Christofer Dutz" :
And my only concern about native-drivers is that I want to prevent us from
becoming lazy.
I know we had the EIP and Modbus drivers by using external libs and that
wasn't
Forwarding it tot he list (i think chris simply hit reply...) : )
Am 11.09.20, 09:22 schrieb "Christofer Dutz" :
Hi Julian,
I think a "native-drivers" might be a good approach. But if they should
live outside of the sandbox, I would have to insist that who adds something
like that,
Hi folks,
thanks for all the replies and the controversy in here shows that ist good to
discuss the matter, indeed : )
I like Cesars way of putting it (which is pretty close to mine) that PLC4X is a
unified API.
This is the Killer thing here.
And what we currently do and mostly did was "PLC4X
