Technical Forum

Communication / Networks

Using multiple CP341 modules in one system

Erstellt von romihs am 12.07.2012 18:32 (5 Antworten)

12.07.2012, 18:32

romihs

Beigetreten am: 05.04.2010

Letzter Besuch: 28.04.2013

Beiträge: 14

Bewertung:
Bewertung: keine [0 von 5 / 0 mal bewertet].

(0)

Hello,

I am working on a project that requires multiple CP341 modules that communicate with third party deveices via RS-422, RS-485 and RS-232 interfaces.

My question is with regards to FB7 and FB8.

Is it possible to to call these funtion blocks multiple times in one scan cycle?

The majority of my code is based around a state machine which cycles through most of the third party devices and CP341 modules (different LADDR values) one at a time using a single instance of the FB7 and FB8. This works fine, however it is a bit too slow for accessing some of the devices that require rapid polling.

So what I would like to do is create a seperate driver to access the devices that require rapid polling and thus calling FB7 and FB8 a second time.

Will this work?

Best regards

Sandi

Top

13.07.2012, 10:26

smiffy

Beigetreten am: 17.01.2007

Letzter Besuch: 17.05.2013

Beiträge: 759

Bewertung:
Bewertung: Exzellent [4,33 von 5 / 141 mal bewertet].

(141)

Benutzer mit speziellen Fachkenntnissen, die einzelne Konferenzen betreuen

(0)

Yes it will work.
You can call FB7 and FB8 multiple times provided that they are for different CP cards (i.e. separate LADDR addresses). Here is what the manual says:-

Only one FB P_SND_RK and one FB P_RCV_RK can be called simultaneously in the user program for each CP 341 in use.

Programming today is the race between software engineers building bigger and better idiot proof programs, and the universe producing bigger and better idiots.

So far, the universe is winning...

Top

Für diesen Beitrag bedankt sich:

romihs

13.07.2012, 22:34

romihs

Beigetreten am: 05.04.2010

Letzter Besuch: 28.04.2013

Beiträge: 14

Bewertung:
Bewertung: keine [0 von 5 / 0 mal bewertet].

(0)

Hello,

I have that working now.

But what I am seeing is that the communication speed is still quite poor, it takes about 1 second before data is received from each device. The received packet length is either 1 byte long or 24 bytes long, in either case it still takes about 1 second for the data to be received.

I need to get this down to at least 250ms for proper opperation.

The only thing that I think might be causing the lag is the way I have laid out the program. I am programming it in LAD.

I have the EN signals of both FB7 and FB8 connected directly to the power rail. The state machine then first sets REQ of FB8 and then EN_R of FB7, and then waits until the NDR signal from FB7 is present before progressing to the next state (this is where the delay occurs).

Should I be doing something different here?

Should I perhaps not have the EN signals tied to the power rail and place a switch on the EN signal so that the FB is called when it is required?

Regards

Sandi

Top

14.07.2012, 13:23

jklm

Beigetreten am: 22.12.2006

Letzter Besuch: 18.05.2013

Beiträge: 1295

Bewertung:
Bewertung: Exzellent [4,01 von 5 / 151 mal bewertet].

(151)

(0)

Hello,

Are the CP341 plugged centrally or decentralized over Profibus/Profinet?
Because FB7 and FB8 use internally SFB52 and SFB53.
- In centralized setup (CR, ER) no problem.
- If decentralized, take the resource limitations into account
See http://support.automation.siemens.com/WW/view/en/15364459

I also understood from your explanations that your application first sends a kind of request to the partner, and that you get an answer back. How fast does the partner react? Is that documented. May be a large part of the delay comes from the interpretation of the request in the partner?

You could try to evaluate that using a PC + textterminal software (hyperterminal from Windows), sending the request to the partner and measuring how fast the system reacts (with a scope?)

Best regards
jklm

Suggestion was helpful? Thanks to rate it.

Top

Für diesen Beitrag bedankt sich:

romihs

14.07.2012, 20:18

romihs

Beigetreten am: 05.04.2010

Letzter Besuch: 28.04.2013

Beiträge: 14

Bewertung:
Bewertung: keine [0 von 5 / 0 mal bewertet].

(0)

Thanks for the information.

I have 11 CP341's in the system, 2 are local and the remaining 9 are at various outstations (7 locations). I am using IM153-4PN modules to interface each outstation with my PLC (CPU 317-2 PN/DP)

If I am understanding you correctly, I should not be exceeding the number of active jobs I have available to me (8 reads and 8 writes) because I am accessing 9 out of the 11 CP341's via a state machine that calls only one instance of FB7 and FB8 (the state machine finishes each transaction off before progressing to the next slave device)

I have checked the documentation of the device (with which I need faster communications) and it states that the replied packed should always be sent within no later than 10ms after the device is polled.

I dont have an oscilloscope, but I can tell that the received packet arrives very shortly after the transmitted packet is sent as I see both the Tx and Rx LED's light up at the same time on the CP341.

Also, I have an application that is used to test the devices (the slave device in question) and there I can also see that the received packet arrives right after the transmitted packet was sent, there is no noticeable delay between Tx and Rx.

The only thing that I can think of right now is that currently I have the IO cycle Update time set to 512ms on each of the IM153-4PN modules. I had done this when I was debugging another problem I had during the early stages of this project.

I will change these settings back to default a little later, when it will be safe to stop the PLC, and I will let you know if this setting is causing the issue.

Thanks for the help.

Regard

Sandi

Top

14.07.2012, 22:01

romihs

Beigetreten am: 05.04.2010

Letzter Besuch: 28.04.2013

Beiträge: 14

Bewertung:
Bewertung: keine [0 von 5 / 0 mal bewertet].

(0)

Hello,

Just made the changes to the IO cycle update times and have gotten the performance of the communications up from about 4 seconds for 4 accesses to ~1.2 seconds!

Much better!

Thanks again for the pointer.

Regards

Sandi

Top

Aktionen

Link kopieren

Zur Konferenz