Modbus Communication

[Patrick_M_R]

Hi,
I am attempting to establish communication with an infrared temperature sensor over a serial line (RS232 to USB). The sensor is by Omega and it is part of their OS-PC Series, the manual (w/ register addresses) can be found here: OS-PC Series Manual
My LabVIEW 2016 program uses the NI Modbus Library and follows their slave example closely. However, when attempting to read the measured temperature I always receive 0. I know this should not be the case, as I have used other software to verify the communication with the sensor and that it outputs none zero data. Other functionality like turning on the LED does not work through my VI either. I have attached my VI and provided a snapshot of the turn on/off LED case. Since the LED address is 0x0125, I have the address of 292 to compensate for the 0-index vs the 1-indexing (hopefully this is correct).

Hopefully there is some obvious issue here that I am missing and that someone can point out!

Thanks in advance,

Patrick

[Patrick_M_R]

I have opened several of the Modbus VIs (write single holding register, read holding registers, etc.) and it seems as I am running my program, none of the VI inputs are updating (address, # of inputs, register to write). This is likely the source of my headaches, does anyone have an idea as to why this might be happening?

What should be writing into the subVI (left), what the values in the subVI are currently (right).

Thanks again,

Patrick

[Hooovahh]

---

@Patrick_M_R wrote:

I have opened several of the Modbus VIs (write single holding register, read holding registers, etc.) and it seems as I am running my program, none of the VI inputs are updating (address, # of inputs, register to write). This is likely the source of my headaches, does anyone have an idea as to why this might be happening?

---

The VIs are reentrant.  They will spin up copies as needed, and so showing the front panel won't be able to show you the values that went into the VI.  The best option is just to probe the wires going into and out of the VI.  When the VI isn't running (or reserved to be running) you can probably add a break point in the VI, if debugging is enabled on the VI and then you can see the values for each call to the VI.

[Patrick_M_R]

Hmm yeah, I recently attempted the probing and everything is working as expected (it returns an array of 4), the issue is that the array is all zeros when it should not be. The only possible causes for my difficulties that I can think of are either: my addresses are wrong, or something to do with initialization of the slave communication.

[Kyle97330]

Your lower loop error handling is likely hiding errors.  Right now errors are wired to a shift register, which on the next loop around immediately clears the error.  So even though you have an error out terminal showing, it probably only ever has an error in it for a microsecond before it updates to show a cleared error.  And as already mentioned you're not seeing errors on the VI front panel itself because of the reentrancy.

You need to add some other form of error handling whether it's an error popup like "Simple error handler", or adding it to an error log somewhere if you don't want your program flow to halt, so that you can actually get an error return which might tell you what's wrong.  

If I had to take a guess at what's wrong it might be the address.  Sometimes MODBUS addresses are listed in hex so if you put that in as a decimal it fails.  Other times there's an offset you have to add that's not obvious from the equipment manual.  But until you get a legitimate error back it's impossible to know.

[Patrick_M_R]

Yes I noticed the issue with my error handling just a bit ago, I have fixed it since. However, no errors are occurring.

As for the address; the manual lists the addresses in hex, why would it fail once converted to decimal? How else should I be writing the address if not in decimal? Is there a way to input hex values into the modbus VIs?

[Kyle97330]

On the input to the address field, when you create the constant, right-click it and under the "Visible items" menu choose Radix and enable it.  You'll see a tiny letter d for decimal show up, and you can click it to choose hex from a menu which will change the d to an x and you can now put the address in as hex directly (and this will verify your existing conversions too, if you switch the radix on the ones you already made).

[Patrick_M_R]

Ah that is a helpful pointer and makes life a lot easier. Unfortunately, I am still encountering the same issue (reads and writes aren't giving the expected result).

[Kyle97330]

---

@Patrick_M_R wrote:

 Since the LED address is 0x0125, I have the address of 292 to compensate for the 0-index vs the 1-indexing (hopefully this is correct).

---

Have you tried it without this compensation?  I don't think this is a case where indexing matters, this is addressing.  I think you need to send 0x100 instead of 0xFF.

Also, it's a bit weird that you're using the Decimate function to split a 4-length array into 4 1-length arrays, unless you have a good reason for not just using an Index array node resized to 4 outputs, but it's likely not the cause of the problem.

What did you change error handling to do instead?

[Patrick_M_R]

Here is an image of the updated error handling:

Also, when I have "highlight execution" active, I can see that there are no errors.
Yes I agree the decimated array is an odd way to do it, but irrelevant with regard to my issue. I have tried with both addresses and the response is the same, but I do believe indexing does matter.

I have even went as far to read every possible register (1-65535) and it still returns an array of all zeros as the response.

Do you know of an easy way to display what the Modbus VIs are actually writing to my device? I would like to compare it to my other software I have used to communicate with the sensor.

Thanks,

Patrick