I should add, you could also use a JPC (Joint Position Check) to enable or disable another JPC.
This is all covered in the DCS manual.
I should add, you could also use a JPC (Joint Position Check) to enable or disable another JPC.
This is all covered in the DCS manual.
Just to reiterate what Hermann said, there should be a paper with the robot that list the installed options, and also any available uninstalled options.
Also, why can't you discuss what options were ordered with the person who ordered the robot? Or, why can't you just go to the Fanuc website and lookup the specs?
This is critical information. I wouldn't start programming or simulating a robot without it. All your effort may be going to waste!
PalletTool does not generate 1000+ line programs. PalletTool programs are short and concise. They rely on karel variables for position data.
Your statement makes no sense and is not believable. Please prove me wrong by posting the program.
IMHO, Karel should only be used for functions that cannot be achieved through TPP.
Why? Because Karel is closed source. It MUST be edited offline and then recompiled. You MUST have the latest source code to do this, which can't be easily verified. Keep Karel code for Karel only functions, then do the rest with TPP. TPP can be easily edited offline and there is no question as to the validity of the current code. TPP is remarkably easy to edit online, through the robot, via the teach pendant.
The teach pendant is different, but not evil. It was designed to make online edits easy. You don't even need to stop or abort the robot to make edits. Quit fighting what is easy and best. Accept TPP for what it is and learn to work with it.
That being said, if you need to use Karel, check out the latest Karel reference manual, everything you need is in there for robot IO. Again this is the hard way to go, but if you must, it will work. But WHY?
What are you trying to do. Those variables look to be correct, but they require a power cycle.
DCS can dynamically limit an axis, but would require a safety input to enable and disable.
What does the real robot have for software? HandlingTool or PalletTool?
That is what will determine which Fanuc PC software suite you use. It is not just something you decide later, it is based upon the actual robot.
Okay. It's time to stop and listen. Ice is back...
You mention PalletPro. And then HandlingPro.
What software does you're real physical robot have? If it has PalletTool, or PalletTool Turbo, you should be simulating this in PalletPro.
If your real physical robot does not have some version of PalletTool, don't bother with PalletPro, or trying to run PalletPro generated unit loads in a virtual robot running in the HandlingPro environment. PalletTool / PalletPro patterns are not compatable with HandlingTool / Handling Pro.
HandlingTool / HandlingPro and PalletTool / PalletPro are different. PalletTool / PalletPro are derived from HandlingTool / HandlingPro.
A real robot with PalletTool software can be restored into a HandlingTool RoboGuide workcell. Is this what you are having issues with?
This is so confusing. What is actually going on?
And oh F***! What's this about a YouTube video?
Please no duplicate threads, it's against the rules. Keep this in your pallet tool thread, it's a better place.
Yes you can, but it is not the easiest thing to do. I would start with the basics and master that first. If I am working on a cell that someone else did and restoring from a backup, I usually just remove anything extra just and try to strip it down to one infeed, one pallet station, disable pallet placement and so on. My initial goal is always just to be able to create new unit loads. Once I get that working, then I can add more features back in as needed.
As to the disappearing cases, what gripper is assigned to the unit load, and does that gripper have the product present signals defined in the gripper setup?
Is your computer connected to the robot via ethernet? If so, make sure the real robot is setup to receive patterns over ethernet, the setting is under Setup > Pallet System:
Then in RoboGuide go to File > Download. Add the robot's IP, then select the unit load file (PMULxxx.DT) and press the Download button. A message on the real robot's teach pendant will confirm if this is successful. The main reason for not being successful would be due to not aborting the robot first if it is currently running that pattern.
Are you sure you have the correct harmonic drive part number? It almost seems the gear ratio is off.
Also, why did the first motor and reducer only last a week?
It sounds like your mastering is off. It doesn't take much, and the witness marks on LR Mates are a joke.
This procedure can help improve your mastering.
Fanuc's specific math for CNT is their IP, and they don't share it with anyone.
This post (#2 from this thread) has more information than what Fanuc will officially share.
Just like your first post in this thread stated, you will have to reverse engineer their path planner. There is nothing more that you will get from Fanuc.
The handling tool manual has one four sentence paragraph that goes over CNT, and one picture. In my manual, MAROUHT9307191E REV B, it starts on page 7-80.
Uggh. No Frames at all. Thats ugly. The fact that you don't have a UTOOL defined would make jogging all but the simplest of tools a nightmare. What is this robot doing, and what does it's end effector look like?
First of all, why bother using the user or jog frame coordinate system if you don't have any frames?
Second, what do you mean by rolling? When jogging X, Y, or Z in a Cartesian coordinate system (any other mode than joint), the robot will maintain the orientation of the tool center point, which in this case is the middle of the faceplate. This means that the wrist axes, J4, J5, and J6, will all move to maintain the orientation. This is normal.
Could you share a picture of your overall workcell and maybe a short video of your issue? A few pictures of your tool along the path that you are jogging might help instead of a video if you don't have an extra pair of hands.
I agree with kwakisaki about the unintended effects of trying to fix something that isn't broken.
But, if you still want to do this, why not just send a separate DO for each reference position and "OR" the logic on the PLC side? That allows you to keep the simple setup that reference positions offer, without having to try and hack the system.
There are a lot of different options. What are you trying to do?
What kind of mechanical arm is this? E.G. M410iHS
EPeters1 is almost correct. While his method would work if you change a system variable, by default, P[x] points are stored with a User and Tool frame. If you try to move to them with the wrong frames selected, you will get an fault (frame type mismatch). There is a system variable to skip the frame type check, but it is advisable to keep it set to its default value.
Instead of using P[x] points, you would use Position Registers PR[x]. Position Registers are not stored with a user or tool frame. They are also global, i.e. they can be accessed from any program, not just the program they were created in. Also, each element of a position register is addressable, meaning you can modify any of the XYZWPR individually.
In theory, this plan will work to only use one taught position register, but it will only work if your individual tool frames are taught accurately enough to deal with any non-compliance that your fixture may have.
Looks like hermann beat me to it while I was typing
From the screen that you posted the picture of, press the previous key, that will bring you to a list of all of your jog frames. Then press F3 for other and select tool frame:
Then use the arrow keys to go down to tool frame 10 and then press F2 for Detail:
A picture of all ten tool frames before you press F2 for detail would also be nice, but is not necessary.
Multiple solutions have been provided. If all your inputs are off, the program will execute label 101. Put a jump label 100 after your three conditional statements.
Also, learn to use the step button.