Unhelpful error

[mike.durian]

Here's the error in question:

Not terribly informative.

I am trying to update a device in my schematic. In my library, I added a new technology variant to a device and wanted to make it available in the schematic. I saved the library and then double-clicked the device as found in the device list of the schematic window. Normally, this pops up a message saying it must update the component already in the schematic and warning you to run a DRC or something. This time I got the error shown above and the component in the schematic did not update.

I also tried removing the component from the schematic first and then adding the component. Same error. I went back to the library, removed the technology variant and instead added a new footprint with the technology placed in the footprint name (so there are now two versions of the device with the same footprint - one is the original and one has the technology in the footprint name). Same error when I tried to add it.

I'd really like to get my schematic updated since the component with the old name is EOL and I want a clean BOM. Help determining what the error is would be greatly appreciated.

mike

[jorge_garcia]

Hi @mike.durian,

A picture says a 1000 words usually, but in this case we got 0. Are there any special characters in the new technology name? The fact that adding it to the footprint name causes the same problem gives me pause for concern.

I'm sure you tried but since you didn't mention it in the description, what happens if you try the REPLACE command? My guess is that it should behave similarly but I've been surprised before.

Let me know if there's anything else I can do for you.

Best Regards,

[mike.durian]

Hi @jorge_garcia ,

There are no special characters in the new technology name.

I had not tried the REPLACE command. When I try it, I do get an error message and it even has text in it! However, it doesn't really make sense to me. Here is the new error:

 What it says it true. I changed the symbol and device for a CAN transceiver and it doesn't quite match the old version that is in the schematic. Instead of using separate symbols for the device and its power, I now have them in a single symbol. However, I'm not trying to update that part. I'm trying to update a completely different part, a multiplexer, so I'm not sure why I'm getting the error.

I was hoping to avoid updating the CAN transceiver since I'll need to do a rip-and-replace, but I'll give it a try and see if I can update the mux after the CAN transceiver has been updated.

mike

[jorge_garcia · Accepted solution]

Hi @mike.durian,

I hope you're doing well. So if I'm understanding this correctly the part you are trying to change is not the CAN transceiver but it's in the same library as this part you do want to change.

If that's the case then you have to update both as you've correctly concluded. Let me know if you continue to run into problems.

Let me know if there's anything else I can do for you.

Best Regards,

[mike.durian]

Hi @jorge_garcia ,

Thank you for your help. Your understanding is correct. I was trying to update one component in the library without updating another component in the same library. After deleting and replacing the one I didn't want to update, I was able to update the intended device without error.

I think there are arguably two bugs here:

1) The empty error message. I should have been shown an error message like the one I received when I used the REPLACE command.

2) Having to update unrelated components from the same library. If there are other components in the schematic that share symbols, footprint or attributes with the component being updated, then yes, they should also be updated. But the user should not be required to update unrelated components. If you are explicitly updating to the latest versions in the entire library, then you would expect everything to update. But if you are doing it the way I did, where you add a device to force other devices of the same type already in the schematic to update, then only that component should be updated. Any other differences in unrelated devices should be ignored.

mike

[jorge_garcia]

Hi @mike.durian,

I hope you're doing well. Thanks for reporting this, I'll make a ticket for this and bring the need to update all of the components in a library up for discussion.

Let me know if there's anything else I can do for you.

Best Regards,

[jorge_garcia]

Hi @mike.durian,

So I spoke to the developers and there is a basic requirement that only 1 version of a library can exist within a design. If you could piece meal the updates then that would essentially require that the design store multiple versions of the same lib, which isn't possible and may not ever be.

The recommended work around is to split the libraries when you do the replace the components are in different libraries.

Let me know if there's anything else I can do for you.

Best Regards,

[mike.durian]

Hi @jorge_garcia ,

Thank you for checking on this.

In my opinion, requiring a design to sync to the entire library is an artificial restriction that really isn't needed. In Eagle, when you add a device to a project, the device, symbol and footprint information is copied to the schematic and layout. It's not a reference back to the library, it is a copy. The library is just a handy place to keep the originals until they are copied. There is no need for the project to maintain a back reference to the library.

Of course, if a project has multiple components that have the same footprint, then updating one device using that footprint would require updating them all since they share the same copy in the project. Eagle warns us in that situation.

If Fusion no longer makes a copy and instead uses a reference, then I'd say that is a regression from the original Eagle behavior (as are auto-updates and mandatory cloud storage, but that's tilting at a different windmill). Since Fusion stores every revision of every file forever with a UUID, then it would be seemingly be very simple to maintain a per-device reference to a particular library version. It's really only a problem if Fusion overwrites the library and only knows about the most recent version. But if that's the case, then the simple work-around is to do what Eagle does and just copy the object into the design and drop the reference altogether.

So anyway, I think it is still a bug, or if not exactly a bug, an unfortunate change. Maybe others will chime in with their opinions.

mike