Electrical schematics appearance is not (so) important

In my dealings with users of EPLAN Electric P8, whether they are new users or experienced ones, there is a topic that keeps coming back quite a bit.

If your employer decided that you had go to back to using a drawing board to produce your electrical documentation, chances are you’d think it’s April 1st. Everybody working in a production environment nowadays is expected to use a CAD software of some sort to create production documents. The « CAD software » versus « drawing board » discussion is one that nobody would even dream of re-opening.

But still, even though we use CAD software tools for electrical engineering, our minds are still trapped within a 2D world, the pages on which we create our schematics. For our mechanical design colleagues, the shift has been slowly introduced some forty years ago, with wider adoption since the mid 90’s. The switch from 2D to 3D allowed mechanical engineers to think about what was being designed in practically the same way as it would eventually be fabricated. A threaded hole here, a bend there, a weldment between those two parts and so on. With this new paradigm, we started thinking in terms of model rather than in terms of printed page, which are now merely views into the model. A by-product of the modelling activities. Nobody wants to go back to having to capture the whole model in their mind, and then try to manually maintain a set of 2D drawings in sync with it.

With modelling, mechanical engineering activities were done faster, with much less errors, and as those systems evolved, reusing parts was now a reality. Today, by connecting those 3D models with ERP/PDM systems, we have dramatically improved delivery times, increased our product quality through reuse and have been able to promote the use of international standards.

Unfortunately, things have not evolved so quickly in the electrical engineering community, and being a very strong and vocal advocate of the modelling paradigm, I can’t help but get into those discussions.

My premise is that the very nature of electrical schematics is precisely what’s preventing us from viewing the problem from a different angle. Electrical schematics are based on a « language » made up of 2D symbols, and their interconnections, and so we have what is perceived as a « natural » match between the printed pages, and the conceptual representation of the controls schematics of a piece of machinery.

In the near future, we are bound to come across new ideas that will introduce the same revolution that we’ve seen in the mechanical world in the past decades. For now, we can still benefit from looking at our schematics as a model rather than the final result of our electrical engineering activities.

How? Here are some practical ways that can be implemented today, and for those lucky enough to have a software such as EPLAN Electric P8, they can leverage functionalities built from the ground up to support them.

1. View the equipment as a group of functions that work together to accomplish a goal. This is what’s known as functional design.

2. Think about the devices, or products, that are needed to implement those functions. This means thinking about the characteristics of those products, and how they physically connect together.

3. Think about the physical layout of the functions, how they will be located with regards to one another, and « slice » up this physical space in what we will call mounting locations.

4. Finally, think about all the further descriptive properties that can be assigned to those products. For example, a motor used to drive a water pump can have a function text that reflects its use in the context of that specific machine, thus helping production, installation and maintenance teams gain a better understanding of our machine as opposed to trying to infuse our equipment tags with magical numbers.

Those aspects of our equipments are precisely what the IEC/ISO 81346-1 international standard is built around. The function aspect, the location aspect and the product aspect work together to introduce a « 3D » view that will allow us to create projections, or views, based on the users, or customers, of our documentation.

For example, by introducing the location aspect, it becomes much easier for our warehouse colleagues to create bins of components divided by control cabinets. By using the function aspect, it becomes much easier to assemble our schematics from blocks that have been created, revised and honed over time, so much that we know them to be error free. Finally the product aspect allows us to define the individual vendor parts in such a way that we can perform validations about the number of wires allowed on a connection point and so on.

The EPLAN platform, of which Electric P8 is the flagship, is built from the ground up to support those aspects. Reports generated from the project have a very high added value that production teams will rely upon.

From a practical point of view, a point-to-point wire list sorted by gauge, colour and wire number, is of much more value than the electrical schematics for fabrication purposes. First, being based on the schematic, if this one is error-free, then the list will also be error-free. Then, having a list that gives a worker the wire gauge, the length, the colour, the markings, the source and target connection points, a termination method and even the routing within the cabinet, allows companies to recruit workers with a reduced set of skills with regards to being able to decipher electrical schematics. This reduces the possibility of errors introduced by personal interpretations of schematics.

Another type of data export, made possible by the product aspect, is transfer of the BOM to an ERP or PDM system. Those systems having revision management, make it very easy to compare the BOM between versions. It helps us avoid ordering too many of a very high cost item for example.

As things are today, a very popular CAD software, still heavily used in the industry, has ingrained the concept that the only way to view a machine is through the printed pages, when in fact, everything should revolve around the model, just like it does in the 3D world. The fact that we’re still using 2D schematics as the modelling tool is simply that we still haven’t found the new « language » that will provide a better mapping between the electrical reality, and the model.

A side-effect of this mentality is that draft people have turned their schematics into works of art, putting a lot of efforts in the way things look, but overlooking the most important part of our model, that is the data.

If we want to bring our companies to a greater level of competitiveness on the global market, we have to concentrate our efforts on what will bring the most value, and that’s not the looks of our drawings, but rather the properties, the data that underlies our designs.

How to parse C/C++ declarations

This was somewhere lying around in one my old HDD backups, and I always wanted to put it somewhere convenient for me to be able to reference it on demand.

