Modbus RTU slave

Hello everybody,
I' m trying to make modbus slave device on labview. Has anybody experiences with the similar project. Please send me some links/advices which could help me in realization of such a project.

Hi kingarth,
I made slave devices using NI's Modbus Library for LabView 7.1: http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=F1582737BACF5CA8E0340003BA7CCD71&p_...
This same library should be available for 8.0 and has been downgraded to 7.0 and 6.1.
I found no major difficulties. Programming is enough straightforward, there are examples in the library itself.
I did not test it thoroughly, though, because I only needed a handful of digital inputs.
Paolo
Paolo
LV 7.0, 7.1, 8.0.1, 2011

Similar Messages

How to modbus RTU with CWserial

i want to implement the modbus RTU protocol under VB6. i choose the NI control which has the functions to Async read and write rather than MScomm.
but there is a question i can not figure out.
i use a Byte array to catch the return data. By GetBytesAtPort, i know there is only 7 bytes send by modbus slave.
but it seems take 14 bytes array to hold, so i can't parse them to Hex and do next job. why? and how to make it right?
thanks very much
code samples
Private Sub Command2_Click()
Dim temp2(7) As Byte
temp2(0) = &H1
temp2(1) = &H3
temp2(2) = &H7
temp2(3) = &HD2
temp2(4) = &H0
temp2(5) = &H1
temp2(6) = &H25
temp2(7) = &H47
CWSerial1.WriteAsync temp2
end sub
Private Sub CWSerial1_WriteComplete()
Dim num As Long
Dim da() As Byte
num = CWSerial1.GetBytesAtPort
da = CWSerial1.Read
num = CWSerial1.GetBytesAtPort
End Sub

hey, jake.
thanks for your help.i think i miss some info to make the question more clear ,and seems the question i had asked was solved by StrConv.
And there is another one.
As your recommendation , i have use the CWSerial1.GetBytesAtPort which return the right number of bytes.
And i need the return data in Hex form. so i use StrConv to parse codes.it works fine.
But , when the return data more than n bytes(n>11, which get from GetBytesAtPort ), the byte array i get is always (n-1)bytes.
(not 0 or 1 using to start counting make the different ) it just not right.
I think the way i transforms codes is not so good to achieve the job,but how? thanks again
the codes as below
Private Sub Form_Load()
CWSerial1.BaudRate = 9600
CWSerial1.Parity = cwParityNone
CWSerial1.ComPort = 1
CWSerial1.DataBits = 8
CWSerial1.StopBits = cwStopBitsOne
CWSerial1.ReceiveBufferSize = 1000
CWSerial1.Configure
CWSerial1.DataAsString = False
End Sub
Private Sub Command2_Click()
Dim str1 As String
Dim i, j As Long
Dim da() As Byte
str1 = Text2.Text
str1 = str1 + CRC_16(str1)
ReDim temp(0 To Len(str1) / 2 - 1) As Byte
For i = 0 To (Len(str1) / 2) - 1
temp(i) = Val("&H" & (Mid(str1, 2 * i + 1, 2)))
Next i
CWSerial1.WriteAsync temp
end sub
Private Sub CWSerial1_WriteComplete()
Dim num, datalen, i As Long
Dim da, str1 As String
Dim da2() As Byte
num = CWSerial1.GetBytesAtPort
str1 = ""
da = CWSerial1.Read(num)
da2 = StrConv(da, vbFromUnicode)
datalen = da2(2)
For i = 0 To datalen - 1
str1 = str1 + Format$(Hex(da2(3 + i)), "00")
Next i
MsgBox str1
End Sub

Câblage interface USB 485 NI vers Modbus RTU

Bonjour,
Je recherche le schéma de câblage de l'interface NI USB-485.
Contrairement à la documentation envoyée par NI, mon connecteur RJ45 Modbus RTU 8 bits utilise les broches 5 pour A- et 4 pour B+ ainsi que 8 pour la masse. Il s'agit du câblage que nous réalisons pour les esclaves communiquant sur notre HUB Modbus.
Du coté DB9 de l'interface, je ne sais pas comment connecter les TXD+, TXD-, RXD+ et RXD- (ainsi que la masse).
SI quelqu'un peut nous aider, nous gagnerions du temps.
Nous souhaitons réaliser une liaison vers un VI Labview qui se comportera comme un esclave Modbus.
Nous sommes prenneur d'expérience en ce domaine.
Merci de votre attention.
philippe mocquard
[email protected]

