Gui for c application

T

Thread Starter

Travis

I appreciate any advice. I have been programming HMI's and PLC's for a while. I was about to switch to c-programming for portability when I started researching and have not found many gui builders. I design and program many different control systems and have done fine with plc's and hmi's for a while. My last program turned out extremely nice and I ran into a very substantial lag due to maxing out the plc (I had to mulitplex quite a few of my control functions just to fit within code size limitations). I am not trying to discuss other plc's and have fully decided to make the switch to c-programming for a few reasons that I will list in case I am incorrect in my thinking:

-portability (I would think that I can use the c-application on everything from a RTOS to windows 7 or OSX so I can write the program once and use for embedded micro-processors or a desktop on a plant floor)

-no hardware limitations (if I am using a panel pc and running an application that is taking the hardware to the limit and notice considerable lags, which happened in the above situation, I can just move to a panel pc with faster processor or more memory ect)

-If/when I decide to switch to microprocessors and develop my own boards I will know c so can use any of the standard compilers for the embedded processor manufacture of my choice

Now for the issue currently at hand. Assuming that my above thinking is correct, I want to start learning c. I catch on to languages very quickly and feel extremely confident that I can learn c quickly and start designing so systems within a few weeks (always had a strong aptitude for languages). My biggest hang-up is the gui programming. I am not interested at all in hand coding a gui and need a wysiwyg builder. What I have been looking for since their does not seem to be an all in one c gui builder out there that I can use c for everything is to create the brains of the application in c and figure out what gui builder/language I can use to connect to my main c-application. This seems to be a pretty clean scenario for me as I am used to similar architecture with the HMI and plc (HMI is the U.I. for the plc application) and would allow me to change my U.I. without changing my main application. Does anyone have any suggestions for a gui builder that I can connect with a c-application. I need something that will have examples and/or tutorials to catch on to as this is all pretty new to me. Thanks for any advice
 
I have a couple comments before answering your questions:

- I would suggest C++, Its not as portable as C, but pretty close. Things like pass by reference make your life easier as you will not be forgetting your "&" all the time. Also, the ability to program objects to group data and methods is very nice in writing well organized code. I don't get caught up in the "Everything must be pure OOP", but there is enough there to be very useful.

- If you notice lags in your code you might consider an RTOS. If you are using linux I hear good things about the PREEMPT_RT patches which allow nearly realtime performance, depending on your definition.

A direct answer to your question might be to use gtk+. It is natively programmed in C, but has wrappers for C++ programming that are popular. I think it is gtk-- which represents the joking naming convention of GPL projects. :eek:)

As far as the GUI builder, there are gui builders for gtk+, such as glade, but as I have found (and others here have mentioned) they are hardly necessary. Unless you are doing a very complicated HMI you might consider using the raw text programming instead. The reason is that GTK is very layout friendly in that you can group things by relationship and it displays them appropriately saving you time in drawing and placing all the controls.

Another option is to just use C# and windows forms programming. It is very quick to set up a simple drag and drop GUI and if this is all you need it will run on windows and linux (with mono runtime). The problem I found with this is that a HMI tends to have a lot of polled IO update displays and you end up doing a lot of programming under the hood to update the displays on the screen. This is why we ultimately developed our own simple library (see below):

I am working with the C# version of gtk, or gtk-sharp, and we have developed moderately complicated screens with very little "application specific" coding. The trick is to develop a library that you can reuse on different projects. For instance, we have a fault message area and an area for buttons and display of variables on every main screen for our machines. This is prebuilt by some library routines and then we customize it with our specific code for that machine. It works well. The reason we are using gtk# instead of gtk-- is that it is very convenient to run on our windows machines to test and then deploy it on our target linux box with the mono runtime for c# programs. It is quite well suited to this kind of work. Java is likely a candidate for this too, I just don't have experience with it.

If you are using your own software system you might consider a low priority GUI screen thread and then have higher priority "machine" threads running in the same process. Otherwise you will need some kind of IPC method to communicate between your GUI and your machine process. I've not done this, so there may be caveats, but it is a worthy goal to have everything under one process. Others may disagree, it depends on your philosophy.

