Crimson 3.0 - logging intermittently changing values

[clay.float]

Greetings PLCS.net Community! I've been a lurker here for a little while, and I've already found tremendous value in the posts I've unearthed to help me out. I'm a total newbie to the world of industrial automation, so I'll be starting from the first rung when it comes to cobbling together functionality for things... on to today's question:

In the system I'm working on, there are a number of intermittently changing values that I'd like to be able to track. A few are manually entered on a daily basis, one is entered on a less frequent basis, and the rest will change depending on the workload of the system as it switches from one stage of operation to another. I will be logging around a dozen parameters like this, in addition to having a separate pair of logs that continuously track different environmental conditions.

Out of the box, the database was set to track these values at one sample per 60 seconds, storing the last 7 files of 1,440 samples each. This isn't optimized for our needs, so I'm changing those over to Triggered logs. Here's an example of what my proposed arrangement is for tracking changed to Parameter1:

Tag Parameter1: this will be adjusted by the user on a daily basis. On that tag, I have set Alarm 1 with Event Mode "Change of State", Trigger "Edge Triggered Event", and On Event "LOGS.Trigger_Param1 := true". I've set Alarm 2 with Event Mode "Change of State", Trigger "Edge Triggered Event", Delay "500 ms" and On Event "LOGS.Trigger_Param1 := false".

Log Parameter1: Update Type: "Triggered Snapshot", file holds 28 samples, system retains 130 files (for 10 x 13 week years; I'll deal with pulling logs off later), Log Trigger "LOGS.Trigger_Param1", Contents "Parameter1"

My Question: Is there anything glaringly wrong with how I want to set it up? Maybe there's a more efficient way, or one that makes better use of Crimson's design?

Thanks for reading!

 

[OkiePC]

The way that you are resetting the trigger tag based solely off of time is no guarantee that the logging has occurred. It may work flawlessly, but does leave a bit of a loophole in that if the logging is not processed within a half a second, the tag turns off and you might miss it.

One thing I have done for a customer is to add an entry to the alarm log any time a user changes anything. It shows the person's name and what they did. This ends up in the alarm history and is highly customizable. It heightens the awareness of the operators when they know that everything they do will be visible on the HMI alarm history page with their name next to it. For example, one of their lake pumps VFD speeds has an alarm set on "Change in Value" and the event name is:
=GetCurrentUserRealName() + " Changed VFD Speed Lake " + Title

Where Title is a string tag in the same tag folder containing the text "Pump 1" in this case. So the alarm history will show "John Doe Changed VFD Speed Lake Pump 1" if John Doe is logged in and adjusts the speed. This is only really useful if you set up the tag security to require someone to log in in order to change it. Also, if you enable the events to be logged to the CF card, you can keep track of these events and review them for virtually forever.

About the Triggered snapshot and the other fields...it has been many years since I set up a triggered log file that I don't recall but it seems that the meanings of "Each File Holds n samples" changes meanings a bit when you are using a triggered snapshot type of log. So I am not sure you will get the results you expect...you might have it right, but it is something that you might need to experiment with.

I have used the FTP capabilities with Crimson quite a bit. I have installed Filezilla on a couple of machines and enabled FTP logging so that I don't have to worry about discarding old files on the memory card since a copy will exist on the FTP server. It was really easy to get that working.

 

[clay.float]

The way that you are resetting the trigger tag based solely off of time is no guarantee that the logging has occurred. It may work flawlessly, but does leave a bit of a loophole in that if the logging is not processed within a half a second, the tag turns off and you might miss it.

You have perfectly captured my main fear there: without a handshake or acknowledgement of some kind, I can't guarantee that it's logged. My understanding is that the Log Trigger requires a false-to-true transition to trigger the logging; maybe I should set it to normally True, then it switches to False for the 500ms, meaning the rising switch back to True will trigger the log... food for thought.

it seems that the meanings of "Each File Holds n samples" changes meanings a bit when you are using a triggered snapshot type of log. So I am not sure you will get the results you expect...you might have it right, but it is something that you might need to experiment with.

Yeah, with it being Triggered, there's no strict binding between time passing and the rolling over to a new file; I'm just trying to loosely line things up so it wouldn't be too difficult to match these logs up with others done continuously or that are triggered at different frequencies. There's definitely more experimenting in my future!

Thanks for the words