I received some very nice answers from the following wireworkers: Khalid Ansari Paul Sullivan Eric Scott ==========================================================================
My own lessons learned: MODBUS is not like some serial protocols that are essentially a simple language for communicating with a controller. MODBUS is less of language and more a way to set parameters of a controller directly (which includes RUN and STOP). With MODBUS you send a sequence of numbers that starts the serial transmission, IDs the device (MODBUS can communicate with multiple devices on a serial network a la RS485), indicates whether the command is a read or a write, IDs the memory location, for write ops sends the new values, sends a redundancy check (LRC or CRC depending), and terminates the transmission. The "syntax" of a read op is slightly different. It will be necessary to have documentation of the controller memory addresses. You cannot even guess what to send otherwise (with a ANSI x3.28 you might actually strike a up a conversation on the fly, but not with MODBUS). I use MODBUS ASCII (as opposed to MODBUS RTU the standard when communicating between a PLC and a MODBUS device). The redundancy check is LRC, longitudinal redundancy check. This was foreign to me and is a little tricky, you sum up the hex representation of the sequence to be sent, calculate the 2s compliment of that, discard the leading Fs saving the last 2 digits, and adding them to the end of the sequence before terminating with a CR and LF. In LV the 2s compliment is very easy to compute - the hex integer is wired through a NOT function, that result is added to 1, and then the leading Fs are subtracted. I didn't stick my head into the CRC method. While there are apparently some pre-existing VI's and other helpful routines out there (some free some costly), for simple control such as I needed a simple VISA communication session is all that is necessary. Using VISA I can turn the spin and stop the drive and change the speed from a VI. If necessary I could also configure the drive in all its gory detail, but this can be done by other means and is not done often so I doubt a VI wil ever be written by me to do that. It is worth noting that his communication is much faster (orders of magnitude) than I had seen with other serial com methods, part of that is baud rate but not all. The contoller on the receiving end doesn't have to do much interpreting of the sequence it is sent, and the overhead at that end must be low. Please feel free to contact me at [EMAIL PROTECTED] if you think I can be helpful to you. If I can't spare the time I will tell you so. ========================================================================== >From Khalid Ansari: Modbus is a simple, open communication protocol originally created by Modicon/Schneider Electric. Though it has been widely used by others and considered "open" for several years, only last week did they give up their copyrights for it. The Modbus protocol can be found here: http://www.modicon.com/techpubs/toc7.html Modbus-IDA now maintains it: www.modbus.org There are several options for communicating to Modbus devices from LabVIEW: 1. Write your own driver ------------------------- Modbus is a simple protocol so you can write a driver, or part of it that you need in LabVIEW. You'll use serial/VISA as with any other serial driver (note that there's a Modbus-TCP protocol as well). The protocol specification above should give you an idea of what's involved. In addition, C/C++ and VisualBasic APIs are also available. 2. Use existing LabVIEW VIs ---------------------------- There are several VIs available out there (none from NI though; some are from Alliance members). Some of these are free: http://www.air.nl/nlibrary/modbus_vi.html http://www.users.globalnet.co.uk/~pseudo/downloads.html (see Eurotherm; uses Modbus) http://www.softwarewithrelish.com/specs/BusVIEW.html http://www.ewebsite.nl/eng/html/modbus.html http://www.saphir.fr/SAPHIRnet/API/ModBusVIEW/index.htm http://labview.citeng.com/pagesEN/products/modbus.aspx Etc... 3. Use an OPC Server --------------------- As Modbus is heavily used in Industrial Automation, there are several OPC Servers available for it, including one from NI: http://ni.com/opc/opcservers.htm Here you'll find a free one from Matrikon: http://www.matrikon.com/drivers/FreeDownloads.asp In LabVIEW, as you very likely know, to talk to an OPC Server, you would either use DataSocket, or use the DSC module which has built-in support for OPC, and is recommended over DataSocket especially when you have a bunch of IO points. 4. Use an ActiveX Server ------------------------- There are ActiveX Servers available which talk Modbus. http://www.automatedsolutions.com/products/modbusrtu.asp A Google search returns a bunch for these. In your case, the turning of the motor, reading its speed, etc., really is writing and reading of the correct coils (discrete points), and registers. These will have "addresses" which the GS2 documentation should provide. ======================================================================= >From Paul Sullivan: Modbus is a simple, open communication protocol originally created by Modicon/Schneider Electric. Though it has been widely used by others and considered "open" for several years, only last week did they give up their copyrights for it. The Modbus protocol can be found here: http://www.modicon.com/techpubs/toc7.html Modbus-IDA now maintains it: www.modbus.org There are several options for communicating to Modbus devices from LabVIEW: 1. Write your own driver ------------------------- Modbus is a simple protocol so you can write a driver, or part of it that you need in LabVIEW. You'll use serial/VISA as with any other serial driver (note that there's a Modbus-TCP protocol as well). The protocol specification above should give you an idea of what's involved. In addition, C/C++ and VisualBasic APIs are also available. 2. Use existing LabVIEW VIs ---------------------------- There are several VIs available out there (none from NI though; some are from Alliance members). Some of these are free: http://www.air.nl/nlibrary/modbus_vi.html http://www.users.globalnet.co.uk/~pseudo/downloads.html (see Eurotherm; uses Modbus) http://www.softwarewithrelish.com/specs/BusVIEW.html http://www.ewebsite.nl/eng/html/modbus.html http://www.saphir.fr/SAPHIRnet/API/ModBusVIEW/index.htm http://labview.citeng.com/pagesEN/products/modbus.aspx Etc... 3. Use an OPC Server --------------------- As Modbus is heavily used in Industrial Automation, there are several OPC Servers available for it, including one from NI: http://ni.com/opc/opcservers.htm Here you'll find a free one from Matrikon: http://www.matrikon.com/drivers/FreeDownloads.asp In LabVIEW, as you very likely know, to talk to an OPC Server, you would either use DataSocket, or use the DSC module which has built-in support for OPC, and is recommended over DataSocket especially when you have a bunch of IO points. 4. Use an ActiveX Server ------------------------- There are ActiveX Servers available which talk Modbus. http://www.automatedsolutions.com/products/modbusrtu.asp A Google search returns a bunch for these. In your case, the turning of the motor, reading its speed, etc., really is writing and reading of the correct coils (discrete points), and registers. These will have "addresses" which the GS2 documentation should provide. ========================================================================== ==== Paul Sullivan very kindly searched the archives and prepared a collection of comments. I will omit them to save BW and hard disc space. ========================================================================== ==== >From Eric Scott: We use MODBUS around here, and at first it seemed daunting. If taken down to the basic building block, it becomes fairly easy to understand. It is basically just serial read/write to specific memory locations. The serial string syntax is comprised of Read Commands: 1. The slave unit ID (8-bits) 2. The MODBUS function number (8-bits) 3. The memory address (16-bits) 4. The length of the address space (16-bits) 5. Checksum (16-bits) Write Commands: 1. The slave unit ID (8-bits) 2. The MODBUS function number (8-bits) 3. The memory address (16-bits) 4. write data (16-bits) 5. Checksum (16-bits) The memory space and write data will vary between manufacturers, but will be given in their documentation. The basic syntax is consistent though. Below is a link to an excellent modbus reference. After looking through this manual, I found modbus MUCH easier to deal with. Since the serial syntax is broken up into byte sections, you can convert the string to U8 array and build or parse from there. http://honeywell.silverw.com/docs/51-52-25-66.pdf Especially helpful was pages 5-6 and 15-28. Perhaps the most difficult to understand was the CRC algorithm and the IEEE754 math required on some of the response data in functions 03 & 04. I can send you CRC and IEEE754 sample vis for you to use and learn if you would like. BTW: There are two types of MODBUS protocols, 8-bit RTU and 7-bit ASCII. I only have experience with RTU. ========================================================================== ==== ORIGINAL QUESTION: I could really use a shortcut to running my new GS2 motor drive from Automation Direct. It has an RS232 interface and can be communicated with via MODBUS. The normal path to running these drives is via a PLC. Since I have a PC with a serial port, I wonder why I would care to use a PLC. I would like to command it directly with LV. I would like to do some very simple things like: turn the motor on verify that it is on or up to speed get the motor speed turn the motor off verify that the motor is off Unfortunately, MODBUS is one of those acronyms I have always read over quickly with out comprehending. Any advise or snippets will be appreciated. Michael E. Ross Senior Design Engineer Standard Motor Products, Inc. Engine Management 2717 Commerce Road Wilson, NC 27893 (252) 234-5821 office and voice mail (252) 234-2000 x4054 laboratory (no voice mail) (252) 234-5801 reception and paging (252) 234-1900 fax
