Thread: Brother TC 32bn Fully automated With ABB Robot

Could someone explain the sequence of software involved with:

Conveyer: Parts (PLC)
Abb Robot: Parts to be machined (Robot Controller)
CNC: Cycle End (CNC Control)
Abb Robot Replace machined part (Robot Controller)
Cnc Cycle start: (CNC Control)

What Software take dominance in controlling these multiple software platforms?

Typically, you set this up so robot is master. The machine is slave to the robot, the automation plc is *somewhat* independent.

The Brother will have the PLC module, and will have the clamping control operated by this. Signals from the machine PLC tell the robot when it can load, signals from the robot request clamping open / close, then a signal from the robot tells the machine when it can cycle again.

On the automation side, typically the robot cycle start, motors on, feed hold and program reset signals will come from the automation plc. The automation plc is handling the safety aspects, thus checking safety gates, automation basic positions, etc prior to cycle start. Once started, the automation PLC is mostly in autonomous mode, relying on sensor signals as to when to index the conveyors, etc. The automation controller will give a signal to the robot saying it is "clear to enter the work area" telling the robot the conveyor is indexed and ready for the robot and the robot will give a "in the work area" signal so the conveyor cannot index while the robot is in the working area. If there is a vision system in place, the offsets from the camera may be passed through the PLC to the Robot. The plc is only acting as a communication device in this regard.

Cool video. Looks like a money printer. At about 2:20 the guy is removing parts from the outfeed conveyor on the bottom - how does it know when to move forward?

1:30-1:40 what is what robot doing? just letting the coolant drip or moving it by an air blast to dry it up or something?

Originally Posted by Joe788

Cool video. Looks like a money printer. At about 2:20 the guy is removing parts from the outfeed conveyor on the bottom - how does it know when to move forward?

Sensor on the conveyor, probably thru beam type looking across the conveyor. On the robot end, the robot knows how many it has put on the conveyor, so it just sends a signal to the automation plc to index the conveyor.

On edit....
If you look at the end of the conveyors at about 30 sec in, you'll see the two little orange sensors on either side of the conveyor ends.

Originally Posted by SND

1:30-1:40 what is what robot doing? just letting the coolant drip or moving it by an air blast to dry it up or something?

Changing tools. There appear to be 3 end effectors for that robot. It's loading at least 2 different part types.

Originally Posted by Tonytn36

Typically, you set this up so robot is master. The machine is slave to the robot, the automation plc is *somewhat* independent.

The Brother will have the PLC module, and will have the clamping control operated by this. Signals from the machine PLC tell the robot when it can load, signals from the robot request clamping open / close, then a signal from the robot tells the machine when it can cycle again.

On the automation side, typically the robot cycle start, motors on, feed hold and program reset signals will come from the automation plc. The automation plc is handling the safety aspects, thus checking safety gates, automation basic positions, etc prior to cycle start. Once started, the automation PLC is mostly in autonomous mode, relying on sensor signals as to when to index the conveyors, etc. The automation controller will give a signal to the robot saying it is "clear to enter the work area" telling the robot the conveyor is indexed and ready for the robot and the robot will give a "in the work area" signal so the conveyor cannot index while the robot is in the working area. If there is a vision system in place, the offsets from the camera may be passed through the PLC to the Robot. The plc is only acting as a communication device in this regard.

Thanks for the incite Tony, in regards to the order of operations. In this type of circumstance how many I.O. would there be tied into the robot controller, and would it be using Ethernet.

Also, is there a sample of code or flow chart similar to this video showing how A robot interacts with the CNC, and conveyer PLC?

Dan-

The current Brother PLC does not support Ethernet communications for anything but program management (upload/download/editing/monitoring). The comm between the robot and Brother would be discrete I/O. It is possible that Ethernet is used between the robot and the automation PLC, but it may also be discrete I/O.
Just from my casual observance of the cycle, signals I would expect for this type of cell would be:
Machine to Robot:
1. Ok to enter work area
2. Clamp fixture open
3. Clamp fixture closed
4. Fixture rinse finished
5. Machine is faulted
6. Hard-wired E-stop from the Machine (Typically you set it up so that a Machine E-stop stops the robot, but a robot E-stop does not stop the machine.)
7. Pallet 1 is to be loaded
8. Pallet 2 is to be loaded

