Profibus data acquisition

Hello guys!

There's a little problem I faced.

I need to get data from a current sensor (ABB IFOCS) through the Profibus interface. I use a Siemens S7 313C PLC and a CP 342-5 communication processor.

This is the program that I have come up with:
OB1


FC 16


FC 3


DB 3




The problem is when i gather the values from ABB - it somehow makes copies of the active value:



What i thought was that the FC84 function fills the table with ONLY one value each OB1 cycle.
When I look at the chart I come to the conclusion that FC 84 is executed 8-16 times each cycle of OB1 and copies THE SAME value from the buffer (FC2).
And when I measure a real current pulse - the PLC skips over the actual current value and as a result I miss the whole process due to its rapidity (32 ms).

These numerically equal numbers seem strange to me. It doesn't make any sense after all.

What do you guys think the problem is?
Can the data acquisition be optimized?
I see 2 stages of data transmission:

1) Acquiring data from slave ABB sensor->PLC->DB30 - 32 bytes (16 words of parameters)

2) Copying one of these 16 words to a DB3 using FC 84. DB30 -> DB3

HOW else do you think this can be achieved?



--
Pavel Maslov, MSc
R&D Institute for Electro-Physical Apparatus
St. Petersburg, Russia

Hi!
I'm not sure if I understand you correctly. But if you want only one input per DP_RECV in the array, you should use the NDR bit (M2.0) to trigger the FC84.

Kalle

KalleOlsen said:

Hi!
I'm not sure if I understand you correctly. But if you want only one input per DP_RECV in the array, you should use the NDR bit (M2.0) to trigger the FC84.

Kalle

Click to expand...

Hey Kalle

I trigger the FC84 with a sync-pulse (15 V, 100 ms), which comes from a Pulse Generator and indicates the high-current pulse initiation (~30 kA).

The NDR bit shows if the data from slave has been accepted. The DP_RECV function works once a OB1 cycle, right? So there's no point using NDR as the trigger.

I wonder is there a command that can switch to the next OB1 cycle and which i can put after the FC 84 block? In order to update the data from the ABB sensor (slave).

Have you tried with an edge-detector (FP) on the trigger signal? If you get several samples per pulse, it looks like the sample pulse lasts several OB1 cycles.

Kalle

Edit: Maybe i got your problem now. Could you please post the FC84 contents?

Edit2: It might be that the sample time of the Profibus and CP is much longer than your OB1 time. Then you'll experience exactly what you see here.

Kalle,

It's not about the pulse that triggers FC84, as i tried to initiate it by a marker bit as well. The point here is that I'm not sure about the timing - how long does does DP_RECV run related to OB1 cycle time?

My sample pulse (actual current that i measure) is here:



black - sync
red - Rogovsky coil
green - ABB analog output


PS I haven't put the ABB digital (Profibus) signal, cos it's rubbish

Edit: Maybe i got your problem now. Could you please post the FC84 contents?

Click to expand...

FC84 is a standard function: Add to Table: FC84

Description

The ATT function adds DATA into the next entry of a table and increments the number of entries by one. The table consists of words. The ATT function allows you to add entries into tables for use by the FIFO and LIFO functions.

· The first entry in the FIFO or LIFO table contains the maximum number of entries of the table (table length).
· The second entry in the table contains the number of entries entered.
· The third entry in the table contains the first word of data.

Note: You must initialize the first two entries when you create the table.

Click to expand...

Did you check the DP cycle time?
What is the OB1 cycle time?

You can move the adress area of the ABB unit to the PI-area f.x. byte 80.
Then the operative system will copy the data from the CP-card cyclically into IW80-upwards. You can watch the value in IW82.

For test purpose you could compare it with a copy value and, when your trigger is high, add up a counter every scan it has changed, and another counter every scan it is equal.

Kalle

Edit: AND what sample frequency do you expect with this config? I have a bad feeling you'll be disappointed.

I don't know how to measure the DP cycle time. Could you come up with an idea?

BUT

According to STEP7 PLC properties-> cycle time the OB1 cycle time is from 1 to 8ms (dominant cycle time is ~1-2ms). I also measured the frequency of adding data to table: I initiated a counter that triggers FC84. The "1" signal lasted 7.5 seconds and the buffer (DB3) which consists 5000 values was completely filled within this time. It means that the frequency is 1 value per 1.5ms. Which seems to be OK.

Answering your question about the expected frequency I would like it to be ~1,5-3 ms. As less as possible, actually. My job is to test the digital (Profibus) ABB output. The ABB IFOCS sensor's rated current is 30kA. The Institute's facilities can provide such a current, but the timing is very little (~40ms at 30kA amplitude) for digital acquisition using low-cost equipment (we have 313C, 315DP, 317DP-2 controllers). Now I'm operating the 313C one.

Here http://www.plctalk.net/qanda/showpost.php?p=423778&postcount=9 I was advised that

A 313C is not suited as a datalogger for anything less than 10 ms datalogging time

Click to expand...

So the question still remains:

CAN I USE a 313C PLC as a tool to acquire data of a process lasting ~40 ms with a sample rate of 2 ms (20 values)?
or CAN I NOT? And try to use a faster PLC. In this case which would you recommend? Are the 315-2 DP or 317-2 PN-DP gonna make it?


