The HMI in your pocket

[BobO]

A reply to a super old post, but what's Host's temperature on such a project nowadays? I know a lot has changed in the world since this was started 8 years ago, but the need is still there, arguably more-so? I'd love a (Host designed/manufactured) full-featured solution.

Quite frankly, I think the C-More line falls flat on it's face in several aspects. It can graph, but graphs won't survive a power cycle or program update. It can do remote access, but the experience over phone or PC is fairly grainy, doesn't utilize the device's keyboard, etc. The dev software doesn't even have a find function, let alone replace.

This is just scratching the surface really. I've started using Weintek devices that do much, much better in these departments, but no symbolic access, only native Do-more. Still better than modbus only, but once you start modularizing your code, doing logs, etc, it would be so much easier to be able to access User Data Types natively.

I don't know how it looks on your end, if it would be something that is built into/activated in the next generation Do-more, or a standalone device similar to RHMI's currently. These are just "legacy" type solutions, and I've not used CODESYS/WebVisu, but it seems like they do a lot of things "differently" than the old status-quo. The market is full of HTML5 HMI's nowadays, make it work with that?

It remains a desire. I have had a vision for two level solution. Level 1 is a simple table based HTML generator that makes it easy for users to generate pages that look and feel like BRX built-in web pages. Not an HMI, but a simple monitor that requires virtually zero programming. Level 2 would be full HMI pages built in a DmD based HMI page editor. Not sure if the display would be browser based or app based, possibly both. Rather than have a conventional HMI, there would be a hardened "terminal" that could log into any PLC to view the HMI pages in that PLC.

As part of the Gen2 engine we are working on, I'm sure all of this will get new discussion.

[Garyhlucas]

Wow! Totally blows me away that I started this thread 8 years ago!  Today, I am even more interested in a phone app. I am developing a product that can only succeed if I can get the cost down and eliminating the HMI would be huge.

[Kristjan]

If you will be creating a phone app then you are probably interested in the new Sparkplug POM, or at least the MQTT part of it. A very exciting implementation that I am looking forward to try out.

And it would be interesting to see what you create, you could post some screenshots on this thread to give us some inspiration

[BobO]

If you will be creating a phone app then you are probably interested in the new Sparkplug POM, or at least the MQTT part of it. A very exciting implementation that I am looking forward to try out.

And it would be interesting to see what you create, you could post some screenshots on this thread to give us some inspiration

Our initial effort will likely disappoint...it isn't a phone app (unless you count the browser), just an instruction for user generated web pages. The pages will look very much like the existing BRX web pages, since it is using the same generation code. We are wanting to add some simple widgets...simple meters and maybe a very simple trend line...but mostly the emphasis is textual/numerical displays of live PLC status. Not designed to replace an HMI, just to provide some user generated status pages to be viewed on anything with a web browser.

[Garyhlucas]

Old post, but right now I am programming a machine that has a full PC on board to analyze data from a color analyzer, read a barcode, etc.  The line printer has an HMI on its controller so we have 3 HMIs, touch screen PC with a keyboard too, printer HMI, PLC HMI.  Would have loved to use the CM5 headless, but it has WAY more capability and costs more than a CM5 with a 7" screen!  Seem like a Raspberry Pi level device could easily do this job. 

I am also working on an advanced waste treatment system for homes where the single biggest factor is the total system cost.  No good place to mount an HMI and a bluetooth connection would be perfect.  We need the full capability of a BRX36 so no savings to be had there.  From the state of NJ, there are 60,000 failing septic systems that need to be replaced over the next 10 years!

I am not a wheel inventor, I'm a wheel user.

[BobO]

After much debate, I think we've come to a consensus. We will allow read-only web access with HTTP, but for writes will require HTTPS. Since we really can't serve HTTPS with a BRX CPU, we are doing an HTTPS POM.

Also taking a run at doing some proper HMI widgets.

Early attempt shown. Works and looks great on a cell phone too.

[Controls Guy]

It remains a desire. I have had a vision for two level solution. Level 1 is a simple table based HTML generator that makes it easy for users to generate pages that look and feel like BRX built-in web pages. Not an HMI, but a simple monitor that requires virtually zero programming. Level 2 would be full HMI pages built in a DmD based HMI page editor. Not sure if the display would be browser based or app based, possibly both. Rather than have a conventional HMI, there would be a hardened "terminal" that could log into any PLC to view the HMI pages in that PLC.

Some people are doing that with CoDeSys.  The HMI is web pages in the controller and if you want to duplicate a traditional HMI install, they put an Android tablet or something with a browser and mount it on the door.  I do note that you said HTTP isn't necessarily good as an HMI, and I'm inclined to agree, but this is the kind of thing that's circulating out there.

[BobO]

Some people are doing that with CoDeSys.  The HMI is web pages in the controller and if you want to duplicate a traditional HMI install, they put an Android tablet or something with a browser and mount it on the door.  I do note that you said HTTP isn't necessarily good as an HMI, and I'm inclined to agree, but this is the kind of thing that's circulating out there.