From the Robot to the Machine:
1. Robot is in working area
2. Request to open fixture 1 clamp
3. Request to close fixture 1 clamp
4. Request to open fixture 2 clamp
5. Request to close fixture 2 clamp
6. Request to rinse fixtures
7. Robot is clear of machining area
8. Machine cycle start

From Robot to PLC
1. Robot is HOME 1
2. Robot is HOME 2
3. Robot MOTOR ON
4. Robot IN CYCLE
5. Robot request to index finished conveyor 1
6. Robot request to index finished conveyor 2
7. Robot is faulted
8. Robot end of cycle is complete
9. Robot in working area - conveyor 1 pick up
10. Robot in working area - conveyor 2 pick up
11. Robot in working area - conveyor 1 drop off
12. Robot in working area - conveyor 2 drop off
13. Robot in TEACH MODE (manual mode)
14. Robot in REPEAT MODE (automatic mode)
15. Robot E-Stop

From PLC to Robot:
1. Robot MOTORS ON request
2. Robot CYCLE START
3. Robot PROGRAM RESET
4. OK to enter conveyor 1 pick up
5. OK to enter conveyor 2 pick up
6. OK to enter conveyor 1 drop off
7. OK to enter conveyor 2 drop off
8. E-Stop
9. Robot EXTERNAL FEED HOLD

Inputs Internal to the Robot (but may be passed to the PLC as well)
1. Tool 1 ID (Tool ID is typically a 4 bit binary, thus requiring 4 inputs)
2. Tool 2 ID
3. Tool 3 ID
4. Gripper OPENED
5. Gripper CLOSED
6. Tool changer unclamped
7. Tool changer clamped

Outputs Internal to Robot:
1. Tool changer clamp
2. Tool changer unclamp
3. Gripper Open
4. Gripper Close

Internal signals:
Various keep bits for where the robot is in the cycle, what part it has (if any), and other uses internal to the robot program

Code:
Here is a simple program that I'm using to find the height of a layer of parts on a pallet. It's using a the sensor on a pneumatic cylinder as I only need ~+/- 1 mm accuracy. Any 1xxx series signal is an input to the robot, 1033 - 1040 are internal to the robot (i.e. from end effector sensors), 1041 and up are from the PLC. Any 2xxx series signals are internal keep bits. These act just like an output, but do not go anywhere other than robot memory. They can be read and written and are kept at current state at power off/on. in this code there is no interaction with a machine. I'll put a sample of that in the next post.

Just to help understand the code a bit, there are two pallet types (ptype) for this application with different part spacing on each pallet type, within that, one pallet type can have one of two different part types on it. One will have 20 layers of parts as default, the other will have 18. ptype 2 always has 18 as default. The ONI command acts similar to the skip function on a CNC, the control watches that signal and jumps to where you tell it when it sees it change state (lead edge or trail edge is determined by the sign given the signal in the command) HERE command has the control record the current position of the robot. DECOMPOSE breaks that pose down into a 6 variable array k[1]=X,k[2]=Y,k[3]=Z,k[4]=O,k[5]=A,k[6]=T. These array variables can then be manipulated as real numbers. In this instance, I'm only interested in the k[3] variable, my Z axis position.

