modbus domain resolution?

[Valarauca]

---

@RavensFan wrote:

If your network isn't set up to resolve a computer name, then LabVIEW or the modbus library isn't going to be any smarter.  The libraries all work based on following the network protocols that are built into the PC.

---

The issue is I'm trying to know if the Labview VI does this by default (or if it is changeable). The 'older' modbus library does by default (it force resolves the domain name) but it can be turned off by modifying it (changing a tcp default true to a false boolean input). I can't do this with the newer since its closed source.

This is just one of the possible explainations to the problem (and having every client modify their hosts file seems a poor way to get a software library to work), I saw this before so it was my suggestion as to why I am getting time out errors. Any other suggestions are welcomed.

[RavensFan]

You'll have to show me a screenshot of the VI that shows this boolean input.

I'm looking at the older modbus TCP library and I dont' see it.  Within the MB ethernet master example.vi, it shows the TCP Open connection.  The control wired into it has the default value of 127.0.0.1, but I know you can enter computer names in there as well as IP addresses.  I don't see any inputs that deal with forcing a name resolution or not.

Yes.  Forcing people to change the hosts file is a poor way to make something work.  But if your network isn't doing name lookups correctly, you are either forced to do that, or forced to address the device by IP address rather than name.  It is a network problem, not a LabVIEW problem.

[Valarauca]

---

@RavensFan wrote:

You'll have to show me a screenshot of the VI that shows this boolean input.

I'm looking at the older modbus TCP library and I dont' see it.  Within the MB ethernet master example.vi, it shows the TCP Open connection.  The control wired into it has the default value of 127.0.0.1, but I know you can enter computer names in there as well as IP addresses.  I don't see any inputs that deal with forcing a name resolution or not.

Yes.  Forcing people to change the hosts file is a poor way to make something work.  But if your network isn't doing name lookups correctly, you are either forced to do that, or forced to address the device by IP address rather than name.  It is a network problem, not a LabVIEW problem.

---

TCP listener within the modbus slave deamon.

I don't know if its possible to force domain name resolution from TCP person who 'pushes' the connection, not the listender.

But the issue still stands that I'm getting time out errors when the other library isn't 😕

[RavensFan]

Okay.  Now I can see what you are talking about.

It appears that in the NI Slave Daemon, it uses the TCP Wait on Listener, and it has nothing wired into the Resolve Remote Address, so it defaults to True.  Now I don't know what is happening inside of there, so it must be returning the address of the connection that has been made as a string value.  It is not clear whether it is returning a computer name or an IP address as a string.  (perhaps you can experiment and put an indicator on that wire and see what it returns.)  But the that wire goes into MB Check Ethernet Client which ha MB Ethernet is Address Valid.  It seems to me that it is working with strings and looking for correct dot notation, I imagine as "xxx.xxx.xxx.xxx".  And comparisons are being made against global variables to see if the address is valid.

I can't see why the Wait on Listener would return a computer name.  If it knows the IP address (which is what TCP ultimately uses), I don't think it would do a reverse resolution to come up with a computer name.  It is possible to have several computer names all resolve to the same IP address, so which computer name would it choose if there were multiple choices?

I don't know if this conversation helps you much.  It sounds like the newer library is locked down to a point you can't see into it clearly and see why it isn't working. Maybe someone from NI can investigate now.  I would try playing with the old library more, and put probes and indicators in that just to see how that one is working.  That might give more insight into how the new library might be working.

[Valarauca]

---

I don't know if this conversation helps you much. 

None honestly, I just explained my problem to you in 3 posts, I guess if some other poster sees it will help them some if they have vast insite into a closed source library.

It sounds like the newer library is locked down to a point you can't see into it clearly and see why it isn't working.

I made that point early when a member of the project told me I was wrong for expecting a library to be 'open', and it being closed actually benefited me. I still fail to see why.

Maybe someone from NI can investigate now.

Makes funny sound. I've had NI investigate my issues several times. They normally close because of innaction on NI's account. I think my last was the TCP read was correctly giving the information I could see coming in in wireshark. The ticket closed because NI blamed wireshark for managling the packets.

I would try playing with the old library more, and put probes and indicators in that just to see how that one is working.

The issue is I've made some very VERY heavy modifications to the 'old' library to bolt in some additional functionality, not I need to distrubute the source code of this application without all my changes shipping out, and i'm attempting to do so without modifying all my changes which I need for another project. Its sounding like the slimpiest way at the minute is just buyign a new computer and rebuilding the application...

That might give more insight into how the new library might be working.

In short take wireshark to it and watch the packets.

---

[RavensFan]

---

@smithd wrote:

He is using this one

