Typically in industry, you program the robot to not impact its surroundings. No extra checks.
Did you create a tool model? It doesn't look like you did.
Your mastering may be off for J3 if it doesn't align with the DCS model.
With that said, you can use tool switching (DCS Manual, section 7.9.1) to change the currently active tool model, but you need to do it with a safe level input to maintain rating.
The reason I've been pursuing this is because it's my understanding that my main program cannot sufficiently monitor a digital input during the execution of a motion program (is this correct?).
That is what the skip motion option or the monitor command are designed for. The skip monitors IO, or other conditions, during the move, and will finish the move early if the conditions are satisfied. If you don't need the move to stop upon input of the button, you could use the monitor command and a conditional program to set the flag.
Given what you are trying to do, I would simply do it with background logic. Have it watch the button input, and when high, set the flag. Have the main motion task reset the flag when the alternate path is completed. There is an entire thread in the tools forum going over various BG techniques.
Karel can interact with flags. They are represented by the FLG boolean port array.
Disabled zones do not contribute to process time factor.
DCS zones seem like overkill for recovery, but I don't know your cell.
With that said, make sure your tooling definition does not use the box definition. The box definition is like 20x more expensive than all the others. Changing it out for a bunch of line segments is a great way to reduce PTF.
Also, Joint position checks are virtually free, so if you can do your check with those, give that a try. Also, you can use JPCs to enable/disable cart zones. I did this on a cell that had a 25m rail to get the PTF under budget.
The fence and estop circuits are dual contact. Both sets of wires need to have contacts on them. Each pair of contacts need to actuate at the same time.
The way you have it wired will cause single channel faults.
Here is how I would do it:
: --eg: Zero out pr8, and set it to XYZWPR Rep. ;
: PR[8]=LPOS-LPOS ;
: PR[8,1]=(PR[2,1]*5) ;
: PR[8,3]=(PR[4,3]) ;I've done this!
However, I never got to 3d geometries.
Couple of things I would add to SkyeFire's list:
Make sure your plasma cutter has an automation interface. Most commercial plasma cutters do.
Unless you are cutting thick materials, you will want to have torch height compensation. This can either be done in the robot itself, or by a small servo in the tool.
With the tooling, make sure it is electrically isolated from the robot itself. Most robot brands offer insulated faceplates. You don't want the current to go through the robot due to a bad ground or something like that.
What are your values for UTOOL 1, and UFRAME 2? What arm are you using?
The robot will attempt to move the TCP to the point defined in your UFRAME. Fanuc uses euler angles, defined from the currently active frame. We go over how they work in this thread.
Since there are typically multiple solutions to a point, config narrows them down. I made a short video on them years ago:
For our process, it is important that we are able to control the velocity between points. The tooling at the end of the arm runs at a fixed speed. The velocity is low and, and need to have a controlled velocity between points.
Our position maps would contain a list of positions in the format: X ,Y,Z, NX,NY,NZ, Velocity. So point 1 and point 2 may look like: (1,2,3,1,1,1, .01), and (1.1,2,3,1,1,1, .015) which would mean go from point 1 to point 2 at a velocity of .01 mm/min, go to point 3 at .015 mm/min, etc.
Velocities that low may be difficult to achieve. The minimum speed of a move is 1cm/min. Combine that with a 1% override and $MCR.$prgoverride, and you could get there.
There is also a time value for motion of the move (complete the move in x.x seconds), but you will have to know the distance of the move. That could be an option as well.
I am not confident on the robot accurately running at those low speeds. If the speed is that critical, I would verify the robot can preform that speed externally, with a laser tracker, or some other external measurement device. Also, including the override command in the program will cut the amount of motion commands down to 1/2, as a line will need to be used to control the override.
I'm assuming that the NX NY and NZ are rotation vectors. You will have to convert those to Fanuc's euler angle representation.
When I last had this option quoted, it required a full reburn of the OS.
not true. you can use DI/DO without major purchase. Each Robot comes with a plug that can be used to wire DI/DO.
Conditionally true. This only applies if you are purchasing a Mate controller. A normal controller (R30ib+) will not have IO besides the RI/RO for free.
This question reads a lot like it was generated by chatGPT, but I'll bite.
1. Optimal file format: What format (e.g., CSV, XML, binary) works best for transferring large datasets with associated velocity data to a FANUC controller? Additionally, I’d appreciate more information on how to read the file on the robot side and execute the motion to the next position.
Its best to output in Fanuc's native .ls format. There is an option for importing and converting GCode, but I've never tried it. To import .ls files into the robot you will need the ASCII loader option. If the files are huge, it may be best to compile them before hand, then send them in.
Fusion and RoboDK both have Fanuc post processors, so there is some reference out there if you want to roll your own. We talk a bit about it in this thread.
The compilation can be done via command line tools that are included in roboguide.
2. Data transfer: What’s the best method to send the file to the robot (e.g., FTP, Ethernet/IP)?
Without knowing your setup, it is hard to answer this question. I've used FTP before.
3. Memory and data management: How should I handle such a large file on the robot side to avoid memory issues? Should I break it into smaller chunks and stream the data?
Fanuc's maximum amount of lines in a program is ~32000, so you will need to break up the programs. Likely stream them in chunks, and delete the program chunk that was just finished.
4. Dynamic velocity adjustment: What’s the best way to program the robot to handle varying velocities between points? Should I use KAREL, TP, or a combination?
Typically, the process equipment changes based on the robot speed, not the other way around. Dispense equipment does this. The robot will output its TCP speed, and the dispense equipment will adjust the flow rate to match.
What granularity do you need for this? Where would the error come from? You might be able to just directly modify the override on the fly if all you need is velocity adjustment.
5.Error handling and diagnostics: How can I ensure robust error handling for potential issues like missing points, malformed data, or abrupt velocity changes?
The robot controller will fault for malformed data. For a velocity change it can't accomplish, you may get nothing, a warning, or a fault, depending on implementation. For missing points, that is up to you to catch.
Set your DI to start at 33.
GI/GO is referenced to the rack/slot index, not the DI/DO mapping.
There is a bit in the control_code header, that when set to true, will prevent the robot from displaying the program, and it won't show up in the MD:, or in backups. That could be the case.
You could manually calculate the WPR sections from the rotation matrix, and then place them into a PR with XYZWPR rep element by element.
I've got c# code that does that here. Shouldn't be too hard to convert it to Karel. Converting it to TP would be a bit of a challenge.
I've heard maple systems HMIs can do it, and I know Proface HMIs can work. I've used Proface in the past (10+ years ago now).
I agree with gpunkt. Risky move loading in the system vars. Surprised it worked.
Could have corrupted the OS, or make the robot behave oddly. Did you miss the part where I said explicitly not to do that?
For the files, you should be fine loading older TP programs into a newer controller. I would bet the .io config file would load in as well. For everything else, I would recommend hand typing in. Do not load in any parameter (.sv or .vr) files.
Can you list the part numbers?
Not necessarily. It is how the point is represented in the move. Point can be represented in two ways, XYZWPR, or JOINT. If it is in Joint, you may have some issues.
Point in XYZWPR:
Point in JOINT:
With all that said, you will likely have to do some touchup due to differences in manufacturing of the cell and the arm anyway. Its just if you have the point in XYZWPR rep, it will likely be closer.
I can confirm that a deadman release is always an estop. I've talked to Fanuc about it, as we were integrating a cell where the robot was handling a device only rated for 0.1g of acceleration.
Check the details of all programs. Make sure they have Continue track at program end set to true.
