Posts by Nation

    While word is fine for the merge and search method described above, I'm seconding hermann. Don't use it for editing .ls files. Only use a text editor for that, such as notepad, notepad++, ultraedit, or equivalent.


    The reason is that word will add additional meta data to the file, making it unloadable.

    Well, JT hasn't logged in in 2 years, so I have my doubts that he will see your request.


    However, even without the source code, you can hex edit the karel file to make it work on v9 controllers.


    This is what I did, and I tested it with v9.30 Handlingtool, and it works.


    Modified .pc file is attached.

    Files

    Are all the parts circular in nature? You may be able to get away with just teaching a circle as your gpm, and opening up some of the parameters so it finds anything circular. I did this in a foundry with a ton of various castings.

    Could be inertia mismatch. The load the servo is driving is not supposed to be more than a factor of 5 greater than the servo's motor inertia. Otherwise jerky operation occurs.

    Close, but I suspect there's one extra link in that chain: CNC controllers. I don't know for certain, but what I've seen strongly suggests to me that Fanuc robot controllers and CNC controllers are almost the same beasts, under the skin -- the robot controllers are just "CNCs" with lots of extra axes, and a more complex kinematic model. CNCs came along first, and Fanuc is pretty big in the CNC controller space. And CNC controllers started out a lot closer to early microcontrollers than computers -- G-Code still looks a lot more like Assembly language. I'd be willing to bet that, when Fanuc decided to get into robots, they grabbed their existing CNC controller and just added more axes. There's obviously been some divergent evolution since then, but the roots still show.


    Its the reason they changed the naming pattern from RJ3 to R30iA, to commonize the naming scheme with their CNC line. One of the Fanuc salesmen told me this though, so take that with a grain of salt. Now it is diverging again, as the CNCs are up to 32i, while the robots are still at 30i.

    Sorry for my lack explanation :-)


    By the way, do you have explanation of every karel program explanation?

    I want to study about it.

    No I do not. I found the INVERSE explanation in the iRvision manual, under section 8.1 Vision Support Tools. For GET_HOME I figured it out after someone ran it and blew out PR[1] on a cell I was working on.


    Thanks
    then, do you have ever tried this function?
    if yes, do you have some example for me to learn?

    There is the R798 DRAM File Storage Option. It allows the controller to fetch tp files from locations other than CMOS. I haven't messed with it, but it looks like remote locations are possible.

    There is some wiggle room. I personally have taken a RJ3iB Ipendant and used it on a R30iA controller. The operator had left the R30iA's pendant on a chain conveyor and it got sucked in and destroyed. It just needed a firmware update to work. I would call Fanuc before attempting such swaps though, and I did in that case.

    You don't. Leave the jumpers in and use the Safe I/O area under the DCS menu to connect the safety level input/outputs appropriately. The DCS manual goes over what the bits do.


    Here is an example I've used on a past job:

    Code
    C_SVOFF Servo off command SSO[1]=CSI[1]
    C_FENCE Fence chain ok SSO[2]=CSI[2]
    C_EXEMG External Emergency chain ok. SSO[3]=CSI[3]
    C_SVDISC Servo disconnect SSO[4]=CSI[4]
    C_NTED External enabling device. SSO[5]=CSI[5]
    OPEMG Either of the robot's e-stops are depressed. CSO[1]=SSI[6]
    AUTO Robot in auto. CSO[2]=SSI[7]
    T1 Robot in T1 mode. CSO[3]=SSI[8]
    T2 Robot in T2 mode. CSO[4]=SSI[9]
    NTED Deadman is being held in center position. CSO[5]=SSI[5]

    There is the R798 DRAM File Storage Option. It allows the controller to fetch tp files from locations other than CMOS. I haven't messed with it, but it looks like remote locations are possible.

    My theory:


    I believe Fanuc modeled portions of their TP language on assembly, because it is simple.


    I think the reason they use registers, and the reason they are named registers, is because registers are used heavily in assembly language. A typical CPU has various registers that can store values, and are always at fixed address, so that is why I believe Fanuc went this route.

    This makes the barrier to entry for the average plant guy on the floor pretty low. For example, they don't have to know about the various types of data types, or what a variable is, or how it is scoped. Here are your registers, you get 200 of them, they store numbers, you can get to them from any program, have fun. Same for PRs, but they are positions.


    This is a double edge sword though, as while it easy to understand, TP lacks (or lacked for a long time) some of the more basic program flow structures virtually every language since the 70s has possessed. This also makes doing anything complicated in TP a pain, since you have to have work around the limitations of the language. This also tie's into SkyeFire's point where you need to buy an option to do anything complicated.