Siemens CP343 question

I am using a Siemens CP343 communication module. I am talking to several pieces of equipment with native TCP/IP protocol. My problem is that by doing this, I don't know if there is anything in the buffer. Is there any command to clear out the buffer? Is there a command to see if there is anything in the buffer? The NDR bit does not really mean New Data Ready when you use the CP343 with TCP communication. The NDR bit does not go high until the RECV buffer is full. I need to clear out the buffer of any unwanted data so that I know the reply that I receive is really the response to the request that I just sent out. Can anyone help?

Thanks,
Dave

Hmmm... I wrote my own comm code for a 443-1 using SFC59, and receiving data is pretty straight forward. Which function are you using? And are you calling it unconditionally all the time?

Sorry I did not reply sooner. I was on vacation last Friday.

I am using the AG_SEND and AG_RECV blocks. I am not calling the blocks unconditionally all of the time. I call them when I am expecting information or when I need to send information. The problem is that sometimes the other equipment might have sent a reply when I am performing a reset on my equipment. That puts a "message" in my buffer at that point. The reason that I can't wait for a reply is that I am never sure if my other piece of equipment is turned on or not. For instance, I am working with an EPSON robot. The robot has a long cycle time and/or it wrecks sometimes. In that case, I need to send a reset signal to the robot to clear out the communication.

The other problem is that I don't know when the communication link is established. If I knew when the communcation link was established, that would help greatly. I would then know if the external piece of equipment was ready to receive information.

Unfortunately, the CP343 seems to be very cumbersome to work with. Any help would be greatly appreciated.

Unfortunately, the CP343 seems to be very cumbersome to work with. Any help would be greatly appreciated.

Click to expand...

I wish there was a simple answer, but there isn't. Someday I'm going to write a book about S7 Comunications, and let Siemens give it away to everyone. Maybe it would make up for their confusing and dispersed help files.

I'll add a few comments to your comments:

am using the AG_SEND and AG_RECV blocks. I am not calling the blocks unconditionally all of the time. I call them when I am expecting information or when I need to send information.

Click to expand...

Ok, that may or may not be ok. Typically, I'll just call comm functions unconditionally, but in the cases where I do not, I make sure any open jobs are completed, or I'll reset the job. Keep this in the back of your mind.

The problem is that sometimes the other equipment might have sent a reply when I am performing a reset on my equipment. That puts a "message" in my buffer at that point.

Click to expand...

So what problem does this cause? Can't you just toss out this message? Are the messages time-stamped or is there some index telling you whether you've missed messages or not? If you send a message that you expect a reply to, could you include an ID that had to be returned so you could match it with your query?

The reason that I can't wait for a reply is that I am never sure if my other piece of equipment is turned on or not. For instance, I am working with an EPSON robot. The robot has a long cycle time and/or it wrecks sometimes. In that case, I need to send a reset signal to the robot to clear out the communication.

Click to expand...

Is this reset signal over ethernet? Or do you have some sort of hardware signal? If you do it over ethernet, can you include some sort of heartbeat message, perhaps every 10 seconds? If the hearbeat goes down, you could clear the buffer until the heartbeat is reestablished.

The other problem is that I don't know when the communication link is established. If I knew when the communcation link was established, that would help greatly. I would then know if the external piece of equipment was ready to receive information.

Click to expand...

Well, this is possible, but a little tricky. If you can't use the heartbeat, then you can experiment with the FC62(C_CNTRL) from the CP300 library. I've never used it, but maybe that would do the trick. You can also start screwing around with the SDBs which would give you even more info, but that will be a last resort. Let's see if FC62 works.

Oh, and which CP card are you using (Part# and Revision)?

S7Guy said:

then you can experiment with the FC62(C_CNTRL) from the CP300 library.

Click to expand...

Would this work? I thought it was only for the Profibus CP's, (CP342's) not Ethernet CP's (CP343's) which DaveZ is using.

But if S7Guy says it might work, who am I to argue

Paul

By all means, please argue. Like I said, I never used that function before (I only use the 443-1 cards, so I never looked there), and a quick look at the help file didn't mention that limitation.

So, back to the drawing board. I'll dig around a little later.

S7Guy said:

By all means, please argue.

Click to expand...

Umm, maybe what I said got a little lost in translation, I was thinking that maybe you had a little trick up your sleeve to make this work.

There are two people I listen to when it comes to S7, one of them is you, the other is Hans Berger.

Mr Berger states that:-

SFC62 determines the status of an SFB instance and the associated connection in the local controller. Enter the SFB instance DB in the I_DB parameter...Blah Blah Blah

Click to expand...

That says to me that it is for use with SFB8, 9, 12 and 13.

Paul

Thanks for the confidence Paul. I think we all tend to keep each other on our toes.

I was talking about FC62, not SFC62, but they seem to be similar. Maybe the SFC62 doesn't function at all with the CP300, so Siemens found a work around using the other system functions, and gave them both "62" for a name.

Anyway, if you look at the help for FC62, it specifically mentions that it returns the connection status (i.e. Connection Not Established, Connection Being Established, etc), but I can't see where it limits certain connections. I assumed that any connection from the Connection Table could be entered. Unfortunately, I don't have a 300 PLC to try this.

Yeah, after digging into this deeper, I don't think it will work. I'm not sure where it would be useful yet, but it doesn't look like it will easily tell us much about the connection that DaveZ is using. Dave, ignore everything I said about FC62 for now.

Ah, now that's wierd..

When I expand the library for SIMATIC_NET_CP then CP300, highlight FC62 and press F1, I get the help file for SFC62, which does mention the same as Mr Berger.

Paul

P.S I have just edited this post as I see 'we' have dismissed FC62 as no good for this situation.

I may have to call the blocks unconditionally like you recommended. I am trying to study the AG_SEND and AG_RECV blocks to see how to implement them the best.

As far as the problem with the messages in the buffer, I didn't know if there was a message already in the buffer. I guess that I need to call the blocks unconditionally all the time and then check the done bit or NDR bit before I try to send a command to the equipment. The messages do not have a time-stamp or an index.

The reset signal that I send is over ethernet. I was hoping that there would be an easier solution than writing a new communication protocol between the PLC and my other equipment. If there was a block to check the communication link (like you had mentioned FC62), that would help on one of the problems that I have.

I am using CP343-1 (6GK7 343-1EX11-0XE0) Firmware version 2.0.

You have given me several things to think about, which I think will help. It should at least give me some things to think about as far as some different avenues to pursue. I have been thinking about them yesterday and today. I have several other things that I am working on, so I have not been able to commit 100% of my time to this problem.

Thank you for your time and effort. I may need to ask additional questions as I get deeper into a solution. The other unfortunate part about this problem is that it is on a machine that I am currently 8 hours away from. Any solution that I come up with I cannot try right away. I will be traveling to the equipment next week to try to fix this issue and a few others.

If you have any other suggestions or need any more information, let me know. I will take any information that I can get. Not being an expert on a piece of equipment and trying to use it in an application is a difficult thing. I am never quite sure if I am using the equipment in the correct manner/with the most efficient and cleanest approach.