advertisement
from the Mblogic -hmiserver department...
Mblogic - hmiserver - quick start
Human-Machine Interface and SCADA. topic
Posted by Summer on 22 January, 2011 - 1:10 pm
Hi, I've found the Mlogic project really interesting!

To make in my and newbyes mind a little clarity can you please say me if I've understand the right procedures to make it work:

1) define in mbhmi.config the variables type and address

2) in inkscape create the graphics with the id of the var of mbhmi.config.

3) add the svg to the xhtml file.

4) in xhtml with javascript add events to the var.

is this right?

another little question, I've read the install doc but can't understand what is the difference between "hmiserverMbs.sh" and "hmiserverSbs.sh". the final s and c it's clear, but the M and S I can't understand.

Thanks in advance, kindly regards.


Posted by M Griffin on 22 January, 2011 - 10:13 pm
I'm the author of MBLogic (and HMIServer). You have most of it correct.

The SVG IDs do not have to be the same as the tag names in mbhmi.config. However, it is often convenient to make them the same in order to make them easier to remember (or just so you don't have to think up too many new names). You can really call them anything you want however. In fact, if you use the same tag multiple times then you will have to use a different ID for each one (because IDs must be unique) even though they are all using the same tag.

As for "hmiserverMbs.sh" versus "hmiserverSbs.sh", those start up different versions of the server. It works like this:

1) hmiservermbs = Modbus/TCP server.
2) hmiservermbc = Modbus/TCP client.
3) hmiserversbs = SAIA Ether SBus server.
4) hmiserversbc = SAIA Ether SBus client.

The server versions act as protocol servers (slaves), while the client versions act as protocol clients (masters). If your PLC is a client (master), then you need to use the server (slave) version of HMIServer. If your PLC is a server (slave), then you need to use the client (master) version of HMIServer.

The "sh" files are bash (Linux, Mac OS/X, etc.) shell scripts. You would edit those files to change the communications parameters. There are "bat" equivalents to these in the MS Windows versions.

There are really 4 different programs, which are all distributed together to allow them to share as many files as possible (most of the package is actually taken up by the on-line documentation).

As far as using Inkscape is concerned, there are several hundred SVG widgets supplied in the "HMIBuilder" package. These are stock push buttons, pilot lights, numeric displays, dial gauges, etc. You can drag and drop these onto the SVG drawing using Inkscape. You can also draw your own widgets using Inkscape and use the same Javascript library functions to control them.

All of the above is described in the documentation, although I am of course more than happy to explain anything you wish to know.

You may also be interested to know that I currently working on a program to automate creating the scripting and assembling the web page. The program reads in the SVG drawing, finds all your widgets (push buttons, pilot lights, etc.), and lets you assign the parameters using menus. It then automatically generates the Javascript and inserts it into the web page for you. You still use Inkscape to create the drawing and assign the IDs.

In the mean time if you have any further questions I will be happy to answer them.


Posted by Summer88 on 24 January, 2011 - 3:06 am
Thanks for the fast answer and explanation!

I'm looking at the documentation but, I've tried some editing on the demo running as hmiservermbc.sh (modbus client) and got this error:

"
Mon Jan 24 08:54:24 2011: Error - Bad response from remote host on func: 129 error
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 37256)
Traceback (most recent call last):
File "/usr/lib/python2.6/SocketServer.py", line 283, in _handle_request_noblock
self.process_request(request, client_address)
File "/usr/lib/python2.6/SocketServer.py", line 309, in process_request
self.finish_request(request, client_address)
File "/usr/lib/python2.6/SocketServer.py", line 322, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python2.6/SocketServer.py", line 618, in __init__
self.finish()
File "/usr/lib/python2.6/SocketServer.py", line 661, in finish
self.wfile.flush()
File "/usr/lib/python2.6/socket.py", line 297, in flush
self._sock.sendall(buffer(data, write_offset, buffer_size))
error: [Errno 32] Broken pipe
----------------------------------------
"

There is already a release date for "program to automate creating the scripting and assembling the web page"?


