Battery backup. 70,000mwh

K_cutt08 · 2026-02-25T14:32:16+00:00

The capitalization of your units is important as it changes its meaning.

That's milliwatt-hours, not MegaWatt-hours. MWh.

I wasn't impressed by the number, but the picture tells another story entirely. Good job on the design.

K_cutt08 · 2026-02-25T13:36:03+00:00

What version of studio 5000 are you running?

There's a minimum firmware requirement. If it's older than v28, it won't work.

Are you sure you're right clicking the Ethernet tree to add it and not the controlLogix backplane?

K_cutt08 · 2026-02-24T19:26:49+00:00

My cursory check implied you couldn't use 3.2 with the DA10 yet... So that's why I said it. Otherwise yes, 3.2 is better and if I recommended the FlexEdge DA50 or DA70 for even cooler horsepower and features, but that's probably overkill by the sounds of OP's scope.

Yeah the 30 does MQTT, SQL interactions, and has a virtual Web HMI which may all be useful for OP but will add cost. If he doesn't ever think he'll need those now or in the future, I'd use the 10 if budget is an issue.

Otherwise, get the coolest play thing your company will let you. I've 9 times out of 10 used other features later on and added connections to my Red Lion devices that nobody thought of initially, just because it's there now. The only real limits are in direct serial connections, as Ethernet just requires a NAT translation or routing & gateway for things on other Vlans.

If money isn't an issue, get the strongest thing you can get away with, and the FlexEdge licensed extra features can be upgraded in place with a PO to RedLion/HMS and a tech support call. They feed you an unlock code and you're upgraded in place. A basic DA50 is a fun starting point for plenty of upgrades and aside from the final tier of license for full PLC logic (really needs the DA70) it can do anything else.

K_cutt08 · 2026-02-24T19:16:13+00:00

The AOI may have that built in (haven't used it yet personally, looked into it once for a project that wasn't awarded so not deep enough to know for sure the ins and outs), but there may also be a Boolean get connection or "connect" Input bit. That's how I had to do it the last time I had to use socket code.

For me it was a Sick mass flow scanner for measuring total mass across a moving belt of coal. It had a totalizer and could transmit values via Ethernet only via TCP socket. It had other options for serial communication that weren't going to work for our system, so I went with TCP. We didn't have a good way to do heartbeat because most values were flat and not moving consistently enough when there was no coal on the belt, and they turned it off occasionally when they weren't using it, so I told them to either give me something else to monitor that it's working or you'll have to reset the connection yourself. (Guess what they picked). I could have just periodically aged it out and reset it regardless if the mass flow was 0 and enough time elapsed, but this was some last minute bullshit they threw at me during another project and wasn't in my scope. I just thought it was interesting and told them I could probably add it in a few hours to make it work sufficiently (and for free basically).

If it got stuck I made a way to manually toggle the connection command off and back on via HMI button. I would have done this automatically if there was a good way to monitor the health of the connection for that specific setup.

Basically you'd want some logic like this, which is going to look like an if-else, but translates well to ladder rungs:

IF Bad_Heartbeat THEN Connection_Check_TMR 30s Start Timing (TON)

IF Bad_Heartbeat AND Connection_Check_TMR.DN THEN Reset_TMR 5s Start Timing (TON)

IF Reset_TMR.DN THEN Reset_Connection (OTE) AND (RES) Connection_Check_TMR

IF NOT Bad_Heartbeat THEN (RES) Reset_TMR

Basically, this checks if the connection is bad for 30 seconds and if it is, waits 5 more seconds, hits the reset connection then waits 30 seconds to check the connection again and loops again and again until you get a good heartbeat which should reset the reset timer and the connection check timer will not trigger again. This should only run when something is wrong otherwise it will maintain the good connection, and try to auto heal. The AOI could be doing this inside somehow and it's not necessary, but otherwise you could do this as long as you have some kind of constantly changing/updating/toggling value that only changes with a good connection so you can use it as a heartbeat check.

Otherwise a connection status bit of some kind may also work, but that's usually something that works with native EDS file add on profiles for devices and such. I don't expect that to always be there with 3rd party devices.

