[DavidG]

Hi,
I am using the customisable section of the robot driver:

Code:

CASE 13
;----- Run program COM_VALUE1 ---------
; (to trigger from RoboDK: use robot.RunCodeCustom("program id", INSTRUCTION_CALL_PROGRAM)
program_id = COM_VALUE1

As Albert suggested to me I am using the program id to transfer data to the robot controller (Related thread), thanks again for that clue. Unfortunately there seems to be a limit for the program id. Here is my code snippet:

Code:

if len(sys.argv)>1:
ExtValue = float(sys.argv[1])

if ExtValue != 0:
ExtInt = int(ExtValue*1000+20000000)
ExtProgID = str(ExtInt)
机器人。RunInstruction(ExtProgID, INSTRUCTION_CALL_PROGRAM)

[url=//www.sinclairbody.com/forum/Thread-Python-Specific-post-processor-and-run-mode-for-machining-project][/url]

Basically, if I use something like
机器人。RunInstruction('Program 20', INSTRUCTION_CALL_PROGRAM)
everything works fine. But if I try to pass on a much bigger value like
机器人。RunInstruction(200000年”计划0', INSTRUCTION_CALL_PROGRAM)or (as in my actual application)
机器人。RunInstruction(200000年”计划00', INSTRUCTION_CALL_PROGRAM)
the robot controller receives either 0 or something useless, the response is odd. I checked the data types on the robot side to see if it can handle the value, but KUKA integers can handle 2^31-1.
Do you have an explanation for that issue? Does RoboDK have a limit here?

[DavidG]

Here is a minimum working example for my problem. The RDK project is attached, the relevant section of the robot driver looks like this:

Code:

CASE 13
;----- Run program COM_VALUE1 ---------
; (to trigger from RoboDK: use robot.RunCodeCustom("program id", INSTRUCTION_CALL_PROGRAM)
program_id = COM_VALUE1
SWITCH program_id
CASE 1
$ANOUT[20] = 0.01

CASE 12
$ANOUT[20] = 0.02

CASE 123
$ANOUT[20] = 0.03

CASE 1234
$ANOUT[20] = 0.04

CASE 12345
$ANOUT[20] = 0.05

CASE 123456
$ANOUT[20] = 0.06

CASE 999999
$ANOUT[20] = 0.07

CASE 1000000
$ANOUT[20] = 0.08

CASE 1000001
$ANOUT[20] = 0.09

The program id that is to be called has to be edited manually in the python script. The routine works fine up to a program id of 1000000 (including).
If I call

Code:

机器人。RunInstruction('Program 1000001', INSTRUCTION_CALL_PROGRAM)

I get no response from the robot controller.

[Albert]

You can see that COM_VALUE1 is defined as a REAL (KUKA KRC type of variable). This means it is a floating point variable (32 bits). This type of variable can hold 6 up to significant digits:
https://en.wikipedia.org/wiki/Single-pre...int_format

However, you can take advantage of the decimal values and pass additional information if required (no need to multiply your value.

RoboDK was rounding the value to the nearest integer but we've updated RoboDK to allow passing decimal values for a function call (latest version required). I recommend you to update RoboDK and use floating point values. Even if RoboDK will remember a 64 bit double, the KUKA controller will receive a 32 bit floating point value.

[DavidG]

Hi Albert,
thanks a lot for solving this puzzle. I really did not see that I am dealing with floats here.

The reason why I used this procedure

Code:

(Value*1000)+20000000

is becauseValuehas a format like 'x,xxx.xxx'. Multiplying it with 1000 gives an integer value <10,000,000. I created two different programs inside the robot driver. To decide which program should be excecuted I either add 10,000,000 or 20,000,000 to my integer value and us it as a program id. So, if my program id is somewhere between 1E7 and 2E7, program 1 is excecuted. For a program id between 2E7 and 3E7 program 2 is excecuted. That is kind of a bad style but I did not see another way to pass a value and an identifier for the program with only one argument.
Maybe it would be a nice and powerful feature if you could change the structure of the program call to something like:

Code:

机器人。RunInstruction('program id','optional argument',INSTRUCTION_CALL_PROGRAM)

Don't get me wrong, I think I am all good with the solution at hand, so I do not want to be greedy. Please consider this as a feedback or as a suggestion for a future update.
Thanks for your great support.