MakeTP and SetRobot tools

    I don't have a RoboGuide license available at the moment, so I'm trying to use the MakeTP (installed by RoboGuide V9) tool to compile LS files into TPs that I can load. And I'm running into an odd problem. Basically, if I ASCII export a TP file from the robot, and try to run MakeTP on it without any edits, MakeTp throws errors. After doing some tinkering, I've found that MakeTP seems to be choking on any and all of the Macro calls in the LS file.


    I'm guessing that this might be because I don't have a robot.cfg file for this robot? As I understand it, I need to run maketp /config <file> on the config file before running MakeTP on the actual LS file. And I have to create the config file using SetRobot. Is that correct?


    However, I haven't been able to run SetRobot correctly. If I just run SetRobot from the command line, it pops open a "Select from the Robot Neighborhood" dialog box that wants me to select a robot from my RoboGuide cells, but it won't let me navigate outside of the RoboGuide tree. And since I don't have a virtual cell for this robot, this presents a problem.


    I've tried running SetRobot D:\BackupDir\ where D:\backupdir\ contains a full IMG backup of the robot, but it just opens the same dialog box. Trying to run SetRobot with -? or /? switches does the same thing -- SetRobot doesn't seem to accept any arguments, and nothing I've tried gives me the typical "help" that most DOS command (including MakeTP) throw for the '/?' switch.

    You need to create a Roboguide cell will all the options you ever imagine you would want and then run setrobot on that. Keep that config file and you will be good. If you don't have a roboguide license then you will need to at least get a free trial running to create the cell. Alternatively, you could also get a free trial of OLPCPro to create the cell.


    Without the virtual cell created you are dead in the water. It will still work after the trial is up but you need to have it created initially.

    Not sure if this will work for maketp. I used to run printtp on an entire AoA backup by copying all of the files into the same directory as printtp. Unfortunately I can't test it because new IT security measures now prevent me from running any of the executables in the WinOLPC folder.

    Quote from Hazard

    Not sure if this will work for maketp. I used to run printtp on an entire AoA backup by copying all of the files into the same directory as printtp. Unfortunately I can't test it because new IT security measures now prevent me from running any of the executables in the WinOLPC folder.

    Did you have to run PrintTP against each .TP file, one at a time? Because whenever I try to do printtp D:\directory\*.tp it just throws "copy to/from directory failed." But it works if I type out an entire single file name.


    Quote from HawkME

    You need to create a Roboguide cell will all the options you ever imagine you would want and then run setrobot on that. Keep that config file and you will be good. If you don't have a roboguide license then you will need to at least get a free trial running to create the cell. Alternatively, you could also get a free trial of OLPCPro to create the cell.


    Without the virtual cell created you are dead in the water. It will still work after the trial is up but you need to have it created initially.

    Does the robot model and/or OS version matter, or is it just the options?


    Would this mismatch in options explain why MakeTP is choking on Macro calls, though? I thought Macros were a standard part of all Fanuc controllers.


    After some experimentation, I've narrowed things down a bit: lines that call un-installed options throw an error that says that specifically. But when MakeTP chokes on the Macro calls, the error is simply "invalid coding of line." It doesn't seem to make any different if the linked Macro is a TP or KAREL program, I get the same fault from both. And I know the Macros are good, as they're runnable on the robot.

    Version can matter but generally less important on newer robots. What versions are you dealing with?


    Directly calling macro is really no different then calling or running a program. I would try replacing your direct macros with a call or run statement depending on your need and see if it compiled. Personally, I avoid using macros because I think they are implemented poorly in the Fanuc environment.


    Also, printtp is the opposite of maketp. It converts binary to ascii.

    Quote from HawkME

    Directly calling macro is really no different then calling or running a program. I would try replacing your direct macros with a call or run statement depending on your need and see if it compiled. Personally, I avoid using macros because I think they are implemented poorly in the Fanuc environment.

    Unfortunately, I'm stuck with a standard package and template dictated by the customer. Which includes a large number of pre-made Macros that I have to use, and cannot modify.

    Quote from HawkME

    Also, printtp is the opposite of maketp. It converts binary to ascii.

    Yeah, I know -- But since Hazard brought it up, I gave it a quick try, and ran into the wildcard issue.

    Quote from HawkME

    Version can matter but generally less important on newer robots. What versions are you dealing with?

    Looks like 8.33, which is odd given that this robot is literally brand new. Probably the Big Customer's custom core load is built on 8.3 and they're not ready to update yet.


    I asked about the version mainly b/c on everything else I've ever done on Fanucs, they seem to be extremely fussy about exact version numbers -- packages for version 9.1.2.5 won't work on version 9.1.2.4, figuratively speaking.

    Quote

    Did you have to run PrintTP against each .TP file, one at a time? Because whenever I try to do printtp D:\directory\*.tp it just throws "copy to/from directory failed." But it works if I type out an entire single file name.

    No. I just copied all of the .tp into the same folder as the printtp executable then executed the printall.bat from the same folder. No subfolders - all files in same folder. The printall.bat has the following in it:


    echo off

    for /f "tokens=*" %%a in ('dir /b *.tp') do printtp %%a %%a.txt


    I am not sure what version this came from. I got it online somewhere years before I convinced management to buy me roboguide.

Advertising from our partners