Announcement

Collapse
No announcement yet.

P3k/Slave Setup

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


  • P3k/Slave Setup

    Hey Guys, I'm pretty new to the PLC world. I am working on setting up a project where I am using a P3k as a master and am using several Click PLCs as slaves. I am connecting to my slave units via ethernet. I am wondering what is the best way to set this up. Can I use a network RX/WX? or do I need to do it through modbus RX/WX?
    If I use modbus, how do you set up and map addressing for multiple slaves?


  • #2
    If you use modbus, the slave modbus address for Click PLCs is set.
    To see the modbus addresses, open the Address Picker and choose Display Modbus Address.

    For each slave read/write instruction, specify the network address for that slave.

    I use the Click as a slave IO using modbus quite a bit. It is cheap, easy, and modular for equipment that may change around.

    Comment



    • #3
      If you give me until this evening I can give you a stripped down version of program to do exactly that. You don't need a program in the Click* if you're just using the Click's as remote I/O and reading the input's and writing the output coils directly.

      You would use the MRX and MWX modbus instructions (which can do either Modbus over serial or ModbusTCP over network). The RX and WX instructions are strictly for use between PxK processors, IE P3K talking to P1K.

      If you haven't purchased the hardware yet, I would suggest spending the additional few dollars on the P1K now that they are available. Programming with the RX/WX instructions are significantly easier as it will import your tags in both directions and you aren't stuck with addressing directly to modbus addresses, which can get confusing, fast, especially when you're dealing with multiple Click's as slave I/O since they all use the same exact addressing. If you were to use P1K's as your slave I/O, you name all of the tags in the P1K's, then import those into the P3K program. Those tags are then available in your tag database just as if you're using local I/O.

      The response time seems to be significantly faster for some reason as well, that is to say if a button is pressed on one of the remote I/O PLC's, it shows up faster on the P3K. This was an issue I had with using Click's for remote I/O. Outputs were always fine. Inputs using toggle or other latching switches were fine, but pushbutton inputs didn't always catch if the user didn't hold the button for longer than one would think was necessary. The same would apply for any other sensor that may send out a quick off-on-off pulse. The issue in my case was basically that with two remote I/O Clicks, I needed to cycle through 6 instructions in my comms setup, two MRX instructions to read both X discrete inputs as well as DF analog inputs and a MWX instruction to write the output coils, per Click. My cyclic counter to pulse through the instructions ended up having to get set to 2ms which according to Tech Support was absurdly fast. Basically it was possible for a user to press a button on one of the slave units during the scan window of 10ms. The Click would register the button press fine, but by the time the scan got back around to that Click, the input was already off so it missed the input. It got to the point that I had to start setting 20ms off-delay timers for those inputs on the Click's, which is why I have a * up top. While you don't NEED a program in the Click, you may end up having to write one to get it to "trap" certain types of inputs. My situation is a little different than most. My programs run escape games in themed attractions, rather than an industrial operating environment. This issue cropped up where players had to enter in a button press sequence, akin to dialing a phone number. During the comms cycle, the P2K was missing some of those inputs.

      P1K's are definitely more expensive out of the gate than Click, you're looking at a ~$150 difference between a base model $70 Click vs a similarly configured P1K. Past that the I/O modules are very similar in price. Analog on the P1K is surprisingly less expensive than Click, by a pretty large percentage. Apples to apples, a 4ch 13bit 0-10v card on Click is $89 where on P1K it's only $67. For the time being I'm stuck using a mix of P1K and Click, only because the P1K doesn't have a large selection of I/O modules. I hope that will change. I typically use 2-3 times the amount of inputs than I do outputs, so not having 15 or 16pt inputs cards makes it a non-starter for me in some applications.
      Last edited by Brandon_; 01-18-2018, 02:03 PM.

      Comment



      • #4
        Originally posted by Brandon_ View Post
        If you give me until this evening I can give you a stripped down version of program to do exactly that. You don't need a program in the Click* if you're just using the Click's as remote I/O and reading the input's and writing the output coils directly.

        You would use the MRX and MWX modbus instructions (which can do either Modbus over serial or ModbusTCP over network). The RX and WX instructions are strictly for use between PxK processors, IE P3K talking to P1K.
        ^ what he said

        Originally posted by Brandon_ View Post
        If you haven't purchased the hardware yet, I would suggest spending the additional few dollars on the P1K now that they are available.
        Unless you need a point I/O card of specific density that is not yet available. See Brandon's point below.


        Originally posted by Brandon_ View Post
        Programming with the RX/WX instructions are significantly easier as it will import your tags in both directions and you aren't stuck with addressing directly to modbus addresses, which can get confusing, fast, especially when you're dealing with multiple Click's as slave I/O since they all use the same exact addressing. If you were to use P1K's as your slave I/O, you name all of the tags in the P1K's, then import those into the P3K program. Those tags are then available in your tag database just as if you're using local I/O.
        ^ again...

        Originally posted by Brandon_ View Post
        For the time being I'm stuck using a mix of P1K and Click, only because the P1K doesn't have a large selection of I/O modules. I hope that will change. I typically use 2-3 times the amount of inputs than I do outputs, so not having 15 or 16pt inputs cards makes it a non-starter for me in some applications.
        And further, if you are just using this as a few nodes of REMOTE IO, maybe ProNet, CPoE or EtherNet/IP can help remove slave CPU code requirements.

        Comment



        • #5
          Originally posted by kewakl View Post


          And further, if you are just using this as a few nodes of REMOTE IO, maybe ProNet, CPoE or EtherNet/IP can help remove slave CPU code requirements.

          Ugg. I tried ProNet, what a supreme pain in the dick to setup. After spending a while watching videos and getting it setup, I tried out the RX/WX instructions. What a walk in the park compared to ProNet!

          I really wish Productivity had a ultra stupid simple to setup instruction like Peerlink on the DoMore platform. That said, Peerlink is very limited on the number of I/O blocks that you have.

          What would be ideal would be to be able to add a P1K (or even another P2K or P3K) full system as a remote base group. I'm still mind boggled as to why the remote base group is limited only to the P2-RS CPU's. I'm going to buy P1K's for remote I/O. There is zero reason for me to buy P2-RS's and build full backplane systems at this point. Why not help a brother out and make the integration cake for me? I digress.
          Last edited by Brandon_; 01-19-2018, 01:54 AM.

          Comment



          • #6
            Originally posted by Brandon_ View Post


            Ugg. I tried ProNet, what a supreme pain in the dick to setup. After spending a while watching videos and getting it setup, I tried out the RX/WX instructions. What a walk in the park compared to ProNet!
            .
            I did a sample project with ProNet. I didn't find that I needed the services of a mohel to accomplish it.

            Comment



            • #7
              Hey Brandon,

              What can we add to the help files that would have helped get you going faster using ProNet. We prefer the use of ProNet since gives more flexibility and the amount of data that can be shared between cpu's. Therefore, any feedback you can provide would be appreciated. You can PM me if you would like with details.
              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've used remote io using the Ethernet/IP abiility of the P2k. If you can, then that is the easiest I would say. No ladder logic needed. The IO I used was Snapio by Opto22. I was going to use a remote P2k slave, but the PxK hardware is not good in the cold. The IO that I used is placed in a roof top condenser, Indiana winter got down to -10F so far. I have a small heater in the cabinet, but no way would it keep to 32+F in there.

                Comment



                • #9
                  The P1000 would be a great for Ethernet remote I/O for the P2000 and P3000. We have a couple of systems using the P3k with multiple remote I/O racks and GS drives. The setup and programming is pretty slick, but the remote I/O is expensive.

                  Comment



                  • #10
                    Originally posted by P3K_ADC_Eng View Post
                    Hey Brandon,

                    What can we add to the help files that would have helped get you going faster using ProNet. We prefer the use of ProNet since gives more flexibility and the amount of data that can be shared between cpu's. Therefore, any feedback you can provide would be appreciated. You can PM me if you would like with details.
                    How does ProNet give more flexibility? Why would I want to have to move data into an array for ProNet to work, when I can simply use the Rx or Wx instruction and deal with the remote tags directly? I ultimately never used ProNet as it was significantly more work than just using Rx and Wx so maybe I'm missing something in the big picture?

                    For my particular use case, to make things perfect, allow full blown P1 and P2 CPU's to be used as remote racks. Don't limit me to using just the P2-RS cpu. If you gave me the ability to use P1K's as remote I/O directly without having to deal with additional instructions, allowing me to use a off-board P1K just as if it was part of the local system, I would probably immediately stop shopping other PLC vendors. Right now we're looking at moving to Beckhoff or BRX.

                    I really love the PxK platform and I fan-boy it constantly, but the lack of a PWM instruction and poor external data handling (I shouldn't have to deploy a C-More to have the ability to email a log file) has me looking at other options. And for the love of all things holy, please have the dev's look into having PSuite check on startup if there is a external monitor connected. If it doesn't detect an external monitor, have it put the windows back on the main monitor.

                    Comment



                    • #11
                      Originally posted by Brandon_ View Post
                      And for the love of all things holy, please have the dev's look into having PSuite check on startup if there is a external monitor connected. If it doesn't detect an external monitor, have it put the windows back on the main monitor.
                      been whinging on this since .... @2012?

                      Comment



                      • #12
                        Yeah, still an issue obviously. I work with dual monitors when I'm at my desk (via my laptop) and I don't always remember to open PSuite, move all of the windows back to the laptop display and then close out before I go back home for the week or head to a jobsite. It really makes me scratch my head at the dev's sometime as to why a pretty mature piece of software still responds in the way that it does. Past that, having a processor that is billed as "we have all of the comm's and data logging!" but can't do something as simple as email the CSV files. And the logging function itself is mediocre at best. Certainly not to downplay the dev's, but in my ~3 years of using Productivity, I think the only actual new instruction that has come out has been the Custom Protocol instruction (which I AM thankful for!), but past that, there never seems to be any increase in value of the platform.

                        Comment



                        • #13
                          And now, my secondary monitor is dead! KARMA?

                          Comment



                          • #14
                            Maybe a bit of karma and irony both!

                            Comment



                            • #15
                              "Yeah, still an issue obviously. I work with dual monitors when I'm at my desk (via my laptop) and I don't always remember to open PSuite, move all of the windows back to the laptop display and then close out before I go back home for the week or head to a jobsite."

                              Just FYI, if you go to Tools -> Reset Screen Layout it will move back any open windows to the main screen.

                              We will get with developers to begin looking into making this an automatic function if only 1 monitor is detected.
                              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

                              Working...
                              X