Hi everyone,
FTTM 13 on the same box as FactoryTalk View SE, logging about 40 tags off a 1756-L73 to SQL Server on the IT side every 10 seconds, scheduled transaction. Went to pull a report Monday and there's been no rows since Friday 18:40. Configuration shows running, data point connector and transaction both green.
What I did find is the transaction's cache file in the FTTM folder. It's 2 GB and growing, so it's collecting and not delivering. I stopped and started the configuration, no difference, then checked the L73 tags in the live data connector test and the values come through, and pinged the SQL box, that's fine as well. Someone suggested a reinstall and I'd rather not.
PLC side fine, database side dead, cache filling. Where do I look between the two? Is there a log in that FTTM folder that says why the delivery's failing, or am I stuck asking IT what changed on the SQL box on Friday night?
Don't reinstall.
What's the exact error in the FTTM log for the database connector, and in the SQL Server log at 18:40 Friday? One line each. Not the summary, the line with the reason.
> the line with the reason
FTTM log: "Login failed for user 'fttm_svc'" repeated every 10 seconds since 18:42 Friday. SQL side says the same, error 18456, state 8, if the state number helps. So it's the account. That account hasn't changed as far as I know.
State 8 is a wrong password. Ask whoever runs the domain when fttm_svc's password expired, my money is on Friday evening, the policy rolled over and nobody told the box. Nothing wrong with FTTM. It did what it should, the database connector lost its login so the transactions went to the cache file instead of on the floor. That's your 2 GB.
Get the account a new password with expiry off, put it into the database connector's connection settings, then stop and start the configuration. It replays the cache into SQL on its own. Ours took about an hour for a similar size, and you can watch the file shrink.
There's a writeup on the logging side of this: https://plctr.com/best-practices-for-plc-data-logging-and-remote-monitoring/
Password had expired Friday 18:40, IT confirmed it. Reset it, updated the connector, started the configuration. Login errors stopped.
Cache file isn't shrinking though, still 2 GB, and still no new rows. Half fixed, I guess.
Is the new login actually mapped to the database? Reset password, fine, but if IT recreated the account instead it lost its db_datawriter role. Check the SQL log again, different error this time?
IT had deleted and recreated the account rather than resetting it, so the SQL login existed with no user in the database. DBA mapped it back with datawriter, restarted the configuration, and the cache drained in about 40 minutes. Rows from Friday on are all there, timestamps intact.
So it started with the service account password expiring Friday evening, and FTTM buffering to cache exactly as it should. The second half was IT recreating the account instead of resetting it, which left a login with no user in the database. New password with expiry off, connector updated, user mapped, cache drained itself. The L73 was never in it.
The first few hundred rows after the restart came in out of order. Doesn't matter for the report but I don't know why.
Thanks scott_m, suel.
State 8, Friday evening, expired password. Same story every quarter somewhere.