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

Similar Messages

How to use third party usb 485 interface

I have a third party usb-485 interface that we frequently use within our company and want to be able to use Labview to create a program to talk to our systems. The interface is a kk systems usb-rs485 isolated converter which I have been able to recognise in MAX explorer after using the NI VISA driver wizard but I am unsure how to now use it for 485 comms within Labview. I don't seem to be able to detect it with the VISA configure serial port vi. I have used the NI usb-485 interface before and found this quite easy to set up but am not sure how to use this third party interface. I have attatched screen shots of the MAX window to show what it is seeing. Any help would be greatly appriciated.
Attachments:
MAX usb 485 screen shot.PNG ‏102 KB
MAX usb 485 screen shot2.PNG ‏120 KB

I have undone everything as recommended and the comm port does appear in the devices tree but when I try to use the device I don't seem to be able to get any response even though I can select the port as the VISA device name in my vi. I am pretty sure I have the baud rate etc.set the same as when we use the interface in other software,is there something else I need to do? I am using the rs485 example in labview as my code which works with the ni-usb485 we have.

USB-485 driver for Windows 7

Does there exist on the NI website a device-secific Windows 7 driver for the USB-485? I know I can download and install NI-Serial package (all 517 Mb of it) and get the driver for this thing, plus the drivers and libraries and help files tons of other stuff for dozens more devices that I'll never use, but I don't want to do that. I just want the Windows USB driver for this single device. Is it available?

That may be true but it would effectively eliminate the NI product from contention when someone was just looking for a simple 485 COM interface without any of the other extensive software baggage that the NI part drags in. In this case I guess something like the FTDI part with its 2Mb driver will be a more reasonable choice. I appreciate NI having hardware that supports their software and vice versa but I would think they'd also want their hardware to be usable (where conveniently possible) in generic software environments as well, just so they were not walking away from that market segment.

Creating LabVIEW Executable for sub-20 Multi Interface USB Adapter

Hi
I'm using Sub-20 Multi Interface USB Adapter (www.xdimax.com) for GPIO and SPI. The code is based on .NET constructor Node. I can access the device and perform all the tasks but I'm unable to generate executable.
The application comes up with this error (on any machine including the development machine)
"This VI is not executable. The Full development version of LabVIEW is required to fix errors"
I'm using labVIEW 8.2 and .NET Framework 4 is also installed.
Thanks

Hi AA76,
That is good to know, at least we know the cause of the error. The KB - How LabVIEW Locates .NET Assemblies shows the LabVIEW search directories. I suspect what is probably happening in this case is the relative path. If the system is looking for the same relative path this is probably different. You say that even on the development machine the .exe does not load the library. Is this when you have just created the .exe or after running the installer? If it is after running the installer what about before you build the installer?
Finally where is the assembly located?
Regards,
James
James Mc
========
CLA and cRIO Fanatic
wiresmithtech.com/blog

Impossible d'utiliser LabView 8.5 avec une interface USB-GPIB sur un MacBook

Bonjour
J'aimerai utiliser LabView 8.5 sous un macbookpro (intel leopard) mais je n'arrive pas à communiquer avec l'interface usb-gpib, j'ai plusieurs version de ces interfaces B et HS, seul la led sur la HS s'allume. Si j'ai bien compris ... les drivers pour ce genre d'interface ne sont pas compatiblent avec OSX , mais alors comment faire avec un portable ?? merci

Bonjour,
Effectivement, vous avez raison, les interfaces USB-GPIB ne sont pas compatible avec MAC. Par contre, je peux vous proposer d'utiliser l'un des 2 articles suivant:
NI GPIB-ENET/100
NI PCMCIA-GPIB
Vous trouverez la liste des drivers compatibles sous le lien:
GPIB Driver Versions for non-Microsoft Operating Systems
Bonjour jounrée
Nick_CH

Line-in or audio interface USB/Firewire

Hey i record a lot of video for my church, and now im getting to the point where i want to record audio digitally via soundtrack on my macbook pro for special occasions like concerts. I did it last week of a wedding and it came out ok, I had it set up like this. (LR) 1/4in cables for main audio mixer to a small 6 ch mixer then out 1/4 cable (LR) into a 1/4 to 3.5mm adapter into line in to the mac. Is that a good set up or would getting a interface usb/firewire like the (M-Audio FireWire 410 4-In / 10-Out) make a big difference as far as sound quality and liveliness is concerned. I don't want to wast money but i love quality, and also would that 2nd small mixer be a wast? Got a feeling that to much preamp to begin with? Give me your thoughts please.

Hi,
Normally I would use a separate interface, like you mention. In general, the Analog to Digital Converters are going to be a bit better in a dedicated audio device, so that should make for better quality recordings. And you have the possibility of using balanced cables, which reduces the interference risk.
About the 2nd mixer, normally the signal that's coming out of the main mixer is going to be line level. So, you wouldn't need the mic preamps from the 2nd mixer; is there a reason why you used it besides that? You might not have control of the main mixer, and need some kind of control over the gain going in. Is that the case? In general, it's a good idea to keep your signal chain as short as possible. The more cables and connectors, the more that can go wrong. So unless you need the control or the gain, the 2nd mixer seems unnecessary.
Hope this helps!
Matt

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

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

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

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

Câblage interface USB 485 NI vers Modbus RTU

Similar Messages

Maybe you are looking for