Posts by I3ooI3oo

    Is this auto generated, or created manually?

    It is manually created. While I write the robot process along with laser process, ultimately our field service department will be doing the install along with training the staff on how to use the system. Knowing that I task the FS department to create one based on printed copies of all the created TP Programs. This lets me know they truly understand the process and are capable of answering any questions that may arise during the install of the system.

    I'm a fan of both. I write most programs to be vertical when starting, however soon morphs into horizontal once I find code that I have already written being needed again. Each time that happens a new program is born.

    As HawkME stated using an exact AI to R[j] can be problematic, both because of what HawkME said about the precision and the fact you may want to have it be a range that be something like 0-10 volts = 500-1250 mm. For something like that I would calculate the slope and offset and then multiple it by the value of the AI. If you wanted to have discrete positions then you would have to setup multiple IF .. Then for each of the discrete settings.

    R[1] = AI[1]
    IF R[1] > 0 and (R[1] < 2.5 or R[1] = 2.5) then
    PR[1] = PR[10]

    R[1] = AI[1]
    IF R[1] > 2.5 and (R[1] < 5 or R[1] = 5) then
    PR[1] = PR[11]

    R[1] = AI[1]
    IF R[1] > 5 and (R[1] < 7.5 or R[1] = 7.5) then
    PR[1] = PR[12]

    R[1] = AI[1]
    IF R[1] > 7.5 and (R[1] < 10 or R[1] = 10) then
    PR[1] = PR[10]

    This would give you 4 discrete locations for the voltage range of 0 - 10 Volts

    Depending on the volume of air needed and the speed in which it is needed. You can have the valve at the base of the robot and use Air 1 to pass it up to the EOT. Air2 is connected to the internal valves which can't switch vacuum.

    It would normally go to Earth ground which the arm doesn't really have. I would worry about connecting to 0V as it may connect the external sections of the device to 0V which isn't always a good thing.

    Robot --- vacuum
    P1 <---------> P1
    P8 <---------> P2

    When you change the state of RO1 it with engage/ disengage

    Personally I have had that issue many times when using GET_OFFSET, I prefer to use POS_FOUND and just move there. I also make sure my userframe and my camera calibration are exactly the same. I think the problem is it is offsetting the tool frame not the userframe.

    L P[1:Home] 100mm/sec FINE ;
    L P[3:Perch] 100mm/sec FINE ;
    R[1:PART1]=1 ;
    LBL[100] ; Note I never start with label 1 as what if you need to use a lower label
    FOR R[2] = 1 to 6
    R[3] = R[2] + 10 ; Assuming offset PR are 10-16
    L PR[1:P1] 100mm/sec OFFSET PR[R[3]] ;
    L PR[2:P2] 100mm/sec OFFSET PR[R[3]] ;
    L PR[3:P3] 100mm/sec OFFSET PR[R[3]] ;
    L PR[4:P4] 100mm/sec OFFSET PR[R[3]] ;
    L PR[5:P5] 100mm/sec OFFSET PR[R[3]] ;
    L PR[6:P6] 100mm/sec OFFSET PR[R[3]] ;

    Trying running in T1 with browser connected to the run-time. I found when the cable starts to go bad I had similar issues. The camera was still taking images however the image was much darker than normal. Once the cable was replace the issue went away.

    On a R-30iB it will leave you with the error User Cycle Power, since the R-30iB can't do it for you.

    There are a couple of method that are used to avoid moving into a possible issue like wrapping hoses or wires. The simplest method I can think of is forcing a move that is part of the direction you want it to move to. So say your wrist is at 5° and your pick up location is at 345°. Normally the robot would try to go to the position by spinning counter clockwise as it's only 20° that direction. So I would move to 180° which the shortest path would be to move clockwise 175°. Then allow the robot to move to the desired 345°. Since the clockwise motion to 345° is only 165° it will continue to go clockwise to the position that is desired.

    Your robots are connected to the PLC, you use the PLC like the police would direct traffic. One robot requests to enter the area of interference. The PLC checks the other robot to see if it is clear. If so, the PLC grants the permission to enter the area. When the robot enters the area, it will turn the clear bit off. For safety, you should turn it off, not on, because if one robot controller gets shut down while it is in the interference area, it will be assumed to be not clear because the signal for clear is not on.

    I think what the last part of is trying to say is when a bit is asserted or high is a safe condition. So you turn the bit off (signal low) to indicate that a robot is in the interference zone. Using this method allows for a robot being off to be in all interference zones at the same time since all of it's outputs are low.

    In my setup signal high is the NOT in that location. I also inverted the bits and logic so when looking at the I/O on is shown when the signal is not present. My setup also used data transfer between robots (J740) so I could transfer position registers and data registers. However data transfer between robots was not used for safety checks only for remembering which parts were taken off the pallet so the robots didn't check a spot the other robot already had.

    I think your server cost are a bit high. A dedicated server that can handle the load of 100+ simultaneous users should cost a lot less than that. Our dedicated server in a data center in Atlanta is only $199.00 USD which is less than half of your costs. No one expect you to have to pay out of pocket for the hosting. However the ads seem excessive to say the least.

    Personally I have setup multiple robots working in the same are with nothing more than reference positions being used, and another bit for each saying they are going to a reference position.

    Theses 3 robots have 3 potential crashing locations.
    1. The pallet where they pick up parts.
    2. The laser where the part is processed.
    3. The flow tester where the Epson robot is.

    Before each move the robot checked if the other robot's going to location bit was on. If it wasn't then the robot checked if the other robot was at the location it is going to goto. If both checks cleared then it would turn on it's bit showing the is was going to the location. It would wait until each of the test was successful before moving.

    Below is a video of this system in action. The parts have been blurred out for NDA reasons.

    A position register PR[j] doesn't hold frame data. This is a nice feature which allows you to move to a point with different Utools. Often when using different EOT grippers we want to place the part in front of a camera or laser. The focus location doesn't change in space however the tooling holding parts has. You can move to the same location part location with different tools and still have a part in the same location. The robot's position will not be the same but the parts will be.

    A program position P[j] does store both utool[j] and uframe[j] information.

    I have a command to enable HTML5 menus and another to disable. When HTML5 menus are enabled you can't select a BGlogic program as described.

    setvar $UI_CONFIG.$ENB_HTML5 0

    setvar $UI_CONFIG.$ENB_HTML5 114

    Personally once disabled I leave it off.

Advertising from our partners