Algorithm for Recording Unspecified Number of Points KRC2

When we coat parts, we use a general parametric program that fills in areas of surfaces based on a minimal number of points that are input, defining the part. The information for the definition points is input offline and then the operator goes in, does a "dry run" where he has the tool follow the contours and areas of the parts to verify that the program will overlay all of the areas of the part that need to be coated.

Here's where the problem is:

The program as written offline is routinely not exactly what is necessary to coat the part. The operator sometimes has to modify the definition points by a millimeter or two, or thirty or two tenths. However, most points are correct and do not need to be changed.

What I want to do:

Is there some way of "saving" only the modified points in a .dat file without having to set up every possible point that it could require in advance?

My current thinking for a workaround is this:

The .dat file will have:

DECL E6POS pointMod001 = {x 0, y 0, z etc...}

DECL E6POS pointMod002 = {x 0, y 0, z etc...}

...

DECL E6POS pointMod1000 = {x 0, y 0, z etc...}

This would have an associated (absurdly?) long SWITCH statement in the program that would check for whichever point number is being modified and then either assign the pointModXXX variable to a given value or it would pull the pointModXXX variable and return it to the main program to come up with the correct location.

But there has to be a better way. Or at least I would think so. Ideally, I would want something where if the offline program is correct to begin with and the operator has to make no point modifications, the modification program is nearly empty. But if the operator has to make changes on a hundred different points, then I would like all of those points to be generated/saved/whatever we are calling this operation.

I would want to have an auxiliary program that can be used as a template where it is given the name of the job number and then this can be stored for future reference.

For a little more background, the reason I am wanting this is that we may receive three different shipments from 3 different suppliers that are allegedly the same part, but which are actually different enough through tolerance stackup that they require three different programs to coat all of the areas. All of the parts in each order are close enough not to require changes on any given order, but from one order to the next, there could be some significant changes.

Any thoughts on how to keep something like this down to the most efficient number of lines of code? Or how to have a dat file that only stores the points that are modified?

Thanks for that, panic mode, but unless I'm missing how this information is stored in the system, this will not "save" the values for next time, or to be shared to another robot where I can run the same program on more than one machine at the same time. I am looking for some means of having one robot do the "measuring" and then having other machines also run the program. Will I be able to do this somehow using an array?

Fubini, Thank you - Unless I misunderstood what I was reading (high probability), it does not seem to be what I am looking for.

Currently, I have no problem using one program on three different robots, specifically a KR60, a KR140 and a KR210. I may not have explained my problem very well, so here is an example of what I am trying to do:

If I want to have the program follow the outline of a square, which is what the drawing says I am going to receive from the supplier, I can program that offline and have all three robots pull that program and they will all three do exactly what I want them to do.

However, sometimes when the first operator pulls up the program and does a dry run to verify that it is following the path as required, he finds out that the part is not a square. Instead, it is a trapezoid. Two of the points are exactly where they are supposed to be, but two of them need to be modified.

Note that the operator will set up the coordinate system to align with the part in question at the beginning of each part or each production run, so that is not the issue. It is assumed that this is going to be done each time regardless and this is not where my problems lie.

When the operator goes in to change these two points to modify the program to trace a trapezoid instead of a square, I want to be able to have him save the program back to the server and have all of the other robots follow the new trapezoid.

One thought I had would be to create a structure to store point numbers along with relative coordinate values and then have a subroutine to go through and check for which is the next "available" modification point and have the program make the changes when the operator needs to do so. My .dat file would include this:

STRUC POINTMODTYPE {INT pointNum, REAL x, y, z, a, b, c}

DECL POINTMODTYPE pointMod001 {-1, 0, 0, 0, 0, 0, 0}

DECL POINTMODTYPE pointMod002 {-1, 0, 0, 0, 0, 0, 0}

...

DECL POINTMODTYPE pointMod020 {-1, 0, 0, 0, 0, 0, 0}

This would allow the program to look through to find the first unassigned point modification variable (the first one that is not "-1").

So if the operator gets the trapezoid in the example above, I would have the program work such that after running it and making the changes on, for example, point numbers 2 and 3, the data file would look like this:

STRUC POINTMODTYPE {INT pointNum, REAL x, y, z, a, b, c}

DECL POINTMODTYPE pointMod001 {2, 12.3443, 0, 0, 0, 0, 0}

DECL POINTMODTYPE pointMod002 {3, -3.4231, 4.5549, 0, 0, 0, 0}

DECL POINTMODTYPE pointMod003 {-1, 0, 0, 0, 0, 0, 0}

...

DECL POINTMODTYPE pointMod020 {-1, 0, 0, 0, 0, 0, 0}

Note that the program calculates the pointModXXX variables solely as the amount of deviation from the offline programmed point array, which we might make as an E6POS array that we set up as runPoints[1000].

This way, it would be easily apparent that points had been modified and the program can automatically do a calculation to add these various points into the long array of points that is used for the overall tool path. It also wouldn't require having named variables for each and every point on the path. It would only require enough explicitly-named variables to cover the deviations from the path.

