Posts by verove

No dispenseware, just self made routines.

In my particular case, I'm dealing with dosing equipment, so I'm already using triggers for the signals that are tied to that.

But my program has a few routines that it runs to change state between programs (e.g.: make sure the dosing equipment is ready, entering / exiting areas, etc) and only the last point is a fine point. So, once it reaches the last fine point, it's running all the routines, but it's running it too fast and the peripherals are lagging behind.

I do like the idea you mentioned to use triggers to synchronize some of these routines, though. I'll try sprinkling these around instead of running them all back-to-back to see if it improves.

Quote from Lemster68

It is possible to give the motorsoff input while the program is executing, however, it is recommended to issue a stop first. Does the input turn on for a minimum of 50 ms? That is a requirement for all system inputs. Check to make sure that there is no filter active set for that signal in the configuration.

You might be onto something here. The original PLC program was sending the Stop and MotorsOff at the same time.

As a test, we put a very short timer to delay one signal from the other and this got rid of the error.

It was just a pain to try to figure this one out, since normally the errors give you clues as to what signals are causing the error -- but not in this case.

Quote from Lemster68

My first instinct then is to think that the motor on signal is still on when the motor off signal is sent.

I've had this happen before, but at least when that happened, they message on the log mentions that it's because both signals are on at the same time. What's throwing me off is that in this particular case, no other faults or explanations are coming up.

Quote from loopindex

Which manual are you referring to?

I've downloaded the Operation Manual, which has an explanation of all the fault error codes.
Additionally, the robotstudio log has no actionable items or causes listed.

That's a typo on my part, I apologize. I'll edit the post with the correct information.

It should read:

When the plc send the motors off input, the error is displayed and the motors never turn off.

Hello everyone,

I have an error that only happens in a very specific situation, but the controller is offering no cause for the error. Hence, asking here.

When the robot is in Automatic, running a program (i.e.: CycleOn is on), and the PLC sends a MotorsOff input the robot is displaying Error 20141: Motors Off Rejected and the motors never turn off (they stay on)

The manual does not give me possible actions, and there are no other errors on the log.

Has anyone come across this problem before?

This is fear, that it was time based (through the prefetch time parameter) instead of logic based (i.e., 3 lines ahead).

My problem with changing the prefetch time is that it affects all program execution.

Hi everyone,

I'm working on a RW6.14 controller and (although I never thought I would say this) looking for a way to slow down the robot pointer.

I've currently come upon the problem that the robot pointer is running too far ahead logic-wise, causing peripheral devices to trigger far too early.

Is there any other way to stop the pointer from going too far ahead other than using a WaitTime\InPos, 0 ?

I'm looking for an instruction similar to Kuka's $ADVANCE=0

Simply, someone taught the tool wrong the first time.

No crash, no redesign, just plain taught wrong.

The rotations of the tool are the same, it's the x y z values that are off by 5 to 10 mm in several directions.

The positions taught are for sealing, picks and drops so being off by that much will dramatically affect the paths.

Lemster68,

For some context, I have a tool that has been taught incorrectly, but a lot of points have already taught with it.

Now, we have retaught the same tool (with a different name), rendering the same physical tool, but the values are quite different.

So, I'm looking for a way to move the points, so that now that the new tool is different, I don't have to modify all the points to match the old positions.

To put it differently, I need to shift the point themselves, so that the tool stays in the same position with respect to the part, but using the tool that's taught correctly.

Hopefully that makes more sense.

Good morning everyone,

Does anyone know if there is a function to offset from one tool to another?

It would be used to move all the points in one program from one tool to another. In other words, this would be the equivalent to Fanuc's Tool Offset function.

I'm hoping that the only solution to swap points from one tool to another is not to just touch-up all the positions.

Thanks for any help in advance!

Hi,

When you're missing a virtual controller, you can contact the Fanuc line and they'll provide it for you.

Hi,

At first glance, I see that you've configured the module as 1 output byte, and 2 input bytes, as opposed to the 1 output / 1 input that you've mentioned. Remember that these values are what the module has not what the module uses.

You don't always need all the fields filled out before you can configure it--you can seen my comment above on which are the more necessary ones. I'd recommend starting by filling only the necessary fields first, instead of importing the whole template.

You can find all these values in the EDS file, depending on what your application is.

Does this coincide with a change in tool or user frame?

If you go to DATA, highlight the 'R' for PR[13] and press POSITION, what comes up?

Also, how many motion groups does the robot have?

Hey,

In case this helps, here's an example of how to do a WZHomeJointDef as a power on event:

!World zone variables definition
PERS wzstationary wzHome;
VAR shapedata shHome;
PERS jointtarget jDeltaPos := [[1, 1, 1, 1, 1, 1],[1, 1, 9E+9,9E+9,9E+9,9E+9]];


PROC rWorldZone() 

  !At startup, this will set DO7 = ON when the robot is at jHome +/-1mm.
  WZHomeJointDef \Inside, shHome, jHome, jDeltaPos;
  WZDOSet \Stat, wzHome \Inside, shHome, DO7_AtHome, 1;
  
  RETURN; 
ENDPROC

Make sure to set rWorldZone() as a power on event. (Controller > Event routine > New Event Routine > Power On.

You do not need to be connected to the robot, no.

Maybe someone else has a different solution, but when this happens to me I just restart my computer. Sometimes RoboGuide gets "stuck"..

Quote from shriraj lonkar

due to the weight issue, I can not use this manipulator as a cobot right now I am using it as a robot

Disabling the force monitor does not affect whether you can use DCS Position Check with a Target User Model.

You can still use all the other functions of the DCS menu, even if you're not using the collaborative functions for the robot.

Quote from shriraj lonkar

I WANT TO AVOID COLLISIONS ONLY DURING THE MANUAL JOGGING

In fact, the DCS Target User Model is designed to prevent exactly what you're looking for.

Things you can check:

- Check that the second time you're pressing the HMI button, the robot is getting a Start at Main. If it's only getting a Start, it's continuing the previous program, and it's not evaluating its location again.

- When you press it the second time briefly, what are the states of doR1_MoveHome, giR1_StyleCode, goR1_StyleCode, giR1_StyleCode,

g0R1_StyleCode and doR1_HomePos?

r1_Comau_init() is not actually checking if the robot is already at home before starting the homing routine. It relies on the style number sent from the PLC to start the homing routine. This means you'll always evaluate all the IF/ELSEIF statements in the recovery routine. If the robot can't find a predetermined location, it just goes to home. (Ah!)

- Does this behavior happen every time you test it or does it only happen when you're trying to send the robot home from a specific location? Could it be that you're trying to home the robot from a location that isn't covered in CheckLocation?

I second what was previously mentioned:

Quote from gmumaugh

Also, in the event that the robot is actually outside of recoverable range, I would delete the commented STOP instruction and the HomePos call and replace them with an EXIT instruction or some kind of error handler.

In case the robot is not in any of the predetermined locations, it should not default to go home. Uncomment the STOP instruction, so it stops and manually homed if it's not in a safe location.