Changing $TOOL not working

That does set tool as far as robot is concerned. But this has nothing to with HMI.

In fact tool_data[4[ is simply a variable of type frane, and the line simply copies the value blindly to $TOOL. Beyond that, the index value is lost or not processed in any way.

Also tool_data[] array is not even a system variable... Just like

decl frame my_tool[500]

;

$tool = my_tool[487]

So how is KSS to know what to do with 4 or 487? The answer is simple...it does not so it does nothing.

If you want HMI to display the tool index, you need to write code that does just that if i recall, variable name is $ACT_TOOL

Check punned topic READ FIRST for info on getting documentation...

Second thing is that an ILF always set the tool according to the tool selected in the ILF. When you set $tool and then use an ILF your assignment to $tool is obsolete.

Best choice IMHO is to use BAS(#tool, 4) to set tool no 4, this sets everything like tool, load and the number shown on hmi.

yes.. Bas call is more compact than typing two lines

$TOOL=TOOL_DATA[4]
$ACT_TOOL= 4

or make your own variant, something like

Set_Tool(n:in)
  DECL INT n
  $TOOL=TOOL_DATA[n]
  $ACT_TOOL= n
END

And what about the load data? If there are questions about precision of movements the first question is about load data.

sigh...

that is what inline forms are for. people that do not know enough about the robots should really get someone knowledgeable to do initial commissioning (check supply, power up, use correct MADA, set tools/ bases/loads, configure tech options etc.). only then, those with limited experience may be allowed to modify existing or make new simple programs, and using only inline form instructions.

KRL programming without inline form motions should be left to experts... and experts will know if and when load changed and if that need to be controlled. just because someone selects another tool, it does not mean that load changed. same goes when one is doing calculations involving flange for example. just because i am changing tool data to get TCP where i need it, it does not mean that load carried by robot is any different.

changing $TOOL does not have any effect on $LOAD and the other way around. but the default when using inline form instructions is that selecting tool, also automatically assigns load with same index.

so if inline form motion is using tool 4, it will assign both tool and load, equivalent to

$TOOL=TOOL_DATA[4]
$ACT_TOOL=4
$LOAD=LOAD_DATA[4]

so when robot is used to pick and place parts, one could create two tools,both would have same TCP and orientation, but load data would be different (one is just gripper, the other is gripper with load). one does need to specify load all the time. failure to do so can and will damage the robot.

i have first hand experience with such cases. my favourite is the one where forced to do something that was not meant for and with load not set correctly. after about a year of bleeping messages, that were ignored, motor failed. was replaced, and client wanted explanation for failure. the only thing wrong was that load data was not entered and robot was using factory default (which happened to be a lot, and this type of mistakes are common). year later same thing happened again. this time they did have entered reasonable load data but they changed the programming and failed to use the load data. so robot was still being stressed exactly the same way.

the robot was doing weaving while arc welding huge circular paths. so it was constantly accelerating and decelerating unaware that it is using very wrong load data - that happen to be 175kg dumbbell used in factory stress tests, rather than actually mounted federlight torch (maybe 1kg) . robot was literally tearing itself apart and complaining loudly. but the messages were ignored and both motors were cooked... motors just happen to be one component that failed but everything else was also stressed excessively - cables, connectors, gearboxes, bearings. some of them amy fail and need replacement, others will keep on working while sustaining unreasonable levels of wear.

which is why initial commissioning and correct setup is so important, robot will spend years doing same set of motions over and over and stopping at same few points. so you do not want to let rookies start the robot up or write key programs. they need to start low, take training, tag along with someone experienced, make changes to already good programs, follow good practices until they are up to speed... and there is a lot to learn. for example load is not just the mass of the tooling, it is also inertia. people who do not know how to manually calculate inertia should not be allowed to change load data - they will have no idea if values they are typing in make any sense and their ignorance can literally kill that robot way too soon.

when in doubt, initialize all thing you need yourself - never assume that things may be right...

for example all motion parameters including tool ,load, base, velocities etc should be initialized all the time. but this is one thing that is often skipped, specially when mixing ILF and non-ILF code. so i prefer to keep them separate, not because of me but because i am not sure ho may be the next person to work on it.