Clay B.
Lifetime Supporting Member
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?Maybe in another device.
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 rid of it.
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?Maybe in another device.
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 rid of it.