WEBVTT 00:00.000 --> 00:13.080 Hello everyone, so I'm Fabia, I'm a PCB designer, so I designed PCB for living and I also 00:13.080 --> 00:17.640 do some kick-up development on my free time. 00:17.640 --> 00:23.520 And today I want to talk about collaboration, the collaborative design between mechanical 00:23.520 --> 00:26.760 and electrical software. 00:26.760 --> 00:32.960 So there's just a few words that we come quite often, there are E-CAD and M-CAD, so E-CAD stands 00:32.960 --> 00:40.200 for electronic computer-edit design and M-CAD is the same thing, but for mechanical. 00:40.200 --> 00:47.160 So, kick-ad is an E-CAD and that well for people in this room, free-cad is an M-CAD. 00:47.160 --> 00:53.360 Does defining those words because they will come quite often? 00:53.360 --> 01:00.000 Okay, and so basically in kick-up, what we do is we design PCB, so stuff like this, and 01:00.000 --> 01:06.520 in the an M-CAD software, we design most of the time, the box containing the PCB. 01:06.520 --> 01:11.600 And the topic today, so it's collaborative design, so how can we have some kind of collaboration 01:11.600 --> 01:15.160 and synchronization between both worlds? 01:15.160 --> 01:20.000 One option, though, is that E-CAD and M-CAD, none of the same software, because there 01:20.000 --> 01:25.400 are some packages that try to mix both of them, and then collaboration will be a different 01:25.400 --> 01:27.520 topic. 01:27.520 --> 01:36.160 So in this presentation, we'll go as follow, basically, and introduce a few ways of doing collaboration 01:36.160 --> 01:42.720 of some simple ones and more complex ones, and then we'll deep dive into IDX, basically 01:42.960 --> 01:50.920 what's the feature of what hard works, and then we'll discuss about the kick-ad implementation, 01:50.920 --> 01:56.400 which is for now a proof of concept, it is not ready to be released, but for now, it is 01:56.400 --> 01:59.120 a proof of concept. 01:59.120 --> 02:06.480 So let's go with basically how we can do collaboration with E-CAD and M-CAD. 02:06.480 --> 02:09.160 Why do we want to do that? 02:09.160 --> 02:14.160 So during this presentation, I used the PCB new icon, which is the green, green thing 02:14.160 --> 02:21.680 here, to represent the E-CAD world, and the gear icon to represent the mechanical world. 02:21.680 --> 02:26.360 And basically, if you want to collaborate, if you want to have collaboration between both 02:26.360 --> 02:33.040 software, it's because we are designing together the same devices also, and we don't want 02:33.040 --> 02:41.480 to do something like design the PCB build the PCB and then design the mechanical part around 02:41.480 --> 02:42.480 it. 02:42.480 --> 02:48.440 We want to design them together, this is time saving, because what we can design at the same 02:48.440 --> 02:49.440 time. 02:49.440 --> 02:55.720 And also, most importantly, it allows us to take M-CAD consideration into while designing 02:55.720 --> 02:58.720 the PCB or the other way around. 02:58.720 --> 03:05.600 For instance, maybe we have, I don't know, like a gear or moving part or something, and 03:05.600 --> 03:07.600 so we kind of have a component here. 03:07.600 --> 03:11.800 And the E-CAD tool needs to know about it. 03:11.800 --> 03:18.600 Last but not least, the primary use of collaboration is making sure that it fits, because 03:18.600 --> 03:22.460 well, there's no thing worse than having your PCB, having your box, and they don't 03:22.500 --> 03:23.460 fit together. 03:23.460 --> 03:29.860 That can also happen, for instance, if you have, well, PCB revision two, we have with 03:29.860 --> 03:34.780 mechanical part version one, and that is well-own issue. 03:34.780 --> 03:38.260 So, ways to do collaborations. 03:38.260 --> 03:43.420 The very old way, I hope we don't use anymore, is basically sending drawings, like 03:43.420 --> 03:48.260 a PDF or paper, we could do this on paper. 03:48.260 --> 03:56.500 So, in this example, this is a M-CAD driven collaboration, at least this changes M-CAD driven. 03:56.500 --> 04:03.060 And so, basically, from the M-CAD software, we will print or send a PDF, we're containing 04:03.060 --> 04:05.900 the 2D drawings. 04:05.900 --> 04:12.140 Then the E-CAD user will need to basically convert this information into the E-CAD software. 04:12.140 --> 04:16.900 That is slow, so it's not very good. 04:16.900 --> 04:19.060 The errors can happen when you do that. 04:19.060 --> 04:24.260 At the moment, you have conversion, especially when they are done by human being, there 04:24.260 --> 04:25.900 can be errors. 04:25.900 --> 04:34.500 Also, if the E-CAD user has something to say, like, for instance, maybe the E-CAD user 04:34.500 --> 04:39.620 needs more both spaces or something, or maybe there's a problem with a specific location. 04:39.620 --> 04:45.060 Basically, what we need to do is to print short your E-CAD software and to send it, 04:45.060 --> 04:51.500 we are messaging up, or you could see it next to your M-CAD designer. 04:51.500 --> 04:57.060 That is also a possibility, but basically it's like finding, walk around to do, have some 04:57.060 --> 04:59.340 feedback. 04:59.340 --> 05:04.740 So, this is not what we use to, this is not what we do, usually today, what we do is basically 05:04.740 --> 05:08.220 we replace with the rowing with a compatible file. 05:08.220 --> 05:14.540 So, if we have a change from M-CAD to E-CAD, the file can be too deep drawings, but 05:14.540 --> 05:19.100 digital, and that can be understood by the E-CAD software. 05:19.100 --> 05:22.940 So, we have the XF, SVG, and IDF. 05:22.940 --> 05:28.820 And in the other way around, we have pretty models, like step or all the 5 formats. 05:28.820 --> 05:34.340 The process is simple, you don't need to convert data manually, the conversion is somehow 05:34.340 --> 05:42.980 the software, so because there is no manual conversion, we have no errors are limited, 05:42.980 --> 05:48.620 you could still have some conversion errors, but that's more like running stuff, so 05:48.620 --> 05:53.580 it should be within the margin of manufacturing. 05:53.580 --> 05:57.660 But see, we still have the issue of the feedback. 05:57.660 --> 06:03.020 So, well, we need to just need that we need to message each other, see what's wrong, we need 06:03.020 --> 06:08.300 to maybe change the part of the board, part of the mechanical part, it's not that great, 06:08.300 --> 06:11.100 but it works. 06:11.100 --> 06:16.300 The one I want to focus about today is to have some kind of synchronized collaboration, 06:16.300 --> 06:22.140 where basically we take the users out of the collaboration process. 06:22.140 --> 06:29.740 Basically, the E-CAD tool and the M-CAD tool will talk to each other directly, using a protocol 06:29.740 --> 06:37.780 to file something, it is still managed by the users, but that's how directly to each other. 06:37.780 --> 06:45.940 And in order to do this, we need to use the same 5 format, the same language as 5 formats 06:45.940 --> 06:52.540 are concerned, and that basically means that feedback can be easy. 06:52.540 --> 06:57.220 I mean, if we are using the same format, we can go both ways. 06:57.220 --> 07:01.140 And so, here comes basically IDX. 07:01.140 --> 07:08.780 IDX is the last kind of collaboration where we have collaboration directly in between the 07:08.780 --> 07:10.780 this software. 07:10.780 --> 07:12.340 IDX is an acronym. 07:12.340 --> 07:17.220 Instant, it stands for incremental design exchange, all of the specification are available 07:17.220 --> 07:26.700 online at the CADM-CADO.org, and well, just like any collaboration, 5 format or protocol, 07:27.620 --> 07:32.660 you can define electrical stuff like the borderline, you have rural areas, maybe in this 07:32.660 --> 07:39.860 area you are limited to, I don't know, 5 millimeter height in component, maybe you have 07:39.860 --> 07:46.260 placement constraints too, for instance, the connector definitely needs to be in a specific 07:46.260 --> 07:50.380 place of the border, you cannot meet anyway. 07:50.380 --> 07:57.660 That's already covered by a lot of design exchange protocols, but the main change here 07:57.660 --> 07:59.300 is incremental. 07:59.300 --> 08:04.540 Basically, instead of sending all the design every single time, we are using incremental 08:04.540 --> 08:06.940 changes. 08:06.940 --> 08:11.780 So we have our starting point, and then we only send the changes. 08:11.780 --> 08:17.780 So with this workflow, we can also accept and reject changes, we can tip and history of it, 08:17.780 --> 08:22.100 and we can also add a comment, that is the feedback. 08:22.100 --> 08:27.660 As an action, we can then add replace remove components. 08:27.660 --> 08:31.860 There's also the notion of object ownership. 08:31.860 --> 08:37.140 Maybe there are some components that are owned by the mechanical world or by the electric 08:37.140 --> 08:38.140 world. 08:38.140 --> 08:44.860 For instance, if we take a connector, the connector is most likely to be a mechanical dependent 08:44.940 --> 08:48.580 because it needs to fit right in the mechanical part. 08:48.580 --> 09:01.420 So the idea is, the mechanical designer is set as the owner of this connector, and then 09:01.420 --> 09:08.260 in the eCAD what this connector would be locked basically, and should not be moved by 09:08.340 --> 09:16.340 or removed, moved or something else altered by the eCAD designer. 09:16.340 --> 09:21.500 One thing with IDX2 is that it can be synchronous or asynchronous. 09:21.500 --> 09:28.860 So you could have some holes on a free time, or you can do the all-way, well-way, like 09:28.860 --> 09:36.700 the current way, actually, of having like triggered synchronization. 09:36.940 --> 09:42.660 IDX can be quite complex, but it is adapted if, for instance, you have several iterations. 09:42.660 --> 09:48.540 If your design is quite complex, you might want to add IDX, because there will be a lot 09:48.540 --> 09:58.740 of iterations, and also IDX supports having several eCAD and M-CAD users, though this is 09:58.740 --> 10:06.060 not fully implemented by most software, but it is something that IDX is thought for. 10:06.060 --> 10:09.420 So let's see how it works. 10:09.420 --> 10:12.940 The first thing is to define a baseline. 10:12.940 --> 10:19.300 The baseline is the first exchange in the IDX synchronization and collaboration. 10:19.300 --> 10:26.060 Usually, you have the board outline, so the shape of the board, you have the collaboration 10:26.060 --> 10:33.220 information like what software, what version, who is the author of the baseline, and you 10:33.220 --> 10:38.740 could also have constraints, like the limited height zone, no component zone, or maybe 10:38.740 --> 10:43.380 no road zone, or via zone, the plenty of constraints. 10:43.380 --> 10:49.380 And so here's a small diagram where the design is driven by M-CAD in this case, at least 10:49.380 --> 10:56.340 the baseline is driven by M-CAD, and so the baseline is focused sent from the mechanical 10:56.340 --> 11:03.580 world to the electrical world, and then the electrical world basically accepts it. 11:03.580 --> 11:09.020 There is no way we should not reject the baseline, because if we can't agree on the very 11:09.020 --> 11:14.100 first message, we cannot agree on making change on it. 11:14.100 --> 11:20.780 So this was M-CAD to E-CAD, but obviously you can go the other way around. 11:20.780 --> 11:25.340 So this is defining the baseline, and so no about changes. 11:25.340 --> 11:30.100 So changes, there can be plenty of changes, maybe we can move, and we want to move an element, 11:30.100 --> 11:35.900 we want to add one, we want to remove one, or we want to replace it, an element can be 11:35.900 --> 11:41.540 a component, it can be a via, it can be a connector, it can be a board shape, basically anything 11:41.540 --> 11:44.260 that can be incorporated on. 11:44.260 --> 11:50.380 So in this case, with the diagram, basically the electronic world wants to submit some 11:50.380 --> 11:55.300 changes, so it will send the changes from the electronic world to the mechanical world, 11:55.300 --> 12:02.020 then from this point the mechanical user, the mechanical designer, can accept or reject 12:02.020 --> 12:03.020 changes. 12:03.020 --> 12:07.540 Independently, it does not have to be in bulk, it's not like accept or reject all. 12:07.540 --> 12:11.260 You can choose what you accept and what you reject. 12:11.260 --> 12:15.420 And then you send back the list of accepted and rejected changes to the electrical 12:15.420 --> 12:23.900 world, and there you have a synchronized execution of changes, accepted rejected. 12:23.900 --> 12:28.980 There is an optional message, which is basically an acknowledgment, which is called the clearance 12:28.980 --> 12:39.020 message, which is not most of the time not implemented, but is defined in the protocol. 12:39.020 --> 12:45.860 So things are great, we have our baseline, we have all the changes after that, and well, 12:45.860 --> 12:49.580 it's incremental, so if something goes wrong in the middle, we are getting out of 12:49.620 --> 12:54.620 sync, and we have an issue, and so this is basically the third kind of user that we have, 12:54.620 --> 13:05.140 which is rebased lining, rebased lining is the action of resetting the collaboration. 13:05.140 --> 13:10.500 It should only be used if we are getting out of sync, if we have an issue with the collaboration. 13:10.500 --> 13:15.460 This getting out of sync can happen, it happens, for instance, if you have a crash in a software 13:15.500 --> 13:22.420 processing IDX. If this happens, well, then we are like in a middle state where one thinks 13:22.420 --> 13:28.540 the message is sent, the other one is waiting for it, and so the only things we have to do is 13:28.540 --> 13:36.540 basically clear the history of the IDX story, and then we have to send the baseline back again. 13:36.540 --> 13:40.300 So basically it's starting fresh. 13:40.380 --> 13:49.100 So this is basically the kind of messages, so baseline, changes, rebased lining. 13:49.100 --> 13:56.860 So in practice, I'm talking about protocol messages, but in practice, those are files. 13:56.860 --> 14:10.860 Those are usually XML files, can show you real quick, if I can try and drop this window, 14:10.860 --> 14:20.260 yeah, this is basically this board, this board is as an example file provided by the 14:20.260 --> 14:30.660 eCADM.org website, which is basically used to test basic input of IDX, and so there's 14:30.660 --> 14:36.940 like component rotation, there's like rule area, there's plenty of stuff, like limited 14:36.940 --> 14:41.900 high zone, a component from here, limited high zone, maybe no components zone, all of those 14:41.900 --> 14:52.260 are components, let me just maybe get it back here, so you can get the other side, yeah, 14:52.260 --> 15:08.140 no, you got it, yeah, that is okay, come on, let's see, so that is basically the other 15:08.140 --> 15:15.140 side where we have the component rotated several times, the same component, okay. 15:15.140 --> 15:24.060 And so this test file is here, let me just try to get the window, okay, and so we have 15:24.060 --> 15:30.580 a edit part, which contains information about the calibration, and so for instance, it's 15:30.580 --> 15:36.380 about information about the participants, the participants, the names, the date of the change, 15:36.380 --> 15:41.660 for the baseline, in this case, this is the baseline, and we have information about the software, 15:41.660 --> 15:47.740 software names, software revision, in this case, the example file has been done with solid 15:47.740 --> 15:53.980 work version 24.4, and also the default length units, you can define length units per object, 15:53.980 --> 16:00.460 but there's like a default length, and well, let it be millimeter or inches or whatever, 16:00.460 --> 16:05.500 so header with collaboration information, and then the body with information about the items 16:05.540 --> 16:12.820 to be collaborated on. In this case, basically, I'm not going to go into details, but basically 16:12.820 --> 16:19.020 you have the box set, the curve sets, so which are the curves that define the bottom line. 16:19.020 --> 16:25.020 So that is the baseline header plus body. When we want to make a change, it's basically 16:25.020 --> 16:31.060 in structure with the next cross section, which is the process instructions, and they 16:31.140 --> 16:39.140 have to basically reference objects within the body, so this is an incremental change, and 16:39.140 --> 16:44.660 so we have, as we can see on the slide, the new version, we try to find it on, you have the 16:44.660 --> 16:49.780 new version and the previous version, both of them are to be found within the body, and we 16:49.780 --> 16:57.460 have version 1, 0, 0, and version 1, 0, 1, and basically, we also have a new item, and 16:57.700 --> 17:02.420 this is the right time tags, so this means that the software knows which one the previous, which 17:02.420 --> 17:13.060 one the new, and so we can, and so we can make the change. So now about sharing IDX files, 17:14.660 --> 17:20.900 because so far, it's always a files, and we still emailing them or something, so we could have 17:21.060 --> 17:29.700 a direct communication. Think is IDX is usually implemented by close source, popularity, 17:30.500 --> 17:36.340 e-card, and MCAT tools, which means that basically, they're not sharing implementation, 17:36.980 --> 17:43.140 so we could have some kind of server-based information, because if we had direct peer-to-peer 17:43.140 --> 17:48.020 communication, that would be an issue, if for instance, if we have the electronics being done in 17:48.020 --> 17:55.780 Europe, and the, and the mechanical part done in the US, for instance, because of time zones, 17:55.780 --> 17:59.940 so the computer will need to be on the same time, basically, and that's within an issue. 18:00.980 --> 18:05.140 One way to have a server though, that is pretty easy, this day is to have a network chat 18:05.140 --> 18:12.340 folder, this is usually the method that can, that IDX is used with, and basically, the e-card 18:12.340 --> 18:18.420 software, there's simply a rise of files in the shut folder. Also, you could try just emailing 18:18.420 --> 18:24.500 the files, but not the best way to do, and maybe you could load the wrong file, so that we could 18:24.500 --> 18:33.780 get out of sync just because of that kind of thing. So this is an example of, this is an example 18:33.780 --> 18:40.340 of one change or change or baseline for instance, but so let's say at some point, we have the 18:40.420 --> 18:46.420 e-card user on the top left and the m-card user on the bottom right, so at some point the 18:46.420 --> 18:52.980 e-card design decides that the design is ready for synchronization, so it basically hits a button 18:52.980 --> 19:00.420 in the in kick out of the electronic control. The software will compute the differences, the changes, 19:00.420 --> 19:05.780 or the baseline depending on what step it is, and then it will write the data in the shut folder. 19:06.740 --> 19:13.220 The m-card tool will detect that there's a new file, and will notify the m-card user, 19:14.820 --> 19:19.140 then the m-card user reviews changes, accepts rejects some of them, all of them depends, 19:20.180 --> 19:27.380 and press OK on the m-card tool, which will write the IDX file back in the shut folder, and then we go 19:27.380 --> 19:33.620 the other way, we are going back to e-card where we detect that there's a new file and we notify the 19:33.700 --> 19:42.500 e-card user, and well I'm talking about detection, but some implementation that just rely on 19:42.500 --> 19:46.260 just emailing and saying, oh there's a new file, please hit the synchronization button. 19:48.020 --> 19:55.860 So that is basically the workflow with IDX. So in kick out, trying to implement this, 19:56.740 --> 20:04.660 as I said, it is for now a proof of concept, it's not ready to be merged, far from it. 20:05.940 --> 20:11.220 There's a merge request at the moment, for it, maybe we'll be kick out version 11, 20:11.220 --> 20:15.940 if we're making a progress on this topic, maybe we'll focus at 12, or maybe for another kick out. 20:17.220 --> 20:22.580 And currently the merge request focuses on decoding information from 20:23.220 --> 20:30.980 the IDX test files, and it has been tested with CMM Solid Edge, which implements IDX, 20:31.700 --> 20:37.140 so which is a mechanical tool. Regarding the features, 20:38.580 --> 20:43.300 basically, so as I said, basically that anything that is e-card to m-card today is not ready to 20:43.300 --> 20:51.300 support it, but it is to be worked on. And so we can read the baseline, we can read changes, 20:51.300 --> 20:58.420 and we can send back the change response, saying accept or not. We have a bit of graphical user interface 20:58.420 --> 21:03.940 to, like a differential review, because when you have changes, you want to know what was before, 21:03.940 --> 21:12.340 and what will be. And also we are trying to handle the repository. The repository is something 21:12.980 --> 21:18.580 in this, in the IDX meaning, it's basically having an extra representation of the board 21:18.580 --> 21:24.980 that is only used for collaboration. It is not used for kick for design. It is the representation 21:24.980 --> 21:34.420 state of the board. So how can we, this is prototype interface, most likely not the one that 21:34.420 --> 21:40.340 will arrive in kick out if it does, but this expanded workflow little. So basically you have a 21:40.420 --> 21:46.260 collaboration folder that you need to set. This is basically where the IDX five will be written 21:46.260 --> 21:52.260 into. You can configure IDX because, well, IDX does several versions. Today, I think the last version 21:52.260 --> 21:58.580 is like 4.50 or 5. But maybe the other software only supports up to IDX version two. 22:00.180 --> 22:06.100 Then you have the IDX history. Well, this, this case, this is not sorted, but you have the baseline, 22:06.180 --> 22:10.420 you have the change, and you have the response. This is basically for testing purposes, 22:10.420 --> 22:16.580 you have the software that's coming from, and you have the date. You have a preview of the change. 22:16.580 --> 22:20.660 In this case, the change is pretty simple. It's just, hey, here's a new board. It's, 22:20.660 --> 22:26.100 it's outline is very tumbler. And you have there here a list of change, in this case, that's only 22:26.100 --> 22:33.700 one. It is marked to be accepted. And, well, they do it, it's improvement. So now, 22:34.340 --> 22:39.780 this is the basic collaboration, but there's quite a few things that IDX enables. 22:41.300 --> 22:46.980 First of all, well, because this is a shelf folder, it is possible to have not one-to-one collaboration, 22:46.980 --> 22:57.700 but one-to-many. So in this case, basically, we just connect all the e-cub, all the m-cuts 22:57.700 --> 23:02.660 software to the shelf folder, and the e-cuts software to the shelf folder. That is useful if you have 23:02.660 --> 23:08.500 one single piece of PCB of design that needs to be integrated into various mechanical parts, 23:08.500 --> 23:14.900 that. If you want to reuse your PCB for various devices. There's one question, though, 23:14.900 --> 23:22.100 that is, how can we add a component in the m-cut wall, and have it shown correctly in the 23:22.100 --> 23:27.700 e-cut wall, because m-cut and the standard m-cut library, and e-cut and the standard e-cut libraries. 23:28.420 --> 23:35.380 So, basically, we need a bridge, could be a product that has management system, 23:35.380 --> 23:40.740 but it could be also a CSV file or something. Well, basically, what we need is to have 23:41.860 --> 23:47.140 link between the component reference, e-cut reference, and m-cut reference. 23:47.140 --> 23:54.180 And then, with this workflow, we can add a connector in the m-cut, and have it shown correctly 23:54.180 --> 24:00.260 in e-cut. We can also add a component in e-cut, and have it shown with a correct, 24:00.260 --> 24:08.020 pretty model in m-cut. Talking about IDX, I said that IDX usually implemented by 24:08.020 --> 24:15.780 close source proprietary software. So, you're going to find IDX in big companies, not very small 24:15.780 --> 24:19.460 ones, because it's worth, it's worth quite complex at the beginning, I mean, to set up. 24:20.180 --> 24:25.860 So, here, I represented a red e-cut tool and a red databases, those are close source. 24:28.260 --> 24:33.780 Maybe what we can do is to replace the close source with an open source one. 24:35.540 --> 24:40.340 But, in this case, we have an issue with that Kika cannot understand that the close source 24:40.900 --> 24:45.860 proprietary database, and that there's one thing that Kika people are really good at 24:46.740 --> 24:51.860 is making importers and converters. We have quite a lot of converters at the moment for libraries. 24:53.380 --> 24:59.940 And so, in this way, we can basically use Kika for in place of the proprietary 25:01.300 --> 25:08.980 e-cut tool. There's one issue, though, is that there's one arrow, this one, that is one sided, 25:09.060 --> 25:14.900 because we cannot write back to the library. So, actually, we still need to keep the close source. 25:15.540 --> 25:21.940 So, it's not so much about replacing, but offering an alternative. Maybe for all the designs, 25:21.940 --> 25:27.860 like, ready to be released, it is important to keep the proprietary tool within the company, I mean. 25:28.980 --> 25:33.300 But, maybe if you want to do a prototype, a prototype concept, so like that, you want to go fast, 25:33.380 --> 25:39.460 you don't want to get all the workflow of the company, then you can be used the alternative workflow. 25:42.020 --> 25:50.660 Talking about the IDX code by itself, today it is the proof of concept is coded within Kika, 25:51.380 --> 25:59.140 but it is coded in a such a way that it is possible to extract it quite easily without dependencies, 26:00.100 --> 26:06.900 for instance, in Kika, we love using WX, and well, that's a use dependency, but yeah, so basically, 26:06.900 --> 26:13.460 if I not to use those kind of dependencies, and so if we could extract it, we could share the implementation 26:13.460 --> 26:21.220 of IDX with Kika and MK2, and then we would have synchronization and doing the work only once, 26:21.220 --> 26:28.580 not every single package needs to be do the work independently, and that's pretty much the end of 26:29.540 --> 26:36.340 presentation, so just as a conclusion, so IDX is a tool for synchronization and collaboration 26:36.340 --> 26:43.940 between E-CAD and MK2, there are other tools. This one is more focused about on changes, 26:43.940 --> 26:50.180 incremental changes, stories to flag that, but there's one thing that does not is replacing 26:50.900 --> 26:54.900 designers talking to each other, it's still important to be able to make a message each other, 26:55.860 --> 27:03.220 it's purpose in not to replace discussion, and as of today, there's a proof of concept in 27:03.220 --> 27:11.460 development, and there's a metric quest for this, but it's not really yet again, and I'm 27:11.460 --> 27:16.580 personally looking forward to sharing this implementation and maybe testing it with an open source 27:16.580 --> 27:27.780 MK2, that is pretty much all. All right, questions for Fabian. 27:33.140 --> 27:39.380 So can this be abused to be used without an MK2, for example, for a multi-board design, 27:39.380 --> 27:45.380 so being able to put them strengths from one board to another one? I think it can, yeah, 27:46.500 --> 27:51.220 the question was got it, yeah, so yeah, I think it can be used in order to 27:53.700 --> 27:58.260 to, yeah, as you said, abuse it in order to have like variants stuff like that, but yeah, 27:59.380 --> 28:06.100 there it's not only for E-CAD in MK2, if you have for instance, maybe anything that connects 28:06.180 --> 28:14.180 collaborates on a PCB, could be maybe EMC tools, could be a, could be product data management tool, 28:14.180 --> 28:19.460 where maybe one designer wants to change a component because it's not fit with the company policy or something 28:19.460 --> 28:25.060 at that. Yeah, not the questions. 28:25.300 --> 28:39.300 And normally you have product data management or technical data management system in between 28:39.300 --> 28:45.620 that coordinates collaboration and all the work packages that need to be separated between 28:45.620 --> 28:52.100 teams. There is no concept of that in KKK, is there something that would be implemented during 28:52.260 --> 28:57.780 this metric, or is it something that comes later? If I understand correctly, the question is, 28:57.780 --> 29:04.500 can we, do we intend to implement some kind of PDM interface within KKK? Yes, normally you start 29:04.500 --> 29:09.780 a session from MK2, get the collaboration information that then gets written into the IDX. 29:10.500 --> 29:17.700 I think doing just bear IDX is quite a lot of work, but definitely if there is a PDM interface 29:17.780 --> 29:22.740 that can be developed in the future, it can be good, but I think that is not in the roadmap for now. 29:22.740 --> 29:26.740 Thank you. 29:31.300 --> 29:36.500 All right, thank you Fabian, and I guess we'll have a brief break before Morgan starts.