CP341 Serial Communication on S7

[userxyz]

hey

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?

Uncheck prevent overwriting done and buffer message to 1, zero is not possible to set. It's not better after this change.



I will give a little explanation of what we are doing with this CP341:
- We are reading a realtime length measurement of a carpet production line. Setting the length to zero is with a key on a multipanel. So then we use the send block once to reset. We want to receive as realtime as possible for the length, no waits..

 

[userxyz]

hey

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).

Enable is allways high in my program, and pulse is once when operator hits a key... calling cyclically ??

The strange thing is, when we add other code, and the cycle time is not 3ms but around 30ms, then we actually see that the RXD led reads with long breaks...

 

[s7xp.com]

Normally ascii comms is like human talking:
I ask something, someone else answers.
The CP card ask for data, machine transmits data.

Some ascii comms use broadcasting. You setup some data to broadcast and the machine sends the data periodically as a broadcast.
In this case the CP card is only receiving.

Please explain which type of comms you are using.

Youre explaination is not very clear to me:
- We are reading a realtime length measurement of a carpet production line. Setting the length to zero is with a key on a multipanel. So then we use the send block once to reset. We want to receive as realtime as possible for the length, no waits..
??
Please be some more specific. Readint the carpet machine is clear. But the zero and the reset not.

 

[userxyz]

Buffer

Normally ascii comms is like human talking:
I ask something, someone else answers.
The CP card ask for data, machine transmits data.

Some ascii comms use broadcasting. You setup some data to broadcast and the machine sends the data periodically as a broadcast.
In this case the CP card is only receiving.

Please explain which type of comms you are using.

Youre explaination is not very clear to me:
- We are reading a realtime length measurement of a carpet production line. Setting the length to zero is with a key on a multipanel. So then we use the send block once to reset. We want to receive as realtime as possible for the length, no waits..
??
Please be some more specific. Readint the carpet machine is clear. But the zero and the reset not.

It's a length meter, connected to S7 via CP341. So it measures the length of the produced carpet. When an operator hits a resetbutton, the length meter must restart from zero... That's the COID command that you can see in the code with a cariage return and a line feed behind this. The length coming in the PLC must be as fast as the measurement ons the display of the Meter.


What have we learned a few minuts ago:

When we call our FC130 (length Measurement with CP communication blocks) 4 times or more in 1 cycle, then it works very good, less and it becomes very slow. So we tried to put this in OB35, but OB 35 in with a cycletime of 5ms makes the cpu cycle very high, so that isn't good.

It's like we need to read several times / cycle to read all the buffered data. When the cycle time is little, then we don't have that probleme because it can read-out fast enough...

So, in addition to this info, any suggestions ?

 

[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

Good to see you found the same results.

 

[userxyz]

...

Hey, I must say that S7xp.com his think does work, excuse me. SO no more loops, and it works

Originally Posted by 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?

Good to see you found the same results.

 

[userxyz]

...

Euhm,

prevent overwriting and buffer to 1 gives good results...

I must say that the OP277 also gets slower when using to many 100ms tags... this also gives a bad image on the situation I think.

I think it works fine now, if it doesn't, I know that I must use a loop then, maybe calculated from the known cycle time...

 

[RMA]

I must say that the OP277 also gets slower when using to many 100ms tags...

It's not just the OP277 that gets slower, your data transmission to the PLC will also suffer. If you're doing logging on the OP you should also be aware that if you have too much data flying around you can lose log entries without there being any warning that this is happening.

On a recent project I had where I needed to log about 1600 tags (on change of state, basic panel rate 1 sec) at certain points in the process where a lot of things were happening at once, any signals which pulsed for less than two seconds were missing in the log.