Update 2:
I created a new project, imported hardware config from old project, imported Config and KRC of the old project, hoping this would copy also the invisible $OPERATE.dat file. Unfortunately, even this method brought no luck.
I ran out of ideas for now, if anyone has other possible solutions I'm open to suggestions.
Posts by LowerCaseDream
-
-
Update: I just created a project with the robot which is present in Officelite's WorkingProject and used the proposal configuration with fewest changes. When I generated the code the OPC arrays were still present... At this point it seems that generating the code as soon as you make a configuration is just something you shouldn't do?
-
- the picture of your options isn't available. Attach it correct.
- only suggestion: it seems that you are missing the opc option on your office lite.
You can try to install it from the older robot, if you have the option files from that robot.
- if the project really uses the opc option, you need to install the option.
- one possibility would be to copy the program files manually into the new project, compare the system files of old and new project and copy relevant parts line by line. Export/import things like I/o and safety coniguration. This is the way I have done it most time, and it always worked for me.
Hi hermann , thanks for answering.
- I reuploaded the picture, hopefully is visible now.
- I just now did the following:
- Create new project, set firmware (8.6.2) and outputs (8192).
- Add robot (KR 180 R3500 ultra K) and its configuration.
- Configure EtherCAT communication.
- I generated the code.
As soon as I generated the code I checked in the KRC:\Steu\Mada\$custom.dat file and saw that the OPC_PAR_---_T arrays were created.
I then restarted the project from zero, added only the robot with its configuration (Power Pack, Servo Pack...) and generated the code. Again, in the KRC:\Steu\Mada\$custom.dat file the arrays OPC_PAR_---_T were created.
Third attempt: project from zero, set firmware (8.6.2) and outputs (4096), added the robot (KR 180 R3500 ultra K) and choosed the configuration with the fewest changes, generated the code. Sure enough, the $custom.dat file showed the same problematic arrays.
At this point it seems clear to me that those types definition is not related to Officelite, but to the robot itself. But now I wonder: if this depends on the robot, why do I have those errors even when importing the hardware configuration of the old project (which has those OPC_PAR types defined in its KRC:\$OPERATE.dat)? How is this KRC:\$OPERATE.dat file generated?
I hope what I'm writing it's clear enough by the way, I'm trying to explain at the best of my capabilities. -
Hi everyone. I'm very new to the KUKA world, so sorry if the following are some trivial questions but I can't solve this problem even after reading a lot of KUKA documentation.
I need to import a real cell in a virtual environment. To do so I need to take an existing robot solution developed on a controller with firmware 8.5.8 and make it compatible with Officelite 8.6.2 (which is our version of Officelite).
The following option packages where part of the original project:Of these Option Packages only the LoadDataDetermination has copatibility with KSS 8.6.2, so I kept that one.
The first thing I did was exporting the partial solution of the original project with all the hardware and importing it on the controller running 8.6.2 firmware. The configuration appears to me to be identical.
However, when I generate the code, I obtain a KRC/STEU/Mada/$custom.dat file with errors within it:Code
Display MoreDECL OPC_PAR_INT_T $OPC_PAR_INT[32]; $OPC_PAR_INT[1]={NAME[] " ",DESCRIPTION[] " ",PAR_INT 0,PAR_ID 0}; $OPC_PAR_INT[2]={NAME[] " ",DESCRIPTION[] " ",PAR_INT 0,PAR_ID 0}; DECL OPC_PAR_REAL_T $OPC_PAR_REAL[32]; $OPC_PAR_REAL[1]={PAR_REAL 0.0,NAME[] " ",DESCRIPTION[] " "}; $OPC_PAR_REAL[2]={PAR_REAL 0.0,NAME[] " ",DESCRIPTION[] " "}; DECL OPC_PAR_STRING_T $OPC_PAR_STRING[32]; $OPC_PAR_STRING[1]={PAR_STRING[] " ",NAME[] " ",DESCRIPTION[] " "}; $OPC_PAR_STRING[2]={PAR_STRING[] " ",NAME[] " ",DESCRIPTION[] " "}; DECL OPC_PAR_BOOL_T $OPC_PAR_BOOL[32]; $OPC_PAR_BOOL[1]={PAR_BOOL FALSE,NAME[] " ",DESCRIPTION[] " "}; $OPC_PAR_BOOL[2]={PAR_BOOL FALSE,NAME[] " ",DESCRIPTION[] " "};
Even though I copied 2 initialization for each array, all the 32 elements of each array are initialized as described above. This code generates errors since the types
$OPC_PAR_----_T aren't defined.
I checked in the original project and these types (or structure, more precisely) are defined in a KRC:\$OPERATE.dat, which is a write-only file which doesn't appear in the file tree.
Since I couldn't include almost any of the optionals which where in the original project, I thought that was the reason those types are missing in my solution. Also, I did not configure the KUKA Safe part, while this was done in the original project.
I could try to eliminate those lines of code and get rid of the errors, but I've been trying to modify system .dat files for a few days now and figured out it only brings problem if you don't know what you are doing.
I would like to add that in the KRC/STEU/Mada folder there's a $machine.dat file which I have no clue from where it comes from.
My final attempt was:
Creation of a copy of the 8.6.2 project with imported hardware configuration, deletion of the files .dat which would be generated with code + the mysterious $machine.dat file in the STEU/Mada folder, generation of code. Unfortunately I tried to upload this on Officelite but everytime I received different error message and, in the end, Officelite collapsed.Finally, what do you suggest I should do now? What would be your way of updating an old project to make it compatible with a newer version of the KSS?
Also, after each of my attempts, Officelite always gave me some warnings, but I'd tackle that problem once I don't have any coding error in my files... -
you probably have issue with READ, MOVE, OPEN, CLOSE
change their names and see if it works
Hi panic mode , thanks a lot for the help.
Was just trying cancelling those words one by one. Apparently MOVE, OPEN and CLOSE are the reserved keywords you need to avoid using in structure, while READ doesn't give me any error. -
Hi hermann,
Thanks a lot for the suggestion, will take a look into it in a second and try to eliminate each word until I find the one (at work I tried to take a look at the column-pointed word, but didn't seem to be the right one...)
Will also search a list of this reserved keyword, in the document I looked there's only a small list used as an example of the most important ones.
Thanks again! -
Officelite: KSS 8.6.2
WorkVisual: 6.0.26
This one should be pretty quick, but I can't wrap my head around it.
This is the code:CodeGLOBAL STRUC T_CARR_POS_PAR E6POS APPR, READ, PREL, DEP, MOVE, E6AXIS XAPPR, XREAD, XPREL, XDEP, XMOVE, FRAME SCAN, OPEN, MIDDLE, CLOSE, PREL_OFFSET, DEP_OFFSET, CurrentPlane, InfPlane, SupPlane, BasePlane
It's a single structure composed by E6POS elements, the relative E6AXIS elements and finally some FRAME elements.
If I write this in a .dat file on WorkVisual no error is given. However, when the project is uploaded on Officelite, I receive this:
Error no. 2327 Type Expected.
I also defined a different structure with only E6POS variables and it works fine. The above-defined structure is, with many other, part of a bigger structure, but this is the only one which causes error.
Thanks for any help! -
put a lot of CONTINUE commands first
Do you mean before the "WAIT FOR" instructions? Or are there other instructions that would block the advance run?
-
Hi everyone, I'm doing my thesis work which consists on programming on WorkVisual. However, I don't have a copy of Officelite, so I can't try my code out. Basically I want to create a spline block and, while executing it, I want to execute a subprogram which involves ASYPTP. Here's the idea:
Code
Display MoreGLOBAL DEF Function() TRIGGER WHEN PATH = 20 DELAY = 0.0 DO AsynFunc() PRIO = -1 SPLINE SLIN MoveUpZ TRIGGER WHEN DISTANCE = 0 DELAY = 0.0 DO BAS(#VEL_CP, NewVel) PRIO = -1 SCIRC Rotate_1, Rotate_2 TRIGGER WHEN DISTANCE = 0 DELAY = 0.0 DO BAS(#VEL_CP, OldVel) PRIO = -1 SLIN MoveDownZ ENDSPLINE WAIT FOR Done ;proceeds with another movement END GLOBAL DEF AsynFunc() output_open_clamp = TRUE WAIT FOR input_clamp_open output_open_clamp = FALSE ASYPTP XMoveClamp output_close_clamp = TRUE WAIT FOR input_clamp_open output_close_clamp = FALSE Done = TRUE END
Variables input_ and output_ are exchanged via Ethercat with a PLC and the exchange is done within sps.sub.
Will this work or it's better to create a .sub code? Is "AsynFunc()" completely independent by the "main" code in "Function()"? Is the movement going to be fluid or not?
And finally, do you have any suggestion on how I should write my code in case this doesn't work?
Thanks in advance to whoever takes the time to answer!