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]
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.
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.
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
Also "MC Continue" reapplies Cycle Start if certain conditions are met!
Thanks for the info selquist. The FS10 is a C controller and the RS010 is an F controller.
OK. The C-controller mfp have an extra column of buttons (compared to a D/E/F-type mfp), so you might need to rearrange a bit, if the mfp is filled. If both pages are in use on the mfp on the old one, you will need to make a few extra buttons for "next page" or "previous page" since there is not a dedicated button for this like on the C-type panel.
Also, I don’t think that the F-controller native have more than 16 In/out, unless it’s fitted with an extra optional IO-board. The C-controller have 0/32/64/96 etc. In/Out normally, depending on the number of IO-boards installed.
I can’t remember if the flange for the tool is different, so maybe you need a new adapter plate or a new mount for the old tool to fit.
I recommend that you get a decent connector-block for the I/O’s instead of trying to solder directly to the 4-layer connector/abomination that it comes with standard.
Something like a Phoenix EAN4046356796606 with the correct cable in between (Think Kawasaki calls them 10-200102L02/L05/L10 where the last two digits determines the length in meters).
Hope it helps.
Is the FS10 a D-controller or a C-controller?
If D, its a lot easier. Btw you only need to re-teach all the positions that are i "joint" since they will be different. All the transformation values is the same... I would convert the "joint" position in the FS10 to transformation, before backing it up, and the convert them back to joint when they are in the RS10. Its a BIG help when re-teaching/fine tuning afterwards...
When changing from D to E, you can take a backup og the old one and delete everything in the file down till the MFP-data. Then you have a copy of MFP, pg's, vars, strings etc. without risking to screw up any robot data.
If the old MFP uses input/output fields with BITS-command, remember that those values is NOT transferred, so screenshot it before changing.
After that you need to check that IO configuration is the same (especially if the old one is with field bus, and not just digital I/O). Take pictures of the signal allocation, to help with this.
Check system switches in "advanced/system switches" and set the ones in the RS that differ from the old.
When going to E-controller, its a good idea to put a TWAIT (like TWAIT 0.02) in every loop: In the autostart's and in you main pg (if there is no job). This will make it A LOT more responsive.
Do it have a lot of PROMPT-menues in the code?
Hope it helps. If it a C-controller, let me know
Also, if you are online in KrTerm you can write: opeinfo
This will give you the same information! Good if you are online via VPN and dont have access to the Teach Pendant.
kwakisaki Yes, fantastic! You are correct! QTOOL is apparently ON in this robot. Though everything is programmed using AS-language, not block teaching. So according to the manual, I must switch it OFF.
We never use block teaching, and therefore have never had the need to work with QTOOL, maybe it has been OFF by default normally, and this robot tricked me by having it ON... Anyway, glad to learn something new today!
In my current application, the operator is allowed to POSMOD/rewrite a position (in TEACH-mode) if he/she is unsatisfied with the current position, but having the TOOL-values disappear randomly made the process unstable and troublesome.... Maybe the real bug is why they did not disappear consistently?
Thanks for the help
I absolutely agree with you on both points. But in all cases I know of, it was done during some kind of rebuild/change to the existing machinery without having to exchange the robot/arm. Moving only upwards in weight, not reducing (which would increase speed). Again, remember, it’s the same robot regardless of the specs-label...
No, Kawasaki does not support this or uphold warranty, but it was Kawasaki that showed us how to do it 
Hi
Thanks for the many hints in all the other posts. What a friendly forum Hope you will help me too.
I have a RS20N that sometimes/randomly (can’t get any logical statistics) resets the WEIGHT and TOOL-values to null, when switching from REPEAT-mode to TEACH-mode. And for the love of everything holy, I cannot figure out why! When restarting the robot in REPEAT-mode, but without any TOOL-values, well.. You can imagine what’s going to happen 
Been programming Kawasaki for the last 11 years not, so this feels almost personal, that I can’t solve it haha...
The controller is fitted with Cubic-S, but we have made no special settings there. The AS/SV versions is ASE_010300X5B/SVE_080000068 so it’s pretty much the latest version.
There are no code anywhere, like in an autostart, that should cause this.
Hope one of you have a good idea. Many Thanks
Its not so strange. Some of the Kawasaki arms share the same mechanical components, where the only difference are the servo parameters.
We have done it a few times at my old company. Switching between ZX130 / ZX200 and RS30/RS50 etc..
Making a ZX130 run like a ZX200 severely changes the servo characteristics, giving it a slower gentler motion. Used when the engineer made the tool way to heavy for the original specs
It is multiplied because it uses the position "start" as a basis every time it shifts row. Not the "put"-position. Se the figure on page "6-54" in the language reference manual.
To make a new layer, you can put everything in a IF THEN ELSE, adding 100mm to the z-value
example
IF layer==0 then
;Calculate the pose for the part in the next row.
POINT put = SHIFT(put BY xs, 0, 0)
END
;
;Calculate the pose for the part in the next column.
POINT put = SHIFT(start BY 0, ys*row, 0)
END
END
IF layer==1 THEN
;Calculate the pose for the part in the next row.
POINT put = SHIFT(put BY xs, 0, 100)
END
;
;Calculate the pose for the part in the next column.
POINT put = SHIFT(start BY 0, ys*row, 100)
END
END
