Sign in to follow this  
Followers 0
Clay B.

Have You Seen this before/

3 posts in this topic

I posted this over at PLC.Net It is a problem I ran into on my last project and I am curious if anyone else has seen something like this. I was able to create code to work around it, now I just trying to understand it. I just completed a project that thru me a curve ball I have never seen before. I am wondering if anyone else has seen something like this. I connected a Rice Lake 920i to a S7-300 PLC thru Profibus DP. The Rice Lake is a generic slave to the S7-300. The Rice Lake requires 4 words consistent messaging. The message form is first word command in Hex second word is parameter in Hex third and forth word can be either DINT or Real. The 3 word is MSW forth is LSW. Commands and Parameters are predefined for the Rice Lake. Curve ball: If I sent my messages from my S7-300 faster than once every 250 mil seconds the return from the Rice Lake would be garbled. What I mean by garbled is this: I would alternate between sending the message First word hex130, second word hex 64, third and forth 1.0 to 8.0 depending on the recipe value I wanted to load into Setpoint 100. The next message would be First word hex140, second word hex 62, third and forth 0; this would tell me the value in Setpoint 98 I would alternate between these 2 messages every scan. I would read the return on every scan. What I expected to happen was when I sent 140,64,1 I would get back 140,status value of Rice Lake,1 When I sent 130,62,0 I would expect back 130,status value of Rice Lake, value of Setpoint 98 (hex62). What I would ACTUALLY get back would be 140, some unknown value, and either the value I sent or the value of Setpoint 98, the other message back would be 130,some unknown value, and either the value I sent or the value of Setpoint 98. Like I said the messaging was getting garbled. The only time I received consistent and expected responses was when I spaced out my messages by 250ms.I would send my first message, wait 250ms send my second wait 250ms repeat. Well having a .5 second plus delay between my action reactions was not acceptable so I had to create an alternate method. This does not correct the messaging garbling; it just allows me to work around it. Has anybody else seen something similar? Also Note: I know the accuracy of my echoes because I got my local Siemens vendor to bring in a Profibus sniffer and we could see the messaging on Profibus in its native form. And in order of send receive. That’s how we figured out the garbling and how much delay we needed to get ride of it.

Share this post


Link to post
Share on other sites
Hey Clay, I moved this from the general lounge to the Siemens forum, should get better responses here. Ken

Share this post


Link to post
Share on other sites
Thanks Ken, I was not sure of the best place to put it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0