CP341 Serial Communication on S7

[userxyz]

I have a problem with a CP341,

When we did tests, the communication worked fine...

But now after mounting in the closet, it's really slow and you can see blinking the RXD led with long interuptions...

The parameters of the module where we connect too are the same

The prtocol parameters in the hardware config of the CP341 are the same

The cable is shorter then in our test application


Any ideas what it can be ?

 

[userxyz]

...

the only thing I'm suspecting is the baudrate of 56000, maybe too high ?

Euhm, the cycle time is 33ms of the cpu, but that shouldn't be the problem I guess ?

 

[Ken M]

In cases like this, it's essential to look for the differences. Any differences. You seem to have already checked out the basic parameters, set-up, sofwtare etc and said they are the same. So the problem can not be from there. You've said the cable is shorter. That is a difference but normally I would expect that to be a good thing. Why do you suspect the Baud rate? Has this been changed from the test? If it has, put it back to the test values and try again.

The most obvious change is environment. Where were you testing it previously and what is different about the installation now? Check everything here - cable routes, terminations, connections etc. Is there a 250kW variable speed drive in the next cabinet that wasn't there when you were testing?

Regards

Ken

 

[userxyz]

...

We tried lower boaudrates, but nothing works...

when we delete everything out of OB1 and leave the Communicationblok for the CP in OB1, then it works good ???

So the other code should be the problem ? or corrupt project ?

i've seen weird things allready in this project

 

[Ken M]

How much code did you test it with? Was there any other code in the PLC at the time, or just the comms blocks?If the PLC wasn't tested with all the code in place, then that represents another difference which now has to be investigated. If it works with only the comms code, start adding the other code back in, block by block (I understand this may not be entirely practical) until it fails again. Then take out the last addition and test that. And so on. There's nothing specific you've mentioned so far which would identify a particular characteristic of the CP341

Regards

Ken

 

[userxyz]

Euhm

I've tested the code with the CP341 Communication blocks and the Ascii to real conversion blocks, without any other code... and it works superb. RXD is blinking all the time.

We we use these blocks in the complete project, we can see that RXD isn't blinking every 3 secs... And the data receiving is very slow, it comes, but we really have to wait 10secs... or something...

Cycle Time with only data reading from CP and coversion from ASCII to REAL is 3 ms, written in STL.

The whole project is from my collegue and is written in LAD mostly, the cycle Time with the 2 together is 33 ms... But this can't be the problem I suppose ? We even tested this in OB35...

It's very weird... it conflicts with something...

 

[userxyz]

Code

http://download.yousendit.com/CBD01FED2EC69DB5

here you can download the code that I wrote for him, for his serial communication, this works, but not when my code is implemented in his project

 

[L D[AR2P#0.0]]

I've come across a similar problem and it is related to your scan time. I was only using FB7 and my solution was to call FB7 ten times (using a loop) every scan of OB1

This was using a 318-2 CPU, so you may need to tune the number for your 315 CPU.

 

[userxyz]

hey

After testing a lot I am now also pretty sure that it's the cycle time...

Is this because the buffer of the CP341 gets full @ a certain moment ?

I've come across a similar problem and it is related to your scan time. I was only using FB7 and my solution was to call FB7 ten times (using a loop) every scan of OB1

This was using a 318-2 CPU, so you may need to tune the number for your 315 CPU.

 

[L D[AR2P#0.0]]

I can only guess so.

 

[s7xp.com]

I have checked the code and it will not work when the cycle time increases.
A few remarks:
1. Receive enable always on.
2. Send request, uses pulse and not always on.
3. You need to program at least 1 program scan, probably more, between the receive done bit (or error, or time out) and send request pulse.

When do you pulse the send request bit:
1. First program scan or start communication
2. After receive done or receive error bit
3. After programmed time out, in case nothing received.

To increase scan time, do not use to much fc and fb calls. Sometimes you use three variables for the same data because of all the fc and fb calls.

Regards,

 

[s7xp.com]

Hardware configuration > CP settings
Uncheck "prevent overwriting" and set "buffer message size" to 0.
ASCII comms: Send -> Receive -> Send. In case "no answer", retry.
No message buffer needed.
May be it is possible to use 3 wire RS232 instead of 5 wire?

 

[S7Guy]

Combo, I don't think this is related to the scan time. The CP341 can process only 30 or 34 bytes at a time (it alternates back and forth), so it could take several scans to send or receive data. I routinely send 500-600 byte messages, and don't have a problem.

As S7XP noted, always leave the enable true when receiving messages, and when sending just pulse the request (but keep calling the S/R FBs cyclically).

 

[userxyz]

Thanks

I will do my best to change my code, shouldn't be much work

Thanks a lot

I have checked the code and it will not work when the cycle time increases.
A few remarks:
1. Receive enable always on.
2. Send request, uses pulse and not always on.
3. You need to program at least 1 program scan, probably more, between the receive done bit (or error, or time out) and send request pulse.

When do you pulse the send request bit:
1. First program scan or start communication
2. After receive done or receive error bit
3. After programmed time out, in case nothing received.

To increase scan time, do not use to much fc and fb calls. Sometimes you use three variables for the same data because of all the fc and fb calls.

Regards,

 

[userxyz]

I need to understand some things...

I need to understand some things...

I have checked the code and it will not work when the cycle time increases.
A few remarks:
1. Receive enable always on.
2. Send request, uses pulse and not always on.
3. You need to program at least 1 program scan, probably more, between the receive done bit (or error, or time out) and send request pulse.

The done bit is high when a telegram is received ? What should I do with it ?? I don't understand what you mean. Do I have to make the enable bit of the receive block only high after a telegram is received ?? I that what You mean ??

When do you pulse the send request bit:
1. First program scan or start communication
2. After receive done or receive error bit
3. After programmed time out, in case nothing received.

To increase scan time, do not use to much fc and fb calls. Sometimes you use three variables for the same data because of all the fc and fb calls.

Regards,

Send request is a reset of the length meter, this bit is high when someone is pressing the button of a panel.


It's not 100% clear to me what you mean.