What's new
What's new

Appearance "Industrial" v/s "Collaborative" Robots

CarbideBob

Diamond
Joined
Jan 14, 2007
Location
Flushing/Flint, Michigan
Someone should make lamp base relays that socket between the bulb and the stack light and sends signals to the PLC
Why?
Run the wires out where?
If you do not know how to tap off these signals on their way to the stack maybe you should not be doing such integration.
I did such with a Vidicon camera once. Was a dumb idea.
Made a printer from an IBM selectric typewriter with a whole bunch of solenoids over the keypad. Another of my very dumb ideas.
What happens if the bulb goes out or the flashing light from a passing lift truck or sunshine just right through a window sets it off?
How hard is it to grab the 12-24-120 voltage on a wire?
Bob
 

Strostkovy

Stainless
Joined
Oct 29, 2017
Why?
Run the wires out where?
If you do not know how to tap off these signals on their way to the stack maybe you should not be doing such integration.
I did such with a Vidicon camera once. Was a dumb idea.
Made a printer from an IBM selectric typewriter with a whole bunch of solenoids over the keypad. Another of my very dumb ideas.
What happens if the bulb goes out or the flashing light from a passing lift truck or sunshine just right through a window sets it off?
How hard is it to grab the 12-24-120 voltage on a wire?
Bob
Run them wherever. Leave the top cover off the stacklight or run it down the base with the rest of the wires.
Chances are you aren't sending 24vac or whatever some random stacklight uses directly into your PLC, so you'll need a relay anyway. Why not install the relay in the bulb socket and leave the machine's wiring unmodified?

To be clear I am talking about electrically connecting a relay coil to the socket, not mounting a photosensor on the bulb.
 

thunderskunk

Cast Iron
Joined
Nov 13, 2018
Location
Middle-of-nowhere
.
I think there's a market for their product, but it's not the "right" way to do it if you want all out reliability for lights out automation.
I gotta lean on Carbidebob’s input on this one. I’m not one to say there’s a right and a wrong way to do anything. If it works it works, but I’ve also seen automation integrations much cleaner than this robotiq kit done with very old machines installed by people I don’t classify as geniuses.

If it were me integrating a robot with one of our 2000s vintage Fadals, which it may well be soon, I’d put a few hours into getting the right hardware picked out so my Rube Goldberg machine had a few less steps to get the result I want. I’ve spent a hot minute with PLC programming; not an expert, not even close to an expert, but at least I know I could program something as simple as interpreting signals from a stack light off the bus to communicate machine status to a robot.
 

Strostkovy

Stainless
Joined
Oct 29, 2017
I gotta lean on Carbidebob’s input on this one. I’m not one to say there’s a right and a wrong way to do anything. If it works it works, but I’ve also seen automation integrations much cleaner than this robotiq kit done with very old machines installed by people I don’t classify as geniuses.

If it were me integrating a robot with one of our 2000s vintage Fadals, which it may well be soon, I’d put a few hours into getting the right hardware picked out so my Rube Goldberg machine had a few less steps to get the result I want. I’ve spent a hot minute with PLC programming; not an expert, not even close to an expert, but at least I know I could program something as simple as interpreting signals from a stack light off the bus to communicate machine status to a robot.
I think the key reason to do it this way is that automation is often added when your machine is swamped with worth. Anything you can setup on a bench and then quickly pop in place with minimal downtime is pleasant.