Bonjour,
Merci pour votre réponse car nous sommes encore en recherche de solution...
Nous sommes en Modbus RTU donc half duplex 19200 Bauds avec un ATV312, deux TesysU, une centrale de mesure Enerium, un API Twido et un HMI STU855.
Après échange avec le forum NI,
nous avons interconnectés le TXD+ et le RXD+ de l'interface NI USB-485 (DB9) et le B ou D0 du BUS (RJ45 broche 5 bleu blanc).
Même démarche pour TXD- et le RXD- de l'interface NI USB et le A ou D1 du BUS (RJ45 broche 4 fil bleu)
La masse broche 1 du DB9 a été connectée au 8 du RJ45 (ground couleur marron)
Après un nouveau contact avec le support NI suite au non fonctionnement, il est apparu qu'il fallait également configurer dans le gestionnaire de périphérique Windows (seven ici) le COM3 (pour nous) en 2 WIRES ou half duplex.
Après un nouvel échec, nous avons alimenté notre PC directement par une prise secteur dans notre armoire électrique.
Il semblerait que la terre soit meilleure, voire réellement connectée car nous ne 'plantons' plus notre BUS Modbus.
Un Hyperterminal sous windows affiche même des info échangées.
Bref, nous espérons avoir réglé le problème matériel.
Peut être que le blindage du DB9 doit être positionné à la terre ? (existe t-il un schéma type ?)
Je pense que notre PC était relié à une prise sans terre (ou de mauvaise qualité) et qu'un diviseur capacitif du filtre de l'alimentation du PC positionnait une tension sur la masse de l'interface...?
Côté logiciel, nous sommes bien en retard...
La libraire NImodbus est installée, nous avons défini un numéro d'esclave (6), la vitesse en 19200 Bauds, RTU...
Nous avons du mal à paramétrer un registre (par exemple 100) qui pourait être écrit par notre HMI (le maître) et lu dans un VI Labview (2012)...
Notre HMI et programmé sous Vijéo.
La fonction MB Slave que nous avons implanté dans le diagramme du VI nous est encore très obscure et une aide serait la bienvenue.
J'aimerais bien avoir votre point de vue sur notre projet.
peut être partons nous dans une mauvaise direction.
Quoi qu'il en soit merci pour votre intérêt.
philippe mocquard
lycée Livet Nantes

Failure of LabVIEW DSC 8.0.1 to yield values of Modbus RTU holding registers

So, I know what I'm doing--or used to. Have done this before in LV 6 and 7. Previously used Lookout OPC drivers and the "Tag Engine".
Recently with 8.0.1, I first set up the Industrial Automation OPC servers (AKA Lookout) to communicate with the holding registers (40,001-49,999) of my modbus rtu Watlow 96 and MLS316 temperature controllers. Subsequently, with the Server Explorer all of my 133 parameters on our 2 rs485 serial ports are communicating bidirectionally.
So now Duh, why can I not bind a shared variable to register, say 40,334, and eliminate the OPC? The data is always reported as bad. Neither can I link shared variables to these addresses through the OPC I/O server.
Am I missing something? Are there any examples of code available where individual modbus holding registers are communicated with bidirectionally?

Well, this may seem rather silly but I viewed the video demo that NI has on binding modbus registers to shared variables before I even made my attempt.
Now, differing from the demo video, I am using modbus RTU on a serial port. Also differing from the video, when I create my shared variables, they are not placed in the same lvlib as the modbus server just created--LabVIEW prompts for a new library to be created.
Could the NI product service staff please test with a serial modbus RTU device (a real living creature and not just a simulation please) the bidirectional communications and prove functionality with the Shared Variable Monitor of your product? I suggest that you attempt communicating with holding registers 40,001 through 49,837.
By the way, my com is set up correctly for I can view and or change all of the desired modbus RTU registers using the OPC Lookout Protocol Drivers through the Server Explorer.
Please do not send me any more links to videos that test with simulations. A real solution is required.
Lloyd Ploense

Lookout 6.0.2 modbus rtu problem?

