The logger for our two packing lines is a workbook on one engineer's desktop machine. Running since about 2021, pulls 40 odd tags off two 1756-L71 racks through a Kepware server sat on the same PC, drops a row a minute into a csv and a macro tidies the lot at midnight.
That PC is on IT's rebuild list for next month and the engineer who wrote it left in March. I copied the whole folder onto a share and ran it from there as a test, and the macro fails on the first write because the path is hard coded to his D drive, so I don't think this is a lift and shift job.
I've got a month. Where would you actually put this, given nobody here is getting budget for a historian?
Not the server room. Small fanless box in or beside the panel, one job on it, writing locally. The day IT does something clever with the network at least the line keeps logging and you pick the files up afterwards. I've got four of those on remote pump stations and the oldest one is six years in, maybe seven, with nothing done to it.
And who backs that box up. That is exactly how you ended up here, one machine, one person, nobody else knowing what is on it.
Put the collector on a VM in the server room where it is in the backup schedule and somebody other than you can see it running. If the network is unreliable enough that a line stops logging when it hiccups, fix the network, because every other thing you do this year is going to hit the same wall.
Network is fine to be fair, it's a flat plant network and the packing lines sit on the same switch stack as the office. What worries me more is that nobody will remember the thing exists in three years either way, and I'm a bit stuck on how you fix that with a box.
You are both arguing about the box and the box is the least interesting part of it. Split it in two. One process talks to the PLCs and writes into a local queue on whatever machine it happens to sit on, a second process pushes that queue somewhere durable whenever it can. Then the box is replaceable. When it dies you lose whatever was still in the queue and not a row more, and where it lives turns into an IT question instead of a controls one.
That also answers your three year problem I think, because the durable end is the thing somebody else is already looking after.
That I'll take. Queue on the box, push to the share.
Fine, as long as the push target is somewhere that actually gets backed up and something shouts when it stops pushing. A logger nobody notices has stopped is the same as no logger, and you will not notice for a month. Export the Kepware config and get it into version control while you are in there, that is the bit nobody ever copies.
Worth a read before you commit to it, there's a writeup on this here: https://plctr.com/best-practices-for-plc-data-logging-and-remote-monitoring/
Went with the box in the end. Small industrial PC in the MCC room, Kepware moved onto it with the config exported into our git repo, a scheduled task writes the csv locally and robocopy pushes to the share every five minutes. The hard coded D path is gone, it reads the folder out of a settings file now.
Alerting is not in yet. I have a row counter and nobody watching it, so suel's point stands and that is next week's job rather than this week's. Cheers all, splitting the collecting from the pushing was the bit I had not thought of at all.
Do the alert before you forget the whole thing exists. That is the failure you described.