SM1231 - Smotthing cycle cause me issue

Hello all, 

I work on a pump wich has a 1212C dc/dc/dc + SM1231AI + CM1241 RS232.

I use a SM1231 AI beacause I have to work with a sensor pressure 4-20mA and the 1212C does not have 4-20mA AI in.It is a 4-20mA because I can use the security "cut wire" (sorry my TIA is in French).

I explain the program of the pressure sensor, it is simple: When the pressure go above a hight limit, the pump stop and a message is send to the PC with RS232. The control software on the PC show "over pressure"

I monitor the serial communication to see what is passing throw.The control soft on the PC send a state question every second to the pump. When the pump is off I only see the questions, normal. 

I switch ON the pump and when the PLC is ready it begin to answer. In the answer I can see the code of error message.

At start up the pump has no pressure so normally I would not have an over pressure error. It is the case when I put 4 cycles in the smoothing, no error. But when I change to 32 cycles, I can see in the serial monitor that the pump send an over pressure to the pc and I have the message in the screen. Normally closing the error message on the screen delete this error but in the serial monitoring I can see that at the second answer I do not have any error message, and I have to do nothing for that...

To resume, when I configure the smoothing of the module at 4 cycles, it is ok but when I choose 32 is not. Could it be a question of priority in the program of the PLC? What does this cycles are link to ? PLC cycle ? Maybe a matter of the nature of the sensor in 4-20mA and the initialisation at the start up ? I tried without "wire cut" but nothing change. I have the feeling that it could be a matter of time at the initialisation, with establishement of the current and number of cycle...

I hope you will understand my problem.

CBB.

Hello Charles-Benoît;

Fos a good description of the smoothing parameter and the effects of its filtering functions, you could read snoop3014's posts in the following threads:

https://support.industry.siemens.com/tf//ww/en/posts/smoothing-of-analog-values/188456?page=0&pageSize=10

https://support.industry.siemens.com/tf//ww/en/posts/s7-1200-analog-module/184920?page=0&pageSize=10

The only thing I can think of is that using 32 samples per calculation (strong smoothing) on a pressure signal (that has a tendency to vary quickly) might take too much time for your process.

Did you try setting a medium smoothing parameter? How does the AI signal respond?

Hope this helps,

Daniel Chartier

Thank you for the links Daniel. I think to understand the smoothing. My problem do not comes from the reading of the value of my sensor but the module itself. 

It seems to give me an over pressure at just the starting up of the module like if it was a cutting wire because I do not have any pressure in it. Really just after few micro second of the starting up. It's as if the module take to mush time to start up with 32 cycles of smoothing and result an cut wire. With 4 cycles no problem.

Maybe I could solved it by a temp at the start up of my program but it will be a patch and I did not solved the problem...

Hello Charles-Benoît;

If I may, one suggestion.

Whenever I have used a 4-20 mA signal modul, I favored using the 0 mA signal as a wire-break alarm instead of the integrated alarm detection.

You could remove the tick shown in your first screenshot for wire-break detection, download the changes to your CPU and verify if you still have problems in startup. If the module no longer generated the annoying signal, check in your program if the value measured is 0 mA at any time and use the result of that comparison to set the alarm bit for wire-break.

Hope this helps, 

Daniel Chartier 

Mr Chartier, I agree with your idea.

The value in the PLC will spike to a maximum numerical value if the current value is even just slightly under 4mA. (That is how wire-break works for the card, if I remember.) Calibrating the sensor to deliver always above 4mA may be a bit of a challenge.

@Charles:

There is another point to consider. The S7-1200 has the ability to make a scope recording. It is called "Traces". Several tags can be included to record in a graphical representation. This is very helpful to see how signals transition from one event to the next.

The best solution comes when understanding the process. Consider using "Trace" on the process before making any changes. Such is my opinion.

Hello !

Thank you all for your answers. They helps me to understand better my issue but I do did not solve it yet ...I prefer answer in one message instead with all the quote. If it is not allowed in the forum I will change that , no problem ;)

0_Einstein

Maybe take a look at FT_AVG from the OSCAT open source library (online search for it in your language).  You can filter your input signal _after_ any input filtering has been applied.

You can use the input filtering and FT_AVG filtering for the cases for normal operation, and for startup/shutdown cases.  Then you can adjust the input filtering to whatever gives you no faults or errors, and adjust the FT_AVG filtering for situations where you need slower control.

If you are reading the serial data, can you send error reset if the PLC logic is in a startup or shutdown case and a known "error" is thrown but can be safely ignored?

Hope this offers you some options, especially knowing about the OSCAT open source library.

Also, Siemens has the LGF (library of general functions) available which may help you solve some problems you might otherwise have to handle and write the logic yourself.

Charles-Benoît

Thank you for the links Daniel. I think to understand the smoothing. My problem do not comes from the reading of the value of my sensor but the module itself.

It seems to give me an over pressure at just the starting up of the module like if it was a cutting wire because I do not have any pressure in it. Really just after few micro second of the starting up. It's as if the module take to mush time to start up with 32 cycles of smoothing and result an cut wire. With 4 cycles no problem.

Maybe I could solved it by a temp at the start up of my program but it will be a patch and I did not solved the problem...

Thank you for showing me this library, I did not know them. Because It is not a personal project I prefer to use Siemens library instead of OS one... The good thing is that I found a function in the Siemens's one : "LGF_FloatingAverage". I could put the number of cycles on 4 cyles and use this function the smooth my pressure.

