Posts by Shellmer

That is probably because your turntables axis are both on the 2nd motion group, declared as axis1 and axis2.

The group exchange uttility I do not remember if allows to interchange an axis for another one, I do not think so...

You may need to extract that .tp file from the controller, convert it to .ls format, then go to the point declaration part and exchange the group 2 axis manually on all points from A1 to A2. Finally convert the .ls to .tp again and load it.

That is what I have done in the past while adapting programs whith servoguns, this should work the same way.

Quote from TP5029

Thanks for advice to use Frame Offset option under utility. It actually worked well, but...

table motion is not along with that...

Let say, by using frame offset, i was able to copy program from T1 to T2. And now am running the program on T2 table. Robot is moving fine with that but table T2 is not rotating according to robot motion, instead of that Table 1 is rotating.

Any advice on that??

thanks in advance.

Display More

You may need to exchange the motion group. As far as I remember you should have another utillity called "Group exchange", then you should replace the T1 external axis for the T2.

I've done this on the past with servoguns but I usually opened the .ls file, changed the axis on all positions, then compiled and loaded the tp again.

Idk how turntables are handled, but on my case working with two servoguns, axis were defined on group 2 axis 1 and axis 2, so it was a matter of changing the used axis on the points manually though the text editor, the group exchange utility will probably give you a way to do this conversion just like the frame offset does without the need to export and import the program.

The way Tituslepic provided is a good one, but remember that you can also use PR instead of P points, PR points are executed no matter the frame or tool you have selected, so you must be sure to select the correct frame and tool before executing them as the robot will not throw any mismatch errors and will go there.

The only downside of using PR is that you are limited to 100 points if you do not increase them through controlled start, but they are very usseful if you do not have much points, the max number of PR is betwheen 200-300, depending on the controller.

Also, always take care with J movements when changing frames, as config and turns are honored and the robot can suddenly decide to do a full axis 4 or axis 6 turn in order to honor the config if frame locations are very far apart.

Quote from RockemSockem

From the description, it sounds like a BG logic issue. I would suggest using condition handlers instead, but you can try to keep using the BG logic. I think the issue is that there is a race, of sorts, between when the controller changes the speed to 10% and when UO8 turns off. If the controller sets the speed to 10% before turning off the UO8 signal, then the speed will be set to GI5. You need a different set of conditions to prevent that from happening. For example, you could have it conditioned off of UO3 so that it is controlling the speed whenever the program is running (you could run into the same issue if you enabled the teach pendant while running though).

I was going to say exactly the same, it's likelly an issue with the temporitation of the signals.

The event triggered by switching the robot from Auto to Manual or enabling the TP is likelly occouring before the UO signal is updated, so the override is likelly put to 10% by the controller but inmediatelly afterwards, the BG logic loop is putting it to 100% again.

I neved tried to do this using the GI directly to write the overriide, I usually use the "Override select" function, there you can select 4 different speeds using 2 bits, it fits the major part of the applications, if this is not ennough, i suggest you to check this other signals instead of the UO8 as they are internal system variables that are probably updated faster than the UO signals.

$CR_AUTO_DO
$CR_T1_DO
$CR_T2_DO

Quote from Foxtrot2050

I would have to check. Not that I am aware of.

Siemens cards installed into the robot have this option avaiable, if you get the CRC signature and you put it into the hw configuration on PLC side, if the CRC changes robot will lose the communication until you update the signature again on the PLC side.

As it loses communication, DCS signals are also lost, so it's impossible to run it on automatic if you do not mess with the I/O safe signals inside the Fanuc DCS configuration... if someone does that, it could potentially bypass all safety, but it will still not connect to the PLC, for that not to happen you can change the default safety password on the fanuc side.

Also, molex cards do not have this function, and Siemens ones only have it active if you put the CRC on the hw config, if you leave it as "0" it not checked.

Glad to help, I've been reading all variables from the Rj3 controllers searching for other info, there are a lot of usseful variables, but it's a pain as some of them are not documented.

Luckilly this one has a good description of what it does.

Have you tried to use the CONTINUE instruction? It should force the pointer to move forward, just insert it before the ÕV_PRO instruction and check if this still happens.

Also... if you need to do it with a fixed value on the movement, why don't you use the $VEL.CP instruction?

Also, check this thread: Kuka LIN Motion Dynamic Speed

Skyefire provides a hint on how you can do this if you need to do this adjustment on the fly, but it seems you may need to control the speed using the SPS in order to adjust the override speed on the fly, not by editing the speed directly on the path program.

An update, I've found this info on an old manual while searching another info, it's from old controllers but it may still be there.

