CRC-16 SI-M Communication Card, Modbus RTU

I am trying to write the CRC-16 Generation Procedure for the SI-M Communication Card from TECO Electric and Machining Company. Here is the algorithm they provide for generating the CRC-16 word (attached is my attempt to implement it, I welcome any suggestions). This is verbatim:
A. Load a 16-bit register with FFFFH. Call this the CRC register.
B. Exclusive OR the first 8-bit byte of the message with the low order byte of the 16-bit CRC registers, putting the result in the CRC register.
C. Shift the CRC register one bit to the right (toward the LSB), zero filling the MSB. Extract and examine the LSB.
D. If LSB is 0, repeat procedure C (another shift). If LSB is 1, Exclusive OR the CRC register with the polynomial value A001H.
E. Repeat procedure C, D until eight shifts has been performed. Wile this is done, a complete byte will have been processed.
F. Repeat procedure B-E to the follwing byte of the message until all bytes of the message is processed.
G. When the CRC is placed into the message, it upper and lower bytes must be swapped.
If anyone understands this please feel free to tell me where I went wrong (see attached).
Cheers!
Message Edited by jmcbee on 02-05-2009 03:25 PM
Message Edited by jmcbee on 02-05-2009 03:31 PM
CLA, CLED, CTD,CPI, LabVIEW Champion
Platinum Alliance Partner
Senior Engineer
Using LV 2013, 2012
Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved.
Solved!
Go to Solution.
Attachments:
CRC 16 Generation.vi ‏9 KB

Thanks for the reply Ravens Fan. This is my first venture into Modbus communication and I knew that inexperience was going to hurt, especially when it comes to interpretting a poorly written CRC-16 algorithm. Luckily I had access to the best minds in this type of work and figured that someone here would have the experience I lacked. As usual I was not dissapointed. I love this forum!
CLA, CLED, CTD,CPI, LabVIEW Champion
Platinum Alliance Partner
Senior Engineer
Using LV 2013, 2012
Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved.

Similar Messages

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

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

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

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

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

How can I configure labview for communication with Modbus I/O?

i read a article about configureing Labview for communication with modbus I/O in NI developer zone, but it was written for Labview 6, how can I configure it with labview 7. it seems there are some difference. Thanks!

In both LabVIEW 6 and 7, you connect to modbus using Lookout Protocol Drivers (LPD) and then communicate to LPD using the tag engine of LabVIEW DSC or through DataSocket.

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

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

MODBUS-RTU connection with aleatory VISA communication fails

Hi everyone,
I have a big problem that I'm trying to repair since a pair of months. I have a MODBUS gateway connected to my pc via RS-485 in RTU mode. The physical implementation is based on Ethernet cable, so I have two connection converters in both endings of the Ethernet cable that wire each line to its corresponding terminal in a RS-485 connector. On the side of the PC i also have an electronic card to convert RS-485 to USB for connect using a USB port for pc's connection. That card is the model USB-COM485-PLUS1 from the company FTDI chip. I have installed on my PC the drivers of the card that configure a virtual COM serial port for my RS-485 communication. On labview I have programmed my interface for communication using a MODBUS library that was installed previously on my PC (I am using my company PC, because i have this problem on my workplace).
The problem is that, usually, my system works correctly, and the communication is perfect. I read always the holding registers of my gateway, and i can write the control registers without problems, but, some times, the connection spend more time without communication that reading, and after some hours in that conditions, it fall in continuous fail and doesn't work any more since the next day. That problems persists even if i restart the PC or shut it down for a while. By the other side, I realized that when the communication falls it only fall on the reading wire, because even if the reading communication is with continuous fail, i can write on the corresponding registers of my gateway.
I'm sure at 80% that the gateway runs correctly, and I have other installation similar with the same gateway, cable, connections and card working correctly. I tried changing the Ethernet cable, changing the RS-485 to USB conversion card and only when i changed my PC, the problem disappears. So I thought it was a problem of the PC. But some time after I changed the PC, the problem returned. After this, I continue making probes and actually I have the theory that it may be a problem because i have other communications running at the same time in my labVIEW app. I think it may be a problem of incompatibility of drivers or a bridge over different communications that make it fail. Because the pc's where this error disappear has not installed NI RIO drivers.
My LabVIEW program also have a communication via Ethernet with a NI cRIO 9076 chassis. That chassis has a module for PROFIBUS communication, also has a module for thermocouple inputs, a module for voltage inputs and other for voltage outputs. All this modules work correctly always. My theory is that some of this other modules in NI cRIO 9076 chassis may cause a conflict that make my system works wrong. Other things that seems me annoying is that i bought recently a new conversion card for RS-485 to USB connection and it doesn't works on my system, I have other two identical cards and they work correctly, and i know that the new card works also in other systems i have.
The issue I don't understand is that this problem doesn't happend many times and it seems to be aleatory... The fail that the labVIEW return when it can not read the holding registers is a timeout error because of a frame error. It would be illuminating for me if that error where periodic or systematic, but occurs only a day every two or three weeks and the rest of time works properly. But on my company, when this installation will work continuously, it can't have any day of non-work.
So, please, I need help with this Issue, I'm lost int he way of resolving it. Thanks only for read this large post.
Regards,
Joaquín
PD: Please, don't damn my English, it is not my mother tongue, I'm spanish.

First of all, thanks for your quick reply.
I had the USB port save power mode enabled. I have disabled it. Actually my system works correctly so I can't know if the problem has been solved, but i have a new converter card for RS-485 to USB and it doesn't works, i have other two that work properly but the new only writes, just like when i have the problem commented. So, I think that if i solve the problem with the new card, i can be sure that I will have solved my connection problem. The new card is configured with the same options that the others, except by the port number, i configured COM 3, COM 4 and COM 5 respectively.
By the other side, when I said that I think cRIO interferes in MODBUS communication I mean that the only things that changes in PC's that correct the problem are that they have not installed the FPGA module or the RIO drivers. And once i changed my PC, the problem was solved since I installed this module and drivers, moment when the problem reappeared.
Thanks again

