Yeah, yesterday was weird. At a certain point, every account showed as being banned. It got me really worried that the forum had been hacked, glad to see it's back to normal.
Posts by RockemSockem
-
-
Alright, so I actually messed up. My "solution" above does not work and, for anyone reading this for the same reason I started it, you probably shouldn't try it. Thank you Nation for showing me the schematic because that is why I didn't even test my "solution" (as to why I said it worked without testing it, that was a silly mistake on my part. When troubleshooting, I undid the power to the output module and didn't wire it back in when I tested my first solution, and when it didn't blow the fuse I thought that meant it worked). I was way overthinking the problem, and the solution is simple.
My current solution is as follows:
Leave EES11/21 and EAS11/21 alone
With PLC outputs in bipolar mode (0=pt0 sourcing,1=pt0 sinking,2=pt1 sourcing... etc) wire point 0 sourcing to EES1, point 0 sinking to EES2, point 1 sourcing to EAS1, and point 1 sinking to EAS2. It works and hasn't blown any fuses. From a circuitry standpoint, this should be the same as using dry contacts, as the external supply for the safety circuit is the same as that for the PLC. Unless I'm mistaken (very possible as I'm no safety engineer) this should mean that it maintains the same safety rating as if I had just used appropriately SIL rated safety relays.
Here's why the initial solution I came up with wouldn't work:
The problem was that the safety circuit was being shorted. Because each point on the output module was powered in parallel, the signal from the safety circuit could go straight to the common of the DC PSU, thus blowing the fuse. Swapping the polarity of the output point wouldn't have done anything to prevent that as the signal could have travelled through either wire and down to the parallel connections. In fact, it might have been worse because I'd be pitting my DC PSU against itself, I think.
-
Than you Nation. I did remove the factory jumpers from the internal to the external and supplied my own 24VDC. Is that diagram in one of the manuals? I was looking for something like that but couldn't find anything.
-
Swapping the outputs so that the negative side went to EES/EAS 1/2 and the positive side to EES/EAS 11/21 worked. If there are any issues this might cause later on down the road, please feel free to chime in. Otherwise, I consider this solved. -
Hello All,
I have a robot cell I've been working on for a few months, it is my first integration project (I do not work for an integrator, I am a first time automation engineer at a manufacturer), and I have a problem. I'm using an Allen Bradley Compact GuardLogix PLC with safety IO modules to control the safety and other parts of the cell. My plan was to have the safety devices (interlock, e-stop button, light curtains) input to the PLC, and then the PLC output to the EES and EAS terminals on TB0P4. After testing and popping fuse 1 a couple times, it isn't working. It looks like I need to use dry contacts to complete the safety circuit and not powered points, so my questions are:
Can I use my output module (5069-OBV8S) by wiring it in bipolar mode with my negative to EES/EAS 1/2, and the positive to EES/EAS 11/21, or will that also pop the fuse? I currently have the positive to EES/EAS 1/2 and negative to EES/EAS 11/21.
Do I need to get safety relays for this instead? Since I'm using a safety PLC, would it be ok to use normal relays controlled by the safety output module? It is being built to SIL2.
Can I make my module points dry contacts somehow? My apologies if this is a dumb question, my PLC education was... limited, to say the least.
Does the safety circuit run on the EXT 0/+24V in TB0P6 and should I be looking at how I have that wired instead? That is wired as +24VDC to EXT24V and the negative from the same DC PSU to the EXT0V.
I am out of my depth, with no real experience or education in safety wiring, so my apologies if this isn't making sense.
-
Yes, I know. The issue is that macros assigned to UK shouldn't require holding down shift, but on the robots I have access to it does.
-
My apologies for not getting back to you, I completely forgot I made this thread.
All of the above is correct. From what I recall anyways, it happened in any mode.
-
Hello,
I was setting up some macros yesterday, assigned to the user keys, and when testing them the controller issued alarms saying that I need to hold down shift to use them. From the manual, I read that that should only be the case for macros assigned to SU inputs, but I was using the UK inputs. Not a big deal as I don't need that many assigned, but very confusing. Anybody know why it might be doing that?
-
You can check what options you have installed by pressing MENU > 0 > 4: STATUS > Version ID > Softkey F3 CONFIG. There will be a list of every option installed.
-
Found the solution in this thread. Turns out my firewall was blocking IE.
-
It was on the Pendant. It didn't ask me anything about Javascript, but I'll check the settings.
...The more recent version of robot controller need a software installed in the compiuter that is trying to connect to the robot controller.
I have tried it with iPendant Controls V7.50, V7.70, and V9.30.
-
I did try the recommended solution; curiously, the LPCOND_TIME was set tp 48. I changed it to 40 with no difference after discovering it.
The iPendant and the controller have their own software loaded onto the devices.
-
Hello,
Last week I got our robots hooked up into our wireless network, and started checking out the different webpage functions. After getting all the software (I think) needed onto my computer, I tried to use the echo pendant function and got a PMON-001 error and accompanying OS-26 error. I'm not sure what OS-26 is, as I haven't been able to find any documentation on it. What I suspect is the problem is that the iPendant software is out of date; the robot version is 7.70, and the iPendant is something like 7.50. I can't update it just yet as I'm waiting till they're pulled off production, but while I'm waiting, can anybody confirm or deny my suspicion, or shed light on OS-26?
-
The promised update:
We went with the IOGEAR GWU637. It has an operating temperature range that worked well, as our plant floor gets quite hot (112f in the controller). That said, I wouldn't recommend it on the simple fact that it is not powered over ethernet, which was an oversight on my part. If anyone needs a wireless bridge, PoE is the way to go. But, these do work.
-
Thank you RookieWithRobots.
We checked that on the robots and they're set the same (-1), so it isn't that, unfortunately.
-
A colleague figured it out. The points were taught in the world frame, and for some reason it doesn't throw the error when that's the case. Or at least that's how our robots are configured. Weird.
-
Hello All,
Bit of a weird "problem" on my hands. I went out to take a look at one of our robots and just poke around for a bit, and noticed that the positions saved for the robot used a different userframe than the program dictated. To my understanding, this should cause an INTP-252 (EDIT: or INTP-250) error, but it hasn't. The robot runs fine, but I am a little concerned what might happen if some other error comes up. Any idea why this might be happening (or not happening, I suppose)?
EDIT: This is only happening on one of the robots as well.
-
I believe $UI_CONFIG.$hmi_mask is what you're looking for. To enable/disable the HMI menu, you'd want to flip bit #1.
-
For anyone reading this, we decided the force control was not appropriate. We are looking into passive compliance devices instead, but even just taking the force control off of the programs has improved the performance of the robot.
-
Thank you DS186 and hermann, I think that is actually everything I need for my project. I'll update when I get it all set up.