LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Decode a serial protocol

Hello:

 

We have an application in which we have to monitor in LabVIEW some load cells that transmit the weight readings via a RS-422 protocol. There's no information available about the protocol, this is propietary information of the manufacturer of the load cells, and the intention of the project is to replace the current control system. We don't know the baud rate or any other details, we just know it's RS-422, and that is somewhat related with something called "Oberon".


We have a sniffer connected to the RS-422 bus and have been able to collect some information. Now we're analyzing this data. Right now, we have been unable to find a logic sequence in this data. We also tried to find the weight values shown in the current system in the data, coded in some way, with no result.


I wonder if someone has ever been involved in a similar project, that can offer me some guidance on how to attack this problem.


Any idea is welcome.


Best Regards.
 

Robst.



Robst - CLD

Using LabVIEW since version 7.0


Message 1 of 35
(6,699 Views)

My first guess would be that you don't read the correct data...  I have seen 'coded' noise when I haven't set the right speed, start-, stop-,databits  (and yes even 9 databits are possible and not supported by all serial hardware)

 

There is normally no need to encrypt loadcell data (like in security/entrance systems)  , sometimes there are fancy protocolls to enshure correct data transver (more than a CRC at the end).

 

My crystal ball guess: It will be a modbus protocoll....

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


Message 2 of 35
(6,680 Views)

Hello Henrik:

 

Thanks for replying. Yes, we may be working with "noisy" information, because of the wrong communication settings. The problem is we don't know which are the right settings...that makes it even harder. And I'll analize the data to see if I can find a Modbus Protocol. Thanks for the suggestions.

 

Do you know if there's any way to determine the communication settings?

 

Thanks in advance.

 

Robst.



Robst - CLD

Using LabVIEW since version 7.0


0 Kudos
Message 3 of 35
(6,646 Views)

The best way to determine the communication settings is to read the manual.  But you said the manufacturer is making all this secret and proprietary?  That is a good excuse to scrap their products and use something else.

 

What instrument did the manufacturer intend for their load cells to communication with?  Who's equipment is this?  Any links to their website?

Message 4 of 35
(6,621 Views)

Thanks for replying Ravens Fan.

 

Yes, the manufacturer is making all this secret and propietary. We have suggested the customer the idea to replace the load cells with analogic load cells or with digital load cells with a known protocol, but they say it would be too much money. The original objective of the project was to replace the control system and keep the current cells, but so far we haven't been able to find information about the protocol or to decode it.

 

The current control system runs in a Touch Panel PC with Windows on it. This is the master that communicates with the cells and controls other equipment.

 

This is an URL to the most recent Load Cell the manufacturer makes:

 

http://www.colortronic.co.uk/products/dosing/csl.asp

 

Also I've attached the datasheet of this cell. In the datasheet, it says RS-485 but in some drawings we have seen RS-422. It's a 4 wire bus (Tx+,Tx, Rx+, Rx-) plus GND. Also in the datasheet, in the Interface section they say "Detailed information on request", which has proven to be totally false.

 

Any Ideas?

 

Thanks in advance.

 

Robst.



Robst - CLD

Using LabVIEW since version 7.0


0 Kudos
Message 5 of 35
(6,611 Views)

Is there any accompanying manuals that discuss the addressing scheme for the Load cells?  It appears that you have access to the application.  Is it a self contained EXE or does it use DLLs?  You maybe able to make use of function calls in the EXE and/or DLLs.  If possible, you maybe able to just utilize their function calls to access the load cell data for incorporation into your new custom app. Did Colortronic also write the application that you are replacing? What is the EULA for the application? You may find wording in their that may compell them to turn over that data.

Just a thought!

Message Edited by PJS on 04-13-2010 09:24 PM

Paul
Message 6 of 35
(6,605 Views)

Hi Robst,

 

Im sure that you have thought about this but thought it might be worth mentioning anyway. Have you tried all your scanning for baud rates etc... with the 422 pairs reversed? It may be the case that you have the Rx+/Rx- reversed. This would give you garbage data. As i said, im sure that you have tried this but thought it worth mentioning in case its been overlooked.

 

Rgs,

 

Lucither

------------------------------------------------------------------------------------------------------
"Everything should be made as simple as possible but no simpler"
Message 7 of 35
(6,600 Views)

Hi Robst,

 

