Joe E.
MrPLC Moderator-
Content count
1604 -
Joined
-
Last visited
Community Reputation
262 ExcellentAbout Joe E.
-
Rank
Propeller Head
Contact Methods
- Website URL http://
Profile Information
- Gender Male
- Location Harrisonburg, VA
- Country United States
Recent Profile Visitors
12853 profile views
-
IO_Rack liked a post in a topic: Event Based Logic
-
Honestly, I'd ask the customer for an example. From a similar machine if possible. "Event based" is a pretty vague description and I'd want to know what they mean by that before committing to it or starting any detailed programming.
-
Some PLCs also let you do a hardware interrupt based on an input changing state. Of course, you can also accomplish that with a conditional subroutine that only executes when the event occurs. As I think about it further, I think most of the PLC programs I've worked with are, essentially, event based. In other words, when the operator hits "start", do these things until the operator hits "stop". Or, do xyz when sensor abc turns on. Did you have a more specific event in mind?
-
I've gotten into the habit of limit checking tags/addresses used as array subscripts to make sure this doesn't happen. A simple LIM instruction preceding the indirect address use keeps the fault from happening. You can then trap it and "do something" to fix the offset or alert the operator/maintenance/programmer/someone of the issue. Ideally, that trap would never be triggered because the preceding math would be written in such a way that it wouldn't cause the overflow. Ideally...
-
Mickey liked a post in a topic: SLC 5/04 Communication Issue
-
pturmel liked a post in a topic: SLC 5/04 Communication Issue
-
SLC 5/04 Communication Issue
Joe E. replied to Con/Drv EE's topic in Allen Bradley / Rockwell Automation
Generally speaking, unplugging the HMI doesn't interfere with the process itself; it just make it inconvenient to interact with it. It's possible, however, that someone at some point in some place added a sort of heartbeat of some kind between the HMI and PLC to make sure the HMI is present and running. I sincerely doubt that's the case here, but hyper-prudence suggests not unplugging it until the system is in a safe state where an interruption won't be harmful. Once verified that all is well, the system may be resumed. As for the cables.....it's complicated. Do you have access to an offline backup of the PLC program? Look for a file with an .RSS extension. If it's an accurate backup, you can look in the channel configuration to see if it's RS232 or DH485. That will tell you which cable you need. If it's DF1/RS232, you can just use a USB-RS232 adapter (Keyspan USA19HS is my choice) with a crossover (null modem) cable. If it's DH485, you'll need a UIC adapter. My first choice for that is: https://www.plccable.com/allen-bradley-1747-uic-usb-to-dh485/ To connect via the round mini-DIN, you'll need a DH+ adapter, which is more problematic. And a LOT more expensive. AB's version is the U2DHP, which is expensive and fragile. At my last place, we had 2 or more randomly just stop working with no visible damage or misuse. We had a large installed base of ControlLogix systems with lots of spare parts, so we had a ControlLogix chassis set up with 1756-ENBT and 1756-DHRIO modules. That made it easy...ish to connect to the SLC 5/04 and PLC5 PLCs. As a somewhat easier (but still expensive) alternative, we also had a ProSoft gateway module we used. It was a little tricky to initially set up but worked easily once working. Lasted for years. If I encountered a DH+ device here, I would seriously consider this instead: https://www.plccable.com/allen-bradley-1784-u2dhp-alternative-usb-to-data-highway-plus-dh-anc-120e/ That one has the advantage of not needing an external power supply, which was a serious limitation of the ControlLogix chassis and the ProSoft module. -
Powerflex 40 Firmware update
Joe E. replied to Shomation's topic in Allen Bradley / Rockwell Automation
To add to ElectronGuru's warning, I've seen a firmware update fail on a PF7xx once that bricked the drive. Thankfully, we had a spare on hand. Doubly thankfully, the one doing the flashing was an AB engineer so they ate the cost of the replacement. I've generally seen FW updates on PLCs and modules go pretty smoothly, but I would be cautious about flashing a drive. Could be that I'm biased because I've only been involved with a very small number of them and one of them failed but if I didn't really need the updated FW in that drive, I'd probably leave it alone. -
I would be too.... Thank you for sharing the fix! Another reason why it's important to maintain current ProSave backups. That was part of my routine back when I was working with MP and Comfort panels.
-
Hmmmm.... No idea if this will help or not, but in Windows if you hold shift and right-click on a program in the taskbar you can pick "Move" and use the arrow keys to move it around. You'd need a USB keyboard and if the taskbar is hidden, you're out of luck. This is an interesting one.
-
Ethernet/IP communication with Allen Bradley PLC in network
Joe E. replied to Deeksha's topic in Allen Bradley / Rockwell Automation
I know some devices at least used to allow a "listen only" connection where additional "masters" can read data out but can't send commands. For example, more than one PLC could read the input/output status but only one PLC can control the configuration and outputs. Not sure if these support listen-only and it's not relevant to OP's original problem, but it could be useful to know at some point. -
I'd probably try to plug in a USB mouse. Maybe it can grab the sliver.
-
The last license we bought was when I started here in early 2020 and subscription was an option. We went with lifetime. Interestingly our self-support online TechConnect is way less than the license was. I don't remember the subscription prices being nearly as high as a lifetime one, though. Their pricing has always been a little....schizophrenic on some things though.
-
Joe E. liked a post in a topic: [Q] Studio 5000 Versions
-
To clarify what's been said above, with a warning that the latest RA licenses may not work the same way since they're really pushing subscriptions: At my last place, we had lifetime licenses originally purchased at v10 or so that were still active and in use to active up to v30 or v32 when I left. Others were bought around v20 or v24 and could also be configured to activate back to v10 and up to whatever was current. The only additional cost wasn't an additional license, but an annual support contract that lets you download the installer files for other versions. It's a similar situation where I am now. Our annual contract is substantially less than another lifetime license of the software. I use virtual machines for all of my automation software. Right now, I'm using a Win10 VM with versions 24 and 28-34 installed. I have an older Win7 VM with versions 10-16, 18-21, v24, 28, 30-32. I also have an XP VM with v10-16 and 18-20. I rarely use either of the older VMs any more since most of our stuff here is in the newer versions.
-
Joe E. liked a post in a topic: Ethernet/IP communication with Allen Bradley PLC in network
-
So, some more details. The BSL and BSR instructions operate on a rising edge of the rung enable. You would enable the instruction once every time the encoder turns enough for a part to have passed by. The last one I did is in a CompactLogix. I had to create a tag called "Track_Array" of type DINT[1]. The Array tag of the BSL instruction was Track_Array[0]. Its Control tag is a new otherwise unused tag and the source bit (for me) is an Always_Off bit. Length is the number of parts that can be on the conveyor plus a few. If the conveyor is more than 32 parts long, you'll want to have your Track_Array tag bigger. For example, DINT[2] will get you 64 positions. The one I did was anchored at the load station being station 0 so I used a BSL. If instead you want the end to be bit 0, you'd use a BSR instead. Doesn't really affect things other than how you think of it. Here's the rung with the BSL. CAM_00 is on once per machine cycle. In your case, you'd flash it once every time a part spot has passed by on the conveyor: Here, we set bit 1, which is where the servo loads the blanks: Here, we clear bit 8, which is where the finished parts fall out of the machine. Like I said before, I'm not 100% sure this is really the best way to proceed for you. It may make more sense to use a FIFO array. Use an FFL instruction every time a part passes by the sensor and an FFU every time a part arrives at the end position. Downside to using a BSL/BSR is if the parts can slip on the conveyor. If that's not an issue, the FIFO won't work if parts can be removed from the conveyor between the sensor and end. That's why it's good to have multiple tools in your belt.
-
If all you want is to store good/bad, use a bit shift array using a BSL or BSR instruction. High level description: You'll execute the BSL/BSR once per "interval" of the conveyor's movement. Let's say the end position is at bit 0 of the array and the sensor is at bit 20. The sensor will set/reset bit 20 of the array while the reject/whatever sequence looks at bit 0. A BSR is fired to shift the data automatically.
-
Ethernet/IP communication with Allen Bradley PLC in network
Joe E. replied to Deeksha's topic in Allen Bradley / Rockwell Automation
I've seen many applications that used the dual ports in a daisy-chain configuration. Is the main drawback that all downstream devices go away if one in the middle is powered off? Or is there another reason too? -
Are the products all the same size? If so, I would first create an array big enough to have one position for each place a product could be on the conveyor. Array could be bits or integers, depending on how much info you want to track. Use the encoder to advance the array. Write to the right spot in the array at the sensor and read from it at the "store" position. That's my first pass thought.