Posts by Elderwild

It seems to me that you need to write some PLC relations so that the robots are talking to each other through the plc. You will need to find open DI's in each robot, write them down. Then you need to find the appropriate DO's form your robots that are signaling that they are clear. Create a DO from the plc to each robot that turns on when it receives the DO from the other robot. This signal will be your new robot DI. The signal will probably be sent through your LAN connection.

Also you will need to add some kind of wait command that correlates to your new DI where you are having your collisions.

I hope this makes sense to you. You need to use the plc like a relay but right now it seems like you only are sending a message out, but not relaying it to the other robot.

Thanks for confirming that. I thought the image should have been good as well based on how I told them to shut down. I am not saying that they followed all the directions to a T, but they said they did. I guess I'm curious to know how we were able to fix and boot back up if there was a problem with the "hard drive"? Which leads to the second question, Should I be worried about this happening at the next shut down? ... and the Third... Is there anything I can check to see if it is working properly?

Skooter , thanks for the reply. I tried all of those things, no dice. I found out that what ended up happening was a corrupt boot image. The reason for this was an old version of the controller battery charger .07. Apparently, chargers before rev 10 had a programmed runtime, after which they will no longer charge the controller battery. When the robot was shut down for maintenance, there was not enough charge to last for the hour or so we were down. Consequently, the SMB lost communication with the controller and also the compact flash drive was corrupted.