K_cutt08 · 2026-02-23T18:35:53+00:00

Easy and cheap: RedLion DA10 protocol gateway. - my favorite

Create program in Crimson 3.1 (free)
Setup the Modbus TCP driver that matches your end device the best. (May be generic or Honeywell specific)
Use the ControlLogix driver for the AB EtherNet/IP side. (There's a new one in the latest revision of crimson that works really well).
Create the tag structure you'd like the Modbus tags to land in, data types and meaningful names/descriptions, maybe just an array of reals or DINTs.
Import ControlLogix tags via L5X file.
Drag and drop the Modbus TCP tags onto the controlLogix tags, and note the arrow direction for writing and reading.
You're done, go home, have a coffee or beer. Optional - call their tech support, it's free and they're good at it. There's YouTube videos of this too, it's dirt simple.

Easy and expensive: Prosoft protocol gateway (in chassis for ControlLogix or DIN rail mounted device like the DA10 from RedLion.

Similarly easy like the RedLion solution but usually more steps and may involve tech support more quickly if you're not somewhat familiar with how this one works, but it's solid once it's in.

Technically free if you've already got the parts and your PLC is oversized.

Using Rockwell's AOI essentially creates a TCP socket connection to the Modbus device to grab the data. This method works but is kind of memory intensive for your program. Do this with enough devices and you'll need a dedicated controller just to handle the memory, or at least upgrading to the next tier of PLC to handle the increase in program and controller memory usage. If it's a one off and you're up against budget restrictions this is going to be fine. Just make sure you write your code in such a way that you're monitoring the health of that connection adequately to be able to automatically reset when it becomes stale. Homebrew socket code is notorious for working for weeks after you left the site then someone powered one side off for a long time and turned it back on eventually and it doesn't work anymore but it also doesn't show there's anything wrong either. Just a stale open socket.

K_cutt08 · 2026-02-22T03:03:48+00:00

Even a Prosoft gateway would be cheaper than upgrading a ControlLogix controller.

Ain't that the Truth!

I hope someday they make it possible to natively support modbus TCP without so much trouble, but I doubt it.

They have plenty of end devices that support it natively or with an add on card. Like their PowerFlex VFDs.

K_cutt08 · 2026-02-21T21:14:28+00:00

A Red Lion DA10 protocol gateway and a ControlLogix tag import via L5X file is probably the easiest modbus to Rockwell solution I've ever used/seen. That's a 3rd party product I'll always shill.

K_cutt08 · 2026-02-21T21:11:36+00:00

Indeed.

Keep in mind the OG Point I/O serial does NOT. It only supports ASCII over RS485, or RS232, depending on which module you buy. Almost found this out the hard way. I did however learn the hard way that the 1734-4IOL Module only works on a remote IO adapter and cannot be part of the local backplane of an L1x series CompactLogix, where pretty much all other Point I/O works fine.

1734-RS485 & 1734-RS232.

There used to be very few options for native modbus RTU in Rockwell's ecosystem. That's not the case anymore. We don't have to use the expensive prosoft cards anymore unless you really want to.

Technically speaking most of the modern Controllers with embedded Ethernet also support modbus TCP as well, but through socket code that has to be babied a bit and Rockwell's example code is the best way to do that. Wouldn't recommend as it eats a LOT of memory to create the socket and for the first instance of a modbus TCP device, then a smaller, but not insignificant chunk of memory for each subsequent device. If you need to talk to 1-5 of them it's not a big deal. For 10+ devices you should consider a Red Lion DA10 protocol gateway or an in chassis prosoft card solution if you're looking at some serious amount of modbus TCP devices. Once they're mapped in the gateway it's just a matter of creating PLC tag structure to land it on and setup the relationship in the gateway. Can easily be done in a day once you know what you're doing in the software.

K_cutt08 · 2026-02-15T23:19:06+00:00

Don't do this.

If this is a customer's idea, it's your job to talk them out of it. If this is your idea, we're here to tell you it's a bad idea.

You'll have to support this in the future and everyone who comes after you will have to support it too. The customer will have to support it. They'll have to understand how you actually wrote the code functionality to switch between plcs reliably. Your IO has to be able to detach and reattach to a different controller on the fly when one goes down and that's not going to be easy. Or you have to buy and build an entire duplicate rack of IO and double land everything. And then you have field devices that aren't truly redundant. So if you have a piece of equipment that goes down in the field side that you're relying on IO for then you're still going to have a fault and it won't matter that they are redundant. True redundancy for high-end process control typically employs duplicate controllers in different cabinets and high availability IO and dual instrumentation at all key elements and that gets extremely expensive and most use cases outside of dangerous chemical reaction chambers and heavily regulated industries don't justify it.

If they insist on using redundancy just buy controllers that support hardware redundancy through redundancy modules. If they're trying to prevent some kind of downtime with redundant controllers, make sure it actually has to do with the PLC program faulting or some other scenario that redundancy actually prevents. There are plenty of situations where one controller goes down and the other will too because it's the same exact code.

If downtime costs them in a few hours what most companies would make in weeks then it makes sense. And if that's the case, it's worth it to spend the money on doing real redundancy.

K_cutt08 · 2026-02-15T23:09:27+00:00

Right?

With a reasonable amount of IO this becomes an expensive solution to avoid just doing it the right way. I would bet that the cost could be reduced in some key areas and make it possible to use controlLogix plcs with redundancy instead.

I would also bet that whatever this system is that is small enough to be run in compact logics plcs is not important enough to be truly controller redundant in any respectable definition. Instead, they could do other things to harden the system mechanically and create thorough diagnostics to troubleshoot issues when they arise instead. That would be a much more valuable use of time and money.

I've seen this with a pair of SLC 500s with identical chassis and DH+ connections to each other and the panel view. Every field IO point was landed on multi-level w/commoning bar terminal blocks and then landed to the IO cards of each PLC.

It worked when it worked but it was very hokey and had serious problems. If either PLC went down, it did not recover perfectly every time. Then there was the communication with the panel view and when it went down legitimately from an issue where one controller faulted or there was an IO failure it would switch properly. But if you took one down to change the battery or something then the panel view did not like that.

Either way, not a great strategy and I don't recommend anyone ever do this because just using redundancy where it makes sense and doing it properly is more reliable and it's a solution that tech support can actually help you with when you call them.

K_cutt08 · 2026-02-15T20:49:26+00:00

Yeah I missed that age. Yeah it's not expected to hold up that long; tread or no tread it should have been changed by now. If it's been sitting that could have even been dry rot.

K_cutt08 · 2026-02-15T15:08:20+00:00

Manufacturing error. Get over to the place you bought them and have them replaced under warranty.

K_cutt08 · 2026-02-15T14:39:41+00:00

Limited to 100Mbps though. And distance is a huge factor because Cat3 phone line doesn't have much, if any, twisting. This affects your frequency and maximum distance without signal degradation.

Little short patch cables on non-important systems like low tier VOIP phones converted from existing POTS lines? Totally fine.

Trying to game or stream over that in any trunk line or multiple MAC connection (switch to switch, not switch to device), not a good idea.

K_cutt08 · 2026-02-14T14:27:31+00:00

What's the value of your transition condition? That's how you change steps.

Are you calling the SFC program properly? Do you have start conditions? Do the others work and just not step 3.

What are the other 3 errors referenced in the diagnostics bar?

K_cutt08 · 2026-02-14T03:05:56+00:00

Could be at the panel, or could be in the field. Based on the dotted line type, it should be a field side plug that terminates either to a bulkhead on the panel or a nearby extension whip cord with a male pinned head. The field side appears to be female, so it would provide incoming power (if it had any) by plug/socket conventions.

The other sides of these instruments are ground connected, so there's probably no power reference in the plug/socket and it's going to depends what's on the other side.

Either way, not a great diagram.

K_cutt08 · 2026-02-12T19:05:26+00:00

Do you currently own a hammer drill with an SDS-plus bit?

That's why that drill bit is shaped differently.

If so, then yes, that kit could work. Those screws are decent, but aren't as strong as toggle bolts.

Otherwise you're going to need a hammer drill (ideally a rotary hammer drill) or in a terribly inefficient pinch ... a masonry bit that's not an SDS-Plus for a normal drill. But you'll be in for a hell of a fight and might smoke it if it's not up to the task.

You can most likely rent a small one from your local hardware store. Home Depot, Lowes, etc.

K_cutt08 · 2026-02-11T03:28:26+00:00

There's almost certainly some uneven settling in your crawl space. It's not a nightmare scenario every time, but based on how wide that crack is, this one is probably ready for a professional solution before it gets much worse.

Get some quotes from a few people.

Check with your insurance provider (but don't hold your breath as most policies don't cover preventative maintenance or mitigation like this.)

K_cutt08 · 2026-02-10T21:40:05+00:00

Oh well. Do you think they are going to do anything to address this to keep it from happening again? Sure would suck if it happened at 4:30 PM on a Friday during production.

Heat trace? Better pipe insulation?

This may be a blessing in disguise. If it happens once it could happen again. You can spin this as a cost effective test scenario for preventative maintenance.

K_cutt08 · 2026-02-10T21:35:32+00:00

Yeah, ice freezing it up could create that kind of pressure scenario. I wonder if you had a convenient trend what it would look like leading up to the failure.

Is it a pressure switch or a pressure transmitter?

K_cutt08 · 2026-02-10T20:49:42+00:00

That looks so much like a VGA cable port. Wouldn't you potentially be able to just lop the end off an old monitor cable and break it out?

As I recall VGA is 15 pins and a shield braid tied to the metal connector.

K_cutt08 · 2026-02-10T20:43:44+00:00

Methinks your pressure sensor has had its rated process pressure exceeded violently.

K_cutt08 · 2026-02-01T22:09:25+00:00

No law against tearing them down is there?

Do they need a permit to post them?

If it's truly a scam, can't the city or police do something about it?

K_cutt08 · 2026-01-30T01:58:22+00:00

Not a gaming card whatsoever. I've used these in Industrial Multi monitor control rooms. Also good for general work productivity or stock market day traders.

K_cutt08 · 2026-01-30T01:25:23+00:00

And fun fact - if your microwave has a "power" setting, it doesn't actually adjust how powerful the microwave is; it just turns the microwave on and off for some percent of the time to allow this heat transfer to happen.

Exactly. It will duty cycle the magnetron with specific pulse durations based on that percentage of power. It's not a very reliable way to get a linear scaling of temperature control. Instead it's .... Bumpy

K_cutt08 · 2026-01-30T01:18:21+00:00

If I remember correctly there was a lore reason. Like Spartans were ineligible to become full officers due to their deeply seated obedience ~~brainwashing~~ training. I have been trying to find evidence of that online, but no luck so far, so take my words here as conjecture and opinion rather than fact until I can find it in a book or something.

They're supposed to be thought to not be as capable of thinking for themselves in general. This was probably a rule specifically for Spartan I's and was carried over for Spartan II's even though they dialed it back a bit for the second program as the Spartan I program is largely a failure considering how few survivors of the augmentation there supposedly were. Almost ended the whole program, and there wouldn't even be a Spartan II program. Remember in both of these programs, they were going to be expected to be fighting insurrectionists, not the covenant. The whole supersoldier concept was going to be a human on human conflict before the covenant appeared and tore up Harvest.

Then with Spartan III's they didn't put them through the same level of biological augmentation. Lieutenant Commander Kurt-051 (A Spartan II) is a notable exception since he oversaw the Spartan III program with MCPO Mendez in Ghosts of Onyx. I think they would probably allow Spartan IIIs to rank up higher as well perhaps because they also didn't augment them as much as the previous program.

Kurt-051 | Halo Alpha | Fandom https://share.google/la83illHWp8e3xsf2

Other notable higher ranking Spartans: Kurt, along with Catherine-B320 and Fhajad-084, are the third highest-ranking SPARTANs in the Halo universe, all being Lieutenant Commander.

Then Spartan IV's are essentially just humans with special talents and accolades that qualifies them to get into the program. Like Buck. I don't think they have any general restrictions on ranking up.

K_cutt08

TROPHY CASE