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.

Solution. Using 32 bits per way instead of 16. No need for Robot PLC.
Manual for FD does not include this command. Manual for CFDs (my controller) includes this.
This solution includes sign bit. Start number 65 is an example of a bit area. 32 is the number of bits.

'PLC value (DINT) to Robot Integer
V%[1] = ISIG2INT(65, 32)

'Robot Integer to PLC (DINT)
INT2OSIG O65, 32, V%[1]