894x-2A, 894x-2B, 894x-2C relays top view

Howdy people!

Here are some relays I made.
894x-2A is normally open
894x-2B is normally closed
894x-2C is double throw.

Hope it helps to anybody.

Is there a manual how do I pack them to one package?
r894x-2A.fzpz (13.2 KB) r894x-2B.fzpz (13.2 KB) r894x-2C.fzpz (14.2 KB)

Welcome to the forum. Pretty good parts. Fewer issues than a lot of the existing core parts.

I ran those parts through FritzingCheckPart. Here is a summary of what it reported, with my notes from manual inspection added. The information is the same for all 3 parts.

There are ‘px’ units on font-size attributes in the schematic view svg files that Fritzing is known to not handle well. The text size can change from what was intended. Fritzing wants just numbers, without units.

The new convention is to use black graphics for pcb silkscreen. It used to be white instead. The “#f0f0f0” color being used is not correct either way. Fritzing automatically converts (and so does the FritzingPartsCheck tool), but for future reference, black is preferred in the silkscreen of pcb svg files.

The part definitions do not include terminalId attributes for the connector schematic view entries. The connector pins you have defined (linked by the svgID attribute values) should be the terminalId instead, and the svgId should link to a 0.1 inch long line that has one end at the existing connector element. The lines are already there. Just need to move the id="connector«number»pin" svg attributes from the polygon to the line, replace it with id="connector«number»terminal", and add terminalId="connector«number»terminal" after the svgId attribute for the schematicView in the fzp file.

(for r894x-2A, connector 1)

<line stroke="#787878" y1="7.5599999" y2="7.5599999" x1="0.34999999" x2="7.5500002" style="stroke-linecap:round" fill="none" stroke-width="0.75" id="connector1pin"/>
<polygon points="0.001,7.897 0.001,7.21 1.113,7.21 1.113,7.835 " gorn="0.36" style="fill:none" id="connector1terminal"/>

<schematicView>
<p svgId="connector1pin" terminalId="connector1terminal" layer="schematic"/>
</schematicView>

Connector pin numbers should start at 0, and go up from there, instead of starting at 1. The pin names and descriptions can be anything, and do not need to match the numbers.

The breadboard svg files are missing the “breadboard” layerId specified in defintion files. The first (outer) group element in the svg files needs to have an id="breadboard" attribute.

The schematic svg files are missing the “schematic” layerId specified in defintion file. A group element is needed to wrap the graphical contents of the file, with an id="schematic" attribute.

A separate note. Where did you get the pin numbers and sequence? Typically, a DIP (dual inline) package part is numbered like IC’s. Start in the corner (top left or bottom left depending on orientation), then increment along that side, and back along the other side.

Thanks a lot. I spent a whole 24 hours RTFMing and drawing the parts.

Well now I study out FritzingCheckPart software so I guess I’ll fix the issues shortly. It may take some time due to my poor English.

I learnt the relays’ datasheets, indeed:
https://ru.mouser.com/datasheet/2/378/894-DATA-SHEET-1374885.pdf
http://www.songchuan.ru/files/894.pdf

But they both contain no information about pinouts.

Yep, I thought same. But the relays have key marks at another side of the body than IC’s. So I decided to put the sequence of the pins accordinly to the following logics — 1, 2 to coil; 3,4 to shifting contacts; 5 - 8 to the others. Shall I change pin numbers and sequence?

Not necessary (to change numbers). There are a lot of different patterns used. I just wondered where this sequence came from. The hover functionality in Fritzing will show the pin number and name. Only recommended to use same numbers when published information has something to match to.

FritzingCheckPart is a tool to help look for potential problems in part information, based on the best information when it was created. A newer version is being developed. Not everything it complains about is really a problem, but definitely things to look at, and be aware of. It tries to promote clean files.