Rif.: Modbus testing CVI code

[VeryDetermined]

Hi again,

Thank you for your help.

I did understand those functions and now I am able to read from my device but still cannot read which I am figuring it out to find the reason.

In the meantime I have another question that you can help me to overcome this headache which I finally decided to ask after a couple of days.

The problem is that I am reading 2 input registers from the device (for temperature) (using function code 0x04) which is in float type. It means that I have to convert the word to float.

The answer is like this (hex): 01 04 02 43 95 22 F2 crc crc. The bold numbers (data) represent the temperature which is 298.273

I tried to understand the concept behind word to float conversion but still I am confused and I don’t know how it works.

Then I decided to use function conv_dword_to_float (unsigned char * buf, float dvd) or conv_word_to_float (unsigned char * buf, float dvd) from ModbusFramework.c to convert the data ( 43 95 22 F2) to float. However, I am not sure what dvd (Conversion factor to use) is and what its value should be. 

 Your comments gain appreciated.

[VeryDetermined]

I am still  wondering why I cannot write into the device whrease I can read from it. I checked every thing that I knew and I tested it using a Modbus communication tester (got from internet). So I found that I can write using the tester. Now I am thinking of the code. If there is anything in the code that stop me from writing a simple data likee 21 into the device? Is there any way to make sure that the writing function has no problem with my device?

[RobertoBozzolo]

The conv_xx function for unit conversions are made in the assumption that the client multiplies floating point values by a factor (e.g. 100) and then sends the integer part through Modbus ; the funcitons so calculates the integer and obtain the final floating point value by applying the appropriate divisor (value dvd).

Your client appears to send a hrough fp value that you can read back by using this function:

// Type definition
typedef union {
    unsigned char a[4];
    float val;
} FPmb;


// Conversion of value
FPmb 	xmb;

xmb.a[3] = 0x43;
xmb.a[2] = 0x95;
xmb.a[1] = 0x22;
xmb.a[0] = 0xf2;
DebugPrintf ("Union: %f\n", xmb.val);

With reference to your last question, I can't imagine a reason for not being able to write to the device. I suppose that you can actually issue a query command (which returns the temperature value you shown us) and that you cannot write a value in inner registers of the device. If this is true the reasons can lie in a incorrect station address or register address. Does the client return some error message after the write?

[VeryDetermined]

Hello Roberto,

Sorry for late reply.

Thank you for helping about float conversion code. It now works well enough and I have the right numbers now. 

I have almost done whatever I knew to fix the writing problem. But I had no success. So I am going to share the Modbus manual for the device with you. So you can have a look if you want.

(page 13 section 6.8 of the attached file is explaining holding registers)

I am trying to write 21 (volume flow) to replace the default setting (22=mass flow) for "Measurement Counter 1". Then I am using function code 0x10 (write function in Modbus Test code) and set Memory address on 40001 , # of registers on 1 and data to be 21. And immediately the Error -99 (I/O operation timed out) appears after pushing "write to slave" button. If I try to "write to slave" more and more I may receive CRC error instead.

Besides, as I am reading number of input registers with 0x04 function code, I am receiving Error 99 irregularly. I am not sure why this happens. I tried to set a delay for reading the port but it didn't work well enough. Any idea?

[RobertoBozzolo]

I'm not sure on how to address this problem. Is the timeout received on serial write or read? In the second case, you could try querying the device diagnostics (function code 8, subfunction 0x0f to 0x11 to detect what the problem is. Are you sending 21 dec or 0x21 as the data? It seems to me that the instrument is expecting 21 dec.

[VeryDetermined]

Thanks for spending time on my question.

I am receiving timeout error all the times I try to write into the machine and hence I have never been able to write using the Modbus Test code. Sometimes during query for reading I get this error. I reduced the amount of error by setting 1s delay between each two queries, however still I can see the error some times.

And today I saw something new. I found out that when I move my mouse on the panel I get more runtime errors. I checked the items on the panel (command buttons, rings, text boxes, ...) and they all were set on hot control mode. So this is a new problem to me.

Regarding the writing I am sending dec numbers like 21. And same as you I believ that this should work since we are getting the same number in dec format as a response to enquery. (Just to make sure I checked hex and it didn’t work as well) Furthermore, I was able to write into the machine 21 dec using a Modbus tester software (from internet).

Since the Modbus tester software can write into the machine, I am wondering how I can make sure that the writing function works well. This way I might be able to fine the error source or focus on a specific area rather than being suspicious about everything.

Thanks again.

[RobertoBozzolo]

Just to be sure, do you receive the timeout error on ComWrt or on ComRd?

If your modbus test software can dump the content of the created messages, you can check it with the messages you create in your program and see if there is something different.

Also, you should carefully check all communication settings (baud rate, parity, start/stop bits, slave address)

[VeryDetermined]

I receive time out error all the times for ComWrt and sometimes for ComRd.

As a result of error, I can't see the message details during writing (nothing appears in the message boxes) and hence I cannot compare the message with the message from the tester.

Thanks

[RobertoBozzolo]

Well, I must admit that I have almost never seen a timout on write on the serial port! 

I wonder how you read back some data if you receive a timeout "all the times"...

There are some hints on the online help for ComWrt that may help you to discriminate the cause of error, and most of them deal with handshaking: how is your port configured in the OS? And how do you open / handle it? Have you set -1 as Output Queue Size parameter to skip passing through Windows buffers?

Last question: are you using any sort of converter like USB-to-serial or Ethernet-to-serial?

[VeryDetermined]

Hello,

Sorry for miscommunication. I was thinking of something else.

Actually I can read from the device which means both ComWrt and ComRd work during "QuerySlave".

By all the time I meant all the time when I am trying to write into the salve ("WriteToSlave") and I imagine that it happens for ComRd.

And yes. I am using an NI RS485-USB converter (http://sine.ni.com/gallery/app/ui/page?nodeId=12845&mTitle=NI%20USB-485&mGallery=set_ni_usb-485)

I did the following setting according to the device manufacturer recommendations:

the Bias Resistors Enabled option was disabled. 2 Wire Auto for Transceiver Mode was selected. A resistor (1 ohm) was added to the endline on DB9 before connecting to USB-485 converter.