Posts by roho76

Thank You for your reply.

I'm referring to the tool that is swapped out on the turn table. The water jet nozzle (TCP) remains the same regardless of parts. They have about 40-50 different parts that they cut on this system and it could be on either side of the turn table on either booth. We are cutting fiberglass. I understand shoring up the reliability of the turntable is optimal but the customer doesn't want to spend that kind of money. Dumb of them, I know. So I was trying offer a solution to mitigate downtime as much as possible. If I could develop a method of touching both sides of the (X) and (Y) side of the whatever tool they are running with the water jet nozzle to shift and rotate my frame that would be ideal.

Hello,

I'm working on two separate WaterJet systems with two wall mounted Fanuc M-20iA robots. One booth has R-30iA controllers and the other has R-30iB controllers.

Both booths have turn tables that aren't repeatable and customer is not interested in fixing underlying problem so I'd like to try a different approach. When they swap out tools for different parts we always have to touch up the programs as they are usually a couple of millimeters off in both (X) and (Y) and most of these parts have 50 plus features that are being cut out. This is incredibly time consuming and with 2-3 swaps per 24 hour period on both sides of both booths this leads to substantial downtime. Only one frame is being utilized regardless of the part that we are running. They have routines for calibrating TCP but I was wondering if I could use this same method to update my user frame after tool swap to shift my programs into position to avoid doing touch ups? I've used touch sense before on mig welders but this is a water jet and that technology can't be used. I'm assuming this would utilize motor torque feedback as a sort of "touch sense" method like in the TCP_CAL subroutine. I've only used this method once to load a randomly picked metal dowel into a hole until it bottoms out. I would assume I could use the TCP_CAL style method to update my frame in the same manner as it works on the TCP_CAL.

Has anybody written a routine that does this? Does anybody have an example program I could look at/use?

Thank You

I can open .rspag files without issue so far. It's .rssln files that I'm having an issue with.

Quote from saberlars

when create "Virtual Controller" by "Installation Manager" (Create from Backup files),

that VC working fine?

If that created VC working, robotstudio's intergrity ok

> Project file problem

If created VC not working or similar error message appear again

> robotstudio broken. Recommend clean install robotstudio apps.

Display More

I created a VC from scratch and it works. The file that I had problems with was opening just fine on another persons copy of RS but not mine for some reason.

Where would I look in the files for issues to resolve inability to open?

Thank You

Hi all

I'm having a problem when trying to open a project in robot studio. It says "RobVC::Launch: vcrunLoadSystem returned -2147024893".

When I click OK it prompts another window that says "There was a problem starting the virtual controller".

Other people I'm working with can open the file without issue so I don't think there is an issue with the file itself.

I've tried robot studio 2021 and 2022 to open the file to no avail. I've also downloaded the add in robotware versions that should make it work.

Any clues as to what the problem could be? Any help would be great. Thank You in advance.

Quote from Alexandru

Ok, now i have seen, but now you have 8 grippers, so you need to add 2 signals more

IF SIG(1015,1016,1017,1018,1019,1020,1021,1022) THEN

n_pick_failed = 0

ELSE

n_pick_failed = 1

GOTO exit_routine

END

The numbers are already set in the init_vars, but i usually work with array indexes, for example

di_bat_pres[1] = 1015

di_bat_pres[2] = 1016

....

....

di_bat_pres[8] = 1022

and you can check in the load_cells or pick_cells programs like this:

For .i = 1 TO 8

IF SIG(di_bat_pres[.i]) == TRUE) THEN

n_pick_failed = 0

ELSE

n_pick_failed = 1

GOTO exit_routine

END

END

Display More

Nice! I'm going to use that for checking part presents. For the moment we've reverted back to 6 cell because the load tray wont stay put on the pallet. Much engineering needed lol. But the 8 cell program looks for all 8. I'm going to use your code to do the part check. Thank You for that.

Quote from kwakisaki

Good to know and glad you've managed to get a result.

Yes, Alexandru and I were chatting offline about it and the initial code is 'way OTT' for a fixed position application.

This is why I think you have some 'misleading complication' in the calculation routines which for a fixed position application, shouldn't be in there.......and when it comes to a simple modification like yours, it overcomplicates it further.

If you get chance, have a look in the AS Manual in the Sample Programs section.

You will see a very 'basic example' which pretty much reflects your application (IMHO) and you'll see the comparable difference between that and yours.

Display More

I actually seen that the other day when I was thumbing through the AS manual. I plan to make this much more clean and user friendly soon. I've given myself a crash coarse in AS and Kawasaki this weekend. It's becoming mush more clear what I need to do. Thank You for all your help.

Quote from Alexandru

