Why the Q.Macs data structure seems to be so complicated?

Q.MACS uses a pretty complex data model. In fact, everything that the system transmits to the welding machines, are just parameters for the welding of various welds.

Qmacs Database Structure

The real structure of Q.MACS database

Usually in systems such as Q.MACS all these parameters are collected into packages – called Jobs. Job contains the parameter settings for the welding, divided into groups depending on the phase of the welding process: start, basic and final. In other words, – job is a welding scenario.

So why do we still need further items, although they are nothing more than a series of jobs?

Imagine the following situation: You have created a number of jobs for one weld, then for the next one and so on, up to the welding of an entire component. Later you may have to create a similar set for the welding of another component, or even for several components. And even if you save every job with an own name, from a certain point the orientation within so many jobs will be problematically and finally even impossible.

Q.MACS data model reflect the structure of real welded objects

Wouldn’t it be easier, you might think, to divide these jobs into groups? So these groups do not only vary by name but also are structured hierarchically, i.e. that one group can contain others (sub-groups, e.g. file folders in Windows).

Surely it would!

And exactly that’s why in Q.MACS jobs can be collected in so-called containers (or welding scenarios). Thereby, the structure of container corresponds to the structure of real objects. Continue reading