LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Modbus TCP Communication to Festo Drive

Solved!
Go to solution

Hi all,

 

I'm currently trying to connect LabVIEW to a Festo Drive (CMMP-AS-C2-3A-M0 if that's important) over Modbus TCP. For this I am using the Modbus Driver from this Site: http://forums.ni.com/t5/NI-Labs-Toolkits/LabVIEW-Modbus-API/ta-p/3524019

 

The Site references multiple options for Modbus TCP communication, so first off: Does anyone know how to get the Modbus communication option that comes with LV RT? This would be interesting only if it is better than the one I am using.

 

As for my current problem: I am using the Modbus Master Example from the library to communicate with the drive. Connection works out of the box and I have also verified that it's a "real" connection, since it throws an error for all other IP addresses.

When I use the functions I get Error 538181 occurred at <APPEND>Function 15, suggesting that the function is not implemented on the server. This is pretty much expected behaviour.

 

What I don't get is: If I try the Fetch Basic Objects command, I don't get anything. No error, but no data either.

Because of this, I spoke to my colleague who knows Modbus a bit better than I and he said that my understanding of the architecture is correct: My PC is both Master and Client and the Drive is both Slave and Server. 

 

The functions, of course, are working. When I connect the Master Example to the Slave Example I can send and receive data without problems.

 

Does anyone have a suggestion what else I can try?



Remember Cunningham's Law
0 Kudos
Message 1 of 36
(13,404 Views)

For me, the Modbus VIs are under Data Communication > Modbus. I'm using 2016 and 2017, and I think it was the same in 2015. Be aware that they are only in 32-bit LabVIEW. (I didn't know this and wrote my own Modbus library in 64-bit when I was still using that... doh).

 

I'm afraid I don't know what "Fetch Basic Objects" might be - it's not included as a VI in the built-in Modbus implementation I'm looking at, and neither is it a described command in what I think is the relevant manual for your product.

 

The typical types of commands I see (in both LabVIEW and the manual) are Read Holding Registers, Write Registers, ...

Although the manual isn't particularly verbose or helpful (quote below) in combination with Google it should be possible to get started if you can find a library that does what you want/need.

 

3.1 Overview This part of the documentation describes connection and configuration of the motor controller within a Modbus network. It is targeted at people who are already familiar with this bus protocol.

 

Because an example would have killed them...


GCentral
Message 2 of 36
(13,377 Views)

Thanks for your quick answer.

 

The "fetch basic objects" button triggers the "read device identification" function to read the basic parameters (0x00 to 0x02). According to page 44 of the document you linked, which I was also reading, this should be supported. From what I understand this is the *IDN? of Modbus TCP in that it should work on every Modbus TCP Server.

 

Apart from that, I should be able to read certain parameters in a different way as well. On page 183 they talk about the Controller Serial Number at PNU 114. From Google, I know that PNU is basically the Modbus holding register or if read only the input register. However, if I use the read input registers function I get back error code 538183 illegal data value for address 0 and 538182 Illegal address for all other addresses.

 

You are correct, that the documentation is pretty bad. An example would be nice...



Remember Cunningham's Law
0 Kudos
Message 3 of 36
(13,359 Views)
Solution
Accepted by PeterFoerster

Hi there,

 

I'm quite familiar with Modbus, before trying to rule out issues, let's try some simpler communication. I'd first start by verifying that you have following the steps of configuring the device for Modbus as outlined in the below document:

 

 

https://www.festo.com/net/SupportPortal/Files/346072/100005e.pdf

 

By default it won't be automatically set for Modbus. Are you able to communicate with the device through any other Modbus Server software?

 

I'm not familiar with the configuration tool that they mention, tried looking at a video demonstrating the setup but the video and audio quality was too poor. The document I have linked implies that you configure the registers you would like to use, I would contact Festo to verify.

 

Once we have confirmed that it is configured for Modbus TCP and that registers are available (either requiring configuration or not) I would try only to read a specific Holding Register and then use NI IO Trace to try and capture the transmission and response to verify what is happening on the lower level.

 

http://digital.ni.com/public.nsf/allkb/282C5D41E2BA04F2862574BA007803B9

 

Best regards,

 

Ed

 

 

Message 4 of 36
(13,331 Views)

Hi Ed,

 

your advice was really helpful. I downloaded QModbus Master and did a bit more trial and error, nothing that couldn't have been done in LabVIEW, though. So far I had tried to modulate nearly everything except for the number of input registers to be read. Turns out 4 is the sweet spot, which is impossible to know since:

All Documentation speaks of 8 Bytes vs. All Software reads 4 words.

 

After I managed to receive and send the bytes it was pretty easy, though. In This Document on page 120, they describe the protocol, which consists only of 2 frames one for out and one for in.

 

Thanks to everyone for your help!



Remember Cunningham's Law
Message 5 of 36
(13,310 Views)

Hi Peter,

 

Apologies for hijacking your thread but its quite recent and I have a very similar problem you may be able to help with.

I'm trying to establish communication with a FESTO CMMO-ST over modbus.  ( https://www.festo.com/net/SupportPortal/Files/425129/CMMO-ST-LK-SY_2015-07a_8043621g1.pdf ).

 

I have zero Modbus experience though quite a bit with FESTO controllers (I actually have a CMMP-AS motor/controller running using CANOpen interface right beside me).

 

I've managed to read the device ID (so we are communicating). I tried to listen (using NI Trace as suggested) for what was sent and received but nothing is logging.

 

ReadDevice.PNG

 

I've been trying to send the 'basic status' request (pg 34) but to be honest I've no idea how to properly configure the command set (or even the correct vi to use). Could you perhaps share a screenshot of some of your code for sending and receiving commands to your controller? I'm sure with that pointing me in the right direction I can figure out the rest of the command set.

 

Kind regards and thanks,

Dave

 

 

 

 

 

 

0 Kudos
Message 6 of 36
(13,218 Views)

Hi Dave,

 

I hope I'm not too late: The best advice I can give for these drives is to go home, sleep and come back. I've solved most of my problems by re-trying stuff that didn't work the day before Smiley Very Happy

 

In all seriousness, though. I can't share big portions of my code, but if the communication uses the FHPP protocol it's rather simple: The device always sends/receives 8 bytes whereas each bit has a certain function. The functions are for you to find out for your device.

Since my LabVIEW driver- apparently you use a different one-  communicates only inI 16 it's an array[4] of I16, but you can interleave to group them correctly.

So, as a first test, I'd read 8 bytes and look at the result, this doesn't have to be in LabVIEW, QModbus Master comes to mind, which is easier for trial and error. Implemented in LabVIEW, it will look something like this, which gives you back an array[8] of I8s:FHPP Read.JPG

 

 

If that gives you something back, you just need to correlate bits and functions. Normally, the FCT can run in parallel since it uses UDP.

 

You should make sure that you don't have any FHPP+ functions active, for a start. With FHPP+ you have to read/write more than the discussed 4 registers.



Remember Cunningham's Law
Message 7 of 36
(13,182 Views)

Hi Peter,

 

I'm just back from a holiday so hopefully everything will be extra clear 😉

 

Thank you for the valuable pointers - I'll give it a try over the next few days! 

 

Dave

 

 

0 Kudos
Message 8 of 36
(13,160 Views)

Hi Peter,

 

I just wish to say thank you for the valuable inputs - once I familiarized myself with FHPP your pointers helped me a great deal! My stage is fully operational now!

 

Dave

Message 9 of 36
(13,006 Views)

Awesome, glad to help!



Remember Cunningham's Law
0 Kudos
Message 10 of 36
(12,997 Views)