$MACRO_MAXNU
Maximum Number of Macros
This is the number of macros. The default value is 20. 
Power Up: Requires a controlled start to take effect. 
See Also: $MACROTABLE[n] where n means $MACRO_MAXNU.

$MACROMAXDRI
Macro Maximum Number of DI and RI
Description: In the macro function, the macro program can be assigned to DI and RI of the digital input signal. This is the maximum limitation number of the DI/RI macro. The default value is 5. This default value is appropriate for most applications.

For anyone interested, I've not noticed any diference changing the routine logic to be executed with the RUN or the BGlogic, what seemed to make a diference was to handle all the calculations on the robot side, making the PLC a mere passtrought.

I've handled the data on PLC side with a OB30 (cyclic interrupt) so the sensor data is transfered every 1ms to the robot. Robot still updates his I/O at a more slow rate but at least now data only comes with a fixed delay and I can ensure I am capturing the data at a fixed rate instead of adding all the random delays toguether caused by the PLC scan time and the tick rate from the bglogic + i/o communciation.

The data capture is handled on the BGLogic program with high priority.

The problem was not elliminated, but was reduced a lot.

Now, I want to ask a question, this robot has a Siemens card, the ones where you need to create a PLC project and load the card configuration and then export the GSD to load into the PLC hardware... anyone knows if the card can be configured to be faster regarding I/O communication? Like enabling RT or IRT behaviour.

I need to have the most accuracy I can get, but that will not be possible if the sensor refresh his values at 2ms and robot at 20ms... on 20ms robot already has turned the workpiece more than 0.5º, and with the tolerances I am working this is a problem... I think this can work correctly if at least the only bottleneck is the 8ms scan from the BGLogic.

Thanks.

Active uframe or robot "world" being incorrectly set would not cause the robot to move on a curved way if doing cartesian movements, it only would cause to move on an incorrect direction, but the movement should be still linear, even if it goes in a diagonal direction.

If you are experiencing a "J shaped movement", I have given you two possible causes, forget about uframes, utools or cell frames until you can jog the robot lineary without strange motions.... if you jog the robot in world, user or tool it still should move lineary even if not in the correct direction, robot moving on a curved pattern or "falling" middle linear movement is not normal.

Regarding power loss, it is not a problem if the robot batteries that keep the encoders with power still have charge, these bateries are installed on the base of the robot and should be changed from time to time WHILE the robot is still powered on. These batteries are normal non-rechargable batteries that you can purchase on any shop.

If batteries got empty you should have received a "BLAL" alarm (Batery low alarm) or even a "BZAL" alarm (Battery zero alarm).

If you do not change the batteries after a BLAL you run the risk of losing mastering completelly if a power outage occours.

If this happens, the only way to fix it if to remaster each axis manually again with the zero marks, but it's very difficult to achieve the same precission on the robot as from factory when you do it manually... and you also say that robot has vision, that is the worst case scenario since a robot with vision needs to be very well calibrated in order to work correctly.

I repeat, have you checked if robot goes to 0 position AFTER mastering the axis again??? To check it the better way would be to create a new program, record a new point, change it to JOINT representation with fine termination, modify all axis values to 0 degrees and executing the motion.

After doing that you should check if robot moved to zero marks, if not, master the robot again.

Lastly, I don't know if I understood you correctly with this statement:

Quote

The imaged restored is from the same machine made earlier this year

If the image came from the same exact CONTROLLER, so you made a image backup from that controller and you restored his own image on his own controller, then mastering data was likelly lost since it should restore the original mastering after restoring the original image. What loses the pulse count after a power loss are the pulsecoders, so even if mastering is ok on the controller side, new pulse values will be generated on the encoder (robot) side so mastering data is invalid after a complete power loss on the encoders)

If instead you are saying that you restored an image from a similar robot (even if same mechanical unit) from another cell that was installed this year into this robot that is from 2013, this is probably the problem.

You should never restore a image from a controller into another, as all options, data and even mastering from the robot you extracted the image will be restored, and mechanical units all have different mastering data, even if they are exactly the same model.

You have answered yourself, if robot moves incorrectly on cartesian movements and does a curving motion while jogging on cartesian this can be caused either because you have incorrectly calibrated the robot or you have restored an incorrect image on the controller.

If you have loaded an image of an incorrect controller that has not the same mechanical unit type, the kinematic model will not match and linear movements will not work ok.

If you have very bad calibration, the same will happen.... have you moved the robot to 0 marks after doing the calibration and checked that it was exactly at 0 on all marks?

I suggest you to check the original mastering data and restore it manually if you can, this will only work if the encoders have never lost power or battery. Original mastering data usually cames with the robot after you receive it, where I work we usually make a copy of the document and store it inside the controller cabinet.