It’s a post from comp.lang.c++ from when I was doing a lot of C++ development (most of which I’ve forgotten now that I use C# and .NET for EPLAN API development), but I think it’s just too good to let go to waste.

For those who might be interested in such things, enjoy:

Re: int (*t(int))(int *); // what does this mean?

Author: jim.hyslop
Date: 1998/09/17
Forums: comp.lang.c++.moderated, comp.lang.c++

In article <6tok7l$3ook$>,
« JER » wrote:
> Please give me the meaning of the declaration:
> int ( * t (int) )( int * );

The rules for parsing are:
Start at the identifier. Process to the right until you hit the end of the declaration or a closing parenthesis. Process to the left until you
hit an opening parenthesis or the beginning of the declaration. Repeat until the declaration is fully parsed.

So, the declaration is read as:
int ( * t (int) )( int * ) ;
10 6 5 1 2 3 4 7 8 9 11

1 – t
2 – is a function
3 – which accepts an int parameter
4 – [closing parenthesis – parse backwards now]
5 – and returns a pointer
6 – [opening parenthesis – parse forwards now]
7 – to a function
8 – which accepts an int *
9 – [closing parenthesis – parse backwards now]
10- and returns an int [beginning of dec – parse forwards now]
11- end of declaration – you’re done.

So: « t is a function which accepts an int parameter and returns a
pointer to a
function which accepts an int * and returns an integer ». The following
will work with your declaration:

using std::cout;
using std::endl;

int x(int *val)
  cout << "In x, passed value of " << *val << endl;
  return *val;

int y(int *val)
  cout << "In y, passed value of " << *val << endl;
  return *val;

int z(int *val)
  cout << "In z, passed value of " << *val << endl;
  return *val;

int ( * t (int v) )( int *) // Your original declaration
   // Exercise to the reader - how do you parse arr:
   // Hint: "=" is the end-of-declaration
   static int (*arr[])(int *) = {x, y, z};

   if (v < 0 || v >= sizeof(arr) / sizeof(arr[0])) {
      return NULL;
   return arr[v];

int main(void)
  // and how do you parse:
  int(*p) (int *);

  int count=0;
  while(p) {
     cout << "p(&count) returned " << p(&count) << endl;

(English) Creating pull lists reports

Désolé, cet article est seulement disponible en English.

(English) Fun with wire numbering

Automated wire numbering in EPLAN Electric P8 is certainly a great time saver. I’ve worked with 500+ page projects, and I wouldn’t want to go back to use AutoCAD.

While EPLAN is certainly flexible when it comes to wire numbering, sometimes a specific customer requirement leaves me pensive, and sometimes it becomes a challenge I have to accept.

In this example, the customer wanted all connections to motors to be numbered like this:

where the format is <Page number><Non-digit part of motor connection point designation><Counter per motor per page>

The picture above shows a proof of concept with two motors on page 2, and their corresponding desired wire numbers. The more motor on a page, the higher the last digit(s) of the connection designation. I’ve tested my solution with 12 motors on a page with the correct result.

Connection numbering scheme

The idea is to create a connection numbering scheme that defines a format group based on specific devices, in our case the motors, or devices with « MTR » as their DT identifier (note that in some cases the DT identifier for motors might be only « M », so this would have to be tweaked):

I placed that group at the top of the list so that those connections in that group are considered first when numbering. Once a connection is handled by a format group, it is not handled by groups further down the list, so you have to go from specific to general (top to bottom in the list of format groups).

This is how the group is defined:

The selected format elements are:

  • The Page name of the target component.
  • A block property defined on the connection currently being numbered (described in details below).
  • Then finally a subcounter defined over the signal/state of the connection (in our example, the same number on each side of terminals).

Here are screenshots of their specific settings:

Block property format for connections

Block property formats can be defined at the individual connections, but it’s better to define them globally in the project.

Under Project > Properties…, you can select the Formats from the Category drop-down in the Properties tab. This will limit the number of properties displayed in the grid.

Add those two properties to the grid:

Block property: Replacement text [1]:


Block property: Format (connection) [10]:


The replacement text table is defined like this:

It’s important to note the Operator is set to Regular expression on all 3 rows. Then the Source text is the actual Regular expression to evaluate, and the Output text is what we want to replace the match from the RexEx with.

The RegEx is used to detect which pin of the motor we are connected to, and then use « U », « V » or « W » accordingly.

The block property format is defined as follows:

Last function via connection point and target number (PLC), Connection point 1, Target 1: Name of target connection point (Full),

and then the Replacement text is set on the block property format:


By defining a block property format for connections at the project level, we implicitly assign it to all connections of the project.

The block property format « pulls » the Name of target connection point (full), meaning that it will return something such as:


And then using the replacement table and its regular expression, we convert that to simply « U ».

In the connection numbering scheme we have defined the Page, the Block Property, and a subcounter.

All together, those pieces of data form the connection designation as wanted by the customer.


I try to stay as active as I can on the official EPLAN forum in english at:

Registration is required, but free. If you have questions about this, or any related topics (or unrelated), don’t hesitate to ask there.



Problem when using UNC notation for master data directories

On a recent project I had to work with a remote team of designer.

The company provided me with the VPN client configuration and read/write access to a shared folder on one of their servers.

Everything went fine until I started assigning the master data directories within Eplan P8. I kept getting error messages saying that I didn’t have access to those folders. We checked with the IT team, and they assured me the rights were properly set.

It turns out that for some reason, if you use UNC notation, ie \\server\path\to\folder, then Eplan seems to want to have access rights to each folder within the path, which was not the case here. I only had access rights to the deepest directory.

The problem can be easily solved by using a mapped letter drive in Windows that is mapped to the deepest directory, and then use that drive letter in Eplan.


(English) Stopping PLC Tracking at terminal

Désolé, cet article est seulement disponible en English.

(English) Defeating the « Design Mode » annoyance

Désolé, cet article est seulement disponible en English.

(English) Refreshing the GED after changing project setting

Désolé, cet article est seulement disponible en English.

(English) From AutoCAD to Eplan P8

Désolé, cet article est seulement disponible en English.

(English) API to set arrow at graphical line’s end

Désolé, cet article est seulement disponible en English.


Electrical schematics appearance is not (so) important

In my dealings with users of EPLAN Electric P8, whether they are new users or [...]