TIA Portal Datalog On Change Query

[X-tech]

Hi,

I have a Siemens Comfort panel HMI with datalog setup at a remote site and I have been given CSV data from a client for analysis of the log. Using TIA Portal V15.

I suspect I am seeing a spike on an analogue input to the system, possibly for a single scan (S7-1500 system). I am logging this process tag through the HMI in a datalog "on change", no deadband.

I am not seeing a spike in the value within the log however (CSV data) but by process of elimination within PLC logic, its the only thing I can think of which is causing the irregular system behaviour.

I think I am grasping at straws to get some sort of explanation and I am pretty sure I am wrong, but my question is this:

If a process tag is configured for logging "On Change" (no dead band) would this ALWAYS be logged by the HMI even if the process value has spiked for say a single scan only, or can it potentially be missed? If my theory is correct the spike value is around 20% higher than the nominal value being monitored by this input.

 

[L D[AR2P#0.0]]

In the small bit of logging I have done I believe you cannot log on a per scan basis.



Set up a trace in the plc if you want to capture data changes on a per scan basis.



If it's an analogue input, it will be changing all the time (by 1 bit) anyway so you may want to chose your trigger conditions carfully.

 

[X-tech]

Hi,

Yes I understand the HMI logging is limited to 1 second, however if a process tag is set to log "On Change" (not cyclic), is it guaranteed that a process value change at the PLC (even single scan) will always be caught and logged by the HMI data log?

I fully appreciate if a tag is changing every scan at the PLC this will not be caught by the data log.

I guess I don't fully understand how the "On Change" acquisition cycle works? Does the data log use the same 1 second cycle as the fastest cyclic acquisition uses and then checks if the value has changed within this time period and if so logs as a change? When is it sampled?

The PLC is remote on site and I don't have access unfortunately. HMI data logs are all I have to go on.

 

[mk42]

Hi,

Yes I understand the HMI logging is limited to 1 second, however if a process tag is set to log "On Change" (not cyclic), is it guaranteed that a process value change at the PLC (even single scan) will always be caught and logged by the HMI data log?

I fully appreciate if a tag is changing every scan at the PLC this will not be caught by the data log.

I guess I don't fully understand how the "On Change" acquisition cycle works? Does the data log use the same 1 second cycle as the fastest cyclic acquisition uses and then checks if the value has changed within this time period and if so logs as a change? When is it sampled?

The PLC is remote on site and I don't have access unfortunately. HMI data logs are all I have to go on.

When the tag is set up to be logged On Change, it doesn't change the normal tag acquisition cycle. It just means that each time the HMI detects a change, it logs the value. Logging cycle and tag acquisition are different things, but logging cycle cannot be faster than acquisition cycle.

 

[X-tech]

Yes, so logging cycle is 1 second, 2 second, 5 second etc. and is applicable when the logging tag is configured as "Cyclic" acquisition type.

My tags are configured as "On Change" acquisition type. If a process value is constantly changing per scan (within the PLC) I see my log has time stamped each entry at 1 second. Does this mean that the HMI samples only at this 1 second "snapshot" moment in time? I.e. if a PLC process value was to change after the HMI sampled it and then corrected back to its nominal value before the HMI samples again (faster than 1 second logging cycle) , the HMI would NOT detect this change and therefore not log it?

 

[mk42]

Yes, so logging cycle is 1 second, 2 second, 5 second etc. and is applicable when the logging tag is configured as "Cyclic" acquisition type.

My tags are configured as "On Change" acquisition type. If a process value is constantly changing per scan (within the PLC) I see my log has time stamped each entry at 1 second. Does this mean that the HMI samples only at this 1 second "snapshot" moment in time? I.e. if a PLC process value was to change after the HMI sampled it and then corrected back to its nominal value before the HMI samples again (faster than 1 second logging cycle) , the HMI would NOT detect this change and therefore not log it?

You are correct. The HMI only samples the tags at the tag Acquisition Cycle, which, as I said, is different from the Logging Cycle (if in cyclic log mode). There is no way the HMI can log faster than that, because the HMI doesn't know any other tag data.

 

[drbitboy]

... I.e. if a PLC process value was to change after the HMI sampled it and then corrected back to its nominal value before the HMI samples again (faster than 1 second logging cycle) , the HMI would NOT detect this change and therefore not log it?

Someone could test this pretty easily, right?

 

[X-tech]

Someone could test this pretty easily, right?

Could do if I had some hardware and/or TIA with PLCSIM. I literally have some CSV logs only...

I don’t have access to TIA unfortunately.

Thanks for your help everyone.

 

[L D[AR2P#0.0]]

I am not seeing a spike in the value within the log however (CSV data) but by process of elimination within PLC logic, its the only thing I can think of which is causing the irregular system behaviour.

How have you done this without access to TIA?

 

[X-tech]

How have you done this without access to TIA?

I have hard copies of the logic.

 

[L D[AR2P#0.0]]

What analogue input card is involved, is there any filtering set for the card ? - I've never come across an analogue input 'spike' that lasts for one scan, but there is always a first time of course. More likely outside of the plc and/or a coding error.

 

[X-tech]

Ye for sure. It has nothing to do with the analogue input card itself. There is also 2oo3 voting. I am convinced I am getting noise from driving some nearby motors (time stamps align for this). I was just trying to use the HMI logged data to understand the system (not my system) and tie it all together, which I think I now can. I think the PLC is seeing the spike but I am missing it on the HMI log sometimes (dependant on its duration as below the acquisition time) which was what was throwing me. It may not be a single scan but certainly less than the acquisition time as I am not always seeing the spike but the implications of it I am seeing.

Not the easiest thing to diagnose by delving into paper copies for a site and system I have never seen but its not a very complex system. I am sure it is an external influence causing the issues.

There is no filtering employed on the input card

 

[L D[AR2P#0.0]]

Are there F-analogue modules used in the 2oo3 voting?

 

[X-tech]

Are there F-analogue modules used in the 2oo3 voting?

No, the 2oo3 is performed via software. Modules are just standard SM 531 (7NF10s) taken to separate cards.

 

[L D[AR2P#0.0]]

Debugging someone else's system remotely using print outs - do you want to borrow my hammer and chisel?


We may have been able to help if it involved cats or rabbits (in joke).