If you know the addresses of the load cells then you can use this information to hone in on the right baud rate. If the protocol is modbus it will either be sending Ascii or RTU. RTU format is 1 start bit, 8 data bits (LSB first), 1 parity and 1 stop bit, 11 bits in total. Ascii is 1 start bit, 7 data bits (LSB First), 1 parity bit and 1 stop bit, 10 bits in total.

 

 

 

 RTU B.jpg

 

Ascii B.jpg

 

As you can see, with RTU the first sent byte will be the address value. In Ascii it will be the 2nd and 3rd charectors. Also, with Ascii the Start char is the colon (:) and the end chars are carraige return and line feed. I would imagine that it may be easier to hone in on the correct parameters listening to the computer tx side. This will be because it will most probably only be sending request data, with only the address section changing. The rx side will be the load cells responding to this data but sending different load information. Hopefully listening to the tx side you may see the same bit of data being transmitted with only 1 byte (for RTU) or 2 bytes (For Ascii) changing.

 

Even if the protocol is not modbus, the protocol will almost definately start of with sending the address information at the beginning of each transfer. I would try and isolate this to find the baud rate.

 

What software are you using to view the data? ideally you will want the software to be able to show your data not only in ascii but raw values also.

 

Rgs,

 

Lucither

------------------------------------------------------------------------------------------------------
"Everything should be made as simple as possible but no simpler"
Message 8 of 35
(6,592 Views)

Does "analogic" mean analog?

 

I find it difficult to believe replacing the load cells would be too much money.  It seems the most expensive part of what they have now would be whatever controller these load cells are connected to now.  You could easily spend more in time than the cost of load cells in trying to decode the communication protocol.

 

I would think either the controller manual or the load cell manual would tell you what the baud rate is or how to determine its setting.  It says it can handle 2400 to 38,400 baud.  So it must tell you some way to be able to change it.

 

Try connecting and O-scilloscope to the lines.  Try to capture a signal in the middle of the communication and use the O-scope to determine the time a bit pulse is high or low.  With that and some math, you should be able to determine what the baud rate is.

 

Once you have the baud rate, you can tap into an RS-485 line, convert it to RS-232 and snoop on it with your PC.  Then you can experiment with the number of data bits, then determine if parity is being used.  When you have the right settings, your sniffer (try portmon on the PC to watch the PC's serial port) should show you the hex data that is being passed.  Then you can look for patterns, see if there are any termination characters, and command/response pattern, to help figure out how it is communicating.

Message 9 of 35
(6,588 Views)

Thanks to all for answering.

 

I can access the application upon request and when the line is not producing. It's an executable that runs in the startup of the Touch Panel Computer. The application is also developed by Colortronic. The whole system is branded Colortronic, despite many components were just rebranded. As far as I know the communication is embedded in the software. And, I haven't read the EULA yet, I don't know if it's available in the computer. I'll check it out to see what can I find. Thanks for the suggestion.

 

And, we're pretty sure we have made the right connections in the Rx+/Rx- and Tx+/Tx- terminals, but we'll check it again. At this moment all the suggestions are welcome, and we may have been so busy trying to decode the data that we may have overlooked something.

 

The addresses of the load cells are just 1,2,3,4 and 5, or that's what the software shows. We'll use Lucither's suggestions to analize the data looking for the addresses at the very beginning of the data packages, whatever the procotol is, Modbus based or not.

 

We're using a serial protocol analyzer called Serialtest, coupled with a USB RS-422/485 Sniffer. This is the link to the page of the sniffer in case someone else is interested: http://www.fte.com/products/SerialAnalyzers-RS422485.aspx

 

I agree that it may be more costly to invest time and resources in trying to decode the protocol rather than replacing the cells, but unfortunately that is not our decision, it's the customer's, but we'll talk to them again about that.

 

I've searched through all the Colortronic software and haven't found an option where to configure the communication settings, maybe all the devices work with factory settings. But, as Ravens Fan says, it should be a way to set or determine the settings. I just wonder where it is...

 

We're going to do the oscilloscope analysis suggested, to determine the communication settings. Once we have determined the communication settings, we will capture new data, and analyze it, being certain that the data is correct.

 

And by the way, yes, "analogic" was supposed to be "analog" Sorry about that Smiley Tongue

 

Thanks again to all for your time and advice. I'll let you know what are the results of the analysis using the O-scope.

 

Best regards.

 

Robst.

 

 

 

 

 



Robst - CLD

Using LabVIEW since version 7.0


Message 10 of 35
(6,547 Views)