Read 16 input bits to V1% without using internal PLC

Hi guys. I have 4 EZ03V4's, and are new to Nachi but old to other brands...

I wish to avoid using the internal PLC to handle variables (16 bits) and run values from/to the EthernetIP directly in the usertask. Single bits are no problem. Only Byte/Word gives me a headache.

I can use the "Combination Output" O5101 as a 16 bit output together with MULTIM O5101,V1% to write to 16 bits. But the "combination input" combines to logical 1 signal, so i guess, I can’t read the binary value from 16 inputs using this function. Can I even use MULTIM in the usertask?

So how to write a variable to 16 bits in the usertask?
And how to read the value of 16 bits in the usertask? If at all possible... Or am I doomed to use the Internal PLC and subsequent interlock.

Any guide is much appreciated Many thanks in advance

Thanks for that input bsrr. Because of that, I actually found an example in the UserTask-manual on how to read data from bits using the same command. The example uses both 2 decimals and sign bit.:

‘OFFSET
‘X (in the range of I2001 to I2016)
L1% = GETSIGB( 251 , 0 )
L2% = GETSIGB( 252 , 0 ) AND &H7F
L3% = L1% + L2% * 256
L1! = L3%-2*L3%*INP(2016)
V1! = L1! / 10

Now lies the task of testing, which solution is the easiest and fastest to work with In my case, speed is number one priority, but ease of maintainability is on a strong second place.

I plan to clock/time both ways. Using Software PLC (Continuously calling BTOD16 and DTOB16) and without PLC (using UserTask with MULTIM/Combination Outputs and GETSIGB-commands).

Will post result of tests before Christmas Interesting what the fastest way to move data to/from the robot will be. Hope to avoid using the Software PLC (and by it, another layer of scan-time), but if the other solution works out to be cumbersome, it can end that way.

Examples with following settings:
PLC Scan time = 0.5ms
EthernetIP poll/RPI = 5ms
Robot PLC = 5ms
Delay in Usertask = 10ms
No motion running!
Results is each after approx. 20 manually started cycles, logging the maximum response time...

Moving a value in 16 bits (using BTOD16 and DTOB16) from PLC -> Robot PLC -> Usertask -> Robot PLC -> PLC:
-Usertask Priority 4: 210ms
-Usertask Priority 5: 60ms
-Usertask Priority 6: 70ms

Moving values without the Robot PLC in bits from PLC -> Usertask -> PLC:
-Usertask Priority 3: 130ms
-Usertask Priority 4: 60ms
-Usertask Priority 5: 37ms
-Usertask Priority 6: 35ms

Leasons learned so far:
-Handling data through the Robots internal PLC adds a lot of delay.
-Usertask priority, going from default 4 to 5 have enormous influence.