If you have the data and it is still valid, it's better to restore that data than to remaster the robot again yourself, as it will not lose precission.

Quote from Iprogram

I guess i am really asking how to do this? and what i did wrong to not make that work. for instance i can do the following expression:

n=35

DOUT[n]=ON

so what am i doing wrong with the indirect addressing of UseZone[n]=true

Display More

They are totally different things, by writting "DOUT[n]=ON" you are already accessing some type of array, that's how Fanuc handles the I/O addressing, just the same as it works if you put a register inside, that is called indirect accessing and it just works because fanuc has done it that way.

But no, you cannot do what you are trying that way by simply writting a number after the variable name, the only brand I know that allow this is ABB, but only if you use functions that search the variable tables for variables with the name you provide on a string.

You may be able to do it on fanuc by using the BYNAME routine, search it on the "Karel reference manual" if you are interested and willing to try it, but I sugggest you to an array of booleans, that will be the easiest way you will be able to handle it, there is not need to reinvent the wheel if you only want to apply this on a little routine.

Quote from d.kerekes

I do not know, if it is helps You, but one of the BG logoc what we are using:

123: !Robot actual position ;

124: GO[11:4336:CurrPosX]=($SCR_GRP[1].$MCH_POS_X*10) ;

125: GO[12:61953:CurrPosY]=($SCR_GRP[1].$MCH_POS_Y*10) ;

126: GO[13:5523:CurrPosZ]=($SCR_GRP[1].$MCH_POS_Z*10) ;

127: GO[14:65523:CurrPosW]=($SCR_GRP[1].$MCH_POS_W*100) ;

128: GO[15:64052:CurrPosP]=($SCR_GRP[1].$MCH_POS_P*100) ;

129: GO[16:14064:CurrPosR]=($SCR_GRP[1].$MCH_POS_R*100) ;

Display More

I see, take into account that MCH_POS data is only updated while robot is executing a program both in T1 or AUTO, this variables are not updated while jogging the robot manually.

If you need to get the data while jogging you can get the same data from this other variables:

If you want the position from world:

$SV_INFO[1].$CART_POS[1]

If you want the position from the current selected UFRAME:

$SV_INFO[1].$CART_POS_UF[1]

But... with the code you provided, I do not see any movement or where and how you SET/RESET that variable, please, provide the TP code where you set the variable DO to ON and the one where you set the DO to OFF.

UI are not safety rated, they are OK if for safety you refer to "machine safety", like stopping the robot if it invades a machine area while a cylinder/servo is moving or machine is has not the correct conditions for the robot to access and robot invades the area, but they are not ok to use if there is risk to people.

If you need to stop the robot because it involves any risk to people who work with it, you should use the safety signals provided on the safety board (ES/AS) or the DCS safety signals, also this signals should be handled by wiring safety devices, relays, or by a PLC safety capable that can handle all the logic.

Please, do not be the guy who force a HOLD signal as the only way to stop the robot when the access door from the cell is open, this is NOT OK and doesn't ensure the robot will not start to move while people are inside, and please, please, please... ensure safety circuits work OK after wiring them!

if you do not know how to handle this, contact a professional.

Usually, increasing things like max number of payloads, registers or PR is done through a controlled start.

When you start the robot that way you can increase limits, but I've never needed to do it with macros, this is done through the "Program setup" menu as far as I remember.

Check if there is any item regarding maximum macros.

If you do not need that axis to reset exactly at 0, you may be able to just remaster the axis again after every cycle or before starting it.

And I say that because even if you move the axis from 0 to 360 degrees, if you master again the axis on that position you may have some positional error, axis may be 0.1º off and after 100 re-masterings you may have added 1º of error.

If this is not a problem, I think you could do it through karel or modifying the mastering variables directly so you do not need to unwind the axis.

Currently I have a similar application where I do that, but not on a fanuc axis, instead I remaster a siemens servo to 0 every time I complete the whole motion because I do not want it to unwind and I do not care about the final or initial position of the servo, I only need to rotate certain degrees after a new cycle begins and nothing more.

Check this thread, there is info about an automatic axis remaster through program, it's from a turntable, but it's pretty similar:

Thread

Program to set turntable to zero

Hello, I am new to the forum and new to fanuc robots, we have a 6 axis fanuc robot in group 1 and a turntable in group 2 (Axes 7 and 8).

The case is that we do not have the continuous turn option installed, so if we make a program to rotate for example 60000 degrees, at the end of the program the table is located with that number of turns.

Is there a way to make a program that allows me to set to zero without doing 60000 in the other direction?