You might look at M. Griffin's MBLOGIC system if you can use a web based HMI, it is flexible and open source and he is a helpful contributor to this forum.

KEJR
 
W

William Sturm

I would suggest find a small portable web server library for the C portion and use a Web browser for your HMI.  That way, you will be as portable as possible.  GUI's tend to be not portable, as far as I am aware.

 Bill Sturm
 
Our http://pvbrowser.org could be a solution for you.

You can easily integrate any C application into a pvserver.
As GUI designer you can use our integrated designer or Qt Designer from Nokia.
If you want to use SVG in your GUI you should use Inkscape for the design.

Since pvbrowser is a framework for HIM/SCADA you will be much quicker than if you would use GTK or Qt directly.
Also data acquisition is integrated.
As a side effect you will always get a network capable solution.
 
GUI builders are associated with a particular GUI toolkit. If you want a cross platform GUI, then you need a cross-platform GUI toolkit. Here's a list of some common GUI toolkits and their most common GUI builders (there are others as well).

Gtk+ = Glade
Qt = QtBuilder
wxWidgets = wxFormBuilder

Gtk+ and Qt are probably best know for being used as the basis of the Gnome and KDE desktops on Linux, BSD, and various unix flavours, but they are also used in phones and many other embedded applications. Qt is also used in quite a few MS Windows programs, as many programmers prefer using it rather than the native MS Windows GUI even if portability isn't a concern. The MS Windows and Apple OS/X GUI toolkits are part of their respective operating systems and are not cross platform so they are out of the question for your application.

Something else you might want to consider is to use Python instead of C. You will be able to write an HMI type application with much less code using Python than C. Python is much more easily made cross platform than C (you have to actually work at it to make Python platform dependent) and there are Python bindings for all of the above GUI toolkits.

If you decide to use Python you might also want to look at skipping the GUI toolkit and making direct toolkit calls as it's not actually that difficult and the nature of Python is such that GUI bindings for it don't need the masses of boilerplate that languages like C or C++ require. Some types of programs can use drag and drop GUI builders, but some applications don't have a fixed screen layout so you have to generate the UI dynamically anyway (I'm working on a program like that right now).

A very easy GUI toolkit to use is Tkinter, which comes bundled with Python. However, good documentation for it is hard to come by with the best book that I've seen being "Python and Tkinter Programming" by John E. Grayson. It's actually the best book on GUIs of *any* sort that I've seen, as the author's background is programming interfaces for equipment so the examples that he uses are a lot more meaningful than the typical business applications that most books use. On the negative side of Tkinter, you have to take a few extra steps to make Tkinter look nice as the default theme is pretty plain, and there is no GUI builder available. On the plus side, GUI programming using direct toolkit calls doesn't get any easier than this.


Another approach you might want to consider is a web based interface. I have an open source / free software (GPL) project called MBLogic that includes a web based HMI. The main MBLogic program is a complete automation platform (including soft logic), and HMIServer offers the same web based HMI in stand alone form.

Here's the project page:
http://sourceforge.net/projects/mblogic/

Here's a link to the part of the web site that discusses the HMI:
http://mblogic.sourceforge.net/mbhmi/mbhmiintro.html

I'm in the process of finishing a new program that automates most of the GUI building process (that's the program that I said requires a dynamically generated interface), so the manual process listed there for assembling web pages will very shortly become obsolete. It will be a case of drag the widgets onto the drawing, right click on each one and give it an "id" (name), open the drawing in the new program (MBLogic HMIBuilder), pick each "id" and then select your options, pick a template, click on "save", and it will automatically generate the web based HMI. I expect to have this done within a few days to a week.