One of our customers has Lookout 6.0.2 communicating with several CMI Scada Packs over wireless modems using Modbus RTU protocol. Suddenly last Friday night he got comm fail alarm pages on all but one site. The Modbus statistics window revealed that Lookout had stopped polling all sites except the one site that stayed in communications. The only activity was the one site.
He watched it poll this way for 2 hours, never returning to the normal polling cycle.
I had him exit and re-launch Lookout and polling returned to normal and has been that way since late Friday night.
This system has been in service for several years with very near 100% good communications sice we deployed it, up until now.
It was obviously a Lookout failure, since the only action taken was to exit and re-launch Lookout.
Isn't there a watchdog timer for this sort of error?
Is this a failure of the Modbus cbx object? (We are using the plain vanilla Modbus driver)
Roger Foote
Foote Control Systems
Solved!
Go to Solution.

Hey Mr Domer
If it's the one I think it is, I designed and built the RTU system and repeater system after the "Packaged" system became obsolete.
That was back when 1200 baud was fast! I guess it was compared to the 300 baud limit on the old stuff. Probably been re-built a couple of times since.
Thanks for the sequencer suggestion. I will have to think on this since we are pushing the limits for polling... Some ScadaPacks in this syatem have to do up to 25 modbus transactions per site... We have serious I/O in this sytem lots of which is in floats. Haven't tried DNP yet but I am getting pressure from some distributors to go Clear SCADA and use DNP to thin out redundant polling. Thing is this system has worked flawlessly for years and now suddenly we have this issue, so I am not ready to throw in the towel yet and I doubt the board would go for the moneys to implement it. We are adding another 8 pump site this October after the canals are off line but before they are drained for winter. This is so we can test the system before the frost protection season for the almond crop.
If NI can't fix this I will probably just insist that my clients reboot every week. I am fortunate that these are not unmanned districts. Only problem is that each of them are at least a 2 hour drive from any one point so I need to keep callbacks to a minimum which would be zero callbacks if it weren't for software screwups.
Best regards
Roger

Using Modbus RTU in Labview 8.5 for Terminator Field I/O

We have on site Terminator: T1H-EBC100 Field I/O's and are trying to use Labview to control it. We currently use Labview with our NI Fieldpoint modules and RIO's. We have been trying to find a way to use LabView to control the Terminator Field I/O and it uses ModBus RTU for its protocol. Does Labview 8.5 support this and any suggestions on getting the process started in using it.

Our modbus solutions don't work with max.
Instead you send a message over TCP/IP or serial with a message for a particular node address. Only the node at that address will respond or act on the message.
Modbus is much different that FP in this respect. The modbus specification doesn't require pre-discovery of every node.
Additionally, because of this you should be able to send a message to the terminator even though it isn't discovered. You just will be need to configure the address correctly.
Jesse Dennis
Design Engineer
Erdos Miller

Query format in MODBUS RTU PROTOCOL

Hii
Pl send me
1. query format for Modbus RTU Protocol with ODD Parity.
2. If query goes to instrument using ODD Parity then how to do Error Checking? should it be based on Parity bit checking or based on CRC bits ckecking?
vijtin

Hii
Thanx for support but I have idea regarding error checking methods using Parity or CRC.
I want to know only query format in Modbus RTU protocol while sending Parity Bit (either odd or even).
With Parity None my query format is...
01 03 0001 0002 C40B
Where 01 is address of device
            03 is readcommand
            0001 is starting location
            0002 is length of data which i want to read
         & C40B is CRC
Same as above example what will be the query format with Parity EVEN or ODD?
Plz help me.....
vijtin

Modbus RTU - Reading Holding registers problem - Novus myPCLab

Hello,
I'm trying for a few days to read Holding registers in Novus myPCLab (it uses Modbus RTU protocol). I used both DSC module and Modbus library with no success (it appears to connect correctly but cant read).
I need to read the given current.
Does anyone have any idea about what am I doing wrong?
Here are my vi and the modbus address.
Via DSC
I used the PLC address at "HR Inicial" and 1 at "numero de registros"
Via library
I used the PLC address in "starting address"
Solved!
Go to Solution.

My problem now is that my VI doesn't stops after I stop the while loop, it is necessary for a flat sequence implementation.
Or my other best option is to read and write without closing the Modbus connection. Is that possible with a global variable?
I guess I do have to execute this "Modbus VI" to get my variables at a Main VI if they are in the same project. So, can I make my "Modbus VI" works in the background while the Main VI (who reads and write the addresses from the global variable) works, and when I finish running it, they stop together?
ModBUS VI

Need help with Modbus RTU over TCP communication