.PROGRAM findz (); Find Layer
;************************************************* ******************************
; Find the layer height
;************************************************* ******************************
HOME 1
IF SIG(1076) THEN ; cycle end requested
SIGNAL 2006 ; sub needs to run
subfault = 1
HALT
END
BASE NULL
TOOL NULL
IF (npal == 1) THEN ; If new pallet == 1
currlay = 0
END
IF (ptype == 1) THEN
IF ((npal == 1) AND (oclay <> 20) AND SIG(2002)) THEN
currlay = 18 - oclay
npal = 0
END
IF ((npal == 1) AND (oclay <> 20) AND SIG(2001)) THEN
currlay = 20 - oclay
npal = 0
END
END
IF (ptype == 2) THEN
IF ((npal == 1) AND (oclay <> 18) AND SIG(2003)) THEN
currlay = 18 - oclay
npal = 0
END
END
SIGNAL -33,34 ; retract slide
SWAIT 1033,1036,-1035 ; wait slide retracted, cylinder down
CALL calc
CALL posit
upwait:
IF SIG(-1114) THEN ; If Pallet not ready
IF SIG(1076) THEN ; End of cycle requested
subfault = 1 ; Set sub eoc keep bit
HOME 1
HOME 2
HALT
END
GOTO upwait
END
SPEED 30
JMOVE abovepal
IF (npal == 1) THEN;
IF SIG(2001) THEN ; If part type 1
POINT setheight = SHIFT(abovepal BY 0,0,-(currlay*lthick+30))
END
IF SIG(2002) THEN ; If if part type 2
POINT setheight = SHIFT(abovepal BY 0,0,-(currlay*lthick+60))
END
IF SIG(2003) THEN ; If part type 3
POINT setheight = SHIFT(abovepal BY 0,0,-(currlay*lthick))
END
END
IF (npal <> 1) THEN ;
POINT setheight = SHIFT(abovepal BY 0,0,-(currlay*lthick))
END
LMOVE setheight
STABLE 0.2
BREAK
TWAIT 0.2
IF SIG(-1033) THEN ; Sensor not made
rbmes = 30 ; Z cylinder sensor not made
subfault = 1 ; Set sub eoc keep bit
SIG 2006
HOME 1
HOME 2
HALT
END
ONI -1033 GOTO zset ; Watch sensor
ABS.SPEED ON
SPEED senspd MM/MIN
DRAW 0,0,-190 ; draw down to find layer
; Sanity Check
BREAK
HERE errht
subfault = 1 ; end of cycle bit if robot did not find layer
rbmes = 16 ; Robot did not find height
SIGNAL 2006
JMOVE abovepal
HOME 1
HOME 2
HALT
zset:
IGNORE 1033 ; Quit watching the ONI signal
ABS.SPEED OFF
BREAK ; Pause preprocessing to get accurate data
HERE height
DECOMPOSE k[1] = height
zshifta = DISTANCE(passhome,height)
zshift = zshifta + zcorr
szshift = senseht-zcorr
JMOVE abovepal
HOME 1
SIGNAL -2006 ; sub has completed
.END

Here is a snippit of code from a machine interaction. This is a two station machine, hence the "Left Side". I'll only post for one side of the actual part exchange for brevity as this is a fairly long program because we have code and options for having the robot follow the station as it moves from left to station right for speed reasons. In this case, there are only 4 inputs from the robot end effector, 1013-1016. Everything else either comes from the machine or from the PLC. Most of them in this code sequence come from the machine. Any two or thre digit signal are outputs to either the machine or the PLC. Most are to the machine in this case.

;************************************************* **************************
; MACHINE SEQUENCE (LEFT SIDE UNLOAD)
;************************************************* **************************
30 SPEED 100 ALWAYS
SWAIT 1022 ; Wait On Machine Ready For Loader
SWAIT 1024 ; Wait On Machine On Left Side
SIGNAL -40 ; Set Robot NOT Clear Of Machine
TWAIT sdwell
SWAIT 1022 ; Verify Machine Ready For Loader
SWAIT 1024 ; Verify Machine On Left Side
speed = MSPEED ; Variable for Robot Speed Check
SIGNAL 13 ; Unclamp Part Request
TIMER (2) = 0 ; Reset Machine Loading Cycle Timer
ACCURACY 100
JMOVE #exitleftu
SIGNAL 20 ; register rinse on request
ACCURACY 100
JMOVE unloadapprl; Move Above Unload Left Side
ACCURACY 2
LMOVE machunloadl; Move To Unload Left Side
followl = 0
SIGNAL 11,-12 ; Close Gripper 2
lloaded = 0
SWAIT -1016 ; Verify Gripper 2 Not Open
IF ((SIG(-2202) OR speed<>100) AND firstl<>0) THEN ; Anticipate Gripper Close Option
SWAIT 1015 ; Verify Gripper 2 Closed
END
SWAIT 1020 ; Wait on Machine Clamping Open
ACCURACY 100
LMOVE unloaddprtl; Move Above Unload Left Side
SWAIT 1015 ; Verify Gripper 2 closed
SIGNAL -13 ; Reset Unclamp Request
firstl = 1
;************************************************* **************************
; MACHINE SEQUENCE (LEFT SIDE LOAD)
;************************************************* **************************
35 SPEED 100 ALWAYS
SWAIT 1022 ; Make sure machine still ready
speed = MSPEED ; Variable for Robot Speed Check
ACCURACY 100
JMOVE loadapprl; Move Above Load Left Side
SWAIT 1020 ; Wait on Machine Clamping Open
SPEED feedmach ; Reduce Feed Speed for Loading
ACCURACY 2
LMOVE machloadl; Move to Load Left Side
SIGNAL -9,10 ; Open Gripper 1
SIGNAL -15; unfinished part has been gripped
lloaded = 1 ; Set Unmachined Part Loaded Variable
SIGNAL -20 ; Register rinse off
SWAIT -1013 ; Verify Gripper is Not Closed
IF (SIG(-2202) OR speed<>100) THEN ; Anticipate Gripper Open Option
SWAIT 1014 ; Verify Gripper is Open
END
IF (SIG(2206) AND (speed==100)) THEN ; Anticipate Cycle Start Option
ACCURACY 125
ELSE
ACCURACY 50
END
LMOVE loaddprtl; Move Above Load Left Side
IF (speed>80) THEN ; IF moving fast enough
SIGNAL 14,40 ; Start machine clamping cycle
SPEED 100,100 ALWAYS
ACCURACY 20
JMOVE #exitleft; Move to intermediate point
SIGNAL -14 ; Remove clamp request
JMOVE #unloadwait
GOTO 38
END
IF (speed=<80) THEN ; Clamp Delay based on speed
IF SIG(2207) THEN ; Autospeed option
SPEED autospd ALWAYS
ELSE
SPEED 100,100 ALWAYS
END
ACCURACY 50
JMOVE #exitleft
ACCURACY 100
JMOVE #unloadwait
SIGNAL 14,40 ; Start machine clamping cycle
DLYSIG -14,3 ; Reset clamp request
GOTO 38
END
38 PRINT "LOADING TIME =",TIMER(2) ; Print the Loading Time
IF SIG(2207) THEN ; Auto Speed Adjust Option
SPEED autospd ALWAYS
ELSE
SPEED 100,100 ALWAYS
END
GOTO 50

