Skip to Content

SiePortal

The integrated platform for your product selection, buying and support workflow - bringing together Industry Mall and Online Support.

SiePortalDeutsch

Search

Home
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menu temporary not available
- Menue temporary not available
- {{item.title}}

Products & Services
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
MySiePortal MySiePortal
{{(apiData.MySiePortal | filter:{'rank':1}:true)[0].title}} MySiePortal
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Cart ({{apiData.CartCount}})

Navigation

Using multiple CP341 modules in one system

Created by: romihs at: 7/12/2012 6:32 PM (5 Replies)

Rating (0)

Thanks 2

6 Entries

7/12/2012 6:32 PM	Rate (0)
romihs Posts: 14 Rating: (4)	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
romihs Posts: 14 Rating: (4)
Suggestion To thank Quote Answer

7/13/2012 10:26 AM	Rate (0)
smiffy Platinum Expert Joined: 1/17/2007 Last visit: 3/10/2025 Posts: 1557 Rating: (540)	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 FBP_SND_RK and one FBP_RCV_RK can be called simultaneously in the user program for each CP341 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...
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users romihs

7/13/2012 10:34 PM	Rate (0)
romihs Posts: 14 Rating: (4)	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
romihs Posts: 14 Rating: (4)
Suggestion To thank Quote Answer

7/14/2012 1:23 PM	Rate (0)
jklm Platinum Member Joined: 12/22/2006 Last visit: 1/25/2022 Posts: 1742 Rating: (309)	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 explanationsthat 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 thatusing 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? Feel free to rate it.
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users romihs

7/14/2012 8:18 PM	Rate (0)
romihs Posts: 14 Rating: (4)	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
romihs Posts: 14 Rating: (4)
Suggestion To thank Quote Answer

7/14/2012 10:01 PM	Rate (0)
romihs Posts: 14 Rating: (4)	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
romihs Posts: 14 Rating: (4)
Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on