For example, some parts of our sandblasting booth were failing because sand gets blasted into everywhere, always. I made a brand new electrical system on our workbench, bolted it to the wall, and ran new wires along the old ones and swapped connections over in an evening. (We actually have stacked control boxes for progressively better valve upgrades we've accumulated over time.)
 

escapethewrmhole

Aluminum
Joined
Dec 10, 2017
I gotta lean on Carbidebob’s input on this one. I’m not one to say there’s a right and a wrong way to do anything. If it works it works, but I’ve also seen automation integrations much cleaner than this robotiq kit done with very old machines installed by people I don’t classify as geniuses.

If it were me integrating a robot with one of our 2000s vintage Fadals, which it may well be soon, I’d put a few hours into getting the right hardware picked out so my Rube Goldberg machine had a few less steps to get the result I want. I’ve spent a hot minute with PLC programming; not an expert, not even close to an expert, but at least I know I could program something as simple as interpreting signals from a stack light off the bus to communicate machine status to a robot.

It doesn't always work that way, some machines do not give you access to their PLC under any circumstances i.e. Okuma, and I also believe now haas does this everything is locked and inaccessible.
 

YoDoug

Plastic
Joined
Jun 29, 2022
It doesn't always work that way, some machines do not give you access to their PLC under any circumstances i.e. Okuma, and I also believe now haas does this everything is locked and inaccessible.
If you know what you are doing you can get to and modify the Okuma PLC. However, it is way more complicated than standard ladder PLC programming. In the reference manuals for the Windows based controls there are instructions to open the PLC software on the control, search for a signal, and do a trace function.

I am a big proponent of feedback. I like to have switches, sensors, signals, etc for as many steps in an automated process as I can. This allows for safer control and also makes troubleshooting a lot easier.

Aside from that I use the OKUMA THINC API to make the automation interfaces. I have a similar version of a standard app running in 10 different Okumas to talk to a PLC through Modbus TCP that is the central hub. The robot also talks to the PLC. Every 100ms my app passes info like door unlocked, incycle, end of program, alarm, door closed, and a few other signals. In some machines I pass common variable values from the control to the PLC registers. In others I read in PLC registers to common variables. I physically jumper into the cycle start, feed hold button, and Mcode answer, the rest is done through the API app. All of our robots are ABB except for one Doosan cobot. The Doosan is connected to an M560V. The PLC is the central brain of the system. There is an HMI that allows user to select linkmode for robot control of door, Vise open/close, etc. When not in linkmode the operator can control the doors and vises from the HMI. Below is a pic of the M560V and Doosan H2017. It runs between 5-12 hours unattended most nights. The Doosan is our only cobot, All of the ABB's are industrial robot ranging from 20kg to 200kg. There are some features of the Doosan I like a lot, but I prefer the ABB's overall. My robot programs are very parametric and make use of a lot of subs and function calls. The Doosan control really seems like in an effort to dumb it down for entry level users they actually make it harder for advanced users.

 

escapethewrmhole

Aluminum
Joined
Dec 10, 2017
If you know what you are doing you can get to and modify the Okuma PLC. However, it is way more complicated than standard ladder PLC programming. In the reference manuals for the Windows based controls there are instructions to open the PLC software on the control, search for a signal, and do a trace function.

I am a big proponent of feedback. I like to have switches, sensors, signals, etc for as many steps in an automated process as I can. This allows for safer control and also makes troubleshooting a lot easier.

Aside from that I use the OKUMA THINC API to make the automation interfaces. I have a similar version of a standard app running in 10 different Okumas to talk to a PLC through Modbus TCP that is the central hub. The robot also talks to the PLC. Every 100ms my app passes info like door unlocked, incycle, end of program, alarm, door closed, and a few other signals. In some machines I pass common variable values from the control to the PLC registers. In others I read in PLC registers to common variables. I physically jumper into the cycle start, feed hold button, and Mcode answer, the rest is done through the API app. All of our robots are ABB except for one Doosan cobot. The Doosan is connected to an M560V. The PLC is the central brain of the system. There is an HMI that allows user to select linkmode for robot control of door, Vise open/close, etc. When not in linkmode the operator can control the doors and vises from the HMI. Below is a pic of the M560V and Doosan H2017. It runs between 5-12 hours unattended most nights. The Doosan is our only cobot, All of the ABB's are industrial robot ranging from 20kg to 200kg. There are some features of the Doosan I like a lot, but I prefer the ABB's overall. My robot programs are very parametric and make use of a lot of subs and function calls. The Doosan control really seems like in an effort to dumb it down for entry level users they actually make it harder for advanced users.

I am still not sure Okuma ever gives you actual access to the PLC, even with the chgcond password.

We also use modbus for communicating to the devicenet in the machine. Ours is a lathe though, so we control everything with the robot, door open/close, chuck open close, orient, 2nd orient, cycle start, robot request/answer etc. We didnt have to jumper to anything.
 

YoDoug

Plastic
Joined
Jun 29, 2022
I am still not sure Okuma ever gives you actual access to the PLC, even with the chgcond password.
I have never personally tried it, but was told you can modify the PLC and have it save if you know how. As I said, it is very complex and wouldn't recommend it. The PLC is a Fuji-Electric and uses a version of the D300win programming software that is loaded on the machine. https://www.fujielectric.com/products/plc/product_information/prgrm-expert/

We have the Okuma Robot interface in our lathes as well. Only cable from the robot to the lathe is an ethernet. In our mills we don't have the Okuma interface, which is why we jumper into a few switches. The first mill we automated didn't come with robot interface and autodoor. To add those options in the field is very expensive. Once we designed our interface it was easy enough to add to the next three mills and save the option cost from Okuma.
 








 
Top