Process Failure when communicating over MODBUS using LabVIEW 2011 and DSC

I'm currently trying to read from a PLC's holding registers using MODBUS/TCP. I've confirmed that the PLC is updating the values and responding to MODBUS communication correctly using a third party program called Modbus Poll. However, when I try to poll the PLC using LabVIEW's shared variable engine, I am unable to read any values from the same addresses that I'm viewing with Modbus Poll.
My setup simply consists of a PC connected directly to the PLC over Ethernet, with no router in between. I am using LabVIEW 2011 SP1 with the DSC module.
I opened the NI Distributed Systems Manager to view the status of all shared variables in the Modbus library that I created and I've noticed that the CommFail bit is permanently set to "true". All other variables with a "read" access mode report "Process Failure". I've tried restarting the process as well as stopping and starting the local variable engine with no success. I've also restarted my computer several times to see if any services were failing, but this does not seem to have fixed the problem.
I finally resorted to monitoring communications over the network card that I have the PLC plugged into via Ethernet using Wireshark and I've found that while Modbus Poll is communicating with the PLC, many MODBUS and TCP packets are sent and received. However, when solely using LabVIEW or the NI DSM to communicate with the PLC, there does not appear to be any communication over the network card.
Something that may be worth noting is that I was able to communicate with the PLC and read values from it with the DSM on just one occasion, when I first figured out which addresses I should be reading from. It all stopped working shortly thereafter. Prior to this, "CommFail" was not usually set to "true" with my current configuration. Thinking that it was my firewall, I have since turned my firewall off, but this seems to have had no effect on the problem either.
Any help on this matter would be appreciated.
Solved!
Go to Solution.

Just a thought but I think the register addresses used by LabVIEW are one off of the actual register #. I was using a CRIO as a modbus IO Server and had to shift the register addresses by 1 to get things to work correctly (can;t recall if it was +1 or -1). This is documented somewhere on ni.com but can;t seem to find it now. But here is another link that may help:
http://zone.ni.com/reference/en-XX/help/371618E-01/lvmve/dsc_modbus_using/
Dan

Communication with modbus devices

Hello All,
My name Peter, I am currently exploring what LabVIEW has for instrument communication. I have explored a little on NI-Visa and used it for instrument communication through USB and Ethernet. My next task just now is to see how I can communicate with Modbus devices. I have done some background reading on modbus communication protocol and now have some level of understanding of what it is about. I hope to understand more as I continue to read more materials.
I came across an NI-Tutorial titled Connect LabVIEW to any PLC with Modbus. It is about communicating with a networked PLC using modbus. I followed all the steps described for creating Modbus master I/O Server, Binding shared variables to Modbus Address through the I/O Server and writing to Modbus Addresses in LabVIEW. On running my VI to deploy the shared variable, the following error occured.
Can anyone please guide me on what to do because I do not know exactly what is going ON. I engaged in this excercise with the hope of getting to understand more about Modbus communication and then see how I can apply thesame idea to communicate with the Modbus device available in my Laboratory. Please note that I do not yet know much about modbus communication and I am just learning about it now. I do not have any PLC connected to the network. Could that be the reason for the error? If anyone has got any other relevant document to help me get started with modbus communication I will be happy to have them posted here.
Thanks very much for taking time to read through my post message. Hope to hear a quick response from you.
Regards
Peter

Hi SmithD,
I would like to say thank you very much for making out time to respond to my queries. I have done as directed but still not getting result. Following the wire mode port setting configuration, I stopped the process and then selected the RS485/wire4 as the wire mode. On running the VI, an error pops up with the information that the Visa resource is Valid but the port cannot be accessed. I noticed that If I undeploy the shared bound variable the error does not pop up anymore. I concluded that maybe I was not supposed to have added the VISA configure Serial port in the first place.
Kindly tell me what to do.
My task is to read the holding register from a Modbus device. I have the register map with me, and know the TCP and RTU settings for this device. After the attempts I have made so far I was forced to believe that perhaps the device was not responding. I then resolved to using the QModbusMaster which was previously used to read the holding register. For reasons I don’t not know, It worked well with the TCP communication and returned an error that read " slave threw exception > unknown error". With that, I am now sure that the device is functioning properly, at least with the TCP.
Having obtained result from the TCP using QModbusMaster application, I want to simply do the same using LabVIEW.
Some few questions for which I would want to ask for clarification are:
1.) When using the Modbus Library, do I need to create both master and slave instance to be able to read the holding register? My attempt was to create a Master instance with the RTU parameters. The starting address and number of registers were specified at the input terminals of the Read Holding Register VI. This VI immediately followed the Create Master Instance VI. I was expecting that that would read the information contained in the specified registers and output it at the register value terminal. One challenge with this attempt was that with RTU it didn't work. I tried selecting TCP as the VISA resource. But the device was not showing on the list. I went to MAX to create a new VISA TCP/IP resource under the network devices but MAX could not detect the presence of the device. I am now thinking maybe the device is not supported by NI-VISA and so it will not be possible to use the Modbus Library with it.
2.) If the device is actually not compatible with NI-VISA, can DSC I/O server be used to read the information on the holding register?
3.) Do I need an intermediate device between a Modbus device and the PC to be able to read its holding register?
Please if anybody has got a good suggestion as to what to do to get my task achieved, kindly leave me a post.
Thanks
PETER

CRC-16 SI-M Communication Card, Modbus RTU

Similar Messages

Maybe you are looking for