Posts by Nation

    DCS is complaining because it is not getting those signals from a safety PLC.

    You will have to disable DCS, or disable the SAFEIO mapping in the DCS menu that is driving those faults.

    In SAFEIO it would be a CSI bit, but which one depends on how it is mapped. The CSI bit would be mapped to a SSO bit, so look for what is driving those.

    They are not accessible from the teach pendant. You will have to write them offline as a .ls file, and then load that into the robot if you have ASCII upload, or compile it with roboguide if you do not.

    That is one of the quirks with using that variable. I only use it for outputting single step status. Never writing to it, as I've had the same issues as you are seeing.

    I usually just setup the system to turn off single step when the robot is fired up in auto, by using the production check under program select under the setup menu.

    As someone who has written a couple of company robotic programming standards, and implemented many more, I've never seen something like that.

    Most customers like having the bulk of their motion path in a single program, separated by process, or part, but a program per motion? That would be a pain in the ass. I imagine it would destroy the motion planner's ability to look ahead. The path would be very jerky.

    I would like to read these standards that these mechanical engineers are referencing. Might be good for a laugh.

    Looks for the raising edge of a signal. If your signal is already on, it will still wait at that line, unlike ON.

    1.with any "built in procedure" all in/out have to be populated? For example 'GET_TPE_PRM(x,x,x,x,x,x)'.....

    Correct. I'm not sure if Karel even supports optional arguments. Would be something to look into, but in this case, none are optional.

    2.also depending on the Data type of the TP argument only one of the variables will be populated,even though all 3 are shown, int_value, Real_value, or str_value?

    Also correct. The others are there in case the user passes in a real or a string. Like Titus said, data_type will tell you what came in, then you use that to know which var to look at. Pretty clunky, but that is Karel in general.

    Guess I will just have to accept this and learn that the manual isn't entirely right.

    Haha, welcome to the world of Karel.

    22 GET_TPE_PRM(1, data_type, int_value, status)

    ^ ERROR

    ROUTINE called has less arguments than ROUTINE definition. Routine: GET_TPE_PRM

    You have to use the amount of arguments defined for that routine. None of them are optional. Doesn't matter if you don't use them later, they still need to be populated.


    26 IF Data_type <> PARM_INTEGER THEN -- make sure parameter is an integer

    ^ ERROR

    PARM_INTEGER was probably a constant defined earlier in the program. I don't think it is a global constant. That, or it was imported. Check the top of the example program.

    My Karel joint conversion program uses GET_TPE_PRM quite a bit. Check it out here.

    You have to create a file named argdispeg01.dt, load it, and reboot the robot.

    Here is what the contents of the file looks like on a job I did:

    The handlingtool manual goes over it pretty well.

    If you right click on the group of the robot under the tree, you can output it as a .iges file. This file will be significantly reduced in quality however. More jaggy.

    Yesterday, I got called out to a customer of mine with a weird issue on one of their old robots they use in their lab. An old R2000iA/165F running SpotTool+ 6.40.

    They were trying to use the style method of starting the robot, but every time the PLC sent a start signal, the robot would reject the start (SYST-011) with the reason of SYST-073, which according to the error manual states:


    SYST-073 Manual selection mismatch

    Cause: The style input does not match the manually selected style.

    Remedy: The PLC must send a style code that matches the manual selection.

    Which is very descriptive and helpful.

    What does it mean manually selected style? Where is this set? The style program exists, was defined in the style table, and was enabled. The bits for style selection were coming across from the PLC fine as well.