Posted by M Griffin on 24 January, 2011 - 3:32 pm
What you see there is two different error messages. The first one "Bad response from remote host on func: 129" is a Modbus error indicating that whatever you are connecting to is reply with a Modbus error code of 129. If you click on the "Data Messages" menu on the web interface (http://localhost:8082/statussystem.html), you will see a log table with the Modbus requests from HMIServer and the responses from the field device server (whatever that is).

The second message (the long one that starts with "Exception happened during processing of request from") is one that I find very puzzling as I am not able to reproduce it despite trying a number of different ways. That is an error message (more technically, a "traceback") from the web server system but it's not pin pointing the error other than complaining about a "broken pipe" (this is an error message from the standard library). Did this second error happen more than once, and if so, is it always associated with the first error message (the Modbus communications and the web server are two different parts of the program)? What web browser (and version) are you using?

As to the first error, an error code of 129 indicates that the field device server (whatever HMIServer is talking to) replied back with an error relating to function 1 'read coils' (Modbus errors are the function code + 128). The "Data Messages" page (as mentioned above) will give tell you which function (command) is causing the error (look in the response column for the error, and then in the request column to see which address is associated with it). If you need any help in understanding this let me know and I will explain this in more detail.

I am assuming in all this that you are working with your own field device using your own configuration. What PLC (or other device) will you be using?

The demo which comes with the system uses the server version (hmiservermbs) so that it doesn't need a Modbus server just to run the demo. However, in the "demosupport" directory there is a copy of "mbasyncserver" which acts as a stand alone Modbus/TCP server. I used to have a separate demo for each version of HMIServer, but I simplified that down to a single one (HMIServerMBS) a few releases ago. You will need to run that on a port above 1024 on Linux because of security restrictions (the documentation will tell you how to re-map that to make it look like port 502 however). For demo purposes however, I typically use a port in the 8000 range to avoid conflicts.

As for the program for creating the scripting and assembling the web pages, it will be called "HMIBuilder". There is currently a package of that name with MBLogic, but it just consists of the SVG widgets. I currently have most of the features of the new program working and expect to have everything done (finish the program, test it, write the documentation, update various associated items) in a week or two.

If this doesn't answer your questions, please let me know and I will try to help you further. As I said above, the first error message is a Modbus message indicating a problem reading coils. The second error message is connected with the communications between the web server and your web browser (which handles the system monitoring and HMI). That one I cannot reproduce at present, but if this is something that you can reliably reproduce in some manner, then I would like to get to the bottom of it.

You can ask any further questions here, or if you wish there is also a user forum on the MBLogic project site. Either place is fine with me, so use whichever you find more convenient.


Posted by Summer88 on 26 January, 2011 - 4:58 am
Hi, thanks for the help!

I'm on a debian testing, using firefox (numericpad not work on this browser), google chrome (everything works fine),and a modbus slave device.

I've solved the first error. now I can see from the log page that it's ok:
Request Response
{"id":"HMI Demo110120", "msgid":2034, "read":["A40110", "A40111", "A40112", "A40113", "A40114", "A40115", "A40116", "A40117", "A40118"], "write":{}, "events":{"serial":0, "max":50, "zones":["zone1"]}, "alarms":["zone1"], "alarmhistory":{"serial":0, "max":50, "zones":["zone1"]}, "alarmack":[]} {"read": {"A40117": 0, "A40116": 0, "A40115": 0, "A40114": 0, "A40113": 0, "A40112": 0, "A40111": 1, "A40110": 25, "A40118": 0}, "msgid": 2034, "stat": "ok", "id": "HMIEST", "timestamp": 1296035236.7540359}

The second error still remain, it append every time I load a page from a client. I'm using a microplc from an italian producer with modbus tcp/ip standard protocol. But the problem happen also with simulator.

Can I kindly ask you other questions:

How many clients can get connected at the same time (is hardware or software related)?

If I've got 300 word in all the application is there a way to load only the one corresponding to the ones in the loaded screen, I mean make different clienconfigdata for different application pages but in the same project?

Thank you very much for your work and your time!
Kindly regards



Posted by Summer88 on 26 January, 2011 - 8:40 am
If could help debug I can send you a detail of communication taken by wireshark.

To optimize communication can I ask you why don't you use the modbus function ReadMultipleRegisters, so you could read a list of var sub-sequentially at one time.


Posted by M Griffin on 28 January, 2011 - 4:38 pm
This is a follow-up for the benefit of anyone else who has been following this discussion. The problems appear to have been:

1) Incorrect configuration.

