Announcement

Collapse
No announcement yet.

Ways to retrieve logged data from BRX?

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


  • Ways to retrieve logged data from BRX?

    Hello,

    Trying to determine what PLC to pair with a c-more HMI. I liked the programming features of the do-more series, so that's what I'm leaning towards over the productivity line. I need a way to retrieve log files automatically - the PLC won't have network access, so e-mail won't be an option. However, there will be a PC that can bridge the PLC network to our LAN. I was hoping to use this PC to use FTP or similar on a schedule to pull all files -- as long as FTP/HTTP or similar is an option, I can easily write a script to download the log files at whatever interval we need. I know the productivity series has the web view where you can access files from the SD card, does BRX offer the same?

    Thanks!


  • #2
    If there is a PC with network access, why can't you put an email relay on the PC?

    Comment



    • #3
      Originally posted by BobO View Post
      If there is a PC with network access, why can't you put an email relay on the PC?
      Not allowed by IT for many reasons (which I agree with)

      I'll take that as no web access on the BRX like the productivity suite?

      Comment



      • #4
        Originally posted by K_For_Potassium View Post

        Not allowed by IT for many reasons (which I agree with)

        I'll take that as no web access on the BRX like the productivity suite?
        I fully understand why you want factory processes air gapped, but if the PC is already LAN connected, I'm not sure I understand how web access is any different than a local mail server or relay.

        The short answer is no, there is no web access, in part for the same reasons as your IT guys. You can access log files via DmD. You can use the DMLogger device to log directly to the PC. You can use MQTT to generate logs elsewhere. You can write your own web service with custom protocol instructions (it's been done). And coming later this year, you can use HTTP(S) based REST APIs to access databases to create logs. But no web access to the files.

        Comment



        • #5
          Thanks, BobO. I appreciate your help!

          IT does not support anything not provided/setup by them nor anything that we buy/setup for production. I can setup a mail server on our production LAN all I want - I have no problem doing this personally, as I have decades of experience in many realms of IT. I just don't want to setup something that only I can troubleshoot/maintain and leave them stuck when I leave or get hit by a bus. The bridge PC would grab the log files, generate charts in excel files for each batch, then backup the logs and excel files to a network drive. I guess the solution for me is to go with productivity 2000 or 3000 and do a little extra work with the programming.

          At least I can look at the BRX again for future projects when the API option is available.

          Thanks again!
          Last edited by K_For_Potassium; 09-20-2018, 08:53 AM.

          Comment



          • #6
            I guess we're gonna have to suck it up and get a simple web interface on there to access the file systems. With limited sessions and limited functions, it wouldn't be that bad from a security or implementation perspective, but our original vision was much more elaborate. In Host tradition, we set standards for ourselves well beyond what our users generally want or need, and then because we don't feel like we have resources to do what we want (rather than what customers want), we don't do anything at all. Kinda dumb.

            As an example, the Do-more engine is capable of function calls with parameter passing and local data, and because we wanted to support all of that for subroutines, we refused to do subroutines until we could do it "right". It finally occurred to us that users could benefit from a much simpler implementation that would be easy to develop, so we went ahead and added it. We still want to finish the original plan, but that doesn't prevent folks from benefiting today. A web service could be the same. Simple now, cool later.

            If any of y'all would like to comment on what you'd like a Do-more sourced web service to offer, I'd love to hear it.

            Comment



            • #7
              If any of y'all would like to comment on what you'd like a Do-more sourced web service to offer, I'd love to hear it.
              I interfaced with a PLC this week that allowed the IP address to be set via a built in web server. That was handy,

              Comment



              • #8
                Originally posted by mwdkmpr View Post
                I interfaced with a PLC this week that allowed the IP address to be set via a built in web server. That was handy,
                So much potential fail there. Can't do initial setup that way though, since you can't do TCP on broadcast.

                Comment



                • #9
                  We were brainstorming today. We like basic system status, file system access, and some basic data dumping. We also like an advanced feature that would allow you to instruct the HTTP server to run a program block in the PLC, which could either return data over the TCP connection or perform other functions in the PLC. That would be the ultimate back door.

                  Comment



                  • #10
                    Can't do initial setup that way though, since you can't do TCP on broadcast.
                    I'm not smart enough to know exactly what that means. They apparently send every PLC out with the same IP address. No broadcast needed??

                    Comment



                    • #11
                      Originally posted by mwdkmpr View Post
                      I'm not smart enough to know exactly what that means. They apparently send every PLC out with the same IP address. No broadcast needed??
                      Ah...that would work as long as you only have one.

                      Comment



                      • #12
                        Originally posted by BobO View Post

                        Ah...that would work as long as you only have one.
                        Usually a setup like this is for directly plugging into the device first to configure before putting it on a LAN, or on a small isolated LAN where devices are limited or with no potential for conflicts.

                        Comment



                        • #13
                          Originally posted by K_For_Potassium View Post

                          Usually a setup like this is for directly plugging into the device first to configure before putting it on a LAN, or on a small isolated LAN where devices are limited or with no potential for conflicts.
                          But what if that isn't the environment people are working in? If we pre-configure to a sub-net or IP config that conflicts with their network...highly likely...the user has to resort to changing the PC's IP config, something beyond many users' experience level. I think both PxK and Click pre-configure, but I also think they both use TCP, which requires an IP address to even talk. All Host products use UDP for programming and setup, specifically so we can talk to unconfigured devices. I'm a little surprised that isn't a bigger support headache, but I guess it isn't.

                          We will likely add IP config to the web interface we are planning, but I expect the initial state to stay the same.

                          Comment



                          • #14
                            Originally posted by BobO View Post

                            But what if that isn't the environment people are working in? If we pre-configure to a sub-net or IP config that conflicts with their network...highly likely...the user has to resort to changing the PC's IP config, something beyond many users' experience level. I think both PxK and Click pre-configure, but I also think they both use TCP, which requires an IP address to even talk. All Host products use UDP for programming and setup, specifically so we can talk to unconfigured devices. I'm a little surprised that isn't a bigger support headache, but I guess it isn't.

                            We will likely add IP config to the web interface we are planning, but I expect the initial state to stay the same.
                            I've mostly seen it only on hardware where vendors typically do the initial setup -- probably an important detail that I left out... rarely (but I won't say 'never') have I seen it on systems/devices where the end user performs setup and/or where there are alternative ways of changing network info (direct system menu, USB setup, etc...). Normally, I would say just grab an IP from DHCP and display it on a screen for initial setup, but there's no display available. A quick look at the DHCP server can help find the IP, but that's inconvenient. I would still add the IP configuration page in the interface - not for setup, but for changes/updates.

                            Comment



                            • #15
                              Originally posted by BobO View Post
                              If any of y'all would like to comment on what you'd like a Do-more sourced web service to offer, I'd love to hear it.
                              Basic PLC status, with the ability to add custom fields.

                              Ability to upload files from the SD card to a remote server (FTP, Azure, etc.)

                              Ability to serve the SD card via FTP so a user can connect and copy files from the card.

                              Comment

                              Working...
                              X