Thoughts on Graphical/Visual Programming Languages

‚ÄčI dont see a lot of information on personal blogs/diy projects regarding the use of Visual Programming Languages, but this is what I use in my current role as a Control System Engineer developing engine control and test systems. I actually call them graphical programming languages, so if I use the terms interchangably here then I’m actually talking about the same thing. We use visual programming languages for engine ECU control code and Test Cell control code (Simulink + Stateflow and Labview respectively). I believe graphical programming languages are pretty widely used in the automotive industry, and appear to have massive buy in from plenty of other industries too. I think its easy to see why.


Simulink was classically used for simulation and modelling of physical systems, but I believe it is also now a staple in the control engineer’s toolbox. It essentially allows you to ‘wire up’ your data flow paths between logic blocks, and Stateflow allows you to create a State machine as simply as any flow chart tool. It then autocodes this into C code, and compiles it to binary to run in real-time on your hardware of choice.
I’m not sure what the hard core *insert text based langauge here* coders would think to this, perhaps specifically embedded C coders, but personally I believe it’s fantastic. I’ve coded a lot in PHP, and a little bit in C/C++/Java etc. Simulink is far less prone to typo-style silly mistakes, weird logic written by a wizard-in-the-zone, addressing incorrect data and state/data mismatches. It is also much more clear with a quick look what the logic is doing, the ‘code’ could be directly pasted into a management presentation to illustrate what some logic does. Debugging (which is required less often) is much faster to isolate the problem as the code is easier to understand. The fact that you mostly want all of your code to fit on one screen also massively encorages code modularity which therefore encorages unit testing and code reuse. The biggest benefit of all is the speed of development, but i suspect this is in part due to a goos compreshensive library provided with simulink. However, it is still faster to develop new logic than in C based languages, and mostly it works second try!
To me it seems that graphical languages work very well for embedded applications, perhaps because they are appear analagous to analog electronics which, when well designed, can perhaps be neater and simpler than a digital electronics solution. 
There are of course some cases where a graphical language doesnt quite make as much sense, for example, I really wish I hadn’t used LabVIEW to try and process large sets of engine test cell data and generate reports. Even MySQL and PHP would have been easier for this. Simulink also isn’t so good for code which needs to be written in a specific way for speed purposes (since it’s autocoded) however, I suspect it can still achieve better code optimisation than the average coder – certainly better than my C code!
I’d be very interested in hearing what other’s experience is with graphical verses text based, and primarily whether they have had specific issues with Simulink for embedded applications. We currently maintain two different Engine Control architectures in Simulink using the OpenECU platform, and while we are still in the relatively early stages of product development, I just couldn’t imagine doing it any other way – and this will become even more true as our systems are taken to a higher level of refinement and into high volume production. 
I would also be interested to know of any other (open source/free) graphical programming languages, as the biggest disadvantage for my personal projects would be the cost of a Simulink/LabVIEW buildchain.
Wikipedia does provide a long list of other ‘Visual Programming Languages ‘including one which looks of particular interest called Flowcode, which is designed for the Microchip range of chips, including the ubiquitous and cheap Arduino platform. Flowcode is available as a free download, so I may give this a go for some of my home projects. One disadvantage may be that it would generate code which would be less compatible with porting over to the ESP32 or ESP8266 than code written in the Arduino platform.

4 thoughts on “Thoughts on Graphical/Visual Programming Languages

    1. Scott Snowden Post author

      I’m in South of England – I haven’t been working on this recently, but I do professionally develop engine control systems still.

      Reply
  1. Raymond Chiu

    Visual programming languages are great for rapid development, however, that being said, if there is a problem with the underlying code generation or you want to create new GUI functionality, one must understand the language (C++) to be able to trouble shoot it. Even then this no guarantee that the problem is at this layer and not at the compiler: if this were the case then you would need to move down a level to evaluate opcodes of the target MCU.

    Reply
    1. Scott Snowden Post author

      It is helpful to understand the foundations of things you are working with – but at some point you have to trust that the building blocks you are using are not faulty. While I could theoretically go into Simulink’s autocoded functions to debug something, if I suspected a problem at that level then instead I would be calling their support and expect them to investigate.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *