alkaram Posted January 27, 2015 Share Posted January 27, 2015 Hello, I am trying to communicate with a CO2 sensor via a UART serial connection. I've read through the manual on serial connections in DAQFactory but I'm still struggling. The serial communication is all in hexidecimal. I searched online and found a manual explaining the call sequence to request CO2 data (imgur link to hexidecimal code). If I input this command into the monitor, I get a response. I even found out how to write a command to the monitor through a sequence using hexidecimal. However, I can't figure out how to write the response string (containing information about CO2 levels) to a variable in DAQFactory. Here is an imgur link of my code for writing a command to the monitor and my attempt to write the output values. My idea was to write the response output to a string, then convert this hexidecimal output value to a CO2 concentration, and then save this to a test channel or data output file. This is how I have my serial connection configured in case it's relevant. Link to comment Share on other sites More sharing options...
AzeoTech Posted January 27, 2015 Share Posted January 27, 2015 That device is talking Modbus. Ignore the hexadecimal stuff and thoughts of trying to write your own protocol and just use DAQFactory's built in ModbusRTU driver. Like most manufacturers it seems, this company has filled their manual with explanations of the Modbus protocol which are very well documented elsewhere (i.e. modbus.org), and very little time talking about their registers and the formatting of their registers. The only chapter you need to worry about in the manual is chapter 4 "Modbus registers on sensor". The rest is totally extraneous and there to confuse you. Start with the ModbusRTU sample application in the DAQFactory samples folder, or go through the Modbus guided tour. I believe that you want Read Holding U16 on register (channel #) 3. It might be one of the other holding types. As I said, if they had spent more time on the table and less on rehashing the Modbus standard, I would be better capable of telling you exactly what settings you need. (sorry for the griping, but I see this over and over again) Link to comment Share on other sites More sharing options...
SteveMyres Posted January 28, 2015 Share Posted January 28, 2015 I HATE when manufacturers document protocols in their device manual, especially widely understood protocols like Modbus. You can't help but think reading the 30 page explanation that there must be something proprietary about their implementation or else why go on for 30 pages about it, when you could just like to Modbus.org. If they just said "Hey, it's Modbus. If you don't know how to do Modbus, that's a more fundamental problem, you're not ready to try to communicate with this device.", you'd be up and running in half the time. Link to comment Share on other sites More sharing options...
AzeoTech Posted January 28, 2015 Share Posted January 28, 2015 Exactly. Really the only things that need to be documented are the register list and any differences / limitations from the Modbus standard, which this manual does in chapter 4. They could just eliminate all the other chapters and be good Link to comment Share on other sites More sharing options...
alkaram Posted January 28, 2015 Author Share Posted January 28, 2015 I have to admit, I'm new to serial communication and the Modbus standard. I didn't know which DAQFactory Modbus driver I was supposed to use since there so many Modbus options (i.e. Modbus TCP, RTU, RTU Slave) but this is probably due to my unfamiliarity with the protocol. Anyways, I tried the build-in Modbus RTU driver and selected the "Read Holding U16" I/O type for polling. However, I kept getting a timing error. DAQFactory spit out an error regarding the timing and/or offset and then continuously gave a timeout error thereafter. I also tried all other Holding options and the same thing happened. I tried following the ModBusRTU sample but the troubleshooting button just gave me a blank screen. I did notice on this sample that under configuration, EVEN parity was selected. After going back through the CO2 serial communication manual, I noticed that the default parity for the sensor was NONE. I'm sorry, but I don't know whether or not this is an issue or how to fix it. I've been trying to a really long time to get this sensor working through DAQFactory because logging the data through the sensor software is causing huge headaches for me when trying to compile all the data that I have from running experiments. Link to comment Share on other sites More sharing options...
AzeoTech Posted January 28, 2015 Share Posted January 28, 2015 The timeout error means the sensor wasn't responding. The manual states that the sensor should be 9600 8-n-1. This probably isn't the default in the sample, so you'll have to change it to match. You'll also need to figure out what the ID of the sensor is. I'd start by trying 1. It won't be 0, and will be between 1 and 247. 254 might work if you only have one sensor, but I'm only guessing based on the manual. If you continue to have problems, email us directly. Link to comment Share on other sites More sharing options...
AzeoTech Posted January 28, 2015 Share Posted January 28, 2015 Oh, and the clarify: in general: ModbusRTU is for serial connections ModbusTCP is for ethernet connections Anything with Slave would be for a Master device connecting to DAQFactory. In general you will never use slave. There are exceptions, specifically when you use a serial to ethernet adapter and do RTU over ethernet. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.