Announcement

Collapse
No announcement yet.

Turn an led on - Modbus and Labview

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts


  • Turn an led on - Modbus and Labview

    I am in the processing of learning/integrating Labview with a DL205 (DL260 CPU). I want to start simply (so I thought) and turn on/off the led indicators on an F2-16TD2P output module. I have available (as input) a "coils to write" as toggles and "starting address" field from within Labview. I do not know what the "starting address" (or any addresses for that matter) are of the outputs on this module (or inputs on the D2-16ND3-2). I am reasonably confident that I am communicating with the PLC from Labview (I can both ping the PLC from a command prompt as well as when I run my Labiew test see the "ACTIVE" led on the ECOMM unit running).

    I have been cramming trying to figure this all out but I have to figure that there is a simple "memory map" of the adresses for these things. I am coming to terms with the "terms" used for PLC's (again, all new to me) so any help is appreciated.

    I'd also like to hear from anyone else that has been through this "Modbus/Labview" integration. So far, I am not using OPC or anything like that; just the free VI's available for Modbus. I think (shortly) that I will be moving to one form or another (KepDirect or NI) server... I need to do it via Modbus first as some of the other components in the system may not have OPC available. Right now, I'd really like to turn an led on and off...

    Thanks in advance.

    MT


  • #2
    Try these two references:

    http://support.automationdirect.com/...odbus_xref.pdf

    and

    http://support.automationdirect.com/...conversion.xls

    for conversion between the AD references and the cooresponding Modbus references.
    thePLCguy

    Bernie

    Comment



    • #3
      I have been working with Labview Modbus Library to link with C-more panels,terminator field I/o and PLC's.So what are you trying to accomplish with integrating the 2?

      Comment



      • #4
        From within Labview I want to set/reset (on/off) "OUT 0 -A" on the F2-16TD2P module in a DL205. If you look at the Labview "MB Ethernet Example Master.vi" there are toggle switches for "Coils to Write". I want to turn on/off the "OUT 0 -A".

        Near as I can tell this requires the address of this "bit" (coil?). I've looked at the conversion spreadsheet but these do not correlate to what I am seeing.

        Comment



        • #5
          Just to put in a few words on this. Writing directly to outputs usually doesn't work too well. The communications happens at the start of scan. If the PLC writes to the output coil in the program, then whatever the communications does to the coil is lost.

          The best solution is to write to internal coils (C bits) that are dedicated to the LabView app (IE not turned on or off by anything else) and use these to trigger the output.

          Lastly the PLC requires an END statement and must be in RUN for the output to turn on.

          You may already know these things, but I thought I'd state them for those reading along who haven't done this sort of thing before.
          If you have an urgent issue, please contact AutomationDirect's Technical Support team.

          AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

          Comment



          • #6
            Thank you!

            Thank you for the reply. I know nothing about these things (PLC) and this is exactly the kind of information that I need. I am an electronics engineer and got "thrown" into working on this (because all electronics and programming is the same ). I program microcontrollers in assembly language was given the task of integrating Labview with a system that uses 8 DL205 PLC systems.

            The task at hand is to create a Labview front-end that allows the user to read/modify register values for dwell (for example) etc. If you were to take the "Labview" perspective it's as simple as firing up a VI (Labviews "virtual intruments") and filling in the boxes. As I am finding out this is not nearly the case...

            Usually when bringing up a new microcontroller design we take a very simple path; blink an led. If you can blink an led then it tells you that the communication path is good, you can load the program and see a result. I thought I would take the same approach with this. If I can turn on the led on the output module (you get the idea). I looks like this isn't going to be close to the same case, which raises a huge pile of questions (or huge pile of something else). Please bear with me...

            1.) If you have to have a program running on the PLC then that program must have "hooks" in it to deal with communication (in this case Modbus). Is this correct? If so...

            2.) I've been looking at OPC Client/Server integration. It seems that I would need OPC server from National Instruments as well as the OPC client from Automation Direct (Kepware?). From what I've gathered this "breaks out" all the I/O with names (tags) for the individual I/O. My thinking was that once I had access to each I/O I could then read/write from these at will. It seems that this is not the case; a program must be running on the PLC and needs hooks for this communication (?).

            3.) To sum up working with the PLC's; a program has to be running that interfaces "to the outside world"? For those that work with these things every day this may sound like a stupid question but for those of us (me) that work at the bit level on the hardware this is not the case; I can go in and affect any register at will.

            Much of the PLC world is foreign to engineers like myself. Not to sound ignorant, but examine the situation that I have in front of me. I've been given the task of integrating the PLC's using Labview. If you ask the Labview people they say "sure, just use the Modbus VI's". Follow the example programs, it's a no-brainer". Fire up the example, configure the IP address and off and running... no, doesn't work. Now that you've told me that a program has to be running (on the PLC) I can understand why. However, from my perspective and experience this is counter-intuitive (i.e. if I am "directly talking to the hardware" no program should be running). The Labview stuff said NOTHING about having to have a program running...

            It may sound like rambling but I think there are a lot of people in my position. I would like nothing more than to bring in a system integrator that has been through all this and knows this stuff. But as we all know, the economy, limited budgets, limited staff, etc. are demanding that internal staff take on these things (and ownership).

            If someone would be willing, it would be a HUGE benefit to someone like me to see a break-down, road map, flow-chart - anything that shows on the system level how this works out. For example, if I follow what was said, I must have at the minimum a program running on the PLC that exposes the registers (controlling coils?) that are being addressed from within Labview. If I had known this a couple of days ago I wouldn't be peeling sections of my scalp off (all the hair is gone)... IDEALLY an example program that runs on the PLC documented such that it says "you write to "x" register to turn on/off "bit x". Hell, once I get through this this I'd be happy to post exactly that...

            Right now, I have to get a book and learn to write a PLC program...

            Thanks again.

            Comment



            • #7
              Originally posted by pioneer View Post
              1.) If you have to have a program running on the PLC then that program must have "hooks" in it to deal with communication (in this case Modbus). Is this correct? If so...
              The 'hooks' are already there and written into the PLC firmware. The absolute minimum that is required is an END statement and for the PLC to be put in RUN mode. With no program other than an end statement the PLC will act like dumb I/O that you can read and write to via MODBUS or an OPC server.


              2.) I've been looking at OPC Client/Server integration. It seems that I would need OPC server from National Instruments as well as the OPC client from Automation Direct (Kepware?). From what I've gathered this "breaks out" all the I/O with names (tags) for the individual I/O. My thinking was that once I had access to each I/O I could then read/write from these at will. It seems that this is not the case; a program must be running on the PLC and needs hooks for this communication (?).
              OPC is an industrial standard for devices to talk to a software package. Think of it as an application layer. Only one OPC server would be needed from any of a various number of suppliers. The only requirement would be that the OPC server is capable of communicating with an AutomationDirect DL205 series PLC. Once you have the OPC server setup and communicating to the PLC, it will supply the Client (in this case Labview) with tags to be able to monitor and control the PLC.

              Again, the minimum program is to have an END statement and the PLC must be in the RUN mode. Once this is accomplished, you could read and write to the PLC from the PC.

              3.) To sum up working with the PLC's; a program has to be running that interfaces "to the outside world"? For those that work with these things every day this may sound like a stupid question but for those of us (me) that work at the bit level on the hardware this is not the case; I can go in and affect any register at will.
              Correct. The PLC typically has a program that is written in Relay Ladder Logic (RLL) that processes the inputs to the PLC and turns on outputs to cause events in the real world to happen. This program can be either self contained and have no external communications or it can be monitored or controlled by an outside source.

              As far as learning about PLC's, might I suggest heading over to PLC's.net? Phil Melore has written a couple of general purpose books that teach the basics of programming. Also his site has quite a bit of online learning available as well.
              Last edited by Do-more PE; 05-26-2010, 11:59 AM.
              If you have an urgent issue, please contact AutomationDirect's Technical Support team.

              AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

              Comment



              • #8
                Ron Beaufort's training videos on Youtube are also a good introduction into many of the concepts of PLCs. He takes the time to explain how things really work and how that might conflict with someone's current knowledge of PLC's. It gets down to basics in a way that you as an assembly programmer might appreciate.

                http://www.youtube.com/user/RonBeaufort?blend=2&ob=1

                Note that his videos are directed at Allen Bradley PLCs, but generally the concepts apply to AD PLCs as well. For reference, the DL line of AD PLCs will function the same as the SLC line from AB (sychronous IO). Also note that the instructions in the AD software will have different names, but all the instructions that Ron uses should be there. (OTL = SET, OTU = RST, etc...) Descriptions of the instructions available in the AD PLCs are available in the PLC CPU manual. Most of the instructions that you are likely to need (I'm guessing) will be covered in chapter 5.

                http://www.automationdirect.com/stat...er/d2user.html

                Brian

                Comment



                • #9
                  Great info!

                  Thanks very much for both replies; this has been more helpful than you know. I'm going to the PLC.net site and work from there. I'm blocking out the next week just for this...


                  EDIT: Checking out PLCs.net. What do you guys think of the book they have "Your Personal PLC Tutor...A Guide to Understanding PLCs"? I'd order one today.
                  Last edited by pioneer; 05-26-2010, 01:59 PM.

                  Comment



                  • #10
                    I haven't read it myself, but it regularly gets good reviews on the forum.

                    http://www.plctalk.net/qanda/showthread.php?t=53691

                    If you have more questions while you are working next week, feel free to post them here or at plctalk.net; I'm sure someone will help.

                    Brian

                    Comment



                    • #11
                      Originally posted by bfitz View Post
                      I haven't read it myself, but it regularly gets good reviews on the forum.

                      http://www.plctalk.net/qanda/showthread.php?t=53691

                      If you have more questions while you are working next week, feel free to post them here or at plctalk.net; I'm sure someone will help.

                      Brian
                      Thanks very much, will do.

                      Comment



                      • #12
                        Getting closer...!

                        The day of reading and "programming" is paying off to some extent. I wrote a few simple programs to get the feel of things; reading an input, write to an output. So far so good...

                        I ran my Labview program and could turn on/off outputs from Labview (Bank A and B on the F2-16TD2P). I'm a little confused about this operation. Initially my PLC program was a simple "-|X0|-(Y0)" - END statement. When I ran this with the Labview program I could toggle all of the outputs EXCEPT Y0 (i.e. Y1 would toggle on/off, Y2, etc.) When I made the PLC "program" nothing but an END statement I could toggle all outputs. Any outputs being "used" in the program would not respond to the Labview commands. This isn't a total loss as I am learning how these things are addressed and such. What throws me is the previous post that "the hooks are in the firmware" to allow communication via Modbus. What concerns me is that we will have programs running on the machine with registers that will be monitored and if need be changed on the fly (Dwell time for instance). I *guess* I thought once I knew where these registers are and can read/write to them it would be "relatively" straight-forward to write to them. But from this little experiment it looks like if the register is being used on the PLC it is blocked from outside change. I'm going to continue forging ahead with this... I did order the PLCs.net books (workbook and info book together). They should be here in a day or two.

                        The big question is; am I really "sortof" wasting my time with this? Should I jump and get an OPC server? Does using the OPC server alleviate some (or most) of this stuff? I've been reading about these things and if you believe whats said 100% they practically do everything for you... Or is it a case of "if you don't get what's going on with Modbus you're screwed going to OPC". One of the other things I keep seeing is bottle-neck and such of Modbus. We're running 14 PLC's (mostly AD stuff, one Unitronics HMI and some Emerson Servo drives). These have OPC available (for free?), though they still have Modbus. I have a bit of a budget to get the OPC stuff if it will really get to the core of the issue.

                        Any advice is gladly welcomed.

                        Thanks.

                        Comment



                        • #13
                          The PLC has it's own program to run. Since x0 isn't on, the PLC keeps turning Y0 back off.

                          If you are trying to adjust a timer value you will put a timer (TMR) in the plc program. For the setpoint use a valid VMEM register (say v2000). As long as nothing else in the plc program forces a change to this register, the number written from labview will be left alone at that address and will be the timer preset.

                          Hope this helps a little, or gets you pointed in the right direction,
                          Bob

                          Comment



                          • #14
                            Originally posted by ADC App Assist View Post
                            Just to put in a few words on this. Writing directly to outputs usually doesn't work too well. The communications happens at the start of scan. If the PLC writes to the output coil in the program, then whatever the communications does to the coil is lost.

                            The best solution is to write to internal coils (C bits) that are dedicated to the LabView app (IE not turned on or off by anything else) and use these to trigger the output.
                            I just wanted to set this back in front of you as well, if you want to control outputs from labview.
                            Bob

                            Comment



                            • #15
                              Originally posted by pioneer View Post
                              The day of reading and "programming" is paying off to some extent. I wrote a few simple programs to get the feel of things; reading an input, write to an output. So far so good...

                              I ran my Labview program and could turn on/off outputs from Labview (Bank A and B on the F2-16TD2P). I'm a little confused about this operation. Initially my PLC program was a simple "-|X0|-(Y0)" - END statement. When I ran this with the Labview program I could toggle all of the outputs EXCEPT Y0 (i.e. Y1 would toggle on/off, Y2, etc.) When I made the PLC "program" nothing but an END statement I could toggle all outputs. Any outputs being "used" in the program would not respond to the Labview commands. This isn't a total loss as I am learning how these things are addressed and such. What throws me is the previous post that "the hooks are in the firmware" to allow communication via Modbus. What concerns me is that we will have programs running on the machine with registers that will be monitored and if need be changed on the fly (Dwell time for instance). I *guess* I thought once I knew where these registers are and can read/write to them it would be "relatively" straight-forward to write to them. But from this little experiment it looks like if the register is being used on the PLC it is blocked from outside change. I'm going to continue forging ahead with this... I did order the PLCs.net books (workbook and info book together). They should be here in a day or two.

                              The big question is; am I really "sortof" wasting my time with this? Should I jump and get an OPC server? Does using the OPC server alleviate some (or most) of this stuff? I've been reading about these things and if you believe whats said 100% they practically do everything for you... Or is it a case of "if you don't get what's going on with Modbus you're screwed going to OPC". One of the other things I keep seeing is bottle-neck and such of Modbus. We're running 14 PLC's (mostly AD stuff, one Unitronics HMI and some Emerson Servo drives). These have OPC available (for free?), though they still have Modbus. I have a bit of a budget to get the OPC stuff if it will really get to the core of the issue.

                              Any advice is gladly welcomed.

                              Thanks.
                              This is in fact a case of it won't matter whether you are using OPC or Modbus. You have setup an instance where Labview and the PLC program are fighting for control of Y0. Because of the way the PLC processes information, it will always win.

                              See page 3-19 in the manual for a visual on this. It processes communications requests first, then it executes the ladder program, then it updates the outputs. What is happening in your |X0|--(Y0) program is this:
                              The PLC receives the request from Labview to turn on Y0 (bit status 1), so it places a 1 in the proper position in the output image register (_NOTE_: the output does NOT turn on at this time.) The PLC then processes the Ladder program. X0 is off, so it writes a 0 to the Y0's output image register. Note that even though X0 is off, something happened; this trips up a lot of people with a computer programming background. Finally, the ladder program is complete so it copies the output image register to the actual outputs (this is the step when the outputs actually turn on or off.)

                              So, you need to get Labview and the PLC to stop fighting. One way to do this is to just have an END statement for a program. If the PLC has no instructions, it can't fight. This is not, however, a popular option. You may need the PLC to respond to a break in communications. Communications protocols may be too slow to respond to the process remotely. You get the idea.

                              So, instead of using Labview to write directly to the outputs, most people will use it to write to an unused internal register like C0. Then in the PLC program you would have |C0|---(Y0) as a rung. Whenever C0 is on, Y0 will be on. You can also combine C0 into more complex logical structures. Imagine X0 is a safety permissive that is wired to the PLC and must be on to let the process run when Labview calls for it. Labview will request the process to run by turning on C0. Your rung would look like |X0|--|C0|---(Y0). Now, both the safety permissive and the Labview request have to be present for the process to run.

                              In the end, its all about getting them to work together to accomplish what you want.

                              If you have other questions, feel free to ask. At this point, it might be good to start laying out what you want the PLC to actually do (versus what Labview will be responsible for) and you can start writing the PLC program.

                              Also, I see Bob types faster than I do.

                              Brian

                              Comment

                              Working...
                              X