Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Can I add another Function Code to the MB ( Modbus ) query VI's?

I am trying to read register addresses via Modbus RTU over TCP (at least I THINK that's the proper description) from a Honeywell UDC3200 temperature controller. Where I am running into issues with the LabVIEW MB VI's downloaded from NI is that certain register locations (what I would call the configuration settings) can only be read and written with Function Code 20 and 21 respectively, though the LabVIEW VI's don't have these Function Codes as options in the drop down menu in the originating cluster or Bundle/Unbundle by Name properties. Additionally, I cannot figure out how to unlock them for editing to add these two Function Codes that I need to communicate with those specific registers. Even the security section where normally a password could be entered is grayed out so I don't know if this is some super-serious-secret-squirrel kind of stuff or if I'm just missing something. Any help figuring out how to communicate with this controller would be greatly appreciated. Best Regards, LLF264 LabVIEW 2010
0 Kudos
Message 1 of 7
(4,473 Views)

Can you post a link to the code you're talking about?  

National Instruments
FlexRIO & R-Series Product Support Engineer
0 Kudos
Message 2 of 7
(4,444 Views)

Thanks for the help !!

For clarification, I believe the flavor of Modbus that we are using is Modbus TCP.  I've attached a screen shot of the VI, which is one layer deeper than I think we need to start, but it is a cleaner VI and the concept should be the same no matter which layer we are at within the NI Modbud lib of VI's. 

 

The same function codes are in the originating cluster as well as bundle by name, but none of them have an entry for function codes 20 or 21.  We have tried adding them in different methods but have been so far unseccesfull.  As shown in the picture, "Write General Register function code 21" has been added manually, but it certainly is not correct as the VI calling this VI does not give us a way to call that function code.  We can't set these "properties" (if that's the correct term) globally to all function codes referenced in other VI's.

 

The .jpg with the red circle is the top layer VI that needs to be able to call the function code(s) that we need to add.

I think that we can solve our base problem if we can add function codes to that VI's.

 

We can add them to the VI in the screenshot "we need to add function codes here", but they don't show up in any other VI's that reference or use that VI.  Other VI's don't allow us to even add those. 

 

0 Kudos
Message 3 of 7
(4,440 Views)

When you're making these modifications are you editing the type def?  

 

Right click on the cluster and select "Open Type Def", Then make your modifications in there.  Once you're done, it should ask you if you want to update the type def, select yes.  

Now all of the controls that reference that type def should be updated. 

More reading can be found here: 

http://digital.ni.com/public.nsf/websearch/1B04FD6A11E6F17286256C6300588BFA?OpenDocument

National Instruments
FlexRIO & R-Series Product Support Engineer
0 Kudos
Message 4 of 7
(4,415 Views)

We tried editing at the type definition level and still get the same result.  It doesn't stick.

 

We've made more progress on the over VI, but are coming back to this sticking point.

 

We need those two function codes added to the VI, or we need to be able to go in and add them ourselves to be able to communicate with the extended addresses that the modern MODBUS protocol allows.

0 Kudos
Message 5 of 7
(4,327 Views)

After you make your changes in the type def, try changing the type def in your VI from a constant to a control, then change it back to a constant.  

 

 

Then you'll have to add your VI to the polymorphic VI.  You can do this by right clicking on the main VI and selecting "Open Polymorphic VI"

 

Dave T.

National Instruments
FlexRIO & R-Series Product Support Engineer
0 Kudos
Message 6 of 7
(4,287 Views)

Issue solved.. we were having fits getting things to "stick" because we were sometimes trying to edit clones and sometimes the original... the key is to make sure that you are editing the original and not clones that spawn themselves when opening a sub-VI.

 

For the next layar of problems with ModbusTCP/Honeywell communications, I'll start another post.

0 Kudos
Message 7 of 7
(4,185 Views)