2) Excessive CPU load from animations may have been the cause of the "broken pipe" errors.

3) The user has decided to use the main MBLogic package rather than HMIServer in order to take advantage of the ability to make multiple outgoing client connections.


Posted by M Griffin on 26 January, 2011 - 6:32 pm
I've been trying to reproduce your error on both Debian Stable and Ubuntu 10.04 (I don't have a copy of Unstable set up however). I get no broken pipe errors and the keypad works fine. I've tried the following browsers: Firefox 3.6.15, Firefox 4.0b10, Chromium 10.0, Opera 11.00, Epiphany 2.30.2, Midori 0.2.2 (the browsers were all running on Ubuntu, as the Debian system is a server only). I have tried creating various errors related to missing files or incorrect file permission bits, and the system simply tells me it can't load a file (which is the correct behaviour). The "broken pipe" may be the server complaining that the browser is cutting off a file transfer in mid stream. What version of Firefox are you using?

If you wish, you can e-mail a copy of the contents of your "hmipages" directory and your "mbhmi.config" file to me, and I will have a look at it to see if I can reproduce it. If you look in the main download package there will be a package called "MBLogic". That includes a file called "MBLogicInstall.pdf". That file has a section called "Support and Development Contacts". I have an email address there for developer contacts. I don't post it here because of spammers.

If I can't reproduce it from your application files, then we can try making a copy of the SocketServer library and inserting some debugging code into it to see what it was doing when the pipe broke. At the moment, the trace-back is saying it was trying to flush out the write buffers to finish a request, and that's what seems to be happening in the source code as well.

I do have one thought on this. Do you have a really big PNG or JPEG file you are including in your web page as a background image? Is there any chance the web browser is choking on that and cutting off the transfer? I suspect it's a non-essential file like that, because if it was for example a JavaScript library, then the HMI wouldn't run.

As for your other questions:
HMIServer comes in both server and client forms. The server version is used when your PLC is a client (master), and the client version is used when your PLC is a server (slave). The server version can accept an unlimited number of connections from PLCs. The client version will make one connection to a single PLC.

If you need to make multiple client connections to multiple PLCs (or field I/O) then use the main MBLogic package. That does include a soft logic sub-system, but you don't have to use the soft logic features. The HMI systems are identical in both. You can make an unlimited number of client connections from MBLogic to PLCs (or other field devices), and it also includes a Modbus/TCP server which will accept an unlimited number of incoming connections at the same time. The number of client or server connects will only be limited by CPU load. I've tested it with up to 100 connections (incoming and outgoing).

HMIServer was originally created to develop the HMI system for MBLogic. The Modbus/TCP client communications system was then added to make it a stand-alone HMI system. The S-Bus versions and Modbus/TCP sever version were developed for user applications. All 4 versions were recently merged into a single package. It is intended to be simpler to configure and easier to install than the main MBLogic system, so it relies only on the standard Python libraries (the main MBLogic package also requires Twisted). I do have plans to add the ability to optimise communications by merging adjacent reads into a single request, but that has to fit in with the other project priorities and also remain simple to use. Currently, I'm focusing on features to make the HMI easier to configure (for example, the program to automatically generate the scripting) and on features that people need for specific applications.

If you have a big application and need optimized I/O then another answer to that can be to use the main MBLogic program. Client requests are inherently optimised there because you configure what reads and writes you want to perform as part of the communications configuration and it runs those on a regular polling interval (which you also configure). The HMI requests are then served out of the MBLogic program's own memory. That also means that if you have multiple workstations viewing the same HMI the PLC doesn't see any additional message load since all HMI requests are handled by the MBLogic server instead of passed through to the PLC.

You also get the advantage with the main MBLogic package that alarms and events are logged to a database and you can query that database using a provided web client, and also you can edit the configuration files using web based forms in the web based management system. Client communications status is monitored and reported in the status system so you get better troubleshooting features. HMIServer is intentionally simpler than the main MBLogic package because it's meant for people who don't want the additional capabilities. Both HMIServer and MBLogic use the same HMI files (including the same "mbhmi.config" file), so you can switch from one to the other quite easily.

