KRC 2 Velocity of motion lines are not being updated in .dat file

Quote from deadlyrefuge

I have tried using the CHANGE softkey to change the velocity, but that doesn't work.

"Doesn't work" how? Details matter. Does the Change button just not do anything? Does the ILF open up? If/when you try to make the change and hit OK, do any messages show?

Are these ILF points created using the Move menu option? Or was this program copied into the robot from somewhere else?

Regardless, the PDAT.VEL and LCPDAT.VEL values in the .DAT file are irrelevant for ILF motions. The BAS call inside the Fold is what matters:

;FOLD LIN P3 Vel=0.1 m/s CPDAT2 Tool[3]:HVOF 8 Base[4]:MPBP Square 2;%{PE}%R 5.6.13,%MKUKATPBASIS,%CMOVE,%VLIN,%P 1:LIN, 2:P3, 3:, 5:0.1, 7:CPDAT2
$BWDSTART=FALSE
LDAT_ACT=LCPDAT2
FDAT_ACT=FP3
BAS(#CP_PARAMS,0.1)
LIN XP3 
;ENDFOLD

The red value you enter in the VEL box of the ILF is (or should be) written into the (also red) value in the BAS call. And that value is what normally sets the motion velocity, not LCPDAT2.VEL

First thing to check: if you use the Change button, does the value in the BAS call change? If not, something may be broken in your ILF, which is... not good. Second, if the BAS call value does change, but the robot still moves at max speed, that suggests something has been modified in BAS.SRC.

just to be precise - what was shared is actually content of the files, and not the actual files. and the shown content is also only partial. actual files would have more info - they would show header before DEF line as well as file attributes. if the files attributes are not correct (read only), it is still possible to open or select the module but not edit it.

my suggestion is to always describe problem in such a way that others could reproduce it. in this case that would include user level, operating mode, how the module is accessed exactly (opened or selected), list any messages before and after attempt to edit, show operating mode, etc. i know that it is hard to think everything that others may ask for so perhaps a video clip or few pictures could help.

Quote from deadlyrefuge

The velocity that we have set in those motion lines is not updated into the .Dat file.

those are inline form motions. velocity is set in the SRC file and some of values in DAT file are simply not necessary.

if you look inside inline form of any motion, you will see that programmed speed is set just before actual motion (PTP or LIN) by calls to BAS module. to see what is going on you need to check BAS.SRC.

BAS(#PTP_PARAMS,50) ; sets PTP velocity to 50%

inside BAS.SRC you should see something like:

so when using #PTP_PARAMS, internally there are three subroutines that get called and the last one is VEL_PTP(50) that sets velocity to 50% (REAL_PAR gets value from your program)

BAS(#CP_PARAMS,0.1) ; sets CP velocity to 0.1m/s (LIN and CIRC)

like above here the last subroutine is VEL_CP(0.1)

after that instruction pointer returns to your SRC file and executes next line of program which is motion... velocity values in DAT file are ignored and it turns out - in your version of KSS, editor does not bother to update them in the DAT file

you are welcome

btw as far as i can tell this is not common. if my memory is any good, editors usually do update things in the DAT file too. that is at least the case in everything i recently checked out. but there are some version differences and when replying i used screenshots from BAS.SRC that is similar vintage as yours. this is just to show that details do matter. i am not telling forum members to share details because i am trying to show of or intimidate. there are simply too many things to think of and very often things come down to something that was misunderstood. when i read (skimmed) your first post, it sounded like inline form editor was crashing or maybe failing to update value or that program was possibly executing at different velocity than programmed. i did not realize that program was ok but the concern in question was simply the non-changing value in DAT file (and that is not expected for me as well )

Also shame on all KUKA customers that want to have backward compatibility for way back . That's the only reason why its not removed. Actually removing it would be quite simple for KUKA. but you would not be able to easily port from controller A where dat-file VEL exists in the struct to controller B where its already removed in the structure declarations. In the past when something similar was done the cry out of important customers was so big that KUKA learned to avoid to get himself in such situations.

Another strong argument to not change stuff like this is the following:
The structures you are referring to in the dat-file are intended to be used together with inline forms and therefore addresses people who do not care how internally inline forms are working because they use the HMI GUI menues anyway for their programming as intended by KUKA for this type of users. So they do not need to understand whats going on behind the scenes to get their job done. As said before the robot behaves exactly as expected when using inline forms. The confusion only sets in for the small amount of users that want to use inline forms but also want to understand the behind the scenes. So basically "experts" of some kind. If you would remove the VEL structure you would make the "problem" a concern not only for a few "experts" but also for the vast majority of GUI programmers who do not bother about this stuff as well. And then these would also have to deal with the above mentioned compatibility issues.

Fubini

Yes, of course the backwards compatibility, but somewhere there must have been a break of it. As the structure is existing, and so you can think that it was used in former days. Then someone decided to do it different, that was the mistake. But that's history, we have to deal with it, and so there will be some more Kuka users that will fall into that trap .