Thanks.

Nelson Castro

May 4th 2020

You are likelly missing the DO update betwheen PLC cycle scans and I/O updates, every BGlogic loop runs at a minimum of 8ms tick rate, it depends on the controller type, only way to ensure you are executing the bglogic at a minimum of 8ms is to set it to priority hight, if it's on normal it can vary.

And even that way, it seems I/O update time on the robot side is done every 20ms or so (at least with siemens cards), so if a signal changes OFF/ON/OFF on that interval you will not notice on the PLC side.

This is a problem I have right now with a communication I need to do in real time, I've not found a way to transfer I/O changes faster than that even implementing cyclic interrupts on the plc side, the communication is slower than what I need.

Please, provide an example of your normal TP program and also the BGLogic one, in order to help you we need to know how are you handling the movements and I/O changes.

Quote from rpgemployee

Hello everyone,

I'm trying to create toolpaths and generate programs using RoboGuide. Everything seems to be working fine except when I try to move the Tool Center Point with my mouse. Whether I offset it in a direction +/- or just grab the little TCP dot and move it, RoboGuide pauses for about 3-4 seconds with a little pop-up menu stating "Waiting for SysRdy UOP signal". The robot arm "ghost" will then move to the TCP briefly and then the TCP will move back to where it was originally. When I created my station I used a very recent backup of the files (not an image). Our real robot has a bunch of safety interlocks in place that prevent certain things from running unless certain conditions are met (doors are closed such that prox sensors activate, spindle needs to be warmed up, robot @ home position, etc). I'm not sure if that could be contributing to the issue but it might help. I've noticed that cycle restarting the controller makes it behave briefly, a few moves maybe, before the issue resurfaces. Any suggestions to help resolve this issue would be greatly appreciated, thanks!

Reserialize the robot and remove all safety options like the DCS one, you can also add the IRProgrammer option if you want in order to modify the program on a more easy way if you want to also code logic (it's a web interface like the TP that allow you to write instructions directly and more things instead of adding them through the TP menu)

That's what I do every time I create a cell from a backup, so I don't have problems with the controller requesting me to validate dcs or putting them in bypass.

To reselialize the robot, click on the robot mechanical unit item, then open properties and select the reserialize option.

A new screen will open where you will be able to modify the robot options, change them, and then you will be warned the system will be modified. Just accept and a new system will be created and your old one will be replaced.

Take into account that you will lose the posibility to see the DCS zones on roboguide if you disable the dcs option, but this should not be a problem if you plan to use it only to adjust offline paths.

You can recalculate all points from the path given the old tcp and the new one, same with uframes.

You can do it using the utility "Tool offset" or "Frame offset" but ONLY if you are not using tool offset or frame offset instructions inside the program in order to aproach start or retract from end points and if your points are not saved inside PR.

I say this because if you have a point like

J P[1] 100% CNT100, TOOL_OFFSET PR[100] and you do this recalculation, if you per example were doing a Z retract and you change tool to another one that has a different z direction, robot will likelly crash.

Other than that, the only two more things to take into account is that this utility only works with P points, PR points will be left unchanged.

Also after doing this you will need to edit the UTOOL_NUM and UFRAME_NUM instruction assignments on the tp module with the new utool and uframe numbers you will be using or it will warn you after trying to perform the movement.

If your points were saved inside PR points there is still hope... you can still convert them but you must do it manually by selecting the uframe/utool num you used to taugh them, converting all points to joint representation using the data screen, then selecting the correct utool/uframes and converting to cartesian coordinates again.

I suggest you to insert a new name if you use the tool offset uttility, so it does a copy with the new points, then you can test the program and delete the old one + rename the new one with the original name.

First of all, linear motions do not honor the config turns, so if you are not able to reach a L point the first thing you should try is to change it to a J one and try again, if you still cant reach, you can tru to change the turn number from axis 6 to -1, 0 or 1 and see if you can reach.

If you are trying to move to a PR point using the "Move to" button, forget that, instead create a new tp program, add the instructions to select the correct utool and uframe and add a J motion to move to that PR point.

This will ensure the robot moves to the position with the same config and turn number you have recorded previously.

Lastly, if you have recalibrated the robot and you have previously saved a position that was near a config change (like FUT to NUT), or even a turn number change (000 to 001 -> axis 6 goes beyond 180dg), after the new calibration that config may no be possible to be achieved.

I've found this problem before with some robots where axis2 was incorrectly calibrated the time positions were taught.

Also ensure that you have selected the correct tool and frame if you are moving to PR positions and they are jot save in joint representation, as PR cartesian points work with any utool or uframe you have selected...