Thank you for the feedback. It is good that you managed to change the programs.

Also in the program plc_load_cells or plc_pick_cells you dont check if the robot picked properly all bateries. The code exists, but it is commented, for example this:

;IF (SIG(di_bat_1_pres)==TRUE) OR (SIG(di_bat_2_pres)==TRUE) OR (SIG(di_bat_3_pres)==TRUE) OR (SIG(di_bat_4_pres)==TRUE) OR (SIG(di_bat_5_pres)==TRUE) OR (SIG(di_bat_6_pres)==TRUE) THEN ;OR (SIG(di_bat_7_pres)==TRUE) OR (SIG(di_bat_8_pres)==TRUE) THEN ;Check to make sure there are no batteries present

; n_pick_failed = 1

; GOTO exit_routine

;ELSE

; n_pick_failed = 0

;Do Nothing

;END

; in front of the line means that the code is commented. What kind of batteries does the robot handles?

Display More

I actually check it in the pick_cells and load_cells routine. There is definitely some clean up that needs to happen.

Quote from kwakisaki

A very simple test program, you can write to evaluate your positions.

Just by extracting what is used in plc_pick_cells program for the motions.

This same principle can be applied to the plc_load_cells too.

You could then use Teach Mode and Check ALL positions independently.

(I am assuming you understand the code below and already conversant with Kawasaki Operations).

For example your taught position x_xfer_pallet[1] can be tested simply by using the following extraction from plc_pick_cells into a separate program:

POINT x_pick_appro1 = TRANS(-2.5,0,-50,0,0,0); Approach 1 offset

POINT x_pick_appro2 = TRANS(0,0,-5,0,0,0); Approach 2 offset

POINT x_pick_depart1 = TRANS(0,0,-25,0,0,0); depart from pick offset

POINT x_pick_z_adjst = TRANS(0,0,r_z_ht,0,0,0); RISKY height offset set by the IF Panel Input button

JMOVE x_pick_z_adjst+x_xfer_pallet[1]+x_pick_appro1; Joint move first approach to location [1]

LMOVE x_pick_z_adjst+x_xfer_pallet[1]+x_pick_appro2; Linear move second approach to location [1]

LMOVE x_pick_z_adjst+x_xfer_pallet[1]; Linear move to actual pick position [1]

LMOVE x_pick_z_adjst+x_xfer_pallet[1]+x_pick_depart1; Linear move to depart from pick position [1]

JMOVE x_pick_z_adjst+x_xfer_pallet[2]+x_pick_appro1; Joint move first approach to location [2]

LMOVE x_pick_z_adjst+x_xfer_pallet[2]+x_pick_appro2; Linear move second approach to location [2]

LMOVE x_pick_z_adjst+x_xfer_pallet[2]; Linear move to actual pick position [2]

LMOVE x_pick_z_adjst+x_xfer_pallet[2]+x_pick_depart1; Linear move to depart from pick position [2]

JMOVE x_pick_z_adjst+x_xfer_pallet[3]+x_pick_appro1; Joint move first approach to location [3]

LMOVE x_pick_z_adjst+x_xfer_pallet[3]+x_pick_appro2; Linear move second approach to location [3]

LMOVE x_pick_z_adjst+x_xfer_pallet[3]; Linear move to actual pick position [3]

LMOVE x_pick_z_adjst+x_xfer_pallet[3]+x_pick_depart1; Linear move to depart from pick position [3]

|

|

|

|

|

JMOVE x_pick_z_adjst+x_xfer_pallet[27]+x_pick_appro1; Joint move first approach to location [27]

LMOVE x_pick_z_adjst+x_xfer_pallet[27]+x_pick_appro2; Linear move second approach to location [27]

LMOVE x_pick_z_adjst+x_xfer_pallet[27]; Linear move to actual pick position [27]

LMOVE x_pick_z_adjst+x_xfer_pallet[27]+x_pick_depart1; Linear move to depart from pick position [27]

Display More

There is a test portion of the teach_pts routine that verifies your locations after touch up. I usually go in and change the reference numbers to the positional data to check more pick/drop locations.

Thank you. Both Kwakisaki and Alexandru. I ended up figuring it out Wednesday and everything that Alexandru posted is pretty much what I changed with the exception of the FOR loop. I'm only executing that code once instead of doing it in a loop for 1 iteration.

All my positions then worked out. I'm going to change the load and transfer count code here in a second. My main objective was getting the pick and drop positions working since they started production a day sooner than expected.

I appreciated all you're help. Much appreciated. It's so amazing that this group exists and it has some of the best people to interact with.

Quote from kwakisaki