https://decibel.ni.com/content/docs/DOC-30140

---

Are your sure he is using that one?

How is that one better than the one in the previous link?  Why are the links for downloading the files on this community page broken?

[smithd]

---

@RavensFan wrote:

---

@smithd wrote:

He is using this one

https://decibel.ni.com/content/docs/DOC-30140

---

Are your sure he is using that one?

How is that one better than the one in the previous link?  Why are the links for downloading the files on this community page broken?

---

It certainly sounds like it. 

The newer library is faster, cleaner, and more modular. Part of the reason I'm personally looking for feedback is to get an understanding of how useful that modularity is or if people would just rather edit their copy of the library. It sounds like thats what Varalauca is doing with the older library.

As for the links...they are just attached to that page, and I just downloaded it myself to double check. The older lib (http://sine.ni.com/devzone/cda/epd/p/id/4756) is also still available.

[RavensFan]

Those links do not work.  I just went there myself and tried them.

If I click on them, it just reloads that webpage.

If I right click and do a "save target as", then it tries to save the file DOC-30140.htm.  Not the actual file "ni_lib_modbus_library-1.0.9.22.vip"

Here is the hyperlink directly copied from that webpage, and you'll see it takes you directly back to that webpage.

ni_lib_modbus_library-1.0.9.22.vip

It sounds like Valarauca IS working with the newer library because he said he can't get into it due to the password protection.  I use the older libraries (the older, older ones before the newer polymorphic version now in http://sine.ni.com/devzone/cda/epd/p/id/4756, and I don't remember seeing that one being locked down.  I've drilled pretty deep in there.)

[smithd]

@Valarauca wrote:

---

I don't know if this conversation helps you much. 

None honestly, I just explained my problem to you in 3 posts, I guess if some other poster sees it will help them some if they have vast insite into a closed source library.

---

I found this dialog helpful. In your original post you mentioned using the master VI, and I provided a screenshot of the only TCP functionality on the master (besides of course the read and write VIs)...but then you mentioned the slave daemon which is of course part of the slave API. This API uses a separate create listener/wait on listener pair in order to limit the number of connections to the system, but the code you seem to be most interested in looks like this:

As you can see that input is set to false because that information is useless for a slave daemon. I'm not really sure why true is the default, actually, but oh well.

---

It sounds like the newer library is locked down to a point you can't see into it clearly and see why it isn't working.

I made that point early when a member of the project told me I was wrong for expecting a library to be 'open', and it being closed actually benefited me. I still fail to see why.

---

I think that is a little bit more malicious sounding than the situation really is, but it is a fairly accurate assessment. To clarify my point: I'm hoping that it will move from NI Labs to the product. If it goes to the product it will be supported. If it is supported it will be good for users, just like having a (closed) TCP api is much better than our users trying to call socket-level code. Right now, in order for it to be on NI labs, we needed to lock it down. Simple as that.

---

@Valarauca wrote:

---

I would try playing with the old library more, and put probes and indicators in that just to see how that one is working.

The issue is I've made some very VERY heavy modifications to the 'old' library to bolt in some additional functionality, not I need to distrubute the source code of this application without all my changes shipping out, and i'm attempting to do so without modifying all my changes which I need for another project. Its sounding like the slimpiest way at the minute is just buyign a new computer and rebuilding the application...

---

Here is another point of confusion for me and probably for ravensfan. Here, it sounds like rather than trying to debug an issue with the out of box functionality of the API you want to port your existing modifications over to the new library. If this is correct, can you clarify what changes you want to make?

[smithd]

---

@RavensFan wrote:

Those links do not work.  I just went there myself and tried them.

If I click on them, it just reloads that webpage.

If I right click and do a "save target as", then it tries to save the file DOC-30140.htm.  Not the actual file "ni_lib_modbus_library-1.0.9.22.vip"

Here is the hyperlink directly copied from that webpage, and you'll see it takes you directly back to that webpage.

ni_lib_modbus_library-1.0.9.22.vip

It sounds like Valarauca IS working with the newer library because he said he can't get into it due to the password protection.  I use the older libraries (the older, older ones before the newer polymorphic version now in http://sine.ni.com/devzone/cda/epd/p/id/4756, and I don't remember seeing that one being locked down.  I've drilled pretty deep in there.)

---

Correct, that library was open...but also a bit of a mess and a bit out of date. I've used it a few times in the past because it is so flexible and its a great starting point if you want to hack together something custom.

Re: the links, that is a weirdness in the community pages. Make sure you are logged into ni.com (the myni link in the top left), to the forums (clearly you are), and to the community (will be the first big grey header on that main dl page). I've noticed in the past that those downloads will sometimes fail to redirect properly.