But now that gaves me a question : How often the mesure is done ? Does it the "integration time" ? Because if I choos for exemple 100 values, and ma integration time is 20ms I will have my result every 100*20ms = 2000ms so 2sec ?

EDIT: I will not have to wait 2sec... The calculation begin even with 1 value and takes a max of 100 values for the calcul.

Also I forget to answer you: I could not send an error reset. The PC does not know when the PLC is in Startup or Power off...

Also, does it possible to "avoid" the error from modules during the PLC starting up ? If yes, how I could do that ?

dchartier

Hello Charles-Benoît;

If I may, one suggestion.

Whenever I have used a 4-20 mA signal modul, I favored using the 0 mA signal as a wire-break alarm instead of the integrated alarm detection.

You could remove the tick shown in your first screenshot for wire-break detection, download the changes to your CPU and verify if you still have problems in startup. If the module no longer generated the annoying signal, check in your program if the value measured is 0 mA at any time and use the result of that comparison to set the alarm bit for wire-break.

Hope this helps,

Daniel Chartier

I have tested your proposition and even if I tick nothing, my problem is still there.

qwazee

Mr Chartier, I agree with your idea.

The value in the PLC will spike to a maximum numerical value if the current value is even just slightly under 4mA. (That is how wire-break works for the card, if I remember.) Calibrating the sensor to deliver always above 4mA may be a bit of a challenge.

@Charles:

There is another point to consider. The S7-1200 has the ability to make a scope recording. It is called "Traces". Several tags can be included to record in a graphical representation. This is very helpful to see how signals transition from one event to the next.

The best solution comes when understanding the process. Consider using "Trace" on the process before making any changes. Such is my opinion.

 I've never used the trace before, now it's done. I have learned indectlly something new, good!

Does the Trace could be use offline and during the starting up to see what happen ? I do not have anny problem when it is power. I tried to stop the CPU when I am online but I do not have the issue again. It is because the problem comes from the CM1231 at the starting up I think.

I could patch it with the library I think but I always need to understand...

Charles-Benoît

I've never used the trace before, now it's done. I have learned indectlly something new, good!

Does the Trace could be use offline and during the starting up to see what happen ? I do not have anny problem when it is power. I tried to stop the CPU when I am online but I do not have the issue again. It is because the problem comes from the CM1231 at the starting up I think.

I could patch it with the library I think but I always need to understand...

@Charles:

No, traces does not work offline. But you can store online traces to a file for offline analysis.

You could code a data recorder that gives you some idea on what is going on. The easiest is to have a big array inside a datablock. Then add values in the array for a time period.

The other idea is to use a data log. The instruction blocks provide a way to record data onto internal or external memory. Using external memory is the most optimal solution.

Charles-Benoît 

It is because the problem comes from the CM1231 at the starting up I think.

 This may be the piece that can lead to your answer. How does the code handle startup?

To do averaging you need to have some history. At startup there is no history available ..or is it using old history of happenings before the last shutdown?

Consider pausing the actions because of the measured value until the system is fully started. In the example below, Warm-up is used to ignore measurements for a short while. It is also helpful idea to delay the communications until the process is stable.

First-Scan-Bit    Timer      Warm-up
----|   |---------[TOF]--------( )

qwazee

 

Charles-Benoît

I've never used the trace before, now it's done. I have learned indectlly something new, good!

Does the Trace could be use offline and during the starting up to see what happen ? I do not have anny problem when it is power. I tried to stop the CPU when I am online but I do not have the issue again. It is because the problem comes from the CM1231 at the starting up I think.

I could patch it with the library I think but I always need to understand...

@Charles:

No, traces does not work offline. But you can store online traces to a file for offline analysis.

You could code a data recorder that gives you some idea on what is going on. The easiest is to have a big array inside a datablock. Then add values in the array for a time period.

The other idea is to use a data log. The instruction blocks provide a way to record data onto internal or external memory. Using external memory is the most optimal solution.

 

Charles-Benoît 

It is because the problem comes from the CM1231 at the starting up I think.

 This may be the piece that can lead to your answer. How does the code handle startup?

To do averaging you need to have some history. At startup there is no history available ..or is it using old history of happenings before the last shutdown?

Consider pausing the actions because of the measured value until the system is fully started. In the example below, Warm-up is used to ignore measurements for a short while. It is also helpful idea to delay the communications until the process is stable.

First-Scan-Bit    Timer      Warm-up
----|   |---------[TOF]--------( )

 

Ok for the traces, but I do think I will use this later, it's a very good tool.

The datalogger looks interesting too, but with the Covid19 I work at home and do not have any Siemens SD card with me... Also I will keep it in my mind.

Finally, your last idea put me on the track of the solution. I also had explainations from my local Siemens dealer that confirm it !

So I used the First-Scan bit to block at the beginning the firsts cycles of smoothings for some milliseconds. I succed to find a time where I did not have my problem. After comparisation with the time table of the module I am not so far of this result. I think the difference its realtive to the time beginning of the FirstScan bit and the time of begenning of the SM1231

It was a matter of time between the speed of the fisrt reading of the SM1231 and the establishment of the current in the sensor loop. When the SM1231 begin to read the values the amount of current in the loop is not enougth in the sensor loop and the SM1231, sees that as a value of wire break...

Larger the number of cycle of smoothing I use, longer I will have to block the pressure reading to have good values and no more false values 

Thanks everyone