Announcement

Collapse
No announcement yet.

RS-485 Communications W/Click

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


  • RS-485 Communications W/Click

    Hi All,

    I've been on the verge of starting a new project, but due to priorities have not yet gotten knee deep in PLC's yet. The project I am planning to work on involves communicating with a laser system via RS-485. It seems mostly straightforward with one exception: at the end of each string, I need to calculate a BCC to send out with the string. Can I accomplish this using a Click?

    To keep the project moving, I had already purchased the click along with the add-on modules that I thought I would need. As I begin to learn more and more about this project, I'm beginning to wonder whether or not my purchase was premature. I am also planning on communicating with a stepper drive using RS-232 to send ASCII commands. Would a different PLC be better than the Click for this project? I don't want to go too far down the programming road only to find out that I'm using the wrong equipment for it.

    This forum has been a great source for knowledge and information. I'm hoping it continues that tradition with my questions!


  • #2
    bgirouard, it sounds like you are communicating via ASCII strings with the laser system when you say "at the end of each string". Is this correct? You are also using ASCII strings to communicate with stepper.

    We did a project communicating with (2) different devices (stepper drive and power supply) using 2-way (command/response) ASCII communications. We went with the DL205 and the CoProc module. I would recommend looking at the CoProc module for multi-port, 2-way ASCII communications. The CoProc module is also available for the DL06 and the DL405. The CoProc uses RS232 ports, so a RS232/485 FA-ISOCON would be needed.
    Last edited by KPrice; 06-14-2010, 10:50 AM.

    Comment



    • #3
      Depending on the nature of your BCC another advantage of the CoProc is that its ERRCHK function will generate the checksum character(s).
      thePLCguy

      Bernie

      Comment



      • #4
        Originally posted by KPrice View Post
        bgirouard, it sounds like you are communicating via ASCII strings with the laser system when you say "at the end of each string". Is this correct? You are also using ASCII strings to communicate with stepper.

        We did a project communicating with (2) different devices (stepper drive and power supply) using 2-way (command/response) ASCII communications. We went with the DL205 and the CoProc module. I would recommend looking at the CoProc module for multi-port, 2-way ASCII communications. The CoProc module is also available for the DL06 and the DL405. The CoProc uses RS232 ports, so a RS232/485 FA-ISOCON would be needed.
        As far as I can tell, all of the CoPro modules have at least one port that can be wired for RS485. I know the CoPro for the DL205 series has two ports that can be wired 232, 422, or 485.

        Brian

        Comment



        • #5
          bfitz, yes, you are right. Good catch. We use the FA-ISOCON even when RS485 is available for the isolation, on the DL260 for example. But still you are right - I don't know what I was thinking about.

          Comment



          • #6
            Thanks for the insights. I guess I'll have to put aside this Click that I already purchased for something else. I just wish I had looked into this a bit more, but I know I'll find another project to use this for.

            I found three DL205 units in our facility dated 10+ years ago that have not been used for at least a few years. There is a D240 CPU and two D250 (it's NOT a D250-1) CPU's. Are either of these CPU's worthwhile to use, or should I simply start over with them?

            Also, I noticed that the backplanes are old model numbers (two D2-04B and one D2-09B, again both WITHOUT the -1). As far as I can tell, the individual modules installed show the identical model numbering that is shown on AD's website.

            My question is: Should I bother using any of this equipment, or purchase a whole new round of components? Since these units and modules are noticably more expensive than the Click hardware, it would be nice to be able to re-use some equipment that would otherwise just collect dust before making its way to the trash/recycler.

            One thing for sure is that I need to purchse the new revision of DirectSoft, since what I have here is version 2.3 . I believe I will have to purchase the new software, since I cannot find any license key for this old software I have, and I cannot find the original invoice records from the original purchases.

            Again, thanks for the help to this point. I have a feeling you'll be hearing more from me as I try to wade through this whole project!

            - Brian G.

            Comment



            • #7
              If you purchased through ADC, we may be able to look up your purchase record for Directsoft. Just call in and ask. If not then you might have to repurchase, but it's worth the call.
              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
                I don't think that any of us responding to your original post meant to imply that what you are trying to do with the CLICK is impossible, just that we would likely have spec'd a DL PLC with a CoPro to handle the strings. Part of this recommendation is that we (or at least I) am more familiar with the DL and CoPro programming methods. I don't have any direct experience with the CLICK platform, and I'm guessing that bcarlton and KPrice have much more experience with the older platforms than with the CLICK.

                You may want to post more details on your setup (laser communications specifications, stepper comms specs, description of what else the PLC will be doing, etc.) and we (or someone more familiar with the CLICK) might be able to give you a better go/no-go indication. Edit: this info will also be useful in spec'ing a DL system in the event your CLICK won't work.

                Brian

                Comment



                • #9
                  You might not want to give up on the CLICK just yet. Are you communicating through MODBUS over one port and ASCII over the other? If so, the CLICK will work just fine. Actually, you can set the RS-485 and the RS-232 ports for either ASCII or MODBUS in the CLICK software so it should work.

                  Calculating the BCC still might be a problem, but if you can do the first steps of getting the 232 and 485 sending stuff to your stepper motor and laser system you might have a better understanding of what needs to be done to get the BCC stuff working, and be able to ask more precise questions on the forum. Also, you might have a better chance of saving a couple hundred dollars for your company by experimenting with the CLICK a little bit. The "SEND" and "Receive" commands are pretty basic so you should be able to get stuff being sent out it's ports pretty quickly.

                  Comment



                  • #10
                    I recommend keeping your options open. Experiment with the hardware you have in hand. Especially with what I have highlighted in red.

                    Originally posted by bgirouard View Post

                    To keep the project moving, I had already purchased the click along with the add-on modules that I thought I would need. As I begin to learn more and more about this project, I'm beginning to wonder whether or not my purchase was premature.
                    Without a doubt the 205 system has the most options available. But Szarman has a valid point.

                    Originally posted by Szarman View Post
                    Also, you might have a better chance of saving a couple hundred dollars for your company by experimenting with the CLICK a little bit. The "SEND" and "Receive" commands are pretty basic so you should be able to get stuff being sent out it's ports pretty quickly.
                    PERCUSSIVE MAINTENANCE: The fine art of whacking the devil out of an electronic device to get it to work again.

                    Vaughn

                    Comment



                    • #11
                      Thanks again guys for all the feedback, it’s very refreshing to see a thriving forum like this!

                      In general, this laser system is welding different cylindrical assemblies which will in turn require unique parameters to be defined for each. These parameters will be mostly involved with the laser system I’m using, and the stepper drive will only require speed and either a distance or time setting (not sure on this one yet).

                      The two primary devices I will be interfacing with is a stepper drive and a Miyachi Unitek laser system which uses RS485 commands, but more on that in a minute. The stepper drive is AD’s STP-DRV-4850 (ASCII). This is a very straightforward approach, and I’ve done some simple ladder programs to send commands to this drive, so I’m feeling pretty confident about that aspect.

                      The laser system is a little more involved. I’m planning on adjusting/setting several parameters via RS-485, as well as firing and stopping the laser system. There are several ASCII commands to send, but the general format is such: [STX] [laser data] [ETX] [BCC]. The laser data details are too much to post here (several pages of their documentation). It seems pretty straightforward, but for each parameter (there will be approx. 15-20 parameters to set) I need to adjust/change the above-mentioned string needs to be generated.

                      I am planning on tying this all together with a C-More panel for a clean interface, but I understand that I need to get the ‘guts’ taken care of first, and I’ll worry about that later on in this process. Ideally, I would like to have these parameters associated to one project name for the user to call up and load into the laser system; some kind of table or array of values, in essence. I’m not sure if this would be driven in the PLC or the C-More.

                      As I’ve been looking at this more, it seems to me that all this communications to the laser will be clogging up my Click programming, but this is to the untrained eye that is feeling a bit overwhelmed. I would like try doing some simple communication with the laser system, but I need to figure out how to best calculate the BCC with a Click, if it’s even possible.

                      For reference, I have the C0-02DR-D (RS-485 comm. Port), so I was planning on having one port for C-More/programming, one for stepper drive, and the RS-485 for laser comm. work.

                      Thanks again for all the comments!

                      Comment



                      • #12
                        The laser system is a little more involved. I’m planning on adjusting/setting several parameters via RS-485, as well as firing and stopping the laser system.
                        You may want to investigate using digital IO for firing the laser instead of communications. Serial comms can introduce a variable time delay between sending a command and command execution, especially if there happens to be noise on the line that garbles the communication. You may even want to use the stepper output to synchronize the laser firing to the stepper motion. I haven't used the steppers from AD (or any steppers for that matter); but it would be worth looking into, IMHO.

                        There are several ASCII commands to send, but the general format is such: [STX] [laser data] [ETX] [BCC]. The laser data details are too much to post here (several pages of their documentation). It seems pretty straightforward, but for each parameter (there will be approx. 15-20 parameters to set) I need to adjust/change the above-mentioned string needs to be generated.
                        Do you have a PDF you can share? If not, we will at least need the formula they are using for the BCC calculations and an example parameter. Another big question: will you be reading data from the laser as well as writing?

                        I am planning on tying this all together with a C-More panel for a clean interface, but I understand that I need to get the ‘guts’ taken care of first, and I’ll worry about that later on in this process. Ideally, I would like to have these parameters associated to one project name for the user to call up and load into the laser system; some kind of table or array of values, in essence. I’m not sure if this would be driven in the PLC or the C-More.
                        You have the correct mindset in the sense you should get all this working before adding the C-more. The exception is the recipe system, which is commonly handled in HMIs in the industry. Note that there are some instances where recipes are best handled in the PLC (multiple HMIs, SCADA access, etc.) where synchronizing all the recipes would be difficult.

                        As I’ve been looking at this more, it seems to me that all this communications to the laser will be clogging up my Click programming, but this is to the untrained eye that is feeling a bit overwhelmed. I would like try doing some simple communication with the laser system, but I need to figure out how to best calculate the BCC with a Click, if it’s even possible.
                        From the little I have done with PLCs, it seems that serial comms can take up a seemingly large amount of ladder for the function they are accomplishing. Regular ladder is generally simpler and easier to follow.

                        For reference, I have the C0-02DR-D (RS-485 comm. Port), so I was planning on having one port for C-More/programming, one for stepper drive, and the RS-485 for laser comm. work.
                        Thanks for posting your hardware. It is surprising how often someone asks for help without posting what they are actually using.

                        Brian

                        Comment



                        • #13
                          You may want to investigate using digital IO for firing the laser instead of communications. Serial comms can introduce a variable time delay between sending a command and command execution, especially if there happens to be noise on the line that garbles the communication. You may even want to use the stepper output to synchronize the laser firing to the stepper motion. I haven't used the steppers from AD (or any steppers for that matter); but it would be worth looking into, IMHO.
                          The laser firing will need to be handled through the comm. port because the laser will be in its line communication mode, which will (I believe) lock out its I/O ports. That is not a major issue because once the recipe is established with the laser, all it needs is a start command and the rest is taken care of by the laser. Granted, I need to make sure that things are coordinated, but since I’m performing a weld on a cylindrical body, I can start the capsule rotating anytime before the weld. Also, weld overlap is not an issue, so I can be conservative on timing, if necessary. Later on down the line I can tweak things to get more precise on start/stop locations, but there is no need for that detail at this time.
                          Do you have a PDF you can share? If not, we will at least need the formula they are using for the BCC calculations and an example parameter. Another big question: will you be reading data from the laser as well as writing?
                          Here is a link to the pdf: Laser Manual. Beware, it's a ~13Mb file! The communications section is appendix D, which starts on page 165 of the PDF file (NOT the document's numbering). They do not explicitly give the formula for BCC calculation, but they do give a C+ sample program to communicate with the laser. The laser Mfr. also forwarded me this link on how to calculate the BCC. Finally, they offer a command utility (which I have not yet tried) to experiment with the laser.

                          Would anyone know whether or not this is a worthwhile effort using Click? My biggest unknown right now is this BCC generation. No matter which avenue this ends up going down (Click vs. DL205), it's going to be sizable with all of this comm. traffic.

                          Does anyone know whether or not the older DL205 equipment I found in-house (see post dated 6/14) would be ok to use? Any ideas on how to check/verify?

                          Thanks again!

                          Comment



                          • #14
                            Thanks for the info, I'll try to take a look at it today.

                            As far as the other AD stuff you have, I think it should still be viable. You may want to contact AD directly to make sure. I believe that the bases with the -1 were able to be connected to other bases (local IO expansion). Your bases won't be able to do that, but it doesn't sound like you will be needing lots of IO. Neither one of the CPUs you listed will be able to handle the whole project; or at least, I wouldn't try to. I would use a CoPro to handle the serial comms. Note that you will still need a regular CPU and the ones you listed will probably work just fine for that. You may also need a firmware update on the CPUs to let you use all the new features of DS5 if you go that route.

                            Brian

                            Comment



                            • #15
                              Thanks for your $0.02!
                              I had a feeling that this amount of comm. traffic would be a bit much for one of these. If a coprocessor is what you (and hopefully others) would recommend using, then it looks like the DL205 is the way to move forward on this.

                              Can anyone tell me the difference(s) between the DL250 and DL250-1?

                              Comment

                              Working...
                              X