modbus domain resolution?

[Valarauca]

Concerning the 'newer' password protected modbus library, does anyone know if the MODbus ethernet master forces Domain Name Resolution?

I'm currently on a packet switched but not packet routered network, and I find it impossible to get communication between a modbus slave and master.

[Valarauca]

Bump

[Esteban_B]

Hi Varalauca,

Is this the Modbus Library that you are referencing?

Please let me know

Regards,

[smithd]

He is using this one

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

Varalauca,

I would recommend posting to the main discussion page here in the future:

https://decibel.ni.com/content/thread/17712

as it is directly monitored by both myself and any other interested parties in R&D. I only read this forum when I (occasionally 😉 ) have free time. The other valid thing to post there is feedback about the password protected nature of the code. There are definitely reasons we chose to do this but it would be nice to have some customer use cases for keeping it unlocked.

To answer your question...I am not sure. The modbus api on the master side acts as a pass-through to the open function. Here is the VI in question, but definitely let me know if you have any other questions.

Thanks,

Daniel

[Valarauca]

---

@Esteban_B wrote:

Hi Varalauca,

Is this the Modbus Library that you are referencing?

Please let me know

Regards,

---

That is the older library, that is no longer 'officialy supported'.

[Valarauca]

---

@Esteban_B wrote:

Hi Varalauca,

Is this the Modbus Library that you are referencing?

Please let me know

Regards,

---

[Valarauca]

---

@smithd wrote:

He is using this one

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

Varalauca,

I would recommend posting to the main discussion page here in the future:

https://decibel.ni.com/content/thread/17712

as it is directly monitored by both myself and any other interested parties in R&D. I only read this forum when I (occasionally 😉 ) have free time. The other valid thing to post there is feedback about the password protected nature of the code. There are definitely reasons we chose to do this but it would be nice to have some customer use cases for keeping it unlocked.

To answer your question...I am not sure. The modbus api on the master side acts as a pass-through to the open function. Here is the VI in question, but definitely let me know if you have any other questions.

Thanks,

Daniel

---

That is the one. Is it a possibility that it will not communicate to devices that don't respond to its 'data' poll?

Because I am getting time out errors between it and servers writting with this library as well Adam 4572 moduals.

Also one quick question is why is it closed source, this severally hurts my ability to troubleshoot projects that use this library.

[smithd]

The basic idea is that NI labs consists of things which may, at some point, become part of the product (like ethernet/ip for example). Thus, it was decided that we should lock the API up in order to restrict access to the code until we've decided what to do with it.

The benefit to this process for customers is that if it is added to the product then it will be fully supported by NI, but the downside is this transition period. I know it is less than ideal but hopefully you see our perspective.

The reason I ask that you provide your feedback on the other forum is that it gives the interested parties direct feedback about how you might use it. For example, is it totally useless to put it just into RT without a windows component? What about the Saphir APIs listed on the page, which exist as separate (albeit paid-for) downloads? Do you see the ability to view the unlocked code as a critical component to its use?

Now, back to the issue at hand. I'm honestly a little unclear on the specific issue you are facing. You mention issues with a particular function call?

Either way, my intent with that image was to show you that there is basically no magic happening on the master side of the connection. Anything you can do with the TCP primitive we can do with the modbus master. This is nice because you can simply connect to your device (on port 502) and that should tell you if you'll be able to connect using modbus. Can you clarify if this is sufficient, or what other info you need help with in order to troubleshoot effectively?

Thanks,

Daniel

[MarcoMauri]

Hi Varalauca,

have you tried to communicate with an other MODBUS client? Was it succesful?

You can also try to sniff the network traffic with Wireshark and see what's happening when you are connecting.

Regards,

Marco

[Valarauca]

---

Either way, my intent with that image was to show you that there is basically no magic happening on the master side of the connection. Anything you can do with the TCP primitive we can do with the modbus master. This is nice because you can simply connect to your device (on port 502) and that should tell you if you'll be able to connect using modbus. Can you clarify if this is sufficient, or what other info you need help with in order to troubleshoot effectively?

Thanks,

Daniel

---

---

The issue I am facing is that ADAM's 4572's (A modbusASCII/RTU to modbus/TCP converter) does not appear to communicate with the library in question.

I also have issues with the 'older' library, slaves set up with its API seem to fail communication. The error code I get is 63 (Something something to much time allocation) which is a time out error if memory serves a generic 'couldn't connect within n time error'.

Now my past experiences with NI the TCP communication in NI defaults to having Domain Name Resolution on, instead of just caching IP addresses. My work is on a packet switched network locally, so I can't resolve Domain Names of local computers. I was wondering if this could be an explaination.

I.E.: Ping company-computer-50 fails but ping 192.168.0.5 works

I was wondering if the new library would suffer from this problem.

:.:.:

The primarly problem I have is outlined above. I can't get communication in the newer library between 2 devices on my network. Yet when I use the 'older' library, works fine no issue. When I mix the libraries, nothing works. The only way I can seem to get the new library working is to run its connection across the local loop (127.0.0.1).

[RavensFan]

If pinging a computer name does not work, but pinging by IP address does, then obviously using the the modbus/TCP library with a computer name will also not work.  You will need to use the IP address.

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.

One alternative you have is that you could add the computer name and the IP address for the device to the HOSTS file on your PC.  This is where the PC goes to look up computer names first.  If it can't find something there, then it goes out to your network's router, then if not there, it goes out to an internet DNS server.  Of course if the IP address of the device ever changes (is it statically assigned or dynamically assigned?), the HOSTS file will be wrong and your PC will be going out and hitting the wrong IP address.