Announcement

Collapse
No announcement yet.

CLICK data logging direct to PC via Ethernet

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


  • CLICK data logging direct to PC via Ethernet

    We have been using CLICK PLC with standard C0-01DR-D CPU to control our continuous-belt 3-zone IR furnaces since 2012; no C-more involved as all control/display is via our proprietary control panel and SOLO controllers on each zone. We have a customer now demanding data logging direct to PC via Ethernet connection; no logging to USB drive or to SM card. I am advised that the customer's data access & database management group "will not support any other solution". <sigh>

    One solution might be:
    1) Use BRX CPU as master to communicate with CLICK as slave via Modbus.
    2) Extract CLICK memory data to BRX via Modbus RTU.
    3) Use BRX data logging feature to configure data output file.
    4) Allow customer PC to access BRX Ethernet port to transfer data file.

    Is this possible? Any other solution?


  • #2
    AdvancedHMI. Sry, AD. If you had a PC solution that I could recommend, I would.

    Comment



    • #3
      Hello,

      slb9, You are very close.Its actually fairly simple and inexpensive to do, provided you do not mind putting another CPU beside the CLICK. Take a BRX CPU, the cheapest you can find with ethernet built in, and connect it up to your CLICK using 232 or 485, depending on what you have on your CLICK. Have the BRX read the memory locations from the CLICK you want ot log. Use STRPRINT and STREAMOUT to send it out the Ethernet port on the BRX. Just like you wrote. A line or two of code.

      DoMore Designer comes with a executable called DMLogger.exe. Start it up on the PC you want to log to. It will log the data to DMLogger and you can save it from there.

      Take it a step further and write a line or two extra code in your BRX and also write it to a file on the pc in CSV format directly from the BRX.

      I realize you are not using the BRX for control. But it is a fairly inexpensive way to get data to a PC in CSV format which I believe is what your looking for.



      Did it last week. It works great and your customer will be happy.



      BTW, DMlogger is not a programming package. It just needs to be started and running on the PC. It logs the data itself and there is a button to save the data. Like I wrote, you can write one or two extra rungs of code and write it directly to a CSV file on the pc. You can create new files based on event, time, etc. For this file creation process to work, you must have DMLogger running on the pc.

      Last edited by icauto1; 08-18-2017, 09:28 AM.

      Comment



      • #4
        Hi, icauto1:

        Thanks for your response; I got a similar response from BobO on the Host Engineering Forum and had decided that was the way to do it. Then I talked with our customer and found out that they use KEPware for their data acquisition and monitoring around the plant. Since their KEPware package includes drivers for CLICK Modbus communications, all we have to do is replace the current CLICK CPU with one of the new CLICK C0-11DRE-D CPU's which has a Ethernet connection in Port 1. Our customer has a program that will extract the data from the Modbus addresses that I give them via the Ethernet port. I will add a couple of rungs to move the data they want into a contiguous section of DS memory to make retrieval quick and easy.

        I'll load the new CPU with our furnace software and send it off to them. They can swap the old for the new easily since both CPU's use same I/O connector, RS-485 Port 3 and power supply plug.

        I'll report back here on this forum on the results.

        Comment



        • #5
          Originally posted by slb9 View Post
          Hi, icauto1:
          Thanks for your response; I got a similar response from BobO on the Host Engineering Forum and had decided that was the way to do it. Then I talked with our customer and found out that they use KEPware for their data acquisition and monitoring around the plant. Since their KEPware package includes drivers for CLICK Modbus communications, ...

          I'll report back here on this forum on the results.
          When you say KEPware package includes drivers for CLICK Modbus do you mean that the drivers are described/named for CLICK, or that the Modbus drivers will work with CLICK?
          I am asking a serious question. I don't have kepware, and am looking into multiple scada system's (HW and SW) driver compatibility.

          Comment



          • #6
            Hi, kewakl:

            Sorry for my absence on the Forum as I was doing work on another project.

            Yes, our customer plans to use KEPware Modbus RTU (serial) drivers to talk to the CLICK PLC and retrieve data from PLC memory. I called and confirmed this with AD customer support. All I have to do is provide our customer with the Modbus addresses of the data in CLICK memory from the Address Picker in CLICK program.

            There is this old thread (2013) in this Forum which has a similar topic and positive responses:

            --------------------------------------
            Question about kepware and Click PLC
            09-16-2013, 07:10 PM

            I am thinking of buying a Click PLC, model C0-01DR-D. I have Kepware version 4.300.449.0. Does anyone here know if i can use this version of kepware to connect to a click PLC?
            Thanks in advance for your help.
            --------------------------------------

            I won't know more until we actually get the contract to provide support from our side to help them implement this project.

            Comment



            • #7
              slb9, Thanks for the response.
              Yeah, in the earlier post that you mentioned, Dave is using Kepware 4.300.499.0, the current is 5.11.263.0 Do you know what rev your customer is using?

              Comment



              • #8
                Finally received the contract to port our furnace control s/w to CLICK C0-11DRE-D CPU from C0-01DR-D so that our customer could retrieve data being logged from the furnace.

                Our furnace s/w uses the CLICK CPU as a master communicating via Modbus send/receive commands on RS-485 (Port 3) with several slave SOLO controllers which are actually controlling the various furnace heating zones. Comm rates are set to 9600 baud for reliability. Typical send or receive times are 40-60 ms involving 6 command send actions and 3 data retrieve actions with the SOLO controllers at regular 2-second intervals.

                Our first surprise: the scan rate on the C0-11DRE-D CPU running our s/w is at least 5-6 times faster: 1 ms scan time vs 6 ms. The CLICK Software Status Monitor function was unable to keep up (even worse than usual) and our SOLO controller behavior was erratic. I manually changed the Scan Rate to a fixed 6 ms, but the SOLO controllers still wouldn't reliably behave.

                I called AD and spoke to a CLICK specialist. He told me that they increased the processor speed to handle the faster data rate on the Ethernet Port (Port 1), but that the processor chip runs faster than the comm I/O chip can respond when switching between send and receive modes. He suggested that I insert a 10 ms timer delay to give Port 3 time to get really ready, so I put the following timer in each of our 9 send/receive latches. These latches cleared up the above erratic SOLO controller behavior and after 2 days of QA testing, allowed us to ship the new CPU with new s/w to the customer.

                Click on thumbnail below to see the added timer that worked.

                Click image for larger version

Name:	Added Time Delay Port3 Ready.JPG
Views:	125
Size:	76.0 KB
ID:	109236

                Comment



                • #9
                  I can report SUCCESS in retrieving data being logged in the CLICK CPU using Kepware.

                  Nearly 2 months later, customer has installed the new C0-11DRE-D CPU and confirmed that the new programmed CLICK PLC is working and logging data that can be retrieved via the Ethernet Port 1 on the CPU using Kepware's CLICK drivers.

                  One final note: the customer had to supply me with the Port 1 IP Address, Subnet Mask and Default Gateway settings they expected to use so that I could store that as part of the re-compiled project in the CLICK CPU memory.


                  Comment

                  Working...
                  X