Hey Darren,
you can find a example here:
https://github.com/apache/plc4x/blob/develop/protocols/bacnetip/src/main/resources/protocols/bacnetip/bacnetip.mspec#L1262
and here:
https://github.com/apache/plc4x/blob/develop/plc4j/drivers/bacnet/src/main/java/org/apache/plc4x/java/bacnetip/readwrite/utils/StaticHelper.java#L38
- Sebastian
On 2022/03/03 23:36:21 Darren Everley wrote:
> So I've been doing some further digging around to try and understand more
> about the MSpec code generators and I think my initial feelings about how
> to tackle this issue has evolved.
>
> I'm now thinking about modifying the XSLT to generate a different MSpec
> file that will change the type of the 16-bit float from this:
>
> ['DPT_Value_Temp' REAL
> [simple float 16 value]
>
> ]
>
> to something more like this, once I understand what needs to go into the
> expressions....
>
> ['DPT_Value_Temp' REAL
> [manual float 16 value '{serialization-expression}'
> '{deserialization-expression}' '{length-expression}']
>
> ]
>
> So now my plan is to dig around for some examples of manual field type
> definitions and seek inspiration. If anyone has any interesting/useful
> examples thereof that thye would like to point me at them I'm all ears.
>
> Darren
>
>
> On Tue, Mar 1, 2022 at 11:21 PM Darren Everley <
> [email protected]> wrote:
>
> > Hey Chris,
> >
> > When I say two implementations; what I mean is that the KNX spec has two
> > distinct 16-bit float formats, used seemingly by different equipment
> > vendors (!!?!). So we need a discriminator to route to the appropriate
> > decoding method. One of these is KNX specific as far as I'm aware.
> >
> > For example in the following sample of generated code, the generated
> > readFloat method needs to be able to discriminate the correct underlying
> > data type, one of which is like I said; KNX specific.
> >
> > } else if (EvaluationHelper.equals(datapointType,
> > KnxDatapointType.DPT_Value_Tempa)) { // REAL
> >
> > // Simple FieldA (value)
> > Float value = /*TODO: migrate me*/ /*TODO: migrate me*/
> > readBuffer.readFloat("", 16);
> >
> > return new PlcREAL(value);
> > }
> >
> >
> > So I believe a the tasks required to get this done are as follows;
> >
> > 1. update to the XSD that generates the MSpec (is that correct?). XSD is
> > not really my forte, so perhaps you could help here?
> >
> > 2. update needs to be made to the parseFloat method of ReadBufferByteBased
> > to handle the additional KNX format. This smells bad, as this is KNX
> > implementation details leaking into common code. So any thoughts you have
> > on how to tackle this would be helpful? Perhaps this type of issue has been
> > encountered on other protocols and there is an existing pattern to be
> > replicated? I will then be able to go ahead and implement the necessary
> > changes.
> >
> > 3. then 'finally' the Freemarker template for java code generation
> > (data-io-template.java.ftlh) will need to be updated to 'route' to the
> > appropriate 16-bit float format as implemented in the step above. I will
> > take care of this also.
> >
> >
> > I hope all that makes sense for a relatively late night brain dump!
> >
> > All the best
> >
> > Darren
> >
> >
> >
> >
> >
> > On Tue, Mar 1, 2022 at 11:00 PM Christofer Dutz <[email protected]>
> > wrote:
> >
> >> Hi Darren,
> >>
> >> I have also noticed that my original implementation doesn't accrually
> >> work. So we need to generally fix this. I don't think we need two
> >> alternative implementations, but we need to fix the one we have :-)
> >>
> >> If you've got an idea on how to do that, I'm Haus to help.
> >>
> >> Chris
> >>
> >> Holen Sie sich Outlook für Android <https://aka.ms/AAb9ysg>
> >> ------------------------------
> >> *From:* Darren Everley <[email protected]>
> >> *Sent:* Tuesday, March 1, 2022 11:40:18 PM
> >> *To:* [email protected] <[email protected]>; Christofer Dutz <
> >> [email protected]>
> >> *Subject:* KNX: DPT_Value_Temp aka that 16-bit float with 'special'
> >> encoding
> >>
> >> Hi Chris/All,
> >>
> >> I've been digging around in the KNX code generation areas for the
> >> aforementioned data type; DPT_Value_Temp and it's brethren. So I can see
> >> how the code generators work by driving a 16-bit float to be decoded as a
> >> 'half-precision' IEEE value, via the readFloat method of the
> >> ReadBufferByteBased class.
> >>
> >> Now, with this additional and alternative 16-bit float implementation
> >> needing to live alongside the existing, perhaps it's best to have a
> >> discussion on the most prefered approach for handling this as it seems,
> >> from my fresh and naive perspective, that changes need to be made to the
> >> ReadBufferByteBased class and this will affect a whole bunch of other
> >> modules.
> >>
> >> As always, I'm more than happy to make the required changes here, but
> >> would like some advice from the more experienced developers on this project
> >> before wading in.
> >>
> >> Many thanks
> >>
> >> Darren
> >>
> >>
> >
> >
> >
>
> --
> *Darren Everley - Director*
>
> *Email: *[email protected] *| Mobile:* 07891405262 *| Website:*
> www.xeropoint.co.uk
> *Company: *Xeropoint Ltd. Registered in England and Wales. 11101907
> *Address:* Henleaze House, Harbury Road, Bristol, BS9 4PN
>