Hello!
I'm working with a project that involves communication between a LabView PC, a cRIO-9073 and a few Crouzet PLC's with XN05 modbus extentions. The issue I'm having is to get a stable and reliable connection between the units. The cRIO is communicating with the PLC's by Modbus RTU over TCP and I've created code that read and write to them in a sequential order to avoid possible ModBus conflicts. The LabView PC is sending a "ping" (boolean true) every second to the cRIO over UDP and the cRIO is then sending the "ping" to the PLC over Modbus/TCP. The PLC has a timer that waits for pings, if no ping has been recieved in 7 seconds the emergency brakes are applied and the system shuts down.
The main problems right now is:
* After a while I lose the connection between the LabView PC and the cRIO. "Connection with RealTime target cRIO-9073 has been lost".
- I also get either error code 56 or 66 on the TCP link.
* The second problem is that if I quickly pull a TP-cable from, let's say, a PLC and then directly plug it back in I want the TCP connection to quickly reestablish. However what happens is that the "pings" from the cRIO stops coming to the PLC for like 5-6 seconds (time to reestablish link?), which means the 7 second timer is almost full. One option would be to raise that timer value, but the drawback is that the system will take longer time to respond to an true error which could be bad.. My question is simply, does it really take 5-6 seconds to establish a TCP connection between a cRIO and a PLC? What affects the time?
I would greatly appreciate help or respons on this one. I attach a simplified version of the code I use (all variables and such has been replaced with constants).
Is this a good way to do a ModBus communication over TCP with 3 PLC's? Is there a better, safer, more reliable way? All suggestions on improvment is appreciated
Thanks!
/J
Attachments:
MB_TCP.vi ‏29 KB
MB_PLC.vi ‏28 KB

Dear J,
Check the state machine Architecture here.
1. In your acquisition if you got error in any system you close all TCP connections that is not right your other systems are working fine.
2. You go with parallel loop connection. For each PLC you run separate code with error handlers.
3. Check the attached VI for TCP Read. Same VI you can modify and use for your ModBUS operations.
4. In you Sub VI you are passing a constant cluster. I am not able to understand what is the use of case structure inside the subVI, In you code you are passing the constant so its always same.
As you done previously made 3 loops or VIs to read the data in a main VI. First try to made one VI with one PLC, remove your all bugs and errors and copy it 3-time with different-different configurations.
Thanks and Regards
Himanshu Goyal | LabVIEW Engineer- Power System Automation
Values that steer us ahead: Passion | Innovation | Ambition | Diligence | Teamwork
It Only gets BETTER!!!
Attachments:
Tcp Host.vi ‏28 KB

Modbus Ethernet Slave coils and discrete inputs

Hi,
I'm having serious problems in the comunication of more than 16 bits for coils or discrete inputs.
In this forum i've read some few post about this matter, tried the possible solution but got nothing working.
Guess that there is some kind of limitation or error in the ModBus modules available at the NI Labview webpages.
The idea is very simple:
I want to be able to sent 32 bits of coils from the ModBus Ethernet Master to the slave and sent 64 bits of discret inputs from the ModBus Ethernet Slave to the Master.
Can someone please give me a push? Im' kind of newbie with the Labview and would apreciate if someone that had this problem resolved could guit me a hint.
My best regards, Jorge
Solved!
Go to Solution.

Hi Jorgelopes,
thank's for posting on National Instruments forum.
Can you tell me if you want to communicate with an automate or a computer.
If you do not tried between two computer I suggestion to make the test.
Can you send the VI with which you encounter this trouble?
Best regards,
Flo
Open Diagram First

WLF4 Utility MODBUS RTU Receive Message "ERROR"

Using the WLF4 Utility to communicate with a Watlow controller I get a framing error at every Visa read. I've checked the port settings but can't seem to locate the problem. The attached image is the block dia from the WLF4 Initalize.vi -> ...Read From Register.vi -> ... MODBUS RTU Receive Message.vi
mcnearymw

I am having a similar timeout error (-1073807339) . I have stuck 100msec delays before and after the read visa with no change. I am attempting to communicate with an F4 controller with a very simple vi (using NI WATLOW drivers). I am starting a profile, aborting a profile, current step, current temp. Real simple right? I started my project by validating hardware and I used Watview as a sanity check. The communication path is F4D (RS485) / RS485 to RS232 converter /RS232 to USB converter /PXI chassis.
During development the vi worked fine. After saving my project, I shutdown Labview, restarted labview, restarted my vi and then the MODBUS RTU RECIEVE message error (timeout). I did the usual check of comm port with MAX, revalidated hardware with Watview (verified the Watlow read the thermocouple), and still MODBUS RTU RECIEVE message error (timeout).
I have confirmed that there is a combination of opening my project, starting my vi, then starting the NI "CLOSE" vi, restarting my vi, which clears the timeout problem. If I were to close Labview and reopen my vi, problem reappears.
any ideas?
Attachments:
error.doc ‏202 KB

