Posts by HawkME

The way you described is the best way in my opinion.

If you use UI signals to start then then can't choose anything else.

I think it would be ok. You may want to change it just before the vision program then change it back after wards. That way it doesn't affect the rest of your program. Of course you should test it to see if it takes effect right away. Some settings only change after a reboot.

If you are not doing CAD to path type applications, and know your syntax like the back of your hand, then nothing is more productive than a good text editor.

Do you know the size of parts it is supposed to be picking at a given point in time?

I agree with Lemster. But yes you can lower that time parameter. Do the same for all axes.

You wouldn't create logic for a PID loop in the robot. Instead you would use or purchase an option that handles it for you. You have to tell us the specific application.

Check that your override and program override are both at 100%.

Please post the entire error message.

Right. Do that in BG Logic, then you don't have to have a PLC.

Master is referring to what controls the robot UI signals. In this case the robot would control its own UI signals thru flags.

Don't use Karel. Use a TP program.

Set a max consecutive picks variable.

It will try to pick that many in a row from 1 feed. If it reaches that count or none available it switches to the other feed.

Ideally you would know what the demand is from the downstream production lines. If line A is running twice as fast as B then you may need to pick to meet the demand.

If you have the capability to have the downstream demand as inputs then you can use that as part of your calculation along with if parts available.

If not then you might need to set a pick qty for each line., such as always do 5 in a row for A then 3 for B. If nothing is available then just check back and forth both A and B until one is ready.

Draw a circle on a piece of paper. Draw one line from the center to the edge and label it 0 degrees. Going clockwise label 90 and 180. Going counter clockwise label -90 and -180.

You will see that 180 and -180 are the same point.

If you move past 180 in either direction change the value to what it would be if you started from 0 and took the shortest path.

If you have a negative value <-180, then add 360 to it. If you have a positive value >180 , then subtract 360.

No. It's pretty simple. 180 = -180.

Instead of doing that you can use the RUN FIND command, with find multiple set to whatever # you want in the vision process. Then you simply call GET Offset VR[1] and pick in a loop until there the get offset fails (to a jump label). Then you always use VR[1] and let the system manage it for you.

In other words you call VISION RUN_FIND once and it stores multiple found parts in the background without using a vision register. Then each time you call VISION GET_OFFSET it will load the next found part into the register, overwriting what was there before. When there are none left it jumps to a label, then you can jump back and RUN_FIND again.

Take an image backup first. Then you can always restore the image if you don't like what happens.

Options should stay intact if I remember correctly.

You can't use a regular timer in BG Logic. Either use the timer in a regular program or in BG Logic you can use $fastclock or count scans.

That is not quite true. That's how it behaves when jogging from the pregnant, but the WPR values used in the program are actually Euler angles.

You could configure it to the internal memory port, rack 0, slot 0. Then configure a GO of the same size to the same rack/slot/start. Then you can control it with the GO.

Number of positions has no bearing on how complex your recovery routine needs to be. Instead think about how many different zones or ways you need to recover. If you are picking parts maybe you need a recovery method if gripper is empty and one if full, for example.