Advertising

Posts by HawkME

    I would advocate to get rid of all the different core "Tool" softwares. Move to a single core operating system and have handling, welding, painting, dispensing, palletizing as plugins that can be added. The way it is now there is too much disparity between the different software packages. It doesn't feel cohesive and causes confusion.

    That variable is meant to be read only, you can't execute motion by changing it. To control an extended axis you need to run a regular TP program with a normal motion command to move the axis. If you want pass through control from the plc then you could run that program in a loop using jump labels.

    The 6 point method has to be done a particular way to be accurate in w,p,r. Most people I see do it wrong and end up with the same result as a 3 point TCP or incorrect w,p,r angles. A laser sensor would not be easy, but Skyfire's method sounds like a great way to do it.

    Glad you found a solution, but for others that may view this thread in the future, I recommend using Fanucs built in solution of using UI[18] for main production start, and UI[6] for continue only. Then no system variables or BG logic is required.

    You must still not be doing something right. With Fanuc you can easily achieve what you are after.


    First you need to realize there are 2 different start signals, UI[18] = production start. UI[6] = start. When you configure start for continue only, it affects UI[6]. UI[18] is to start from the top of main. What prog select method are you using?


    Your PLC sequence should be as follows for starting at beginning:


    PLC program:

    1. Pulse Cstop .25 sec

    2. Wait .25 sec

    3. Pulse UI[18] Prod start .25 sec



    Robot Main

    1. Call auto home

    2. ...rest of your program


    Additionally in the PLC add a boolean connected to UI hold, UI start And UI reset. Make buttons for them on your HMI, then you can pause, reset, resume.

    You definitely need to replace the D batteries to ensure mastering is maintained.


    The SRAM can be restored from an image backup, so not a big risk there.


    Wouldn't hurt to make sure a quick master reference is set, but new D batteries should cover you.

    The user and tool frames must be set up exactly the same relative to the work piece. That does not mean they need to be the exact same values, and likely will not be. You need to manually setup\touch up those frames to make them right.


    Different models of arm may have different reach capabilities you would need to watch out for.


    Different controllers or software versions\options may have some instructions that are not compatible with each other. Usually if set the programs up to work with the oldest, most basic version you have then it will be compatible with the newer versions.

    The easy way to check payload settings is menu>system>motion, but I guess the system variables would show the same info.


    Aux axis would have settings such as load inertia ratio, gear ratio, acceleration, max speed. These settings can be viewed and modified in a controlled start under the maintenance menu. Maybe can find them in the system variables also. Be careful not to change the settings unless you mean to. Wouldn't hurt to take an image backup first.


    Sounds like you need to check the speed. First make sure the programmed speed and override is the same on both robots. Then check the aux settings in the controlled start maintenance menu.


    To me that warning sounds like it's spinning too fast to keep track of the marker pulse???

    Neither FTP nor HTTP will be "real time" but either protocol may be good enough depending on what you are trying to do. However FTP will require you have a method in place to compile ascii LS to binary TP. Two-way comm is possible with both FTP and HTTP, but will require the PC program to constantly poll the robot for whatever data you want to read. All interaction would be initiated by the PC.