So I know that I can make this algorithm work, but I still don't really like it, as it is not very elegant. I suppose my main question is: is there a way for the system to create new variables or write new lines of something or another for an indefinite amount of data in the .dat file, similar to how it will create new variables if the operator adds a new LIN motion.

I have other needs for this general sort of functionality, such as having something that tells me how many times the program was run and at what time each run was started and how many times it may have been stopped and restarted during a run. Ideally, I would like to be able to store this information in the .dat file, but if there is some other type of file operating functionality that allows this to be accessed in some other location, that would suit me just fine.

Quote

what do you mean by "...will not save the values for next time"? if the array is declared and initialized in the DAT file, it will....

Ok. I had actually tried this some time ago and assumed that this would be how it would be done, but when I had, it kept coming up with errors. I do not remember what those errors had been, but I gave up on it at the time and I'll give it another shot. It still isn't exactly what I am looking for, as I would like to be able to do this with an unspecified number of points or more generally, an undefined amount of data prior to the operator starting the program.

Quote

transferring file from one machine to others will need some manual work (copy/paste) or some sort of messaging between robots etc.

Agreed. Transferring files from one robot to another presents no issues under any of these scenarios.

Quote from panic mode

well... using collection of variants is not possible in KRL.

So just to be clear, there is no way of saving information such as comments or operator selections or time stamps to any file anywhere, whether it is the DAT file or some other file somewhere else?

In other words, is it correct that the only thing that can be done is to have previously-defined variables with their explicit values assigned in the DAT file and then have the KRL modify these?

My original question being this:

Quote from EngineerTex

SUBJ: Algorithm for Recording Unspecified Number of Points KRC2

...

Is there some way of "saving" only the modified points in a .dat file without having to set up every possible point that it could require in advance?

...

I would want something where if the offline program is correct to begin with and the operator has to make no point modifications, the modification program is nearly empty. But if the operator has to make changes on a hundred different points, then I would like all of those points to be generated/saved/whatever we are calling this operation.

Quote from panic mode

your original question is not very clear. the way i understand it so far is that:

you want to create program structure (SRC + DAT), DAT must be initialized... either with some default value of something specific.

then you want to deploy the files to a robot system (or few...)

then you want to have someone step though the code and if needed touchup some nonspecific number of the points (does not matter how many, none or few or all).

this may require running part of the program back and forth to confirm that change is correct. (well... you may also forget about it and simply run entire program every time but that would be far less efficient)

Display More

Yes - I have these elements already, but stepping through the code is sometimes a pain when there is a lot of deviation between the theoretical shape and the actual shape. Currently, the operator can select the "dry run" mode where he steps through the defining points one at a time. If any need to be modified, he has to stop the program, arrow key down to the line where that point is in the program, manually enter the amount that he wants to change and then restart the program and then on to the next point. Fortunately, the "dry run" mode skips all of the movement that fills in the overlay areas between the definition points, but it is cumbersome to make the manual line edits.

Quote

touchup via INLINE form is possible but not reliable (unless you have UserTech and define own inline form). reason is that if you create hacked version of standard ILF, it can be easily messed up using CHANGE option.

i would rather use one of the STAT keys to display own dialog to touch up or not. And it can list the current index, time etc.

Sounds like this may be what I'm looking for. Is there a recommended place to start studying up on this?

Quote from SkyeFire

Tex -- you're generating a program offline and loading it into the robot(s). And you want an operator to be able to adjust certain points. Correct?

Yes.

Quote from SkyeFire

Do you want the operator to be able to use the TouchUp button on the pendant for easy recording?

Possibly so, but I'm not sure what the algorithm would be to make that happen without using the inline forms where it has LIN and CIRC commands. It sounds like panic mode's suggestion of creating my own inline forms may be what is called for here. However, my motion algorithms are such that although I have the points defined, I usually cannot simply use LIN or CIRC or PTP inline commands to define them, as there are obstructions that would cause crashes if the operator simply stepped from the first point to the second point. The square/trapezoid example was a very simple example. (Often, the program will have the robot sitting still for twenty or thirty seconds while the KRC is is performing the calculations to generate the motion path array and then it will be running for 2 - 20 hours based on only a dozen input points overlaid onto a shape definition.) But all of that stuff happens in the background and the operator doesn't need to be concerned with it. I need a more elegant way of getting what I would think is fairly simple information into the program.

Quote from SkyeFire

A 3rd way might be to create a separate executable program that, when run, would stop at each point and offer the operator a pop-up message to update the point or leave it alone. This would work with the "array of points," but would require some careful KRL programming.

This sounds GREAT! It sounds like exactly what I had been hoping to put together, but I am not sure how to take that information, once generated, and have a DAT file that keeps all of this with an indeterminate number of point modification variables. Along with what panic mode suggests, it sounds kinda like I need to get my hands on the UserTech add-on, figure out how to create my own (hacked?) inline forms and/or use STAT button(s) to make a user interface that will modify the DAT file to create new variables and whatnot.

Any direction to literature and information is highly welcome and appreciated.

Quote

And integrating that with your offline program generator might be a bit tricky.

This will not be an issue. The offline program generator is me.

Sincere thanks to everyone on this.