MBLogic and HMIServer include communication drivers to talk to the PLC (Modbus/TCP and SBus), and they have a built-in web server to serve the HMI web pages. You run the server program on a computer (I've tested it on Linux and MS Windows), and then load the HMI web page into a web browser. The server will set up communications with the PLC, and the HMI web page will poll the server for updates. The web browser could run on the same computer as the server (e.g. on a panel PC), or it can be on another computer (or even on something like an iPad). You can have any number of clients (web browsers) connected simultaneously.
 
J

James Ingraham

Wow. Just lob a grenade in here, why don't you. I'll give you my 2 cents, and then duck, since flaming arrows will doubtlessly follow.

The C language does not define a GUI, as you have already surmised. There are dozens, if not hundreds (or maybe even thousands), of solutions out there that allow you to write GUI applications in C. Off-hand, I'd say a good place to start would be GTK+. It's free, it's cross-platform, it's well-known, it's well-supported, and it has a semi-official GUI builder called Glade.

Queue ten thousand people screaming about why GTK+ is horribly inferior to < some other GUI >.

You have also apparently noticed that C does not define any mechanisms for Inter-Process Communication (IPC). This is actually the bigger problem. While again there are dozens of solutions, there's not an easy one to pick. I recommend using the Apache Portable Runtime (APR). Actually, I recommend using the APR for any and all C projects. Even so, you'll have to choose among signals, sockets, pipes, and shared memory. These are known as IPC primitives. Using IPC primitives is a good way to have race-conditions, deadlock, stale data, and other nasty scenarios. Message passing is a far better way to do it. Something like 0mq, perhaps. Or use an intermediary database, like MySQL, MonetDB, or Redis. (Queue ten thosand people screaming why those databases are all inferior to BerkleyDB or PostrgeSQL or Times Ten or ...)

What you'll notice here is that there are AWFUL lot of things to learn just to get started. The C language itself. The vagaries of the compiler & IDE you're using. The build and deployment environments (not to be confused with the actual library calls specific to various platforms.) APR, or else the specifics of the platform. The GUI API. The GUI builder. Inter-Process Communication or a database.

When my company looked at this problem, we chose to use the QNX real-time operating system. That provided the GUI API and builder, plus message passing for IPC, plus an environment we were relatively comfortable with. The downside is that our stuff is not portable to other platforms (at least not easily) and there is of course the cost of development seats and run-time licenses.

A no-cost solution could be Linux, APR, Redis, and GTK+, with Glade, gcc, and Eclipse CDT for your build environment. (Queue ten thousand people screaming that KDevelop or CodeLite is better than Eclipse CDT.)

By the way, we haven't mentioned how to talk to hardware yet. Here we open yet another can of worms. If you want blazing fast, plug-in cards on PCI / PCI Express are the way to go. Again, there's no standard C library for accessing these, so you'll have to pick a vendor for IO / DAQ cards and learn how to talk to them. If you can live with slightly less performance, you can hang everything on Ethernet (my preference.) Again, you'll have to pick a vendor and learn how their stuff talks. Here I recommend Modbus/TCP. (Remember, C does not have a standard library for TCP/IP communication. Sockets on *NIX and WinSock on Windows, or APR for cross platform.) If you want to get REALLY fancy, you can try and implement EtherCAT and (supposedly) get high performance even over Ethernet. There is an open-source implementation of the EtherCAT master library. (Modbus/TCP you can do yourself easily.)

Let's look at your original question:
"Does anyone have any suggestions for a gui builder that I can connect with a c-application."

Yes, GTK+ / Glade. But you've opened up a big ol' can of worms if you really want to do it right.

-James Ingraham
Sage Automation, Inc.

Resources:
GTK+: www.gtk.org
Glade: glade.gnome.org
Apache Portable Runtime (APR): apr.apache.org
0mq: www.zeromq.org
MySQL: www.mysql.com
MonetDB: monetdb.cwi.nl
Redis: redis.io (weird address, huh?)
gcc: gcc.gnu.org
Eclipse CDT: www.eclipse.org/cdt/
Linux: Geez, I don't even know where to start. Maybe www.ubuntu.com?
Modbus/TCP: www.modbus.org
EtherCAT: www.ethercat.org
 
I appreciate the reply. It has been a while but I remember looking at MBlogic a while back and might be a viable option. I have a lot on my plate usually from hardware design to the software design including the user interface layout design ect. I really am looking for an easy transition from my dedicated softwares that I use now that limits my hardware choices to a more portable universal language like c which will open up my hardware choices to about anything I would ever need. That being said I don't want to have to (or better stated not have time for) deal with the gui any more than a drag and drop input and output to/from my c-application. So before I get neck deep in learning C I have to figure out what avenue I am going to take for my gui to make sure it will be compatible with my C-application. Really the way I would like to design these systems is with 2 different applications:

1st- the main c-application that is doing all of the logic and control
2nd- the user interface portion that just passes info back and forth to my c-application

I am used to this technique now because I currently do the same thing with 2 different components (1 processor to handle the control/logic and 2nd processor to handle the GUI). I can't seem to find where my understanding of all of this is so far off. Is it that hard when programming with an OS (I typically do not have an OS to deal with) to pass variables (inputs and outputs) from one application to another? It seems to me that the U.I. application shouldn't really matter at all and just needs to be able to access the memory area of the main c-application. I would typically have to network/communicate from one processor to another to get info back and forth but since this is all on the same processor I would think I can make my gui with Java, HTML, C++, C#, ect because it is just reading and writing data to the main c-application. All of these should be very portable and cross platform, in my mind, because linux, windows,& Mac OSX have the ability to run say a java application (if the VM is installed) and should be able to "talk" to the c-application that can also run on either of those platforms.

If my thinking is way off I would appreciate any suggestions ect
Thanks in advance
 
C

curt wuollet

The problem is that while C is portable, GUIs tend to be very platform specific. For cross platform GUIs the trend is towards Java and to some extent, Python. One work around is to use a browser interface, but that would be a bit much on an embedded platform. There are cross platform GUI packages that have a C interface and that may be what you are looking for. They, for the most part are proprietary and somewhat expensive. I don't do much with GUIs but there are folks here that do that can perhaps advise you. Bear in mind that the GUI typically involves vastly more code than a typical control app. I do applaud your decision not to simply do the Windows thing. There are plenty of those folks already. In the post PC era, they will be fighting over scraps and legacy. And you will be well positioned.

Regards
cww
 
J

James Ingraham

Travis said: "I really am looking for an easy transition from my dedicated softwares that I use now that limits my hardware choices to a more portable universal language like C which will open up my hardware choices to about anything I would ever need."

Fair enough. Unquestionably, C is more commonly supported than any other language. It is also very flexible and powerful. There are downsides, however. I'm not sure that there's going to be such a thing as "an easy transition."

"That being said I don't want to have to deal with the gui any more than a drag and drop input and output to/from my C-application."

Well, here things get tricky. Because writing a single application with a GUI is one thing. Writing a GUI application that then talks to another application is something else. We'll get more into details in a bit.

"So before I get neck deep in learning C I have to figure out what avenue I am going to take for my gui to make sure it will be compatible with my C-application."

Good plan. On the one hand, like I said before, there are plenty of GUI builders that let you do everything in C. But actually talking between to programs (except for certain languages that inherently support it) is a trick.

"1st- the main c-application that is doing all of the logic and control
2nd- the user interface portion that just passes info back and forth to my C-application"

As I said, there is no standard for Inter-Process Communication in C. Shared memory is the most obvious way to do it, although the implementation of that is platform specific. And shared memory has lots of issues. I could go on about it for quite some time, but it boils down to this. Let's say you define a variable in your main application called "temperature" that is of type float. There is no way for an external program to view that variable or write data to it. Not possible. Instead, you'd create shared memory, both programs would map that memory, and then you would have to carve out a portion of that memory big enough to hold a float. Then you'd have to go to your GUI program and point to that same spot. If you mess up and call it "weight" in the GUI program, you'll never know until you start getting bizarre behavior of the system. If you later decide that there's another variable you want to share and you didn't make it part of the shared memory in advance, you will have to re-factor your main program.

"Is it that hard when programming with an OS to pass variables from one application to another?"

In C, yes. Like I said, C does not define ANY way to do this. You HAVE to rely on the OS (or an abstraction of it) to get Inter-Process Communication. Depending on how complex you want to do things, IPC can be trivial to worse-than-rocket-science. That's why I mentioned known solutions to the problem, like sockets, APR's IPC primitive abstractions, and multi-client databases.

"It seems to me that the U.I. application shouldn't really matter at all and just needs to be able to access the memory area of the main C-application."

Indeed. Except that most systems go out of their way to make sure that two programs CAN'T read each others memory. And of course, on a system (like DOS, for example) that DOES allow you, you still have problems. How do I find the memory area? Will it move when I close and re-start the program? What areas do I want to allow an external program to see?

"...I would think I can make my gui with Java, HTML, C++, C#, ect because it is just reading and writing data to the main C-application."

Yes and no. (HTML can't do this at all by itself, by the way. You'd have to use CGI at the very least.) Java can talk to C... but only if you provide some kind of bridge. Typically, that means creating your IPC in C and using Java Native Interface (JNI) to call C code to do the actual communicating.

"If my thinking is way off I would appreciate any suggestions etc"

I don't know about "way off." Just "this is a deeper hole than you thought." If you're used to using a PLC and an HMI, where the HMI pulls out a specific register, you're in for a real shock when you try to pull this off in C. The closest thing would be shared memory, but while this isn't an overly complex solution it's a lot harder than just plain using C. I'd say most people don't write their applications that way. Partly because they don't need it, and partly because of the gaping hole you jump into to get it right. (An obvious one; security goes out the window. This is an issue with PLCs, of course. Hook up a serial cable and start spitting random Modbus write-register commands and the PLC will happily do whatever it's told.)

You may ask if this is the case then how the heck do databases work. Short answer; I don't know the specifics. Longer answer: Some really smart people worked on this problem for a long time. Now when you write a database you go learn how all that stuff works. But that's a lot of information if you're just trying to do some controls stuff.

Incidentally, I'd be happy to talk about this with you in more length. (MORE length? Jeez, you'd think I'd talked enough already.) Feel free to contact me at jamesi followed by @sagerobot.com You can also get the phone number for my office from our website at www.sagerobot.com

-James Ingraham
Sage Automation, Inc.

P.S. Yes, I am aware that VxWorks makes all C global variables REALLY global, so that you can in fact have a variable "temperature" in a main program that is then accessed by an HMI program using the same tag "temperature." I didn't mention this because portability was mentioned as a desire, and because I got the impression that Travis didn't want to spend thousands of dollars on development seat.
 
K

Ken Emmons Jr.

Travis said:

> so far off. Is it that hard when programming with an OS (I
> typically do not have an OS to deal with) to pass variables
> (inputs and outputs) from one application to another? It

Its not that hard, use shared memory. I think one of the points someone else made is that to go from windows to linux to mac is tough using the same exact code with respect to networking and IPC, such as sockets, shared memory, message passing, pipes, whatever. One thing you can do is write a function called "OpenSharedMem()" or something like that and port that to different OS's.

Driver development is also an issue as someone mentioned. Ethernet has the advantage that although the calls to create a socket are somewhat different they do almost act the same under different OS's, generally speaking. Drivers for Modbus probably exist for just about anything.

KEJR
 
James Ingraham said:

> specific. And shared memory has lots of issues. I could go
> on about it for quite some time, but it boils down to this.
> Let's say you define a variable in your main application
> called "temperature" that is of type float. There is no way
> for an external program to view that variable or write data
> to it. Not possible. Instead, you'd create shared memory,
> both programs would map that memory, and then you would have
> to carve out a portion of that memory big enough to hold a
> float. Then you'd have to go to your GUI program and point
> to that same spot. If you mess up and call it "weight" in
> the GUI program, you'll never know until you start getting
> bizarre behavior of the system.

I've done this, and also have seen it done in commercial products. You define a header file that both the controls C file and the HMI C (or C++) file include. In this header file you define a structure that will reside in shared memory (via pointer) that includes arrays of floats, your ints, [maybe] strings, etc. You also have enumerations or #define statements that correlate to the indexes of these arrays. You could break out the "assignment" of the array indexes into a separate header file if you wish. No risk of name swapping problem that you mentioned. The reason people get into this problem on separate systems is that the projects don't always have the common include file, or what is being called the "common tag database" today.

KEJR
 
In reply to Travis:

>1st- the main c-application that is
>doing all of the logic and control
>2nd- the user interface portion that
>just passes info back and forth to my
>c-application

This is what is often done with our
http://pvbrowser.org

There is a shared memory and a mailbox you might use for communication between to processes.

Here is the class for the shared memory:
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlSharedMemory.html

Here is the class for the mailbox:
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlMailbox.html

By browsing into the source code you will see the #ifdef statements that make the library itself portable. (Linux/Unix/Windows/OS-X)

The GUI part with pvbrowser can be done very easily and comfortable.
 
C

control_lurker

One comment I would make about using any open source package is to read the license agreement carefully. Most indicate if you are writing the application using open source your derivative work also becomes open source and you must provide the source to your customers. This is fine for internal use but may not be palatable for consultants, integrators, etc. Just don't get caught like LinkSys using open source then not wanting to provide the source code later on. You will lose the lawsuit in the courts or in the court of public opinion.

On the topic of writing display vs code it seems strange that people have been working with these two mediums for over 20 years and we still don't have an good, integrated, simple , cross-platform, solution yet. The closest I have seen is LabView in which you have a display window and code window. It is slightly cross platform but kind of expensive.

Just my 2¢
 
In reply to James Ingraham:

> As I said, there is no standard for Inter-Process Communication in C.
> Shared memory is the most obvious way to do it, although the implementation of that is platform specific.
> And shared memory has lots of issues.
> I could go on about it for quite some time, but it boils down to this.
> Let's say you define a variable in your main application called "temperature" that is of type float.
> There is no way for an external program to view that variable or write data to it.
> Not possible. Instead, you'd create shared memory, both programs would map that memory,
> and then you would have to carve out a portion of that memory big enough to hold a float.
> Then you'd have to go to your GUI program and point to that same spot.
> If you mess up and call it "weight" in the GUI program, you'll never know until you start getting bizarre behavior of the system.
> If you later decide that there's another variable you want to share and you didn't make it part of the shared memory in advance,
> you will have to re-factor your main program.

This not a problem within our project:

Here is the shared memory class (for most operating systems in use):
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlSharedMemory.html

Now define:<pre>
typedef struct
{
// todo: your data goes here
}MyData;

and use our shared memory:
MyData my_data;
<snip>
shm.write(0, &my_data, sizeof(MyData));
and in the other program
shm.read(0, &my_data, sizeof(MyData));
You may have my_input_data and my_output_data of course.
Useing shm.read()/shm.write() you automatically use a mutex. If you do not want the mutex use
MyData *my_data = (MyData *) shm.getUserAdr();
</pre>
This can be easily mapped to our
pvbrowser which does the GUI.
 
I've replied to James Ingraham's comments because he has put the issues more clearly, but the answers are really directed to the problem in general.

>As I said, there is no standard for
>Inter-Process Communication in C.

Technically no, but there are a number of common methods for POSIX/unix, and C and unix are very closely tied together. Unix as we know it wouldn't work without doing lots of IPC. Many of these also work with MS Windows, because Microsoft copied quite a few unix features (you can think of MS Windows as being VMS, unix, and CP/M all tossed together in a blender and switched on "puree" for 5 minutes). Most other modern operating systems you are likely to encounter are either unix derivatives or unix clones.

The first thing that really needs to be done with this project is to put together a realistic list of target platforms and use cases. Who is going to use this, where and how are they going to use it, etc. The technical solution has to be derived from that.

>Yes and no. (HTML can't do this at all
>by itself, by the way. You'd have to
>use CGI at the very least.)

A web server is needed to serve the files, and Javascript code is required to poll the server for new data and to update the current page in the background with new data. Updating the page on the server and reloading a new page for each update isn't going to result in a very useful HMI unless your needs are extremely basic. A "web server" doesn't necessarily mean something like Apache however. It's not that difficult to make a simple web server as part of another program.

>Java can
>talk to C... but only if you provide
>some kind of bridge. Typically, that
>means creating your IPC in C and using
>Java Native Interface (JNI) to call C
>code to do the actual communicating.

For raw binary data you also have to consider word sizes, padding and alignment. You either have to really know what you're doing or make sure you use the exact same compiler (including the same version) for both programs. That includes even using C for both programs.

A better solution is to use a well defined protocol such as Modbus, or else encoding the data using JSON to create your own ad hoc HMI protocol. A lot of "simple" things are not so simple once you get into the details. HMI systems rarely need high performance just to pass data back and forth and it's generally a good idea to have an abstract representation for the data to keep the two programs as independent of each other as possible, so that minor changes in one do not propagate themselves into the other.

>this is a deeper hole than you thought.

Yes, like avoiding dead locks in message transactions.

>You may ask if this is the case then
>how the heck do databases work. Short
>answer; I don't know the specifics.

They run a server that binds to a port and listens for clients. The clients send commands in the protocol that database expects and wait for replies. Each database has its own protocol and you typically use a client library to handle the communications. Conceptually, it's no different from how Modbus/TCP works.

There are also "embedded" databases such as SQLite, but these "belong" to a single program and can't be directly accessed by multiple clients. They're called "embedded" databases because they are "embedded" into the application itself rather than running as a server.

The problem with this project seems to be that it's too open ended. It really needs to go back to the basic "who, what, when, where, and why" before figuring out what the solution should be. Let's look at the issue of portability: "(I would think that I can use the c-application on everything from a RTOS to windows 7 or OSX so I can write the program once and use for embedded micro-processors or a desktop on a plant floor)".

I'm going to guess that the control application needs to run on one computer, and the HMI needs to at least be capable of running on another (otherwise, it's not very flexible, is it?). What about viewing the HMI on your wifi connected iPad (or RIM Playbook, or Android tablet)? If you're going to write native code for each platform, you will have to write your HMI in multiple languages because the platform providers don't allow C on all of those.

For the control program, C sounds great, but you're going to need to set some platform targets as writing something in C doesn't suddenly make features available on platforms that don't have them.

For the HMI, there is a cross platform UI technology and it's called a web interface. Any other solution can address only a subset of those platforms. If you are happy to limit what HMI platforms can be used, then you need to make a list of what targets you need to run on.
 
J

James Ingraham

Example from pvbrowser:
<pre>
>Now define:
>typedef struct
>{
> // todo: your data goes here
>}MyData;
>
>and use our shared memory:
>MyData my_data;
><snip>
>shm.write(0, &my_data,
>sizeof(MyData));
>and in the other program
>shm.read(0, &my_data, sizeof(MyData));
</pre>

Nifty. Several points though. First, I trust you know what you're doing, rather than this being the first time you've ever written shared memory code. Second, correct me if I'm wrong, but isn't that C++? Third, I think our points are very similar; it would be beneficial to use existing solutions rather than writing from scratch. You happen to be advocating pvbrowser as the solution, which is fine. I didn't mention it mainly because I don't know enough about it. Maybe one of these days I should correct that.

>Useing shm.read()/shm.write() you
>automatically use a mutex. If you do not
>want the mutex use
>MyData *my_data = (MyData *)
>shm.getUserAdr();

I guess the mutex is a good idea, but does that not create a chance of deadlock? What happens if a program terminates abnormally right on the memcpy line in write, thus not executing myunlock? I have to admit that I haven't looked at stuff like this in a while, so I may just be missing something. But the point remains that it takes a pretty decent programmer with some experience to understand all the nuances of this.

-James Ingraham
Sage Automation, Inc.
 
C
I had to wait until I had time to respond a bit on this, one thing the poster did find out is that programmers tend to be somewhat opinionated:^)

