Advertising

Posts by SkyeFire

    My question though is if the BINPICKING_TPV() is running on SPS.sub, how does the program know to reset if it gets stuck inside BINPICKING_TPV()? I thought the interpreter could only process what it's currently executing plus the advance run. Is it able to continue checking SPS.sub, or does this only get checked after you've finished running through BINPICKING_TPV()?

    That's not how this works. The SPS runs in the Level 0 interpreter, and the "normal" programs run in the Level 1 Interpreter. Each interpreter can issue $CMD Run/Cancel commands against the other interpreter, but not against itself.


    So when the SPS is triggered by some event to issue a $CMD RUN for BinPicking_TPV, that program gets loaded into the L1 Interpreter, and runs there. It is not run as a subroutine of the SPS, and if BinPicking_TPV gets hung waiting for something, the SPS keeps right on going.

    (or should -- a well-written SPS has no WAIT statements or "blocking", but runs as a state machine. A badly written SPS could be written in such a way that a WAIT in the BinPicking_TPV program could cause the SPS to hang)


    However, there are a few caveats: $CMD RUN does not actually start program execution -- it works more like the Select button on the teach pendant. The robot must still receive $EXT_START (for EXT mode) or have the start button on the pendant pressed (T1, T2, AUT modes).


    Also, issuing a $CMD RUN when the interpreter is already occupied won't work. That is why the example program uses $PRO_STATE and other $CMD commands, in proper sequence, to first Cancel the current program in the L1 interpreter, then load BinPicking_TPV.

    Yeah was able to re-create the issue, seems like the second LIN movement causes it to go into lala land when running through the code in manual mode, why would this be, tried using PTP instead which at least casues and error and stops it from moving, is the base reference being reset after the first LIN move

    PTP commands can essentially predict when the endpoint of a motion is going to be unreachable for some reason. LINs and CIRCs, however, can't. It's basically b/c a LIN or CIRC consists of many tiny PTP motions, and the "predictor" can only read one PTP ahead.


    The fact that the PTP throws an error tells us something about the root cause -- the calculated destination is illegal -- either beyond the robot's physical reach, or violating an axis limit. It's not a path error -- it's possible to have a LIN move where the end point is legal, but the linear path will violate limits or collide en route.


    The illegal destination could be due to bad $BASE or $TOOL settings, or something in the calculation of pLayerPosition itself. I notice that pLayerPosition is being shifted relative to its previous position -- if, say, someone were to re-run that portion of the program multiple times, without "resetting" the position, it could "walk" the calculated position well outside of the robot's reach envelope.

    What do you mean by 'root directory of the cell' exactly, what other files are there.

    In my case, /Documents/My WorkCells/CellName/


    This seems to be the "default" location, if I just create the cell, right-click on Files, and select "new file".

    You can add, create, edit and build files on local hard disk.

    That's what I'd like to do, but am having trouble with.

    You can load the files from local disk to the simulated robot by 'right click' and 'load'.

    I actually haven't needed to do that -- it happens automagically when I hit Build. The compiled program just shows up (or gets updated) in the robot's Programs section.

    You can save files from simulated robot to lokal disk, in ASCII or binary format.

    So far, I haven't found any way to save the ASCII version of a PC file. If I lose my "master copy" of the KL file, I'm hosed.

    I can use Notepad++ for the files in the section, and build them in RG (after I have added them once).

    This definitely does not work for me. Making changes in NotePad++ doesn't seem to carry into RG, even if I reboot RG entirely. But then, I can't figure out where RG is keeping all these files. Even when I deliberately change the Files Default Directory, the files in that directory do not update when I use Save or Build in RG. RG is keeping the "master copies" somewhere, but I can't figure out where. Or even force RG to use the directory of my choosing, so far.


    It does appear that using the File Add function creates a link to a file's location, rather than copying the file into whatever RG is using as a "working directory" -- when I used Add on some files that were on a USB drive, they all vanished from RG when I unplugged the USB.

    The only silly thing is: If the program that I want to build is selected in the simulated robot the build will fail after waiting for a quite long time.

    That one I ran into a lot, especially since I'm working on (among other things) background programs (not BG-Logic) that start on boot and run forever. What I discovered is that, if the program I'm trying to Build is still running, or even just selected, on the virtual robot, that blocks the Build process. Or, rather, probably blocks the automatic "export" to the virtual robot. Generally, terminating my background program or doing an Abort All on the virtual pendant fixes this.

    RESUME sends the program pointer back to the level where the Interrupt was declared. Could be one level up, could be ten. So if Main has the DECL INTERRUPT, then calls Sub1, which calls Sub2, which calls Sub3, which calls Sub4, and Sub4 is where the program pointer is when the Interrupt fires, the program pointer will jump back to Main, one line after the call to Sub1, once the RESUME command executes.


    So you get a lot of control over what the program does, but you also have to structure your programs, subroutines, and interrupts very carefully, with this in mind.

    Command line tools? ???


    I've been using RG's editor b/c I, frankly, am still a rank amateur at TP and KAREL, and needed to hit "build" every few lines to ensure I hadn't created some obscure error that would send me chasing down a rabbit hole for a couple hours (it happened anyway, but less often with the regular compiler feedback).

    i/o was allways gray

    That is the motors icon. It changes from Grey 'O' to Green 'I' when the motors are on.


    Since workspace monitoring is disabled, due to the mastering errors, bypassing the workspaces should not be necessary.


    Likewise, when logged in as Safety Maintenance, any Safe WorkSpace violations should be ignored, to allow the robot to be jogged to a safe location.


    $DRIVES_ON is not a signal you need to tie to $IN[1025] -- it's a pulse the robot needs to receive.


    However, you might need to tie $DRIVES_OFF to $IN[1025]. $DRIVES_OFF is an inverted-logic signal; basically, it turns the drives off if the input goes False. This comes from the days when the signals came over discrete wires from remote sources, and it was desired that the robot stop safely if the cable was broken.

    I'm writing a lot of TP and KAREL in RG. I normally start by right-clicking on "Files" in the navigation tree, "New File", and the file type I want to create. When I do this, the new file appears to be created in the root directory of the cell. Which makes sense, b/c these files are being created at the cell level, not per individual robot. When I use the "build" function, the compiled (TP or PC) version of the ASCII file gets added to the Files tree, and exported into the robot's Program section (I've only been doing this with single-robot cells so far, so I don't know what happens in a multi-robot cell).


    Now, the files being stored in the cell root directory is handy, b/c I can open the ASCII files in parallel in NotePad++, which is nicer than the RG editor for some operations. I'd also been thinking about using Git or some other version control on my source files, after very nearly losing weeks of work when RG crashed and completely corrupted my cell this past weekend.


    But... when I use the "Add" function of "Files", the pattern seems to break down. What I did:

    1. Set the Default Directory in Files to the root directory of the cell

    2. Copied my LS and KL files into that directory (the files did not auto-add themselves to the tree, even after rebooting RG)

    3. Performed a manual "Add Files" on all the LS and KL files. This worked, but...


    Even after that, when I make changes in the RG editor and Save or Build, the changes are not reflected in the actual ASCII files in the cell root directory. Even if I use "Save As," the save path is already defaulted to this directory. Forcing the save generates a "do you want to replace the file" prompt, but if I hit "yes", the actual ASCII file does not update.


    So far, the only way I've been able to force the root-directory ASCII files to update is to do an ASCII backup, then copy the LS files from the backup to the root directory. This doesn't work for the KL files, obviously.


    So... if I want to find a reliable location on my hard drive where all these source files are located, and get updated when I use Save or Build in the RG editor, what do I need to do?

    How is the table rotated? How is the reference frame for the robot created?


    If the table is not being controlled as an external axis of the first robot, then getting both robots to "share" the table is as simple as creating the Base frame the same way in both robots, using the same points. Of course, this is vulnerable to the basic issues of robot accuracy, but if you've been doing milling with your original robot, you probably understand this already.


    Since you're doing milling, I assume you already have good CAD for the dimensions between the robot and the table. Repeating this for the new robot should be straightforward. The key is to ensure that the Base frame both robots use for the table has the same origin and rotation in real space. This will mean that the values in each robot will be different -- for example, if both robots were perfectly mirrored in real space, their respective Base frames would probably have a 180deg A rotation, at minimum.


    Optimally, you should probably align your new KL so that it points the same direction (+/-) as the original. Your CAD data will need to match this. If your KLs are geometrically integrated, you may have to change your external axis settings to match the robot rotation atop the KL.

    Well, I'm still not sure why GET_REG doesn't work the way the manual says it should, but I have collected some more data:


    If the Register is set using SET_INT_REG, then GET_REG will return a False rFlag, an rVal of 0, and a correct iVal. However, the moment I set the Register from the pedant, I'm back to scientific notation.


    I worked out a stupid fix using CNV_REAL_STR followed by CNV_STR_INT, and then someone tapped me on the shoulder and pointed me at TRUNC and ROUND. So I can work around this. But I still cant understand why GET_REG works so strangely.

    Being a KAREL newbie, maybe there's some subtle setting I'm missing, but this has me utterly baffled.


    Using the following KAREL code:

    Code
    VAR
    bRFlag : BOOLEAN -- GET_REG flag
    rVal : REAL -- GET_REG result
    iVal : INTEGER -- GET_REG result
    iStatus : INTEGER -- GET_REG status
    BEGIN
        GET_REG(30, bRFlag, iVal, rVal, iStatus)
    END

    If the value of Register 30 is, say, 5 (not 5.0, just integer 5), what I get for output is 5.00000E+00. And the bRFlag is set True.


    If I set R[30] to, say, 5.7, I get back 5.70000E+00


    In all cases, iVal is 0. bRFlag is always True. iStatus is always 0.


    I'm just trying to use the value of R[30], which should always be an integer, in a SELECT CASE switch, but this... I originally had the GET_REG followed by some "sanitizing" checks for iStatus and bRFLag, but those checks kept failing (due to bRFlag always being True), which is what sent me chasing down this rabbit hole.


    What's worse is that every piece of working example code I can find from other people, use GET_REG the same way I am, and get expected integer results. I'm not finding any functions for converting between real and integer in the KAREL reference manual, and setting iVal=rVal throws a compilation error.

    Okay, the "root" directory for the cell seems to be where my .KL and .LS files are stored, when I create them in RG using the "new file" option. I'm guessing that these files are updated when I use the Save or Build buttons in the RG editor?


    Once I hand-built a new cell with the same configuration, and started trying to import my old files, it turned out to be a real pain -- eventually, I just ended up creating new files with the same names in RG as part of the new cell, then opened my original files in Notepad++ and did massive copy/paste into the RG editor. There must be a better way to do this.


    But my big problem (and one no one can probably help me with) is that somehow, I managed to blow up the new cell, the same as the first one:

    :wallbash:

    I was working on some TP and KAREL programs in RoboGuide, and while operating the virtual pendant, the pendant crashed, followed by some sort of RG crash that threw a cascade of dozens of small error popups, and rendered RG completely nonresponsive. I eventually had to use Task Manager to kill RG and re-start it.


    But now I can't open that cell. Any attempt just freezes up RG entirely, to the point that I have to forcibly reboot my computer, or use the Task Manager to kill RG. When opening the cell, RG just hangs in the "Starting virtual robot simulator" stage, showing "cold1.com complete" in the virtual pendant display.


    So, is there any way to recover my work? Especially my programs -- my KAREL programs were all in the Files section of RoboGuide. I have a recent backup of most of my TP programs in ASCII, but not my KAREL.

    Are these robots brand new? Or are they second-hand?


    Follow the links in the READ FIRST topic and download the manuals for KSS 8.x.


    Step 1: determine all active errors. The message window spanning the top of the pendant display is touchable -- this will expand to fill the entire screen, and show all errors. "Active commands inhibited" is simply a side effect of other errors.


    2: Once the message window is expanded, press the ACKN ALL button (lower right). This will clear all clearable errors. Whatever messages remain are the ones that need to be examined and dealt with.


    3: The main menu can be accessed using the small robot-icon soft button on the pendant screen, top left corner. The menu HELP>INFORMATION should lead to a multi-tab screen that shows the major details of the robot. Write them down, don't take fuzzy photos that people have to struggle with to make out details. The Options tab will also be important, as it will show what optional alternate safeties your robot might be equipped with.


    4: Again, using the Main menu, use FILE>ARCHIVE ALL, and use USB CABINET (after inserting a USB flash drive into the cabinet USB socket). This will create a zip file on the USB drive. In the zip file, will be a file called AM.INI, which summarizes most of the robot's details -- post that file.


    5: go to KUKA's website and download WorkVisual, version 5 or 6. This will be necessary later to perform certain configuration changes, but not immediately.