To fix this, it was necessary to delete "image.bin" and replace using the com1 port on top of the controller computer, followed by (pretty sure it was) an IStart. After which it was necessary to replace the DSQC 508 unit to a rev 10 or later version, part number 3HAC 5393-2 in the controller and the 3HAC 16831-1 battery in the Robot. Because of the loss of SMB communication, it was also necessary to do a rev counter update which required driving the robot back to (0,0,0,0,0,0,) and updating. This fix although not complicated, required extensive knowledge of the OS (SC4+) and a laptop with specialty software and connections (you will also need your Key. The process took about 3 hours, including testing, and cost about $2000.00 with parts.

Lesson learned? Please do your battery PM yearly! $400 for batteries is a lot less than $2000!

To save you all some time, if you are worried about the status of your batteries, please send your robot to ABSJ (0) before performing your Service Shutdown. It may not save your boot image, but you can be assured that your robot is in it's proper calibration position (if it is not you have bigger problems) when you are ready to get up and going again.

Cheers, and thanks again to this wonderful community of professionals and the great wealth of knowledge you are all willing to share with others as they grow into their robotics careers!

Kindest regards,

Elderwild

Hello All,

irb6600, m2000A, S4c+

Error at startup:

Startup error new motion -12

Startup error task hio -1

Startup error task hic -1

Startup error task hij -1

Startup error task hpjts -1

Startup error task hif -1

Startup error task his -1

Startup error task hiats -1

Startup error task hip -1

Startup error synchronize task -1

Startup error go task -1

nothing else.....

Does anyone of you robot Gurus have a hint for me as to what happened here?

We did a service shutdown, installed a surge protector on the transformer, then fired back up about an hour later and the above popped up on the screen.

Thanks for the time.

Drew

Did you make a backup? If so reload it and warm start.

Apparece que la systema suya no tiene el dato cierto. Estaria mejor si se puede trazducar a engles para la mayoria de hente aqui. Pero Yo se que hay gente que hablas italiano tambien. Possiblemente Fabian Munoz se puede ayudate.

Lemster68 , Thanks for the Snippet. Wish it was actually that easy to just drop in like that, but definitely a point in the right direction. As for the positioning and why it wasn't working, I calculated everything and put in but went the wrong way the first time. With the gripper fingers I had on, this made dimples in the wrong spot. After correcting for the right position the griper pads wanted to go back to the original spot, this kept moving the castings. So my calculated was not matching the setting that was keeping the castings in place.

I took the head off the robot and did an inspection, I found an alignment pin that was about .1 above the surface of the face plate of the quick change tool plate. I ground it down and started to check the rest of the program cause I was sick of working at the load station and getting nowhere. Started with the sander because I knew I needed some new clearance here.

Later in testing, at the router, I was able to more accurately measure where in space I was and checked back in on those offsets. I set them to the new measurements and they looked familiar. Looking back at my notes the were identical to my calculated ones from the beginning! Wasted hours trying to figure out what was wrong, because nothing was really wrong with the code, it was that stupid pin and the dimples! On the positive side, I have a better understanding of how TCP interacts with world, and that the robot is really accurate after that calibration we did back in January.

Thanks again Lee!

The product area that is concentrically grabbed in three places is round with a slight taper, I guess technically its a cone. The fingers are cut to compensate for this with a taper. Load tables position 1 is the only grab that matters/no regrip. We are using ATI QC-71 Quick tool changer heads. Built new same as old. Put new head on, change Z offset and go to Pos. 1, Robot is shifted in Y+ by a couple of millimeters +/-.5 also slightly in +X by maybe .5mm Z is correct. Not that much but it causes the part to shift in the cradle upon gripping, which throws the rest of the program off.

Tried new tcp calculated by robot with manual Z corrections again Height is correct but when attempting to grab the part was shifting.

I very crudely checked orientation against Tool0 between the two EOATs an hour ago and found a very minuscule difference, about .87mm ish arc length on the OD. I do not think that should be making this big of a difference but I may be wrong. I have a feeling I will need to calculate the QUATERNION and make a small change if I want to do this the way I was thinking.

I would like to manually adjust the TCP to compensate so that I can run either EOAT without editing the program, just adjusting the tcp, depending on the which head is on. Is it possible?

Greetings, it's been a while.

S4C+,6600,M2000A

We have a new PZN+200-1-AS-SD, it is replacing a PZN+200-1-IS. They were made to be interchangeable incase we needed to substitute one for the other. There are differences in diameters due to the dust shrouds and an 8.55 mm difference in the Z of the TCP. I tried using the defined TCP of the old unit for the new one while only changing the Z of the TCP, the height was correct. However, I found that the robot did not go to the proper pick up place. next, I defined a new TCP using the same tools as used for the older one, they were different. I again tried to go to the intended target with the new TCP, it did not go to the correct place. Why?

What is the best way to setup the new PZN without having change the program, as I want to be able to use either EOAT to get the job done? I was hoping that I could set a register up for TP selection to determine what EOAT was on. The registers would change the data that defines the EOAT and then just run that program using either head with no change to the program. Is this possible? If so can anyone help me overcome this first part of the robot going to the correct location so that I can move forward with the minor adjustments to compensate for the change in diameter.

Best,

Elderwild

To clarify, the pick point would actually be attached to the nest, not the part. This would probably not work well for loose parts unless you have vision, but if you have individual nests for the parts it works quite well. I have 15 different job setups, each using different nests from the same workstation. Anyway don't forget the basic stuff SkyeFire, I hope you get it nailed down

I don't have a ton of experience with the Simulation software, but if you know the orientation of the gripper you need to hold the part and the Z spacing from the part to center of tool face, you should be able to create your "Rack array". The array first point would be center of the pickup point. Set Gripper orientation and Z height off "Rack" plane on first part, then use array data for all other points, no jogging necessary. Paths can be programmed as offsets from center point of first part pickup point. Use a "Pounce" point as an intermediary point between pickup and the rest of the cell to avoid confusion and collisions.

So, ok, you provided enough for Skooter to help. I should have said no normal human!

You have not provided enough info for anyone to help you. I suggest that you look through the user manual portion of the forum for the schematics that match your robot and controller. Then you maybe able to find out what those wires are for and where they go.

For the s4c+, on an analogue signal, the voltage goes from 0-24v or it is in milliamps 5-15mA I think. When you set up your signal there should also be section in which you designate what scale (log min, log max) this equals. I.e. 0-24v = 0-18000 rpm or 5mA=0 inches 15mA=5 inches. once you make this designation, you should not have to convert the number as it will be listed for you.

Hope this helps, if not please give some more details as to what you are trying to accomplish.

I guess it would depend on what you want to do with the new I/O. It is possible that it could be done with a plc if you have one, or you may be able to configure an analogue/digital signal to act as one or the other to cover for the missing availability. Otherwise, go to the manuals section of the forum and lookup you controller model to find what options are available to you (you may not have room). From there you will pick an option (may require buying an upgrade with more available I/O channels available), find/create an open slot, add the card, new configuration in the I/O menu and hook up all your hard wires in the proper places. There are Wiring Diagrams in the installation/service manuals that should have all the info you need

Sounds more like an assignment for a programming degree rather than engineering(or your teacher wants this ability and has no idea how to do it.) The best place to start would be to create a known point (origin). Then track each Gcode as a point and a vector(90 degrees to the table). Python should record each Gcode as new position offset from the origin. From this data set it should then be possible using python to format to rapid(you will have to write this code) as "programmed offsets". From these you should be able to apply the perpendicular vector to run a "jtCalc" to create your "RobTargets". You will need to use the "Move C' quite a bit.

Get a copy of the users manual that matches your controller model for the robot, get the rapid commands manual as well, from the manuals part of the this forum. Start studying the terms in quotes. I am no expert and am sure others will be better able to help out on the technical side on rapid things

Remember that all the data you need is supplied or implied and that your problem is one of formatting. Good luck and keep us informed. If you can get it to work, I am sure there are people here that would be interested in seeing how you got it done.

Good luck!

Am I right that you are using the rod to displace sand for a sprue or vent and when you pull it out the rod is damaging the sand? If so, you may want to try to update (or at least check) your wObj OBJ Frame of sand mold and then try the align function inside of jogging to make sure that your P1-P2 movement is a straight line and also perpendicular to your wObj frame.

In order to help you out , you need to be more specific. If you are counting by row, then you are also counting by part correct? Create nLastpartofrow or something like it. Use that to call either ROWTYPEA or ROWTYPEB array data.

Or you could use the MOD math instead. If nNUMBER MOD2 =0 then EVEN:=True ELSE EVEN:=False. IF EVEN then ROWTYPEA, IF NOT EVEN then ROWTYPEB.

Obviously not the proper syntax, but you get the idea.

I suggest researching the NOSTEPIN command of that line. If I recall, that is a way to kind of "Hide" the data it is referring to. It will tell it is running the code but not display it, in your case it looks like it is hiding it from you. I believe you can change that attribute of the SYSMODULE, and hopefully then be able to read and write to it.

Good luck!

Check for loose connections and bent pins. Do a backup and try a reboot. If the Light fails to go green, check your power supply voltages. If they check out, you probably have a bad drive unit which needs replacing. Look through your error logs for any other clues.

Did you have any power surges? Fires? Lightning? Roof leak? Any more clues?

In the future It would help if you let us know what controller you have and what software you are running.