You got it, a Rant, and engineering meeting.
Terry Woods said:
Peter said...
It is the sender’s responsibility to send the data correctly according to the standard. It is the receiver’s responsibility to correctly interpret data send according to the standard.
The sender should not violate the specifications so that it can be 'understood' because then there are two non-conforming devices.
So... let's say you have a "generic" HMI connected to an AB.
And another "generic" HMI, of the same type, connected to an S-7.
Will only one of those "generic" HMI's work?
No... each caters to its particular receiver. That's why many "generic" HMI's come with PLC-specific drivers.
Of course, I know you are referring to a connection through a "network". But, if that network is being used to communicate between two dis-similar systems... then somebody has to "cater".
Does the network do the "catering"?
NO! SST makes bridges that do that. Bridges effectively divide the network in two, or more properly, 'bridge' between two networks.
PLC-A..........NETWORK...........PLC-B
..A....>> Translate A to B >>......B
..A....<< Translate B to A <<......B
If the network expects information according to the "standard", doesn't that leave someone out?
If there is a network like Profibus DP then everyone should 'cater' to the network. Non conforming devices should not advertise as being conforming and should not be used.
Or, is it the case that, one, or the other, or both, PLC's might have a network-driver? In that case, the PLC's are converting their information so that it can be understood by the receiver - in this case, the network.
Yes, the devices must conform to the standards of the network.
Now, change the network to a different kind. Now what happens?
The device need hardware and software that conforms with the new network.
I don't know if I can talk to an AB over TIWAY. If I could, wouldn't the AB have to have a TIWAY-driver? TIWAY knows the TI way. It doesn't know AB-Way.
That is right. An AB device must conform to the network. In this case TI-WAY.
Think of it in terms of someone doing translating at the U.N.
If the "standard" language at the U.N. was Esperanto, then wouldn't the senders and receivers have to "cater"? That is, the sender converts to "Esperanto" and the receiver converts from "Esperanto".
Yes, if Esperanto is the standard.
In this case, it seems there is a third way of expressing data. And both ends of the process "cater" to make themselves understood.
Yes.
Some of the older users might remember my thread "What don't you know". This communication stuff was one of mine.
You would learn quickly if you designed and sold products that work on a field bus and answered techsupport questions.
BEGIN RANT
What I hate are times when my product is the only one that does not work on a 'Profibus DP' network. This isn't because we are wrong. It is because all the other devices the user has are wrong and our product is the only one that is right. Many of the X86/little endian HMIs, PCs etc did not bother to send the data over the Profibus DP correctly. I have had some heated conversions with Horner Electric and CTC. They have accused my product of being the problem when our product is the only one that has been Profibus DP certified on the whole bus. I have been asked to send the low byte first over the Profibus to make it compatible with X86 products and I have refused.
Actually, our product is X86 based ( little endian - Intel Format ) we must swap all words before we send them and swap all words we receive. We do this to be Profibus DP compatible. Our product is Profibus DP certified. It cost money to be certified, but some how the customers alway think it is the little company ( us ) that screwed up and the bigger company could never screw up. I wonder why I paid money to get certified if I am still going to get the tech support calls. I once got a call from a person from company T who was helping a customer get their and our product to work together. The bytes were not swapped properly. I told the company To person how to fix the problem by swapping the bytes on his X86 system. IT WAS HIS PROBLEM YET HE CALLED ME! I read him the riot act. I did convince company T that the default byte order should be big endian instead of little endian. I could not convince them that they should remove the option to get the byte ordering wrong. This also has happen with other products and companies. I get really ++UPSET when these non- conforming companies accuse our product of being incompatible when our product is certified and theirs is not. I was very nice to Jiri by comparison. I am UPSET with the Profibus Trade Organization because they let anyone claim there are Profibus DP compatible. The customers don't know who really make a compatible product. I just get to sort it all out. If you can't tell by now, this is a religious issue to me.
END RANT
OT, for those in the Portland area.
Engineering metting. Meet other engineers. Before discussion boards we would meet like this.
McMinnemin's 23rd & Thurman
Portland Or,
Tuesday, 10/8/02 5-9pm