It's all good advice too:^)

But overall, what I find most striking is the difference between a *NIX systems programmer's approach and modern practice for application programmers. It would be good to look at the _size_ of some of these solutions. A database, this library, that library, Java, a whole scada system, a general class messaging system? The only thing not suggested was kitchen sink 2.1:^)

Let's assume there is going to be a separation between the control part and the GUI part. Let's also assume you may want to run them on the same box or separately on Ethernet or the Internet for flexibility. That implies sockets. Let's go along with the idea that we want to program in C. Let's assume this isn't going to be a life's work. With those constraints, and the most severe constraint that it be cross platform and run on systems smaller than a Cray Supercomputer or the latest Windows requirement, whichever is smaller, my decision tree points to a tiny webserver and a lightweight browser. From my viewpoint this is a huge amount of software, but not anything like some of the suggestions. Second choice would be Glade and GTK and live with the three main platforms for presentation. Of course, I'd use NCurses and Linux on both halves and less than 10 pages of code.

Regards
cww
 
T

Tallak Tveide

>One comment I would make about using
>any open source package is to read the
>license agreement carefully. Most
>indicate if you are writing the
>application using open source your

This is a common misconception. Most licenses state that any modifications to the library itself must be made open source, while if you use an open source library you do not need to make your entire project open source. As you state, read the license. Many new libraries are released under very liberal licenses like the MIT license so that there is no discussion whether this is an issue. But for most cases, this is a non-issue
 