BTW Kalle i didn't get this:

For test purpose you could compare it with a copy value and, when your trigger is high, add up a counter every scan it has changed, and another counter every scan it is equal.

Click to expand...

Could you please elaborate on that?

maslick said:

I don't know how to measure the DP cycle time. Could you come up with an idea?

BUT

According to STEP7 PLC properties-> cycle time the OB1 cycle time is from 1 to 8ms (dominant cycle time is ~1-2ms). I also measured the frequency of adding data to table: I initiated a counter that triggers FC84. The "1" signal lasted 7.5 seconds and the buffer (DB3) which consists 5000 values was completely filled within this time. It means that the frequency is 1 value per 1.5ms. Which seems to be OK.

Answering your question about the expected frequency I would like it to be ~1,5-3 ms. As less as possible, actually. My job is to test the digital (Profibus) ABB output. The ABB IFOCS sensor's rated current is 30kA. The Institute's facilities can provide such a current, but the timing is very little (~40ms at 30kA amplitude) for digital acquisition using low-cost equipment (we have 313C, 315DP, 317DP-2 controllers). Now I'm operating the 313C one.

Here http://www.plctalk.net/qanda/showpost.php?p=423778&postcount=9 I was advised that So the question still remains:

CAN I USE a 313C PLC as a tool to acquire data of a process lasting ~40 ms with a sample rate of 2 ms (20 values)?
or CAN I NOT? And try to use a faster PLC. In this case which would you recommend? Are the 315-2 DP or 317-2 PN-DP gonna make it?


BTW Kalle i didn't get this:
Could you please elaborate on that?

Click to expand...

1: Ad the DP cycle time: In the bus parameters tab; what is the Ttr (target rotation time)?

2: How is your DP settings, speed, number of stations, mode?

3: Ad OB1 cycle time; it will increase when you use the monitoring services.

4: Ad other CPU's. I have minimal experience with your combination, we never use the 342.5 card, allways 300s with built-in DP. The data transfer from CP to CPU is likely to add cycle time to the measurement, but I have no clue how much. Since you have 31xDP at hand, I think it would be smart to try that also.

5: Ad the counters, the point was to check how many different and how many equal samples you got during the trigger period.

Kalle

Hey Kalle!

I use the 1.5 Mb/s speed, DP mode, 1 slave, Ttr is 20.9 ms (see the picture for more details):



Perhaps, increase the speed up to 12Mb/s ??
And should I turn on cyclic distribution of the bus parameters?

Increasing the Profibus baudrate to 12Mbps will give a boost, but you will not achieve a TTR at 2 ms or less.
That profibus updates faster than TTR, means that the actual update rate is quite faster (TTRtyp is lower). However the faster update rate is not deterministic.

Another bottleneck is the P-Bus backplane on the S7-300.

Also, the fastest cyclical interrupt on a 313C is 10 ms.

All in all, I think the 2 ms is not realistically possible with the current configuration.

How is this graph from post #1 made ?:

How is it that there is a sample value at exactly every 1 ms ? Is the time scale on the x-axis correct ?
If OB1 scans approximately every 1.5 ms, then I do not understand how sample values are logged exactly every 1 ms.

Anyway..
DP_RECV may take longer than the OB1 cycle to finish. That is why NDR and ERROR bits must be evaluated.
That you have an OB1 cycle time of 1.5 ms, and the sample values remain constant for 7-9 ms (if the graph is correct), and DP_RECV is called cyclically in OB1, tells us that the data from the CP342-5 takes this long to transfer via the P-BUS.
In this I assume that the data from the sensor arrives much faster than TTR due to that the TTRtyp is much lower. You can easily confirm this by trying to set the Profibus baudrate to 12 Mbps. If it does not make any big difference, then the bottleneck is the P-BUS.
It is also possible to evaluate NDR and ERROR via a timer.

Hey Jesper!!

The x-axis scale is arbitrary, exactly! Here I chose 1 ms. The reason is that I write only values (kAmps) into DB (I don't write TIME). The time step is not crucial now, I need only the shape of the curve to match the actual process. Writing TIME, perhaps, will increase the OB1 cycle time.

I'll try to raise the Profibus baudrate up to 12 Mbps later today. Will keep you informed!


P.S. Jesper, answering your question about the graph - I wrote a simple OPC client in Excel using VBA. There I get values from DB3, which stores an array of Current. Time is incremented with a chosen step. I want to add the timestamp though. I wonder, won't it overload the acquisition process?

Forget about adding a timestamp. The problem is where you should get the timestamp value from. I think the CPU clock operates with a 10 ms accuracy anyway.
You could log #OB1_PREV_CYCLE which is the time between OB1 scans. Beware though that this is whole ms only. If you have approximately 1.5 ms, #OB1_PREV_CYCLE will be something like 1-2-1-2-1-1-2-1-2-1-2- etc.

The real solution would be to force the logging at deterministic intervals. A 317 for example would allow you to have cyclic interrupts down to 1 ms. And connecting the profibus to the onboard DP port would remove the P-BUS bottleneck.