Axioline Read Bitstring16 to Number

PLCnext Technology & PLCnext Controls
1

Hello, I am reading an AxioLine Bus like here: https://github.com/PLCnext/SampleRuntime/tree/master/getting-started/Part-03 but not the Digital Value, instead Analog IN (Arp.Io.AxlC/0.IN02). From the tic-file I can see the value is a Bitstring16, Length: 2. How do these two bytes encode the value at that port? Is there a place I can get that info from? Reading it as an uint16 gives nonsensical values. Best, Soeren

2

Hi Soeren, The data sheet for the analog input module you’re using should have a table something like this: 17 12 2019 19 07 32 Does this make any sense of the values you are seeing? ~ Martin.

3

Hello Martin, it brings me closer, but the values still make no sense. I can see them in PLCNext Engineer, where they make sense, but not when I read them via the runtime app. Is it maybe the 30 Hz Filter which is configured on the channel? What is plcnext engineer doing with the 2 Bytes from read to casting it to an UINT? Or is there maybe a bug in the code on how i read the 2 Bytes? In short, I am following those steps: uint16_t value = 0; readInputData((char*)&value;, sizeof(value)); ArpPlcIo_GetBufferPtrByPortName(…) ArpPlcGds_GetVariableOffset(…) char* readDataBufferPage; ArpPlcGds_BeginRead(…) char* dataAddress = readDataBufferPage + offset; memcpy(pValue, dataAddress, valueSize); The value also changes when I trigger sensorvalue changes, but not like in plcnext engineer. Increasing the sensor input lets the value jump around. If the sensor value (20 mA) is reached, plcnext engineer displays 32xxx. The value read from memory sometimes gets larger than this (up tp 65xxx). Best, Soeren

4

Hi Soeren, The filter on the input channel won’t make a difference, the filtering is done in the Input module before the value gets put on the Axioline bus. You should be reading the same or a similar value to what you see in PLCnext Engineer. A couple of things to check -

                                               * You're using an unsigned int in C++, but you can see from the table that the decimal values are signed integers. Please try using `int16_t` instead of `uint16_t`.
                                               * I can never remember the byte order for these 16 bit values - if you look at the `int` values in hexidecimal, you might be able to tell if the byte order is reversed - the lower order byte should be changing faster than the higher order byte as the analog input value changes.

~ Martin.

5

Thanks, the byte order was the problem! Working as intended now. Thank you very much for the help. Happy Holidays!