Posts by GallusRoboticus

I'm not familiar with Fronius power supplies, so I'm not sure what that signal is. Since you have two cells you might be able to swap components between the cells to narrow down the cause of the issue. If possible you could start by swapping the power supplies and seeing if the error moves to the first cell or keeps happening on the second. Then swap cables, etc. until you get a better idea of what is causing the problem. If you have verified that the signals are identical between the two cells then I would still guess that it's something like a loose connection or faulty wire.

That error means that there is an issue coming from your Fronius power supply. If your power supply doesn't show an error after you receive this message it is likely an intermittent connection issue of some sort. You should check to see if you can pull up an error log or message history on the power supply and double-check all the connections to and from your power supply.

Maybe you could post some pictures to have us double-check your setup? Can you post the MENU > SETUP > Prog Select screen (and the DETAIL (F3) screen)? Also the MENU > SYSTEM > Config screen around line 42.

I'm sorry, I misunderstood your question. You are right that the palletizing command always stores the points in world coordinates. I don't believe there is any way to simply change the user frame to move the pallet points. You would need to use a PR to store the offset between the two pallets/user frames. Something like this:

J P[1] 100% FINE    ;
  IF (F[28:STACK ON C2]) THEN ;
  OFFSET CONDITION PR[31:OFFSET] ;
  ELSE ;
  OFFSET CONDITION PR[100:Zero] ;
  ENDIF ;
  PALLETIZING-B_1 ;
J PAL_1[A_1] 30% CNT100 Offset    ;
L PAL_1[BTM] 500mm/sec FINE Offset    ;
L PAL_1[R_1] 900mm/sec CNT100 Offset    ;
  PALLETIZING-END_1 ;
J P[1] 100% FINE    ;

The pallet registers are only used with the palletizing command. In the palletizing configuration (after you add the palletizing command to your program) you can select which pallet register you want to use and what order you want to increment the register: row, column, or layer. The register indicates the next point in the stack the robot will move to when it hits a palletizing command and it increments when it hits the palletizing end command. When you fill up a row, column, or layer (as defined in the configuration) it will automatically roll the index in the register over to 1.

Yes, this is definitely possible and exactly how we are using this option. The palletizing points work pretty much the same as any point with all the usual motion options.

You get singularity errors when trying to do linear moves to a point that has J5 close to 0. You will either need to change the moves to joint moves or change the points so that J5 is not close to 0.

Denso does not list controller specs in its manuals. I think it runs a Windows Embedded operating system; so you cannot use it like a typical desktop computer, and you would not be able to install other applications on it. The controller is designed as an enclosed system whose only purpose is to control the robot. You would have to use some type of I/O to interface with peripheral equipment or applications running on other computers.

Quote from fmiroslav

How from TP set this flag OFF?

Does Search End do this, setting Master Flag OFF?

Where is placed (generated) offset position?

Yes, I believe Search End will turn off the Master flag automatically. You can also turn it off manually in the Touch Schedule in the same way that you turned it on.

When you run a search with the Master flag off, it will store the offset in the PR you specify in the Search Start command, which in your case would be PR[1].

The first time you run a program with touch sensing you will need to master the part by turning on the master flag in the touch sense schedule you are trying to use. It should automatically turn off after you execute the program the first time.

I use Notepad++ and it gets the job done well enough.

Here's a freely available user defined language for TP and Karel:

http://www.windsortech.eu/en/downloads/syntax.html

It sounds like your problem comes from changing the configuration of a point when you touch it up. The configuration is used for J moves to make sure the robot is in the correct joint configuration at that point, since every point in space can be reached from multiple combinations of joint angles. This would explain why everything seems to work the same until you get to the J move.

Here's a good article explaining this problem:

https://www.onerobotics.com/po…erils-of-six-axis-robots/

When you are touching up a point, keep an eye on the config before and after touchup to see if it changes. It is usually something like NUT 000. You may need to modify this value to get it to keep the path you desire.

pasted-from-clipboard.png

If you need more help with this problem, it would be good to post an example of the code you are running along with some position data of the points that are having the problem.

Are you certain this is gimbal lock/singularity? What you are describing sounds like it might be a joint configuration change. When you create a cartesian point it also stores the configuration usually as something like NUT 000. When you touch up the point does it change to NUT 001 or NUT 00-1? That last digit in the configuration indicates the relative position of the wrist joint: 0 means between -180 and 180 degrees, while 1 means above 180 degrees and -1 means below -180 degrees.

Basically, if you are moving to a point that requires the wrist to be at 179 degrees, then move to the next point that should require the wrist joint to move to 181 degrees, but the configuration still says NUT 000, then it will end up moving the wrist joint to -179 degrees instead. This only applies to Joint moves, so if you have this problem you can consider using Linear moves instead, which will ignore the position configuration.

There is no "distance before" command option that I'm aware of. If you add a blend radius to the motion I know that the code looks ahead to find where the next point is, so you could try using that with an intermediary point; although, I'm pretty sure that will result in choppy movement.

To really achieve your goal, I think you'll need to use a Thread in your program to manage turning on and off your dosing valve. Depending on your application, this could be as simple as turning on a signal before your motion that tells the Thread to wait a certain amount of time before turning on your output to the dosing valve. If you truly need to turn your signal on based on position you may need to have your thread monitor the position of the robot and turn on your signal when it gets to a certain point.

That depends on how accurate you need your user frame to be. If your work space may move relative to the robot, you will need to make sure that you can access each point on the work space consistently to touch up the user frame. If you simply want to define a new orientation different from world, it really doesn't matter as long as you are consistent with using that user frame.

Have you considered using the four-point method? That will let you define the frame about your workspace then shift it to a new origin, so that will work as long as there is one point on your workspace that you can reach with the robot.

You will need to use the <INSERT> softkey to add OR to your condition.

The new statement is IF (...) THEN which only executes the lines of code following that statement when the condition you provide is true, up to the next ELSE or ENDIF command. You should use this to replace IF (!...) JMP LBL statements.

The functionality of the other IF statements has not changed.

Post any specific examples of code where you might want to use this if you want help converting it to use the new statement. It doesn't really add functionality, it just makes the code a lot more intuitive and easier to read.

The simplest method I think would be to set the Program Select Mode to RSR (Robot Service Request).

Here's a very useful article discussing more elegant ways of handling this situation:

https://www.onerobotics.com/po…ing-fanuc-robots-in-auto/

Instructions for upgrading can be found in the manual, section 5.4 Setup Screen -> Update. Basically, with the file on your USB stick, just click SETUP Robot > UPDATE Robot > Search... and select the file you downloaded from the Legacy Download Center, which should be 1.8.25319 in your case.

Welcome to robotics!

If you take a look at the manual for 1.8 it looks exactly like your screenshot. You must be looking at a newer version of the user manual. Since you are running 1.8 you must have a CB2 controller, which I doubt supports those Safety features. I don't know if updating will help anything, but you can take a look at the Legacy Download Center for instructions on updating older versions of the software.

I hope that helps!