Hello everyone, so I'm Fabia, I'm a PCB designer, so I designed PCB for living and I also
do some kick-up development on my free time.
And today I want to talk about collaboration, the collaborative design between mechanical
and electrical software.
So there's just a few words that we come quite often, there are E-CAD and M-CAD, so E-CAD stands
for electronic computer-edit design and M-CAD is the same thing, but for mechanical.
So, kick-ad is an E-CAD and that well for people in this room, free-cad is an M-CAD.
Does defining those words because they will come quite often?
Okay, and so basically in kick-up, what we do is we design PCB, so stuff like this, and
in the an M-CAD software, we design most of the time, the box containing the PCB.
And the topic today, so it's collaborative design, so how can we have some kind of collaboration
and synchronization between both worlds?
One option, though, is that E-CAD and M-CAD, none of the same software, because there
are some packages that try to mix both of them, and then collaboration will be a different
topic.
So in this presentation, we'll go as follow, basically, and introduce a few ways of doing collaboration
of some simple ones and more complex ones, and then we'll deep dive into IDX, basically
what's the feature of what hard works, and then we'll discuss about the kick-ad implementation,
which is for now a proof of concept, it is not ready to be released, but for now, it is
a proof of concept.
So let's go with basically how we can do collaboration with E-CAD and M-CAD.
Why do we want to do that?
So during this presentation, I used the PCB new icon, which is the green, green thing
here, to represent the E-CAD world, and the gear icon to represent the mechanical world.
And basically, if you want to collaborate, if you want to have collaboration between both
software, it's because we are designing together the same devices also, and we don't want
to do something like design the PCB build the PCB and then design the mechanical part around
it.
We want to design them together, this is time saving, because what we can design at the same
time.
And also, most importantly, it allows us to take M-CAD consideration into while designing
the PCB or the other way around.
For instance, maybe we have, I don't know, like a gear or moving part or something, and
so we kind of have a component here.
And the E-CAD tool needs to know about it.
Last but not least, the primary use of collaboration is making sure that it fits, because
well, there's no thing worse than having your PCB, having your box, and they don't
fit together.
That can also happen, for instance, if you have, well, PCB revision two, we have with
mechanical part version one, and that is well-own issue.
So, ways to do collaborations.
The very old way, I hope we don't use anymore, is basically sending drawings, like
a PDF or paper, we could do this on paper.
So, in this example, this is a M-CAD driven collaboration, at least this changes M-CAD driven.
And so, basically, from the M-CAD software, we will print or send a PDF, we're containing
the 2D drawings.
Then the E-CAD user will need to basically convert this information into the E-CAD software.
That is slow, so it's not very good.
The errors can happen when you do that.
At the moment, you have conversion, especially when they are done by human being, there
can be errors.
Also, if the E-CAD user has something to say, like, for instance, maybe the E-CAD user
needs more both spaces or something, or maybe there's a problem with a specific location.
Basically, what we need to do is to print short your E-CAD software and to send it,
we are messaging up, or you could see it next to your M-CAD designer.
That is also a possibility, but basically it's like finding, walk around to do, have some
feedback.
So, this is not what we use to, this is not what we do, usually today, what we do is basically
we replace with the rowing with a compatible file.
So, if we have a change from M-CAD to E-CAD, the file can be too deep drawings, but
digital, and that can be understood by the E-CAD software.
So, we have the XF, SVG, and IDF.
And in the other way around, we have pretty models, like step or all the 5 formats.
The process is simple, you don't need to convert data manually, the conversion is somehow
the software, so because there is no manual conversion, we have no errors are limited,
you could still have some conversion errors, but that's more like running stuff, so
it should be within the margin of manufacturing.
But see, we still have the issue of the feedback.
So, well, we need to just need that we need to message each other, see what's wrong, we need
to maybe change the part of the board, part of the mechanical part, it's not that great,
but it works.
The one I want to focus about today is to have some kind of synchronized collaboration,
where basically we take the users out of the collaboration process.
Basically, the E-CAD tool and the M-CAD tool will talk to each other directly, using a protocol
to file something, it is still managed by the users, but that's how directly to each other.
And in order to do this, we need to use the same 5 format, the same language as 5 formats
are concerned, and that basically means that feedback can be easy.
I mean, if we are using the same format, we can go both ways.
And so, here comes basically IDX.
IDX is the last kind of collaboration where we have collaboration directly in between the
this software.
IDX is an acronym.
Instant, it stands for incremental design exchange, all of the specification are available
online at the CADM-CADO.org, and well, just like any collaboration, 5 format or protocol,
you can define electrical stuff like the borderline, you have rural areas, maybe in this
area you are limited to, I don't know, 5 millimeter height in component, maybe you have
placement constraints too, for instance, the connector definitely needs to be in a specific
place of the border, you cannot meet anyway.
That's already covered by a lot of design exchange protocols, but the main change here
is incremental.
Basically, instead of sending all the design every single time, we are using incremental
changes.
So we have our starting point, and then we only send the changes.
So with this workflow, we can also accept and reject changes, we can tip and history of it,
and we can also add a comment, that is the feedback.
As an action, we can then add replace remove components.
There's also the notion of object ownership.
Maybe there are some components that are owned by the mechanical world or by the electric
world.
For instance, if we take a connector, the connector is most likely to be a mechanical dependent
because it needs to fit right in the mechanical part.
So the idea is, the mechanical designer is set as the owner of this connector, and then
in the eCAD what this connector would be locked basically, and should not be moved by
or removed, moved or something else altered by the eCAD designer.
One thing with IDX2 is that it can be synchronous or asynchronous.
So you could have some holes on a free time, or you can do the all-way, well-way, like
the current way, actually, of having like triggered synchronization.
IDX can be quite complex, but it is adapted if, for instance, you have several iterations.
If your design is quite complex, you might want to add IDX, because there will be a lot
of iterations, and also IDX supports having several eCAD and M-CAD users, though this is
not fully implemented by most software, but it is something that IDX is thought for.
So let's see how it works.
The first thing is to define a baseline.
The baseline is the first exchange in the IDX synchronization and collaboration.
Usually, you have the board outline, so the shape of the board, you have the collaboration
information like what software, what version, who is the author of the baseline, and you
could also have constraints, like the limited height zone, no component zone, or maybe
no road zone, or via zone, the plenty of constraints.
And so here's a small diagram where the design is driven by M-CAD in this case, at least
the baseline is driven by M-CAD, and so the baseline is focused sent from the mechanical
world to the electrical world, and then the electrical world basically accepts it.
There is no way we should not reject the baseline, because if we can't agree on the very
first message, we cannot agree on making change on it.
So this was M-CAD to E-CAD, but obviously you can go the other way around.
So this is defining the baseline, and so no about changes.
So changes, there can be plenty of changes, maybe we can move, and we want to move an element,
we want to add one, we want to remove one, or we want to replace it, an element can be
a component, it can be a via, it can be a connector, it can be a board shape, basically anything
that can be incorporated on.
So in this case, with the diagram, basically the electronic world wants to submit some
changes, so it will send the changes from the electronic world to the mechanical world,
then from this point the mechanical user, the mechanical designer, can accept or reject
changes.
Independently, it does not have to be in bulk, it's not like accept or reject all.
You can choose what you accept and what you reject.
And then you send back the list of accepted and rejected changes to the electrical
world, and there you have a synchronized execution of changes, accepted rejected.
There is an optional message, which is basically an acknowledgment, which is called the clearance
message, which is not most of the time not implemented, but is defined in the protocol.
So things are great, we have our baseline, we have all the changes after that, and well,
it's incremental, so if something goes wrong in the middle, we are getting out of
sync, and we have an issue, and so this is basically the third kind of user that we have,
which is rebased lining, rebased lining is the action of resetting the collaboration.
It should only be used if we are getting out of sync, if we have an issue with the collaboration.
This getting out of sync can happen, it happens, for instance, if you have a crash in a software
processing IDX. If this happens, well, then we are like in a middle state where one thinks
the message is sent, the other one is waiting for it, and so the only things we have to do is
basically clear the history of the IDX story, and then we have to send the baseline back again.
So basically it's starting fresh.
So this is basically the kind of messages, so baseline, changes, rebased lining.
So in practice, I'm talking about protocol messages, but in practice, those are files.
Those are usually XML files, can show you real quick, if I can try and drop this window,
yeah, this is basically this board, this board is as an example file provided by the
eCADM.org website, which is basically used to test basic input of IDX, and so there's
like component rotation, there's like rule area, there's plenty of stuff, like limited
high zone, a component from here, limited high zone, maybe no components zone, all of those
are components, let me just maybe get it back here, so you can get the other side, yeah,
no, you got it, yeah, that is okay, come on, let's see, so that is basically the other
side where we have the component rotated several times, the same component, okay.
And so this test file is here, let me just try to get the window, okay, and so we have
a edit part, which contains information about the calibration, and so for instance, it's
about information about the participants, the participants, the names, the date of the change,
for the baseline, in this case, this is the baseline, and we have information about the software,
software names, software revision, in this case, the example file has been done with solid
work version 24.4, and also the default length units, you can define length units per object,
but there's like a default length, and well, let it be millimeter or inches or whatever,
so header with collaboration information, and then the body with information about the items
to be collaborated on. In this case, basically, I'm not going to go into details, but basically
you have the box set, the curve sets, so which are the curves that define the bottom line.
So that is the baseline header plus body. When we want to make a change, it's basically
in structure with the next cross section, which is the process instructions, and they
have to basically reference objects within the body, so this is an incremental change, and
so we have, as we can see on the slide, the new version, we try to find it on, you have the
new version and the previous version, both of them are to be found within the body, and we
have version 1, 0, 0, and version 1, 0, 1, and basically, we also have a new item, and
this is the right time tags, so this means that the software knows which one the previous, which
one the new, and so we can, and so we can make the change. So now about sharing IDX files,
because so far, it's always a files, and we still emailing them or something, so we could have
a direct communication. Think is IDX is usually implemented by close source, popularity,
e-card, and MCAT tools, which means that basically, they're not sharing implementation,
so we could have some kind of server-based information, because if we had direct peer-to-peer
communication, that would be an issue, if for instance, if we have the electronics being done in
Europe, and the, and the mechanical part done in the US, for instance, because of time zones,
so the computer will need to be on the same time, basically, and that's within an issue.
One way to have a server though, that is pretty easy, this day is to have a network chat
folder, this is usually the method that can, that IDX is used with, and basically, the e-card
software, there's simply a rise of files in the shut folder. Also, you could try just emailing
the files, but not the best way to do, and maybe you could load the wrong file, so that we could
get out of sync just because of that kind of thing. So this is an example of, this is an example
of one change or change or baseline for instance, but so let's say at some point, we have the
e-card user on the top left and the m-card user on the bottom right, so at some point the
e-card design decides that the design is ready for synchronization, so it basically hits a button
in the in kick out of the electronic control. The software will compute the differences, the changes,
or the baseline depending on what step it is, and then it will write the data in the shut folder.
The m-card tool will detect that there's a new file, and will notify the m-card user,
then the m-card user reviews changes, accepts rejects some of them, all of them depends,
and press OK on the m-card tool, which will write the IDX file back in the shut folder, and then we go
the other way, we are going back to e-card where we detect that there's a new file and we notify the
e-card user, and well I'm talking about detection, but some implementation that just rely on
just emailing and saying, oh there's a new file, please hit the synchronization button.
So that is basically the workflow with IDX. So in kick out, trying to implement this,
as I said, it is for now a proof of concept, it's not ready to be merged, far from it.
There's a merge request at the moment, for it, maybe we'll be kick out version 11,
if we're making a progress on this topic, maybe we'll focus at 12, or maybe for another kick out.
And currently the merge request focuses on decoding information from
the IDX test files, and it has been tested with CMM Solid Edge, which implements IDX,
so which is a mechanical tool. Regarding the features,
basically, so as I said, basically that anything that is e-card to m-card today is not ready to
support it, but it is to be worked on. And so we can read the baseline, we can read changes,
and we can send back the change response, saying accept or not. We have a bit of graphical user interface
to, like a differential review, because when you have changes, you want to know what was before,
and what will be. And also we are trying to handle the repository. The repository is something
in this, in the IDX meaning, it's basically having an extra representation of the board
that is only used for collaboration. It is not used for kick for design. It is the representation
state of the board. So how can we, this is prototype interface, most likely not the one that
will arrive in kick out if it does, but this expanded workflow little. So basically you have a
collaboration folder that you need to set. This is basically where the IDX five will be written
into. You can configure IDX because, well, IDX does several versions. Today, I think the last version
is like 4.50 or 5. But maybe the other software only supports up to IDX version two.
Then you have the IDX history. Well, this, this case, this is not sorted, but you have the baseline,
you have the change, and you have the response. This is basically for testing purposes,
you have the software that's coming from, and you have the date. You have a preview of the change.
In this case, the change is pretty simple. It's just, hey, here's a new board. It's,
it's outline is very tumbler. And you have there here a list of change, in this case, that's only
one. It is marked to be accepted. And, well, they do it, it's improvement. So now,
this is the basic collaboration, but there's quite a few things that IDX enables.
First of all, well, because this is a shelf folder, it is possible to have not one-to-one collaboration,
but one-to-many. So in this case, basically, we just connect all the e-cub, all the m-cuts
software to the shelf folder, and the e-cuts software to the shelf folder. That is useful if you have
one single piece of PCB of design that needs to be integrated into various mechanical parts,
that. If you want to reuse your PCB for various devices. There's one question, though,
that is, how can we add a component in the m-cut wall, and have it shown correctly in the
e-cut wall, because m-cut and the standard m-cut library, and e-cut and the standard e-cut libraries.
So, basically, we need a bridge, could be a product that has management system,
but it could be also a CSV file or something. Well, basically, what we need is to have
link between the component reference, e-cut reference, and m-cut reference.
And then, with this workflow, we can add a connector in the m-cut, and have it shown correctly
in e-cut. We can also add a component in e-cut, and have it shown with a correct,
pretty model in m-cut. Talking about IDX, I said that IDX usually implemented by
close source proprietary software. So, you're going to find IDX in big companies, not very small
ones, because it's worth, it's worth quite complex at the beginning, I mean, to set up.
So, here, I represented a red e-cut tool and a red databases, those are close source.
Maybe what we can do is to replace the close source with an open source one.
But, in this case, we have an issue with that Kika cannot understand that the close source
proprietary database, and that there's one thing that Kika people are really good at
is making importers and converters. We have quite a lot of converters at the moment for libraries.
And so, in this way, we can basically use Kika for in place of the proprietary
e-cut tool. There's one issue, though, is that there's one arrow, this one, that is one sided,
because we cannot write back to the library. So, actually, we still need to keep the close source.
So, it's not so much about replacing, but offering an alternative. Maybe for all the designs,
like, ready to be released, it is important to keep the proprietary tool within the company, I mean.
But, maybe if you want to do a prototype, a prototype concept, so like that, you want to go fast,
you don't want to get all the workflow of the company, then you can be used the alternative workflow.
Talking about the IDX code by itself, today it is the proof of concept is coded within Kika,
but it is coded in a such a way that it is possible to extract it quite easily without dependencies,
for instance, in Kika, we love using WX, and well, that's a use dependency, but yeah, so basically,
if I not to use those kind of dependencies, and so if we could extract it, we could share the implementation
of IDX with Kika and MK2, and then we would have synchronization and doing the work only once,
not every single package needs to be do the work independently, and that's pretty much the end of
presentation, so just as a conclusion, so IDX is a tool for synchronization and collaboration
between E-CAD and MK2, there are other tools. This one is more focused about on changes,
incremental changes, stories to flag that, but there's one thing that does not is replacing
designers talking to each other, it's still important to be able to make a message each other,
it's purpose in not to replace discussion, and as of today, there's a proof of concept in
development, and there's a metric quest for this, but it's not really yet again, and I'm
personally looking forward to sharing this implementation and maybe testing it with an open source
MK2, that is pretty much all. All right, questions for Fabian.
So can this be abused to be used without an MK2, for example, for a multi-board design,
so being able to put them strengths from one board to another one? I think it can, yeah,
the question was got it, yeah, so yeah, I think it can be used in order to
to, yeah, as you said, abuse it in order to have like variants stuff like that, but yeah,
there it's not only for E-CAD in MK2, if you have for instance, maybe anything that connects
collaborates on a PCB, could be maybe EMC tools, could be a, could be product data management tool,
where maybe one designer wants to change a component because it's not fit with the company policy or something
at that. Yeah, not the questions.
And normally you have product data management or technical data management system in between
that coordinates collaboration and all the work packages that need to be separated between
teams. There is no concept of that in KKK, is there something that would be implemented during
this metric, or is it something that comes later? If I understand correctly, the question is,
can we, do we intend to implement some kind of PDM interface within KKK? Yes, normally you start
a session from MK2, get the collaboration information that then gets written into the IDX.
I think doing just bear IDX is quite a lot of work, but definitely if there is a PDM interface
that can be developed in the future, it can be good, but I think that is not in the roadmap for now.
Thank you.
All right, thank you Fabian, and I guess we'll have a brief break before Morgan starts.