Announcement

Collapse
No announcement yet.

Input Wanted! BRX HTTP features...

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


  • Input Wanted! BRX HTTP features...

    We are digging into what we might want to add to BRX through a web interface and would love to have input from our users!

    Some ideas we are kicking around now are:
    1. Web pages for:
    a) Basic system status...pretty much anything currently available from the SysInfo dialog pages in DmD.
    b) File system access...minimally file listing and file read access to the ram and sdcard disks. I have mixed emotions about writing or deleting.
    c) Basic image register data display. This is somewhat redundant to 2C below, one being browse-able the other more programmable. May not need both.
    d) ??
    2. REST API for:
    a) Running program blocks. Something like /run/PgmBlockName?parameter_fed_into_string_containing_ whatever_you_want
    b) Reading image register locations and returning as JSON object records. Something like /data/json?FieldJuan=V0&FieldToo=T0.Acc&Field3=D[V1]:3
    c) Reading image register locations and returning as live web page table. Similar to json, like /data/page?FieldJuan=V0&FieldToo=T0.Acc&Field3=D[V1]:3
    d) ??

    We're listening!






  • #2
    Reading from file system would be great. As you said there are serious security issues with writing, and overall it is less useful than reading data out of the PLC. However for the sake of completeness, perhaps make a configuration area in the BRX that the programmer must specifically enable that will allow writing or deleting files.

    Perhaps for the image register data display there could be a new instruction block or two in the PLC that we can put into ladder that is like a "Publish to web interface" or something. It would just be a block where you put in whatever memory locations or I/O address you want on different lines, and then it makes those specific "tags" available on a web page that can be viewed in a simple list. It would also pull the description from documentation for that memory address so that people browsing the web page would see what the data is supposed to be. Allowing the person making the program be able to set the specific data they want displayed and in the order they want would be more useful in my opinion than displaying everything or more data than the person cares about.
    Last edited by MikeN; 10-04-2018, 09:33 AM.

    Comment



    • #3
      Originally posted by MikeN View Post
      Reading from file system would be great. As you said there are serious security issues with writing, and overall it is less useful than reading data out of the PLC. However for the sake of completeness, perhaps make a configuration area in the BRX that the programmer must specifically enable that will allow writing or deleting files.
      If we allow writing /deleting, that is the likely approach. I'm generally a fan of making every part of the PLC's website removable by the system config...including the website itself.

      Originally posted by MikeN View Post
      Perhaps for the image register data display there could be a new instruction block or two in the PLC that we can put into ladder that is like a "Publish to web interface" or something. It would just be a block where you put in whatever memory locations or I/O address you want on different lines, and then it makes those specific "tags" available on a web page that can be viewed in a simple list. It would also pull the description from documentation for that memory address so that people browsing the web page would see what the data is supposed to be. Allowing the person making the program be able to set the specific data they want displayed and in the order they want would be more useful in my opinion than displaying everything or more data than the person cares about.
      I like this idea. I wasn't a big fan of the generalized dump-the-image-register approach, and this is a very good answer.

      Comment



      • #4
        An FTP Server or Client feature would be great. Once the logging and file system was added, users needed a way to retrieve these files. I believe the only three ways to access these are:
        1) Have the Do-More email the files
        2) SD Card
        3) Within the Do-More Designer software: PLC > Browse PLC File Systems

        The C-More panels offer both FTP Server and Client features and is enabled/disabled by the programmer within the project. This would be great to see on within the Do-More family.

        Comment



        • #5
          Originally posted by RoloTomassi View Post
          An FTP Server or Client feature would be great. Once the logging and file system was added, users needed a way to retrieve these files. I believe the only three ways to access these are:
          1) Have the Do-More email the files
          2) SD Card
          3) Within the Do-More Designer software: PLC > Browse PLC File Systems

          The C-More panels offer both FTP Server and Client features and is enabled/disabled by the programmer within the project. This would be great to see on within the Do-More family.
          We are definitely adding file system access through HTTP. Not as full featured as FTP, but plenty capable of returning log files.

          Are there specific benefits to FTP that HTTP can't provide?

          Comment



          • #6
            Originally posted by BobO View Post

            We are definitely adding file system access through HTTP. Not as full featured as FTP, but plenty capable of returning log files.

            Are there specific benefits to FTP that HTTP can't provide?
            My limited experience is with FTP. I don't know that I've used HTTP for file retrieval. If the Do-More were to have the FTP Client feature, and had an event driven file transfer to a server, then this would eliminate user interface and the files could be removed from the CPU, freeing up storage space. As a Server, I assume it wouldn't be much different than HTTP.

            Comment



            • #7
              Originally posted by RoloTomassi View Post

              My limited experience is with FTP. I don't know that I've used HTTP for file retrieval. If the Do-More were to have the FTP Client feature, and had an event driven file transfer to a server, then this would eliminate user interface and the files could be removed from the CPU, freeing up storage space. As a Server, I assume it wouldn't be much different than HTTP.
              You do HTTP file retrieval every time you access a web page.

              The big difference with HTTP is that we are already adding it for other purposes, and extending it to support the file systems is incremental.

              FTP is a considerably more complicated protocol and would be added strictly for files. FTP client would be an entirely different effort with a different set of complexities. We're looking for best bang.

              That said, many have requested FTP, so we'll consider it.

              Comment

              Working...
              X