Thank you, Tony. Those last three posts were full of educational detail.

Originally Posted by sfriedberg

Thank you, Tony. Those last three posts were full of educational detail.

YW, that's what the forum is for, sharing information via asking and answering questions

By the way,

If you notice, programming a robot is very akin to programming a CNC machine. You just have a different syntax to use.
To make some equivalencies:
JMOVE, LMOVE somewhat == G0/G1
SPEED = Feed
The signalling is similar to what M codes do in the CNC world.
The macro language is very, very similar to CNC macro.
This particular robot brand (Kawasaki) uses C++ as the base language for the controller. This AS language shown above is an "on top" language similar to Tcl, etc. Most C++ commands will work also.

Tony,

Thank you for sharing this information, I have much to learn and have been browsing the auctions to jump on a robot like the ones that were just liquidated at the solyndra auction.

Solyndra Sale #4

This is my career goal, and I have every intention to follow this dream.

The automation I'm familiar with (sort of a different standard) and I'm just a troubleshooter, not an actual programmer....but this uses PLC as the mastermind in any process. The robot program (Fanucs) does have its own inputs and outputs and makes some decisions based on that. The robot program defines "segments" which the PLC gives the robot a "continue" bit which manages other processes which may or may not complete with success.

Couple other things I see, my guess is the inbound conveyor is single axis servo to give a repeatable position for the robot to grab the part reliably. The alternative would be to have vision guidance for the robot (essentially vision software (camera on the robot) takes a digital photo of the part, finds a feature on the part, then calculates an offset, the vision software transfers this to the robot and it goes to that position). Also the robot is likely using another set of "mathematical offsets" to place the finished parts on the outbound conveyor. Essentially there is one master position and the others right-to-left are calculated mathematically from the initial master position, the offset is incremented each time a part is set down. Saves time when there is a problem and a programmed point has to be touched up, instead of reteaching all 4 or 5 across, simply teach the one master point and the rest are calculations.

Last thing, from a troubleshooter's viewpoint, the process is super cool when it runs lights out. Rarely does that happen in life The thing in my mind that separates good automation from bad is a) how well the fault messages lead you to the general direction of the problem, and b) how easily it recovers back into the auto cycle (or how many esoteric procedures have to be followed to recover in a worse case!!) Anything can go wrong, the part can be dropped at any time, the end effectors can fail to pickup properly, there will be chips and coolant interfering with part present sensors, etc. The CNC could fault or break a tool. There could be robot crashes due to double parts, the conveyors could be blocked or starved due to operators doing other tasks. And yes, even the troubleshooters occasionally make a mistake in recovering the process