You said your application has "300 words". I assume that is "300 HMI tags". At present there is no feature to have multiple sets of tags and switch between them. However, I have just gone over the communications code in the Javascript libraries and it looks like it would be possible to add that. You would need to add your own scripting to switch between sets of tags - probably one line of Javascript which you would attach to the screen select buttons. The screen select buttons currently do this:

onclick = "ScreenSelect.SelectScreen('mainscreen')"

That would need to be changed (by editing the button files) to something like this:

onclick = "ScreenSelect.SelectScreen('mainscreen'); MBHMIProtocol.SetReadList(Your_ReadList1);"

You would need to define multiple read lists in your config file. The "SetReadList" function call doesn't exist yet, but I think it would be easy enough to write. If it works the way I think it would, then I could commit to having that as a standard feature in all future versions of HMIServer and MBLogic. I can't at this time commit to having it as a feature of HMIBuilder (the program for creating HMI pages) as I won't know how to deal with it until I actually have that program finished.

However, first see the point above on using the main MBLogic package as your HMI server instead of HMIServer. If that satisfies your needs, then you probably want to avoid the extra complexity of switching between tag sets (and figuring out what you need to read for each screen).

To summarise:

1) I can't at present reproduce your error with the current information.

2) Check to see if you are including a large image file in your web page. The browser may be timing out on that.

3) If you want to send me a copy of your HMI application (including the config file) I will try testing it to see if I can reproduce the error (assuming the problem is not solved by point 2).

4) It should be possible to add the ability to switch between different read lists (to read different tag sets for different screens).

5) Check to see if the main MBLogic package fits your needs better. You should be able to move your current application to the MBLogic server without any changes. You will need to configure the communications explicitly however.


Posted by agentm on 25 December, 2012 - 3:31 am
Hello control-freaks :D

I do realize this is an older thread, but:
I was able to reproduce the "broken pipe" error - even though by accident and found the reason for this.

A while ago I move my heating-control system from a PC to a Raspberry PI. It is running three circuits: Furnace, Floor-Heating and Radiators with each having its own pumps and mixers as well as a total of 15 1-wire temperature sensors. I am using owfs for communicating with the sensors and the IOs.

I was checking the performance of the raspi under load and found that each task mbasyncserver.py and hmiservermbc.py would take 15% CPU, leaving about 50% idle.

Suddenly, after 2 months or so the hmi watchdog was displaying red and i got flooded with broken pipe errors. I found the two processes took ALL the processing power with no idle left. Now that can't be good :(

After tinkering a while I tried to reduce the scan rate to reduce the load and lo and behold there it was:

In clientconfigdata.js I changed the scan rate MBT_ScanRate from 1000ms down to 250ms. This was last year on the PC to test the responsiveness of the hmi, so I didn't quite remember right away. After putting it back to 1000ms the hmi was back running. The CPU-time for each task is now 7 to 8%.

Cheers,
AgentM


Posted by KYT on 23 March, 2013 - 2:39 pm
Hi,

I m a newbie in mblogic. I do open the sample demo in the package. But are there any step by step guide for mblogic?

My application is using DGH Modbus module (7 analog I/0 in a single module, Model:D6200) which is using modbus RTU protocol. Connect it via RS485/USB converter to my PC. I would like to do the monitoring on my 7 analog signal and do some control using digital I/O as well.

I do read some help file but not really clear about the procedure.
I assume the step by step as following:

1) configure on mbclient.config (edit the modbusrtu protocol...)

2) configure mblogic.config for my tag

3) configure mbhmi.config for tag to display which may link their address from mbclient.config

4) Using HMI builder to do the html interface n tag.

Am I correct? Do i need to do any configuration on mbserver.config?

Yours reply are most appreciated.
Thank you very much.

Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2014 Nerds in Control, LLC. All rights reserved.

Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.


Fortune
A language that doesn't have everything is actually easier to program
in than some that do.
-- Dennis M. Ritchie
Advertise here
Advertisement
our advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive