Modbus DSC

Good morning,
I want to make a NI cRIO9073
speak with a Maple HMI (Touch Screen) using an RS232 connection. Unfortunately,
I have no previous experience, thus I have to confront lots of difficulties. In
order to obtain this communication up to now I made some efforts which include:
create a project, adding the cRIO ,then create an I/O modbus slave server and
finally a shared variable. I have doubts about the properties setting of shared
variable. What kind of variable type do I need, enable aliasing? What I was
trying to do was writing to a DO channel of cRIO as a first test. I am
attaching a screenshot of the project I made. Up to now I tried to apply
instructions I found in the link: how to turn an RT target into a Modbus slave
using I/O servers, however for serial (RS232) connection, but my HMI displays a
message that can’t find the PLC. I checked settings like baud rate etc and everything
seems ok.
Any possible help or instruction will
be appreciated
Thank you in advance
Attachments:
Modbus_project.jpg ‏98 KB

Good Morning A_Patel,
Yes, I have already used the link
proposed and already checked that the server works by using my PC as interface.
In addition, I have already tested the functionality of cRIO (I have written
and read to and from the same DO channel that I am trying to use in the touch
panel application). I am afraid that it is difficult to solve the problem (if
it is a problem and not luck of communication between the two devices, Touch
panel and cRIO, due to software issues). Anyway, thank you for your
consideration.
Best Regards

Similar Messages

Modbus DSC point not reading correctly

   I'm using LV 2013 32bit on W7-64bit. I'm talking to an industrial controller using Modbus over Ethernet. My current software uses the DSC modbus interface, in which I define the Modbus bus itself within a library in the project, then define each Modbus point as an address inside that modbus definition. Inside LabVIEW, you can then get to the Modbus data via Shared Variables. I am currently using the dynamic shared variable calls, rather than static shared variables. I have points that are Boolean (coils) and Reals, with some Read Only and some Read/Write. In general, all of this works.
   However, there is one Read/Write Real that acts funny. If I set it to a new value or if the industrial controller sets it to a new value, the industrial controller gets the new value. The shared variable engine on my computer even gets the new value, as can be verified by opening the Distributed System Manager. But LabVIEW continues to read the old value, with no errors. Other Read/Write points work fine, and I've looked over the address definition several times and can't find any reason why this point should be any different than the others.
    Does anyone have any ideas why the DSM can see a new value of a shared variable, but LabVIEW continues to get the old value? I've looked at the init case for the dynamic SV's, and I can't see any options there that I can tweak to try to resolve this. My next attempt will be to rewrite the entire sub-system so that it uses NI's latest Modbus library and skips the whole DSC thing. That will probably be much better for other reasons as well. I've noticed that with DSC and Shared Variables, the first time the program runs it gets started pretty quickly, but subsequent runs can take up to two minutes to connect to all the SV's.
Thanks,
   DaveT
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.
Solved!
Go to Solution.

Sorry, I can't help you in this case. The config error was within my own software configuration. I was just telling it to do the wrong thing. Nothing that could be useful for anyone else.
I hope you figure out your issue. I know how maddening that can be.
DaveT
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

Modbus (DSC Module) - Illegal Data Address

Hi
I need to implement a Modbus Slave in an application on a cRIO system. I set up a "I/O server" (DSC Module) and created shared variables for all the registers I need. The Slave has been tested and works fine, I'm using about 20 holding registers and I'm able to both read from and write to them.
The issue is that when the Modbus Master reads a holding register that I have not implemented the slave replies with the value "0x00 0x00" (LabVIEW default for integer) and not with exception response code 02 (a holding register inquiry for a nonexistent address should reply with function 0x83 and code 0x02 - Illegal Data Address).
Is it possible to change a setting or something, in order to force the DSC Module to send an exception response code, in stead of simply a default value, for registers that are not specifically configured?
Hope someone can help me - I would really like not to write all the necessary code for a modbus slave myself.

Hi Lenvno
Thanks for your reply.
I think you misunderstood me.
I have an application running on a cRIO. On this cRIO I need to implement a Modbus Slave in which specific holding registers should be used. Through a serial connection a different device, acting as a Modbus Master, obtains information from this slave.
On the cRIO, in my LabVIEW application, I have created an I/O server - Modbus Slave. Using shared variables I write values to specific holding registers on the Modbus Slave.
The Modbus Master obtains the values from these registers using function code 0x03, read holding register - this works correctly. However, when the Modbus master query registers that I have not defined, the I/O server on the cRIO replies with a register value of 0, instead of Illegal Data Address. It seems like when using this I/O server, all possible Modbus registers is filled with the LabVIEW default value and the slave therefore always will reply with a value even if the register is not used.
My question is therefore, how can i change this? If the Master query a register that I am not writing to (and is therefore unused), I would like the slave to reply with "Exception Response" code 0x02 - "Illegal Data Address", and not just the value of 0.
/Simon

Performance of Modbus using DSC Shared Variables

   I'm fairly new at using Modbus with LabVIEW. Out of the roughly dozen tools and API's that can be used, for one project I'm working on I decided to try using Shared Variables aliased to Modbus registers in the project, which is a DSC tool. It seemed like a clever way to go. I've used Shared Variables in the past, though, and am aware of some of the issues surrounding them, especially when the number of them begins to increase. I'll only have about 120 variables, so I don't think it will be too bad, but I'm beginning to be a bit concerned...
   The way I started doing this was to create a new shared variable for every data point. What I've noticed since then is that there is a mechanism for addressing multiple registers at once using an array of values. (Unfortunately, even if I wanted to use the array method, I probably couldn't. The Modbus points I am interfacing to are for a custom device, and the programmer didn't bother using consecutive registers...) But in any case, I was wondering what the performance issues might be surrounding this API.
    I'm guessing that:
1) All the caveates of shared variables apply. These really are shared variables, it's only that DSC taught the SV Engine how to go read them. Is that right?
   And I'm wondering:
2) Is there any performance improvement for reading an array of consecutive variables rather than reading each variable individually?
3) Are there any performance issues above what shared variables normally have, when using Modbus specifically? (E.g. how often can you read a few hundred Modbus points from the same device?)
Thanks,
    DaveT
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.
Solved!
Go to Solution.

Anna,
    Thanks so much for the reply. That helps a lot.
    I am still wondering about one thing, though. According to the documentation, the "A" prefix in a Modbus DSC address means that it will return an array of data, whereas something like the F prefix is for a single precision float. When I create a channel, I pick the F300001 option, and the address that is returned is a range: F300001 - F365534. The range would imply that a series of values will be returned, e.g. an array. I always just delete the range and enter a single address. Is that the intention? Does it return the range just so you know the range of allowed addresses?
   OK, I'm actually wondering two things. Is there a reason why the DSC addresses start with 1, e.g. F300001, instead of 0, like F300000? For the old Modbus API from LV7, one of the devices we have that uses that API has a register at 0. How would that be handled in DSC?
Thanks,
    Dave
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

IMC Performance at a Glance

Hi,
Does anyone know if it is possible to edit the default "Performance at a Glance" view such that it displays a trend line for for interface statistics (really only want bit/s in and out) instead of a data grid?
I can't seem to see an obvious (or non-obvious) way from the doco or from within IMC itself.
A trend line would be more helpful for me. It would be nice to be able to create custom PaaG views that could then be applied to multiple devices as a template.
-Felipe Avelar-
Copy By "MartiBarber"

Anna,
    Thanks so much for the reply. That helps a lot.
    I am still wondering about one thing, though. According to the documentation, the "A" prefix in a Modbus DSC address means that it will return an array of data, whereas something like the F prefix is for a single precision float. When I create a channel, I pick the F300001 option, and the address that is returned is a range: F300001 - F365534. The range would imply that a series of values will be returned, e.g. an array. I always just delete the range and enter a single address. Is that the intention? Does it return the range just so you know the range of allowed addresses?
   OK, I'm actually wondering two things. Is there a reason why the DSC addresses start with 1, e.g. F300001, instead of 0, like F300000? For the old Modbus API from LV7, one of the devices we have that uses that API has a register at 0. How would that be handled in DSC?
Thanks,
    Dave
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

Performance of intel chipset.

Sir,
Please give me a detailed view of performance, heat generated during operation of various chipset of intel i3 processors.

Anna,
    Thanks so much for the reply. That helps a lot.
    I am still wondering about one thing, though. According to the documentation, the "A" prefix in a Modbus DSC address means that it will return an array of data, whereas something like the F prefix is for a single precision float. When I create a channel, I pick the F300001 option, and the address that is returned is a range: F300001 - F365534. The range would imply that a series of values will be returned, e.g. an array. I always just delete the range and enter a single address. Is that the intention? Does it return the range just so you know the range of allowed addresses?
   OK, I'm actually wondering two things. Is there a reason why the DSC addresses start with 1, e.g. F300001, instead of 0, like F300000? For the old Modbus API from LV7, one of the devices we have that uses that API has a register at 0. How would that be handled in DSC?
Thanks,
    Dave
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

Performance of Spotify on BB

I have an 9320 and 8520.
Both are very frustrating to sync playlists with.
It seems intermittent, delayed, often doesn't work, when you offline a playlist.
I have worked with Spotify, reset devices, with patience, resetting playlists, rebooting, I can sometimes get a playlists loaded for a while.
Has anyone else a better experience? I tell you that android works super fast and has no such trouble. Is there a BB which has spotify superfast as you'd expect?
Thanks ...love BB but got to make it work ...

Anna,
    Thanks so much for the reply. That helps a lot.
    I am still wondering about one thing, though. According to the documentation, the "A" prefix in a Modbus DSC address means that it will return an array of data, whereas something like the F prefix is for a single precision float. When I create a channel, I pick the F300001 option, and the address that is returned is a range: F300001 - F365534. The range would imply that a series of values will be returned, e.g. an array. I always just delete the range and enter a single address. Is that the intention? Does it return the range just so you know the range of allowed addresses?
   OK, I'm actually wondering two things. Is there a reason why the DSC addresses start with 1, e.g. F300001, instead of 0, like F300000? For the old Modbus API from LV7, one of the devices we have that uses that API has a register at 0. How would that be handled in DSC?
Thanks,
    Dave
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

ActiveX performance

I need to invoke methods in a labview application from visual C. It
seems that ActiveX is the best canidate. I'm concerned about the impact
of the ActiveX 'call' method on the performance of the LV application.
For example, if there are other threads running do they all block until
the 'call' completes ?
Chris Timossi
Lawrence Berkeley Laboratory

Anna,
    Thanks so much for the reply. That helps a lot.
    I am still wondering about one thing, though. According to the documentation, the "A" prefix in a Modbus DSC address means that it will return an array of data, whereas something like the F prefix is for a single precision float. When I create a channel, I pick the F300001 option, and the address that is returned is a range: F300001 - F365534. The range would imply that a series of values will be returned, e.g. an array. I always just delete the range and enter a single address. Is that the intention? Does it return the range just so you know the range of allowed addresses?
   OK, I'm actually wondering two things. Is there a reason why the DSC addresses start with 1, e.g. F300001, instead of 0, like F300000? For the old Modbus API from LV7, one of the devices we have that uses that API has a register at 0. How would that be handled in DSC?
Thanks,
    Dave
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

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

Floating point number using Modbus RTU DSC LV 8.2

I'm reading temperature from a Modbus conrolled device. I need to convert a temperature value (17053) read as a double type Shared Variable (SV) and convert it to ieee 754 type to show temp of 79 deg F as shown on the control front panel.
I'm using DSC module LV 8.2. I'm wondering if the conversion is already done in DSC LV 8.5???

seem to find my own answers after putting the post....
I use a typecast to single but I had to change the double to 16 bit integer for the type cast to convert correctly.... see attached png
Attachments:
ModbusSVFloat.PNG ‏28 KB

Dsc module modbus server handling uint8 variables

Hello!
I have a problem with handling Modbus uint8 variables in the dsc module . Unit8 Shared variables
are available in labview but Modbus i/o server Unit8 variables are not:
http://zone.ni.com/reference/en-XX/help/371618J-01/lvmve/dsc_modbus_using/
In our controller we split some 16 bit modbus registers into two 8 bit variables to pack some more usefull data in there.
All of my shared variables are running nicely in the shared variable engine but I've no way of
easily binding them to my Modbus i/o server uint8 variables easily.
Any ideas?
I like the auto-scaling logging and binding of the DSC module shared variables
so I want to avoid some manual labview processes.
I want to view all shared variables in my front ponel at run time. I have 300+ variables so I'm trying to avoiding manual one-off hacks.
James

jamesy777,
The reason Unit8 variables are not available in the Modbus I/O sever is the nature of the I/O server data types compatible with the registers. If you’re writing to two registers, you can just read those two separate registers as U16s in LabVIEW. Otherwise, if you’re writing to the upper and lower half of the register, you can split the register into its 8-bit halves using the Split Number function in LabVIEW.
Split Number Function - http://zone.ni.com/reference/en-XX/help/371361L-01/glang/split_number/
Regards,

Using Modbus TCP I/O Server with new DSC Shared Variables in LabVIEW 8.6

Hello,
I'm using LabVIEW 8.6 and want to communicate with a Beckhoff BK9000 Ethernet TCP/IP Bus Coupler via Modbus TCP. Instead of using the NI Modbus Library, I've tried the new LabVIEW 8.6 feature "DSC Shared Variables" as described at the bottom of this page: Latest NI LabVIEW DSC Module Features and Demos. Reading of analog input bus terminals works fine. However, I haven't figured out yet how to write on an anolog output bus terminal with these shared variables.
It's about a 16 bit analog output and I need to write to the registers 0x1121 and 0x0801. It works with the NI Modbus Library (just using function code 6 and choosing the registers), but on the other hand I don't know which shared variables I have to choose for these registers. I've tried several data items (e.g. 400001 upwards as well as 402049 for 0x0801) but none of them worked. I would be glad for a short explanation - thanks in advance for your support!
Regards
utechle

