Posts by DuhbCakes

    you cannot access that variable on 8.3 for some reason, however you can still change $REFPOSMAXNO and then change the values inside each field of $REFPOS1[#]

    interestingly enough this lets you change the output signal to somthing other than a RO or DO. the default setting for $REFPOS1[1].$DOUT_TYPE = 2 (Digital Out) this can be changed to anything you need. for example 35 sets it to a Flag. $REFPOS1[1].$DOUT_INDX = output number desired.

    for a full ist of io types you can check out kliotyps.kl. this file should be included with any installation of Roboguide products including OLPC or WinOLPC.

    i have done it in Karel, but i dont think you are going to get the precision you are hoping for if that pdf is any indication.

    you can create a csv file as a FILE variable, and use the WRITE built in to fill each field and include a comma as a deliminator.

    ROUTINE output_csv
    i,ii : INTEGER
    FOR i = 1 to MAX_LOG_SIZE DO
    -- Write each log to csv file.
    WRITE log_file(fc_data[i].fs_force[ii]::18::3,',')
    WRITE log_file(CR)
    END output_csv
    ROUTINE copy_2_mc
    status : INTEGER
    sExt : STRING[3]
    sLogFile : STRING[12]
    sLogFile = LogFileName + '.csv';
    OPEN FILE log_file ('RW', sLogFile)
    status = IO_STATUS(log_file)
    IF(status = 0) THEN
    CLOSE FILE log_file
    END copy_2_mc

    the registers can contain integers or reals. Karel does not have floats, or any other format for very accurate calculations. Registers can be up to 32 bits using 2's compliment signed doubleword. This gives you a range From −2,147,483,648 to 2,147,483,647, from −(231) to 231 − 1. when a number smaller than 1.0 is needed, the karel shell will convert it to a 32 bit REAL. i suspect it uses IEEE 754, so it has a significance of 7 digits. this gives a range From -3.4028236E+38 through -1.175494E-38, 0.0, and from +1.175494E-38 through +3.4028236E+38, All REAL variables with magnitudes between -1.175494E- 38 and +1.175494E-38 are treated as 0.0.

    i often have customers who want offsets displayed in thousandths of an inch. this poses a problem, as the built in hmi displays on the TP do not represent anything smaller than .0001 without converting it to scientific notation. when you start doing calculations at that level i recommend converting them to integers first and doing your calculations with whole numbers.

    here is a excerpt from a wiki dealing with it.

    Addition and subtraction[edit]
    A simple method to add floating-point numbers is to first represent them with the same exponent. In the example below, the second number is shifted right by three digits, and we then proceed with the usual addition method:

    123456.7 = 1.234567 × 10^5
    101.7654 = 1.017654 × 10^2 = 0.001017654 × 10^5
    123456.7 + 101.7654 = (1.234567 × 10^5) + (1.017654 × 10^2)
    = (1.234567 × 10^5) + (0.001017654 × 10^5)
    = (1.234567 + 0.001017654) × 10^5
    = 1.235584654 × 10^5
    In detail:

    e=5; s=1.234567 (123456.7)
    + e=2; s=1.017654 (101.7654)
    e=5; s=1.234567
    + e=5; s=0.001017654 (after shifting)
    e=5; s=1.235584654 (true sum: 123558.4654)
    This is the true result, the exact sum of the operands. It will be rounded to seven digits and then normalized if necessary. The final result is

    e=5; s=1.235585 (final sum: 123558.5)
    Note that the low three digits of the second operand (654) are essentially lost. This is round-off error. In extreme cases, the sum of two non-zero numbers may be equal to one of them:

    e=5; s=1.234567
    + e=−3; s=9.876543
    e=5; s=1.234567
    + e=5; s=0.00000009876543 (after shifting)
    e=5; s=1.23456709876543 (true sum)
    e=5; s=1.234567 (after rounding/normalization)
    Note that in the above conceptual examples it would appear that a large number of extra digits would need to be provided by the adder to ensure correct rounding: in fact for binary addition or subtraction using careful implementation techniques only two extra guard bits and one extra sticky bit need to be carried beyond the precision of the operands.[11]

    Another problem of loss of significance occurs when two close numbers are subtracted. In the following example e = 5; s = 1.234571 and e = 5; s = 1.234567 are representations of the rationals 123457.1467 and 123456.659.

    e=5; s=1.234571
    − e=5; s=1.234567
    e=5; s=0.000004
    e=−1; s=4.000000 (after rounding/normalization)
    The best representation of this difference is e = −1; s = 4.877000, which differs more than 20% from e = −1; s = 4.000000. In extreme cases, all significant digits of precision can be lost (although gradual underflow ensures that the result will not be zero unless the two operands were equal). This cancellation illustrates the danger in assuming that all of the digits of a computed result are meaningful. Dealing with the consequences of these errors is a topic in numerical analysis; see also Accuracy problems.

    Multiplication and division[edit]
    To multiply, the significands are multiplied while the exponents are added, and the result is rounded and normalized.

    e=3; s=4.734612
    × e=5; s=5.417242
    e=8; s=25.648538980104 (true product)
    e=8; s=25.64854 (after rounding)
    e=9; s=2.564854 (after normalization)
    Similarly, division is accomplished by subtracting the divisor's exponent from the dividend's exponent, and dividing the dividend's significand by the divisor's significand.

    Quick mastery is a way of restoring master counts. in order to use quick mastery it has to be set up already. Fanuc does not set up quick master on pipeline robots, so if you want to use it, you will have to set it up yourself.

    quick mastery takes a saved position and a set of encoder counts that matches the position. you can use it to get your counts back within one motor revolution. you can also use it to force in old counts see…t-forum/r-30ia-mastering/

    variables of interest are

    $DMR_GRP[1].$REF_POS (joint angles saved in radians)

    if you replace or uncouple a motor or encoder, the data for that joint is now useless. so after any replacements be sure to set up a new quick mastery.

    Fanuc does not set the quick master by default for some reason. The robot ships with a teachpendent box that contains the teach pendent and a bag of fuses. also included is a sheet of paper with the encoder counts. it will list them by axis. $DMR_GRP[1].Master_Coun[1]

    if you go into your reference counts and put these values in, and zero out all of the ref positions (they are in radians) set the quick_master variable to TRUE, and you should be able to move back to zero, and quick master. this will restore your factory counts.

    lets say that your sheet has these numbers on it. currently your actual numbers dont match, but we will make them.

    [1] 45657
    [2] 987654
    [3] 48465
    [4] 9987622
    [5] 1111
    [6] 12377
    [7] 0
    [8] 0
    [9] 0

    set your ref counts equal to the above numbers.

    [1] 45657
    [2] 987654
    [3] 48465
    [4] 9987622
    [5] 1111
    [6] 12377
    [7] 0
    [8] 0
    [9] 0

    Set the reference position to exactly zero. if you use the set quick reference it will often put the angle at something like -.00 so go in and turn them all to 0.00

    [1] 0.000
    [2] 0.000
    [3] 0.000
    [4] 0.000
    [5] 0.000
    [6] 0.000
    [7] 0.000
    [8] 0.000
    [9] 0.000

    set the quick master set to true so that you can use it to restore mastery.


    then go back to your mastery screen and choose quick master, then calibrate.

    run it to zero, if you are off it will be by a single motor revolution. overshoot the witness mark and try it again. eventually they will all snap into position. if your new mastery counts don't match up at all, bu the position is correct it probably just lost the motor revolution info. the new counts will be off by a factor of exactly 2^18 . as there are 524288 counts in a single motor revolution. the high order bits are where the motor revolutions are saved, and there is no good way of getting that back.

    hope this helps. good luck

    works great on a real robot. i tried it on handlingtool 8.2. i took a backup of the robot and serialized the one in roboguide, and it still didn't work in roboguide. the data isnt saved in the or the files. i loaded some on my robot from the roboguide cell and it didnt wipe out my local codes.

    level="0" const="20" access="0" /> <!-- Jog Access-Prohibits WPR, but allows XYZ, JGFRM and Group 1 are forced

    closest thing i could find. not completely what you want. i would probably make a karel program that just keeps them from using the jog keys on the TP , force and alarm or something when one of them is pressed.

    that depends on who is controlling the whole system. if the robot is the sole provider of logic, then wait statements work well, as they will troubleshoot the problem from the teach pendent. if a plc has the sensor, then using rsr/pns works well.

    you can do it like you would on a robot as well. you just need to set the path location first. change the path in the virtual robot settings tab at the bottom of the teach pendent.

    what is the tree look like?
    something like this?

    GPM 1
    - Histogram 1
    - Histogram 2
    - Conditional 1
    - Evaluation 1

    the order in which your tree is setup matters. its possible that one of the higher processes is not allowing another process to run.

    There are a lot of different interfaces you could have, it is dependent on the type of controller ect. A 30iA comes in a lot of different flavors. A Cabinet, B Cabinet, Open Air, European CE, Mate, Mate CE. Paint. etc. beyond that the I/O card itself can be a couple of different options. if it is a yellow box, it is most likely Model A I/O (not to be confused with A Cabinet R-30iA)

    if that is the case, you can find the info you need in the documentation for that controller in chapter 6 of MARMGIOMA12801E_REV_F. You should have a CD that came with the robot, or you can contact Fanuc or your integrator.

    1 : I0+
    2 : I1+
    3 : V0+
    4 : V1-
    5 : V0-
    6 : V1-
    7 : COM0
    8 : COM1
    9 : FG0
    10: FG1
    11: I2+
    12: I3+
    13: V2+
    14: V3+

    the first place i would look is the RP1 Cable. it should terminate inside your controller on the servo amplifier as a 50 pin connector labeled CRF7. power up your controller and check to see if there is 5v going to each axis. they are paired as such.

    J1 13: 5v -> 43 0v
    J2 14: 5v -> 44 0v
    J1 15: 5v -> 45 0v
    J1 16: 5v -> 46 0v
    J1 17: 5v -> 47 0v
    J1 18: 5v -> 48 0v

    this will tell you if your amplifier is producing the voltage you need for those joints. you can check the other side of the cable to see if the batteries produce voltage across those pins. if either of them are dead, then you have isolated which side the problem is on.

    i suspect that it is one of the following items.

    servo amp is bad
    rp1 cable is bad
    robot internal cable assembly (inside the robot arm)

    good luck.

    the error should have a hex code that will tell you which program is causing the problem. If you are not using any custom Karel programs, or a vision/pallet built in then likely you have a core PB corruption. Reinstalling the core software will normally take care of it. Make sure to load on the most resent auto update as well. Restoring from an Image will also replace the core files.

    Monitor the safety variable. You can use the Group Output to run the bitwise operation for you, and map the result to a flag. Or external digital outputs.

    If you have a recent enough controller, then you should have access to flags. Flags are internal Boolean logic, they function like I/O, but no field devices access them. $MIX_LOGIC.$use_flg must be set to TRUE for the flags to be displayed. Flags are mapped like any other I/O in logic.

    Flags are on Rack 34 Slot 1. If you want to push it to a output, you can just map an output either to the flag itself, or you can use I/O Interconnect, or write a BG program to set them equal to each other.

    BG Logic EX.
    : DO[Fence]=F[4:Fence] ;

    Map to DO[i].
    Range [i] - [i+10] Rack 34 Slot 1 Start 1

    see attatched picture.
    Category: Variables
    This variable can be set to a register in logic and have bitwise operations performed to determine the cause of safety faults.
    1 = E-stop on controller.
    2 = E-stop on Teach pendent
    3 = Deadman Trigger on Teach pendent
    4 = Fence circuit
    5 = Robot Overtravel
    6 = Hand Broken
    7 = External E-stop
    8 = Pressure Abnormal
    9 = Belt Broken
    10 = Teach Pendent Enabled
    11 = Fault Alarm

    Minimum: Not available Maximum: Not available Default: Not available KCL/Data: Not available Program: RO UIF: Not available CRTL: Not available Data Type: INTEGER_SK Memory: Not available

    Name: Safety signals status

    Description: $MOR.$safety_stat is bit parameter of safety signals. The bit assignments are as follows. * Bit position for $safety_stat MFS_EMGOP 1 MFS_EMGTP 2 MFS_DEADMAN 4 MFS_FENCE 8 MFS_ROT 16 MFS_HBK 32 MFS_EMGEX 64 MFS_PPABN 128 MFS_BELTBREAK 256 MFS_ENABLE 512 MFS_FALM 1024 When FLTR task detects the above alarms, FLTR set the bit which corresponds to the alarm.

    Power Up: At a cold start, this variable is reset to its default.

    i would investigate the $MOR_Structure variable for tcp speed.

    DMR_GRP[i].SPC_COUNT - current encoder counts

    $PARAM_GROUP[i].$encscales[9] - pulses per degree or mm.

    Fanuc's stock response if you asked them would be to update the teach pendent firmware, and run an auto update. the early rev's of robots always have some issues. i have noticed a lot of them on the 30iB.

Advertising from our partners