Utility MODBUS RTU Receive Message.vi Error

I am currently using the watlow F4 drivers that i got from NI. One of the private files: Utility MODBUS RTU Receive Message.vi is giving me errors everytime i run anything. I have narrowed it down to the property node giving me this specific error attached below. If i take this property node out, then it will time out on the visa read. I have tried to adjust time outs, and bit sizes as seen in other forums, and still wont help.
I using the ICS Electronics(model 4899A) GPIB to MODBUS interface.
Attachments:
Error.jpg ‏1245 KB
modbusrecieve.jpg ‏1559 KB

what was the outcome of your debugging?
this is my situation:
I am having a timeout error (-1073807339) see attachment . I have stuck 100msec delays before and after the read visa with no change. I am attempting to communicate with an F4 controller with a very simple vi (using NI WATLOW drivers). I am starting a profile, aborting a profile, current step, current temp. I started my project by validating hardware and I used Watview as a sanity check. The communication path is F4D (RS485) / RS485 to RS232 converter /RS232 to USB converter /PXI chassis.
During development the vi worked fine. After saving my project, I shutdown Labview, restarted labview, restarted my vi and then the MODBUS RTU RECIEVE message error (timeout). I did the usual check of comm port with MAX, revalidated hardware with Watview (verified the Watlow read the thermocouple), and still MODBUS RTU RECIEVE message error (timeout).
I have confirmed that there is a combination of opening my project, starting my vi, then starting the NI "CLOSE" vi, restarting my vi, which clears the timeout problem. If I were to close Labview and reopen my vi, problem reappears.
Attachments:
error.doc ‏202 KB

MODBUS RTU - Simulate multiple slave to response to a PLC

Hi! I'm new with the use of the Modbus communication. I would like to simulate 4 devices (I/O Extenders) to response to a PLC. It is possible to do this using only one com port with RS232 to RS485 converter. Do you have an exemple that do this?

To you to reply!
I use Modbus Library.
I suppose that to implement multiple slave I need a NI-9871 or a multi port pci card. But I would like to use only one ComPort for 4 devices. To specify which devices I want to simulate (implement) it's 3 I/O extenders 900MB series and a wind sensor. It is possible to do that or I absolutely need a multiport RS485 card?
Attachments:
900mb_discrete_lg_2.jpg ‏58 KB

Modbus RTU over TCP (Simex Transmitter and Advantech Server)

Hey Guys,
somehow i am not able to get a connection over TCP IP using RTU Mode (reading values) from a transmitter which is hooked up to an advantech EKI 1542 Server. The Port is configured as an RS 485.
i am using the modbus library and i tried to adjust the MB serial read holding registers vi to accept a TCP IP Socket input instead of an INSTR. Do you have any suggestions?
Thanks a lot for the forum support!

Hi Christo and welcome to NI Forums!
Is this the ModBus library you are using? If so, I'd recomend to check out the newer, object based library available here. It has a more straightforward setup, especially for using TCP connections. You'll find an example VI for using a master, as well as a slave device, and these you'll be able to use right away without much modification. The code'll look like:
Please test your device communication using this library.
Kind regards:
Andrew Valko
NI Hungary
Andrew Valko
National Instruments Hungary

Modbus RTU Command Via TCPIP and Receive The Holding Register Value

I have connected Energy Meter with Modbus to Ethernet Conveter Via RS485. My Slave Id:1. Mode: RTU. I want to read holdig register values from 3911 to 3920. I have formatted the modbus command and write to tcp write and read the value from TCP read. I have getting invalid values while decoding.
Please provide your suggestion.

Hi,
If I am right you are sending serial ModBus data to the TCP link and you don't handle the received data correctly.
You also are using the wrong port. Default port 502 is used for ModBus TCP.
Here is an example how it could be done. Data in is the loopback command.
Data out is the TCP data without the slave address and CRC of the serial data
Kees

Modbus RTU slave

Similar Messages

Maybe you are looking for