I'm actually pretty pleased with what I'm able to do with HTML. I think this will serve many people's need for simple HMI. I'm actually getting excited about it.

[Garyhlucas]

Bob,
I am extremely happy to hear about this!  Right on time, almost exactly 8 years to the day from my original post.  I was only 64 when I wrote that.

[BobO]

Bob,
I am extremely happy to hear about this!  Right on time, almost exactly 8 years to the day from my original post.  I was only 64 when I wrote that.

Sorry it's taken this long!

[Bill541]

I'm updating a greenhouse controller from a Siemens Logo with a web page HMI to something that can serve pages a bit faster. I did a bit of research on PLCs that have decent web servers and the BRX Do-more had a good reputation. I have spent quite a bit of time porting code to Do-more Designer and have everything ready for the hardware. Since the PLC was on back order, I decided to develop the web page HMI. With the help of AI, the preliminary page looks great and displays the greenhouse data beautifully. Values are updated every 1500mS.

After getting all of this done, I started de-bugging why the HOA buttons did not work. Turns out the REST API is read only. What? Surely there is a way to pass data from the webpage to the PLC for parsing. Searched all over and came across the run/{blockname} method. this code was added to the app.js web file, but when it came time to find the string data in Do-more Designer, WSParam and WSResp were no where to be found.

I'm now at a standstill, frustrated that I may have wasted my time and money. I then cam across this thread, is there still hope using HTTPS POM? What is the recommended way to get data into the PLC from a web page that does not require a server elsewhere?

Thank you, Bill

[BobO]

I'm updating a greenhouse controller from a Siemens Logo with a web page HMI to something that can serve pages a bit faster. I did a bit of research on PLCs that have decent web servers and the BRX Do-more had a good reputation. I have spent quite a bit of time porting code to Do-more Designer and have everything ready for the hardware. Since the PLC was on back order, I decided to develop the web page HMI. With the help of AI, the preliminary page looks great and displays the greenhouse data beautifully. Values are updated every 1500mS.

After getting all of this done, I started de-bugging why the HOA buttons did not work. Turns out the REST API is read only. What? Surely there is a way to pass data from the webpage to the PLC for parsing. Searched all over and came across the run/{blockname} method. this code was added to the app.js web file, but when it came time to find the string data in Do-more Designer, WSParam and WSResp were no where to be found.

I'm now at a standstill, frustrated that I may have wasted my time and money. I then cam across this thread, is there still hope using HTTPS POM? What is the recommended way to get data into the PLC from a web page that does not require a server elsewhere?

Thank you, Bill

Quick and dirty? I'd probably use Javascript to Modbus/TCP. AI should make quick work of that.

The issue of writeability via REST is somewhat controversial. A team at ADC who is responsible for overseeing issues like this has mandated that outside of HTTPS, we shall not allow writing. Given that Modbus/TCP is in far more common use in PLCs than REST, and it is completely unsecure in most cases, I feel like that position is "swallowing camels while straining at gnats". We have created a webpage generation instruction in the PLC and we do allow writing from those pages. By default, the webserver is disabled, and my preference is to make the write option a second tier enable with a "yes, my mother knows I'm doing this" kind of disclaimer. We'll see if that flies, but personal opinion is that it is pretty silly to assume that everything is connected to the Internet when the vast majority are not. Everything in automation carries risks and we learn to manage those. Networking is no different.

The HTTPS POM has not moved forward to this point. There are just a bunch of design challenges. That said, we are developing some Linux based things that will wind up as one or more BRX modules. Easily doable in that environment.

[Bill541]

Quick and dirty? I'd probably use Javascript to Modbus/TCP. AI should make quick work of that.

From what I understand, browsers don't have access to the port used by Modbus TCP. To do this may require running a Modbus program first and then call a browser session for the reads. I don't fully understand all the intricacies, but it is more hoops I'm not willing to jump through at this time.

Given that Modbus/TCP is in far more common use in PLCs than REST, and it is completely unsecure in most cases, I feel like that position is "swallowing camels while straining at gnats".

LOL, I could not agree more, a vault in the front and a screen door in the back!

We have created a webpage generation instruction in the PLC and we do allow writing from those pages. By default, the webserver is disabled, and my preference is to make the write option a second tier enable with a "yes, my mother knows I'm doing this" kind of disclaimer. We'll see if that flies, but personal opinion is that it is pretty silly to assume that everything is connected to the Internet when the vast majority are not. Everything in automation carries risks and we learn to manage those. Networking is no different.

Totally agree, most all of our customers put their systems on a private plant network behind a firewall. Industrial IT folks do not rely on a PLC for security, that's what managed switches and firewalls are for. IMHO, a few sand boxed string registers could be used to capture web writes. These could automatically truncate any string exceeding the register size. Before I knew this was not possible, I was going to use comma separated values followed by a checksum. A ladder program was to be used to parse the checksum and validated the contents before transferring data to the working registers. I suppose one could also include a hash for increased security if they felt the need. Bottom line is the integrator knows the clients needs and their tolerance for risk. Those that are super security conscious will likely not even use the optional web server.

Thank so much for the reply, keep up the good work / fight!