In reply to M. Griffin:

> For raw binary data you also have to consider word sizes,
> padding and alignment. You either have to really know what
> you're doing or make sure you use the exact same compiler
> (including the same version) for both programs. That includes
> even using C for both programs.

A similar approach would be to compile a shared memory "server" driver module whereby the data structures and function calls to access those data structures are compiled at once. Then your native C library access functions are in sync with your SHM structures. It also makes it work with Java, C#, Python, etc.
 
Thanks to all that have written in this post!!! I am really glad there are so many people that have such strong opinions in one direction or another that are willing to share so that I can research each. I have been looking at all of the responses while learning about the different technologies mentioned in each response which is why my response has been slow (still not complete but wanted to respond and thank before to much time passed).

I mentioned previously that I wanted the 2-Step approach of a gui app and separate main/control app. This approach I figured would be a little more difficult and definitely not as clean as a single app but I figured I would be asking way to much to get the gui drag and drop ide that would also let me hand code the integrated main/control app and then compile everything down to c. Most of my gui's are pretty simple and I use a CAD software to create indicator lights, toggle switches, and appropriate animated gifs where needed. My customers tend to respond to the pretty wow effect of animations and typically base my entire control program on how pretty my screen shots are instead of intuitiveness of the gui layout or efficiency of the control algorithms. Usually takes me longer to layout the gui than write my control code but a necessary evil these days!!! Anyway the 2-application approach I figured would allow me to focus on the control code which is what I really care about when designing and would be very portable (at least I thought it would be with c and now that I look a little deeper into it I may have to really consider platform(s) as I am writing the code even if in c. Still no big deal I think. I have looked into the higher level languages like python that was mentioned but I have liking for low level embedded processor boards which if I learned and programmed in c I have the ability to go down to very low level programming as well. This may be something I need to let go of for now if I am taking to much of an unorthodox approach by not making my gui and main app all 1 app. Smarter people than me have decided common ways to do things in programming (although I am not scared to venture outside the box) and would like opinions on just how far I am going outside the box with the 2app approach. In reality my target will be (most of the time) either a desktop computer for SCADA type apps and panel pc's running typically an embedded Linux or windows for the turnkey products we sell that include controls on board. I will interface most of the time with modbus remote I/O for any I/O needs.

Another advantage I was seeing from the 2-step approach was that I don't have to consider my gui when debugging. Personally, I am fine with 1's and 0's but my control algorithms most of the time seem to be graded on how pretty my indicator light renderings are (not really a graphics guy myself but have learned to be because of this). This way the gui can be debugged separately from the main app. I have been thinking and even downloaded (but not played with yet) M. Griffin's software because as for my gui needs I thought the web was a great out of the box thinking (or at least my box). Most OS's have a web client capability which would give me cross platform for the gui and then connect to my c-app (still undetermined method and am looking at all of your suggestions). Thank you M.Griffin for the suggestion and would be interested in what others would have to say about this method. My only concern for this may be speed. Do any of you think I may have problems with this method when I am in speed critical applications? The more layers (i.e. virtual machines) I would think could affect speed and motion control applications but maybe ok for portability and non-speed critical applications.

Again thanks to all who have contributed as you have saved me many nights sitting up to study and understand the best routes to go!!!!!!!!!!!!!!!!!!!!!!!!
 
Top