The Beckhoff documentation says, that holding registers start with 0x0800. I've checked this by using the NI Modbus Library. I used the "MB Ethernet Master Query.vi" togehter with the function code 6 for "Write Single Registers", changed the settings of the starting address to hexadecimal view and entered 801 (since it starts with a control byte in 0x0800 and the data out word follows in 0x0801). Furthermore, I had to address register 0x1121 in the same way for resetting the watchdog. As I've mentioned in my first post, this method works fine. However, I haven't found out yet which shared variables i have to use for accessing these registers.
On the other hand, it's no problem to read data from analog input bus terminals using shared variables. They start with 0x0000 (status byte) and 0x0001 (data in word) and I can read data with the shared variable and data item 300001, respectively.
Message Edited by utechle on 01-27-2009 11:12 PM

Dsc modbus - Serial communication input/holding registers

Hello,
I am trying to create a labview application to act as a Modbus master and control multiple stepper motors. I have the DSC module in labview and am using a serial communication with an RS-485 converter. I have followed this guide: http://www.ni.com/white-paper/13911/en/ However, the driver I am using does not support coils, it only uses input and holding registers and I have not found a guide or tutorial that shows me how to create a labview application that can read and write to a specific address. For now all I want to do is turn the motor on and off using labview. I have used a modbus simulator to communicate with the driver and can do everything I want to do through the simulator. I can not get labview to do anything for me. I would be very happy if someone could direct me to a tutorial that can help me understand labview dsc module for reading and writing to addresses using modbus.
Meesh

Ok, so this is really strange. I solved my problem in a round about sort of way. I'm using a modbus simulator (mdbus) to help me communicate with the driver/stepper motor so I know which address to use. But after I use the simulator I get a communication port error when I try to use Labview. It's like the port is locked in with the simulator and I can't end the connection and let Labview use the same communication port. I can't find anyway to fix the problem except going to this NI site: http://www.ni.com/download/labview-run-time-engine-6.1/746/en/ downloading this software and using the "repair" function. Then I can do a system restart and cycle the power on the driver/motor and then Labview with work again through the correct port. But if I need to use the simulator again then I have to go through this whole process again. Does anyone know what the heck is going on? Or if there is a better way to clear the communication port??

Howto choose modbus tcp functions with dsc 8.0.1 / DSC register numbering explanation

Hello,
after reading in the discussion forums I still cannot solve my DSC Modbus problems.
First I'm confused about register numbering.
Playing around with the registers, which the multiple variable shows, give me the finally success polling values:
Registers in device documentation: 0x0000 - 0x0007 Finally I found them on 300001-300008
Question: Why is the leading 3 needed....?
Sniffing with Ethereal shows me "function 4" is used for reading by Labview.
Question : Howto use Modbus function 3 or (for writing) 5, 6, 15, 16, (read and write) 23?
My biggest problem at the moment:
I want to read register 0x1010 = 4112d it contain a length of process data byte in packed format. Reading ends in exception 0x8BBB0005
Thanks in advance for an answer or just a link with similar problems

You have different types of registers inside a controller. 3xxxxx are input registers and 4xxxxx are holding/output registers. Check out the attached pdf file.Message Edited by unclebump on 07-26-2006 02:04 PM
Attachments:
PI_MBUS_300.pdf ‏173 KB

PLC con Modbus y DSC

Hola! Quiero comunicar un PLC de marca Phoenix Contact modelo ILC 130 ETH con Labview 2011 por Modbus Ethernet utilizando el toolkit DSC. Para hacer esto empece siguiento la siguiente guia:
http://www.ni.com/tutorial/13911/en/
Al hacerla recibo el siguiente mensaje de error
Error -1967353901 occurred at Shared Variable in Untitled Library 1:Untitled 1
Possible reason(s):
LabVIEW DSC: (Hex 0x8ABC8FD3) The Modbus I/O server failed to connect to the Modbus Ethernet slave device. Ensure that the Modbus Ethernet slave device works properly and that the connection between the Modbus master and slave devices is configured correctly.
Del manual del PLC saque la siguiente tabla de modbus
Probe con varios valores pero con todos obtengo el mismo error.
Es la primera vez que uso Labview y por lo tanto no tengo muchas armas para solucionarlo. Alguna ayuda?
Saludos

Bruno:
Agradesco tu respuesta.. ahora he intentado lo que me has dicho y funciona... pero una pregunta mas, de esta manera el acceso compartido al puerto serie por donde sale la comunicacion lo negocian entre los tres server I/O o yo debo definir un esquema en donde quede perfectamente definido cuando acceder a cada uno de los dispositivos para que no haya conflictos en la comunicacion?. Te consulto esto mas que nada porque he intentado definiendo variables globales de escritura a los dispositivos en forma paralela o simultanea y aveces a alguno de los dispositivos esclavos no le llega la informacion que le envio..
Atte..
Adrian.-

Modbus DSC

Similar Messages

Maybe you are looking for