LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problems viewing certain registers in distribution manager

Solved!
Go to solution

I am using the Distributed System Manager to communicate with my Sierra Instruments MFC. For the most part I am able to read in the values of its MODBUS registers. However there are some registers that the DSM doesn't appear to be able to read correctly.

 

In the 1st screenshot I show a working case.

NI-DSM_screenshot1.png

Note the values shown for registers 400043 through 400045 are the decimal value of equivalent 16-bit ASCII encoded characters (as hex), and when combined give the serial number of the MFC. So in my current example:

400043 = 12598 == 0x3136 == "16"

400044 = 13620 == 0x3534 == "54"

400045 = 13624 == 0x3538 == "58"

Serial # = 165458

 

Registers 400047 through 400051 each contain 16-bit ASCII encoded characters that when combined give the Tag ID of the MFC. However when I go to read the 1st of these registers then I get an error, which also screws up reading all the previous registers (I'm not sure why...), as shown below:

NI-DSM_screenshot2.png

 

I know that the info for the Tag ID is there as it shows up in Sierra Instrument's GUI:

SI-GUI_screenshot.png

 

Any ideas?

0 Kudos
Message 1 of 12
(3,286 Views)

Hi Mango17,

 

When does this error occur? Is it only as you read the first value in that range? Can you read from other values in that range?

JD B.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 12
(3,240 Views)

Hi JDragon,

 

What I've figured out is that there is a range of registers 40046 through 40123 (that are all16-bit ASCII encoded values) which for whatever reason are not being read in properly by the DMS (see image below). Below I just show that 40123 causing an error, but I've confirmed it starts at register 40046.

 NI-DSM_screenshot2a.png

 

40046 carries the last 2 digits of the equipment serial number, which in this case are "null", since the serial number is only a 6 character value. Then the other ASCII encoded data which are not being read in are comprised of 8 registers each. Strange enough the very last string carried by registers 40124 to 40131 are read in OK. When the decimal values shown in these registers are converted to hex and then to ASCII it spells "Oxygen" as it should (Oxygen is the last gas ID in the list of gases).

 

What is also strange (to me at least) is that when the DSM tries to read from a problem register then all of the registers before the problem one are also not able to be read in properly even though they were read in just fine before (see image below).

NI-DSM_screenshot2b.png

0 Kudos
Message 3 of 12
(3,227 Views)

Also, I tried to read in the individual bits in any of those registers and that also fails as well. Not sure what to make of it... unless those registers are somehow corrupted or there is no data there at all to begin with (even though there should be according to the equipment manual).

0 Kudos
Message 4 of 12
(3,224 Views)

Looking at the screenshots you've provided, it appears there's a finite range that doesn't work.  If you check for registers outside of that range, everything works as desired.  It's only if you check within this range (40046-40121) that things start to be wonky.

 

This would suggest we have a working communication with the device.  So, we shouldn't need to troubleshoot that.  It also looks like you can verify these registers are valid as the manufacturer's software can read them just fine.  I'm assuming this is the only way that software can get the information you're seeking and there aren't any other places it may be readable by their software. 

 

Once you read one of these bad registers, everything else goes to an unknown state (which isn't fun to say the least).  Are you able to reach one of these registers using LabVIEW instead of the DSM to see if it's problematic everywhere?  I'd expect to see similar behavior.  But, it doesn't hurt to check.

 

Are there any other ranges that provide similar behavior?

0 Kudos
Message 5 of 12
(3,142 Views)
Bo: I also assume that those registers are the only place that this information can be accessed. I'm also in contact with Sierra Instruments about it.

My next plan of action is to use another method in LabVIEW or, as SI is suggesting, another method entirely (e.g. Kepserver) to access the MODBUS registers & see if I have the same problems. I'll post the results of this.
0 Kudos
Message 6 of 12
(3,131 Views)
My current VI interface is using the I/O server method to access the MODBUS registers. I had assumed if the DSM isn't able to access those particular registers then I would have the same problem in LabVIEW using the same I/O server variables.
0 Kudos
Message 7 of 12
(3,127 Views)

That's a fair assumption.  I'd expect to see the I/O Servers behave the same as we'd see in the DSM.  They are built on the shared variable engine, which is what we're seeing in DSM.

 

I'm not really sure what software set you're using.  I'm assuming you have the DSC Module to be working with the I/O Servers as you already are.  It's possible you're using the RT Module if it's a newer version of LabVIEW.  In either of these cases, I'd expect you to have access to the Modbus API.  On the Functions Palette, you'd want to navigate to Data Communication to find the Modbus functions.  You could also look for Modbus Library in the Example Finder.  This example uses the Modbus API.

0 Kudos
Message 8 of 12
(3,088 Views)

We do have the DSC module. We originally purchased LabvIEW 2012 and were since upgraded to 2014 because we had a short-term warranty or something like that. We also have the Modbus API, I just have not gotten around to figuring it out yet. We are just trying to get something up and running as soon as possible, so after some research decided high-level I/O server was the way to go.

 

I do eventually want to figure out what is going on with these particular registers and will use either MODBUS API or external method. However right now I will press on with the I/O server approach since it allows me to access all of the more important registers that I need to control and read flow rate. Being able to tell the MFC what specific gas is passing through it is not a deal breaker. All that does is change the K-factor in the MFC software which adjusts the measured flowrate that the MFC displays, since the MFC is calibrated using air. I can do this conversion inside LabVIEW for now. 

 

 

0 Kudos
Message 9 of 12
(3,081 Views)

When you do get to trying those out, check out the example I mentioned.  It should make understanding the API relatively easy.

 

Is the application working for you without checking those few registers?  Did you hear anything back from the manufacturer?

0 Kudos
Message 10 of 12
(3,051 Views)