My bad, I was using the CAD converter option.
Posts by Nation
-
-
Try exporting as .x_t. I've had success with that. -
An auto update may fix this, but I'm not very confident in it.
There are a lot of settings/utilities that don't play nice outside of the default range of tool/frame numbers.
-
It is the rotation about the world Y axis. 0 is floor mount. 90 is wall mount, with the arm pointing towards the floor when at zero position.
-
I liked the idea of creating a "poor man's" spherical world zone.
Here it is:
Code
Display More/PROG POORMANS_WZ /ATTR OWNER = MNEDITOR; COMMENT = "In Sphere?"; PROG_SIZE = 733; CREATE = DATE 25-02-10 TIME 16:20:56; MODIFIED = DATE 25-02-10 TIME 16:20:56; FILE_NAME = ; VERSION = 0; LINE_COUNT = 20; MEMORY_SIZE = 1057; PROTECT = READ_WRITE; TCD: STACK_SIZE = 0, TASK_PRIORITY = 50, TIME_SLICE = 0, BUSY_LAMP_OFF = 0, ABORT_REQUEST = 0, PAUSE_REQUEST = 0; DEFAULT_GROUP = *,*,*,*,*; CONTROL_CODE = 00000000 00000000; LOCAL_REGISTERS = 0,0,0; /APPL /MN 1: !Sphere Location (World): ; 2: ! X,Y,Z: ; 3: R[11:Sphere X]=(1431) ; 4: R[12:Sphere Y]=(-506) ; 5: R[13:Sphere Z]=(542) ; 6: !Sphere Radius: ; 7: R[14:Sphere Radius]=(300) ; 8: !Current Position of ; 9: ! the active TCP in World. ; 10: ! X,Y,Z: ; 11: R[15:Curpos X]=($SV_INFO[1].$CART_POS[1]) ; 12: R[16:Curpos Y]=($SV_INFO[1].$CART_POS[2]) ; 13: R[17:Curpos X]=($SV_INFO[1].$CART_POS[3]) ; 14: !Calc dist ^2 ; 15: R[18:Dist^2]=(((R[11:Sphere X]-R[15:Curpos X])*(R[11:Sphere X]-R[15:Curpos X]))+((R[12:Sphere Y]-R[16:Curpos Y])*(R[12:Sphere Y]-R[16:Curpos Y]))+((R[13:Sphere Z]-R[17:Curpos X])*(R[13:Sphere Z]-R[17:Curpos X]))) ; 16: IF (R[18:Dist^2]<(R[14:Sphere Radius]*R[14:Sphere Radius])) THEN ; 17: F[1:In Sphere]=(ON) ; 18: ELSE ; 19: F[1:In Sphere]=(OFF) ; 20: ENDIF ; /POS /END
I tested it, and it works. I initially tried using local registers to do it, but it looks like background logic does not like them
-
There is a thread where the OP asks about moving programs from an older controller to a newer one, but not quite the leap as you will be making.
In general, programs are fine to move. Settings and other sensitive stuff should be hand typed.
-
Can you post your IO config on the robot side, and the PLC side?
-
Thank you vey much for the information. Is there a way to know if we have this option pre-installed maybe? Maybe they have it by default nowadays?
JeffBO states the easiest way.
It is very unlikely that your robot will have this option straight out of the box. Fanuc is a lot like Spirit Airlines. They make their money off of the options. At least this option isn't too expensive. At current prices, I will guess it will run about $650.
-
-
In the irVision tools option, there is a karel program called MERGE3D2. Input 3 position register indexes storing your measurements, and an index where to store the result, and it will compute a frame for you.
Note: I've never used it, but the documentation (irVision Operator, section 8.1.4) states that is exactly what it does.
Making a frame seems like overkill though. Could you just do a search along your existing frame axis to verify dimensions?
-
Take a look at my explicit messaging thread in the tools sub forum. Unless you need it in real time, that is probably the easiest way to do it.
-
It is possible. I know of an entire plant that runs using Pro-Face HMIs. No PLCs.
I was involved in the project back in 2013 to directly interface to the robot. So my memory is a bit fuzzy on the details. I do know you have to have the "basic HMI (SNPX)" option installed on the robot though. If you want to get more than the basics out of the robot, there is some system vars to setup, but the manual goes over them.
-
Fanuc is very aggressive in scrubbing their manuals from the internet. I recommend getting a Fanuc webportal account setup. Your salesman can usually help out with this. All the manuals are available there.
According to the SR6iA mechanical manual, when J3 is at its zero position, there should be a 3mm gap between the mechanical stopper, and the robot's housing.
The robot will be picking products from a conveyer. Our client can produce thousands of different products. Eventually our client will be responsible for teaching the products to the vision-system and setting which tool needs to be used in order to pick up the product.
I'd sleep a lot better if i could guarantee the robot can never crash into the conveyor, even if the operator makes a mistake.Keep in mind that DCS does not stop the robot instantly. The robot is a mechanical device, and still requires time to come to a stop. This robot requires about 50mm to bring J3 to a complete stop at 100% with a full payload. More (~12%) if the payload is less.
You could turn on predictive stop, which causes DCS to project the model at the current velocities to ensure a stop before violating a DCS zone, but in my experience that will lead to a ton of false positives if you need to maintain a fast process.
-
I placed your numbers into roboguide, and for they look ok-ish.
Both Z directions are pointing in the same direction. There is a bit of rotation around Z.
How are the picks off? What axis are you picking along?
-
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.
-
-
I've done this!
External Content www.youtube.comContent embedded from external sources will not be displayed without your consent.Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.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.