Yes there are two schools of thought on this, one as robot master, one as PLC master. I _despise_ plc master systems. They are limited, the robot has to have a recovery program that may or may not work properly in every situation, etc. I had one such system crash Wed. We didn't build this system, but as Matt alluded to, troubleshooting is a PITA because they did not set up faults in the robot and the few that are robot related on the PLC don't really lead you anywhere specific. The stop state happened right at a critical juncture in the robot motion and wasn't related to robot motion in any way. However, when the recovery program started, it thought it was somewhere it wasn't, so crashed into the machine.

The way we handle this is: If you notice in the first program I posted, there is a "rbmes = " statement. This is the fault that will be displayed on the message boxes on each page of the robot teach pendant interface panels. Nothing knows where the robot is like the robot does. At any non-e-stop type fault, such as a dropped part, sensor made when it shouldn't be, sensor not made when it should be, cycle end activated, etc we go ahead and recover the robot to the start-up condition before cycle end.

Again, if you notice in the first program, at error the robot moves to HOME 1 and then HOME 2. The robot is ONLY allowed to start at either HOME 1 or HOME 2 again for safety reasons. The robot will go from where it is to where it is told the same as a CNC machine will. If you allow it to just start anywhere, there is a good chance something like what happened wed will occur, where the robot will hit something it shouldn't.

If the robot cannot recover to home at error, our personnel are trained how to manually drive the robot to home via teach pendant and the cycle end sequence in the program. The methods we use are very effective and successful. We have 120+ robotic loaded machining systems we've built that run 24/7, some very similar to the above. It is extremely rare to have a crash. Troubleshooting is relatively simple the vast majority of the time because the robot tells you what went wrong.

As to the "reference points", that is exactly how we do it. For a machine, there will be reference points for the load position, depending on the type of end effector, the unload may be calculated or it may be a reference point. The approach points are calculated also. Again at the conveyor there is a reference position for the load and the unload may be calculated or a reference position. These reference positions are not necessarily the actual load points. We run families of parts, so we teach hard, measurable reference points relative to structure. The actual loading position of the robot is calculated from this reference because this position changes depending on the part dimensions.

Yes, have been there before, jumping around in the robot program (IOW restarting on a different line) can have disasterous results!! More or less it boils down to when the robot gets another programmed point command, it simply goes there via the shortest path. So as Tony states, sending it back home first is a reliable solution.

Our processes are similar in recovery, abort current program, drive robot home, manually place parts, and set the "cycle state" via the HMI to denote the new updated state in the process. The PLC will then call the next robot program in the sequence of operations and the cycle continues. Can get tiresome and thruput-wasting if there's a tricky problem to solve or parts are not picking or placing correctly. Then you jump into a set of human decisions about what to do next to keep production rates up, stop production and reteach points or tweak fixtures, live with the reset/restart/recovery downtime, etc. There are a myriad of choices and typically the robot does not "lose" its position at the programmed points...typically something else has changed. However robot points are easily updated and so often in the interest of time savings the taught positions will be touched up.

Yes, regarding starting at a wrong line...

If you notice in the I/O listed earlier, there is a "program reset". Whenever you either lock the doors on the cell or hit cycle start on the cell, the controller issues the program reset. The robot always starts at the head of the program, and the first thing we do in the program is check to make sure it's at home 1 or home 2, if not, it faults and sits there and looks at you, it will never move. One of our other departments was not doing it this way and trashed a CNC control on a mill because of it. It was a 50kg and it put the grippers right through the control and ripped the guts out.

I typically do a lot of start up checks in the program. I look for things like sensor issues (both made/both unmade on a cylinder), check the valve state vs sensors to make sure they haven't hooked up the sensors backwards to what they should be, robot home, check for keep bits as to where the robot stopped, etc.

We always try to program so the robot shuts down and starts up "gracefully" with minimal operator intervention required to stop / start. If it shuts down with parts in the grippers, it should know that and know what it needs to do with those parts at start up. The operator should not be required to remove them or do anything with them.

You are also correct on the positions, it is *rarely*....almost *never* a situation where the robot "got off", something else happened but the quickest way to recovery is often just reteaching the position.

Hi
I found that our FeedLine Brother video is embedded here in this thread here and I enjoy reading it.
I am amazed that there is a forum discussing robot automation!
Here at Svia we manufacture robot cells based on standardized components/functions. We are specialised on vision guided robots. We do only robot cells that contain a robot, our camera system and one or more of our flexible feeders. We sell and install these here in Europe.
One of them is our FeedLine system. It is our most “simple” flexible in feed system.
The robot cell in the video is setup like this:
One ABB IRB 2600 robot.
Two FeedLine for un-machined parts.
Below each FeedLine is an out going belt for machined parts.
A conveyor belt for statistical quality out-takes of machined parts at a certain interval.
Station for different grippers.