I get the impression this sequencing was not written specifically for this application as I am 'sensing' this is from something else which possibly had a vision camera sending coordinate data instead.

If the parts are being presented in a guaranteed position each time (this is what I am assuming and IMHO), there is way too much calculation/offsetting taking place in the current code for this requirement.

So incorporating such a simple change in line with what your asking, actually may involve more work than is actually necessary for it to fully work.

However, it's a case of not 're-inventing' the wheel and modifying what you have.

Where specifically are you a little 'cloudy' on regarding AS in relation to the code you have:

- Is it that you don't understand the structure/flow of the sequencing.

- Is it that you're just trying to 'patch' in a modification to solve the reduction of the columns amount.

- Is it a combination of the above.

- Is the backup inclusive of any changes you have already made.

- What part of the calculation is incorrect.

Display More

I couldn't tell you if this was written for this specifically. Just trying to make the best of what I was given, unfortunately. I don't think it had vision. After it is programmed the PLC tells me which position to pick from and then which position to drop to. All I'm supposed to do is touch up the outer most corners of the pallet and then run the calculations and it interpolates the X/Y data for the middle positions and populates the (x_xfer_pallet and x_cell_carrier) transformational data so that I have pre-programmed positions for the PLC to send me to.

The problem is that the middle positions are not calculating into 3 columns. The top row (1 - 3) is fine. The bottom row (52 - 54) is in 3 columns although its 2 rows lower than where it should be. So position 53 is where 41 should be (If you're looking at image 1008 posted above).

The parts are presented in a guaranteed position each time.

I understand what I have in front of me. Not sure why it's not calculating properly. Re-writing something from scratch would take me forever. I'm better educated through example, especially when I can compare right and wrong next to each other to see what the problem is.

Patching this is where I'm at now. I'll attach what I have as of today so you can see where I was going with it.

Quote from kwakisaki

That simplifies it for sure.....

Keeps TCP central and just extends the physical tool.

So from a Cubic S perspective, the tool shape points would require extending/have been extended.

I'll have a deeper look at this tomorrow and will run it through KROSET.

Yes, on first inspection you will need to modify the programs you have indicated.

There's a couple of other things in there too.....is your carrier an actual box as opposed to a pallet?

Display More

You are correct. The TCP stays the same and the tool is extended on each side.

They are pallets with pockets that house the parts.

Here is the other picture

Thanks for the reply, Kwakisaki.

The TCP is the same. They are just adding one unit to each side of the existing 6 to make 8 to transfer between pick and drop. There are 24 units across the row and 9 rows. We used to pick up 6 and now 8 which makes the column count go from 4 to 3 respectively. Row count doesn't change. I've added two pics showing the differences in picks and drops from the old to the new.

The points calculations are in the teach_pts routine

Thank You for your reply.

I have 2 pallets. One I pick from and the other I drop to.

I think I need to change the calc_carrier_lo and the calc_transfer_l as well as the variables in the teach_pts routine to make my calculations for the columns. The rows are staying the same.

Is it as easy as changing the divisor to 2 from 3 and just doing a 1 count on the i_count iterations?

Fellow members

I was looking for some help in making an adjustment to these routines to calculate 3 columns as opposed to 4. My transfer pallet used to have 4 columns and 9 rows now there is 3 columns and 9 rows. My carrier pallet works the same way except every other row is staggered so we calculate those columns twice. Once for the non-staggered rows and then for the staggered rows. It would pick up 6 units out of a row of 24 and now we want to pick up 8 units in a row of 24 changing the column structure from 4 to 3. It then takes these calculations and populates (x_cell_carrier and x_xfer_pallet positions so the PLC can send me to whatever pick and drop location it wants to). The rows are not changing but the column structure is. I'm not very good with AS and I'm having trouble getting this thing to calculate properly. The following programs are the ones that calculate the columns and rows:

calc_carrier

calc_carrier_lo

calc_transfer

calc_transfer_l

teach_pts (this is where we teach the four corners)

***The file included is an .ASE file but I changed it to .TXT for upload***

Any help would be very much appreciated.

Thank You

roho76

Quote

The logfile in KRTerm screen grabs the editor window as long as it remains open.

You usually manually open/close this using the window options in the FILE tab.

This was exactly what I was looking for. I thought it was a command that launched this process and a command to turn it off when it was as simple as this. I've saved the file for future use.

Thank You

Hey

I'm trying to create a log file through Kterm of the robot in real time as it runs it's cycle. I couldn't find this in particular when I did a search so sorry if this has already been answered.

I need the command to start the log and then end it once the robot has completed its task. I couldn't seem to find how to perform this task in any of the manuals. Any help would be appreciated.

Thank You

roho76