The customer in this case needed the possibility to machine two different parts at the same time. Therefore the two in-feed systems. There are different fixtures on the turn table inside the Brother machine making this possible.
To control different tasks in the cell we use the below controllers. They talk with each other via Ethernet.

1. PickVision camera system (developed here at Svia). This can be seen as master. The operator chooses what parts he wants to machine on each side of the turn table in the machine. It identifies the parts that are by the operator randomly placed on the conveyor belts. It sends the coordinates and some other information directly to the robot. PickVision automatically changes robot program in the robot controller and sends part specific setting to the PLC when the operator changes what parts he want to produce. In some cases PickVision can also be used to change the NC program in the CNC machine automatically. Some machine suppliers have this possibility. It also starts and stops all items in the cell, robot, plc and so on. If PickVision is connected to internet it can send production data to our server. The customer can monitor the robot cell in his iPhone/iPad. He can see what is produced at the moment and in the past, cycle times, error messages, Search for SVIA in iTunes and you can find our app and run it in demo mode.

2. PLC. This controls the FeedLine in feed and out feed belts, frequency inverters and other Svia standard options. The PLC program is always the same regardless of how the FeedLine cell is configured. The PLC “senses” what items is connected to it and it activates those parts of the program that is needed. On our YouTube channel you can see some examples of configuration. www.youtube.com/visionrobots

3. Safety PLC. This controls all safety related items in the cell. Such as entry doors, emergency buttons, cnc machine emergency stop, light curtains and laser scanners. It is built up similar to the PLC above. It “senses” what is plugged in on its safety bus. The reason why we have developed the quite advanced safety PLC program is that here in Europe it has to be validated externally each time a change is made in order to maintain CE regulations.

4. Robot controller. Of course all robot movements. The robot exchanges I/O signals with the CNC machine. Normally via a bus, usually profibus or similar. Sometimes with hard wired 24 volt signals. If we need to control some equipment that we have designed specially for a customer we control it with the robot I/Os. Most robots and their I/Os can be programmed as a PLC.

The cycle in the video is like this:
1. Robot waits that the machine is turning its table.
2. When the Brother machine signals that it is okay to go ahead the robot reaches into the machine and blows with compressed air through a quiet air nozzle. It blows off coolant and chips from the fixture.
3. It grips the machined part, commanding open fixture and blows again on the fixture to blow away the coolant and chips that was hiding under the part.
4. Robot leaves machine part on the out going conveyor.
5. Robot picks un-machined part from FeedLine with the coordinates that the PickVision sent. When the robot has a gripper that is gripping on the outside of the part the camera system checks that the gripper avoids collision on nearby parts. If there is a collision risk it will stop the cell and operator needs to fix the issue.
6. Robot loads the part into the machine fixture and command clamping of the part. The robot moves out from the machine and starts the machining cycle.
7. The robot changes gripper to next part type. The gripper is coded binary in order to avoid mistakes by operator. Sometimes we use RFID tags on the gripper and the robot passes a reader and check that it has the correct gripper and or fingers.
8. The above steps are repeated with part 2 on the second FeedLine and second fixture.
9. There is a start-up procedure where the robot only loads in parts and an end cycle where it empties the machine.
10. The operator defines an interval of when the robot places a part on the quality check belt. When the robot has put a part on it the operator has to take the part and confirm on a button that he has taken it within a certain amount of cycles. Otherwise the robot stops and waits for the operator. This ensures the measurements are made to ensure quality.

With the above cell the customer can by themselves "teach in" new parts when they get a new or more contracts. Many of our customers are sub contractors and they usually don't know what they will produce in the future, therefore they invest in our systems. They are flexible and not specially made for specific parts. The handling capacity of the robot sets the limitation of what can be handled in the cell.

I hope I could explain the cell and how it works. Sorry if the text fells like an ad, difficult to avoid.. Also sorry for my school English.. If you want to learn more you are most welcome to visit us here in Sweden. We are very open and we share our knowledge to others. We build approx 80 robot cells per year so the workshop is always filled with robot cells to look at. It’s just a flight to Sweden away…

Cheers!

Svia - great reply, thanks for chiming in.