search

fritzing / fritzing-app

Fritzing desktop application
http://fritzing.org
Other
4.02k stars 829 forks source link

core schematic conversion to 0.1 grid #2590

Closed davidperrenoud closed 10 years ago

davidperrenoud commented 10 years ago

From irasc...@gmail.com on May 29, 2013 09:59:41

originally from issue #1941 , comments 32 and up

Another big issue that is not otherwise documented: what do we do about schematic view, since the new schematic view parts all have a completely different grid size. In particular, what happens to all the old parts. On the one hand we could obsolete every part, which is a logistical nightmare. On the other hand we could change all the old sketches, which would be another kind of nightmare for people who spent time in schematic view.

I have a proposal, which works similarly to the way we made the switch from .fz to .fzz. We declare all old .fzz files read-only. When a user opens an old fzz file, they will be asked whether they want to convert it to the new schematic view. If "yes" a copy of the file is created, and all old schematic images are updated, with whatever chaos occurs with the wiring (or we could autoroute).

I am not sure what to do about old .fz files, in the sense of whether to convert in two steps (i.e. first convert to fzz, then when that is loaded, ask about the schematic conversion), or whether to convert all at once (i.e. once you consent to convert to fzz, schematic is automatically converted as well).

Underneath it all is the following. All old schematic images are moved to the obsolete folder but not renamed. If the file is unconverted, the obsolete image would be used instead of the new image. For obsolete generated parts (mystery part, sip, dip, pinheader) I think the old generator code would have to be available, and if the file is unconverted, the old code would be invoked instead of the new code.

So I would call this nasty but not a nightmare.

Original issue: http://code.google.com/p/fritzing/issues/detail?id=2592

davidperrenoud commented 10 years ago

From irasc...@gmail.com on May 29, 2013 09:23:10

More about schematic view. Probably we need to make an svn branch for this code. We should also make a new google doc for the old part schematic view images: for each part, mark whether there is already a new svg to use, whether the new image can be generated (i.e. this is straightforward if the old image uses the standard rectangle style), or whether the new image must be illustrated.

I will generate a first pass of this document.

davidperrenoud commented 10 years ago

From irasc...@gmail.com on May 29, 2013 09:23:31

all the examples will have to be updated for the schematic switchover

davidperrenoud commented 10 years ago

From irasc...@gmail.com on May 29, 2013 09:23:50

what happens to custom part SVGs during the changeover? Rectangular schematics can be automatically upgraded, but what about the rest. I am tempted to say leave it to the user.

davidperrenoud commented 10 years ago

From irasc...@gmail.com on May 30, 2013 00:02:52

Before asking the user about whether to convert the file, if one could determine in advance if the user 'didn't care' about the schematic view, then one could perform the conversion silently. For example, maybe do the conversion if there are no wires (or only a few wires) drawn in schematic view.

Cc: andre.knoerig@gmail.com

davidperrenoud commented 10 years ago

From irasc...@gmail.com on July 26, 2013 14:18:58

An improvement to the scheme would be to change all the relevant fzp files to contain pointers to both the original schematic file and the new schematic file (where the new schematic would be the default). If the sketch being loaded is left "old style" the fzp could be modified by substituting in the old schematic name before the fzp is used to set up the part. Old schematic svg files would still be moved into obsolete, but the new files would have new names, so it wouldn't be a matter of picking the right folder (obsolete or core) at setUpImage() time.

Even beter, if the new schematic files kept the original name, and the old schematic files were renamed with some standard prefix (like "0.3.schem.") then there would be no need to change fzp files (though they would still have to be updated with the old schematic name at load time).

This could make the custom parts issue a little easier. I suspect most custom parts point to core schematic svgs, so there might only have to be a few cases that the user would have to convert. On second thought, the schematic is stored locally in the fzpz, so it might not be so easy to determine whether the file was truly an old core schematic image.

I was hoping to avoid the image conversion business, but it is not only custom parts that we must worry about, it is 3rd party bins, and these are much more likely to use custom schematics.

Labels: -Priority-Medium Priority-Critical

davidperrenoud commented 10 years ago

From irasc...@gmail.com on July 26, 2013 14:27:58

Now that I think about it, writing some kind of automatic converter--for even rectangular-type schematic parts--would be very tricky because there are so many different ways of expressing the same outcome in svg. I think even detecting a rectangular-type schematic would be tricky--you could perhaps use the connector and terminal point locations to determine this, though the logic would not be completely straightforward (i.e. separated pins, approximate measurements, mistakes...).

So maybe we stick to dealing with core schematics, and let everyone else catch up over time.

davidperrenoud commented 10 years ago

From irasc...@gmail.com on July 29, 2013 22:48:58

It may not be possible to reliably detect a rectangular schematic, but the user could advise that it was one, and the conversion could work based on that assumption.

davidperrenoud commented 10 years ago

From irasc...@gmail.com on July 29, 2013 22:51:25

One problem with the conversion is how to deal with parts that do not use terminal points in schematic view. For the core, we will have to find all the parts that currently do without terminal points, and add them (changing the fzp as well as the svg). For custom parts, we will have to tell the user that conversion is not possible.

davidperrenoud commented 10 years ago

From irasc...@gmail.com on November 11, 2013 01:56:44

current status:

-- for generated schematics (pinheader, mystery part, DIP, SIP), both the old and new generator code are in place, though there is no mechanism to switch.

-- missing terminal points have been added to core parts

-- how to deal with the fact that a user may simultaneously, in two different windows, have old-style and new-style schematics. I think each window must have a flag, and that flag must be used at part-creation time to switch schematic svg filenames or schematic svg generation code.

-- rectangular schematic converter is not implemented, though (most of?) the pieces are in place

-- only alert the user about the schematic change if there are schematic traces

davidperrenoud commented 10 years ago

From irasc...@gmail.com on November 11, 2013 02:17:22

what happens in the parts editor?

davidperrenoud commented 10 years ago

From irasc...@gmail.com on November 11, 2013 04:07:27

in the tools folder look for the schem2schem (schematic rect) converter. Also look for new-style schematic images in the not_quite_ready folder.

davidperrenoud commented 10 years ago

From irasc...@gmail.com on November 11, 2013 04:44:19

The following schematic view files currently do not have a replacement, either hand drawn or generated:

acpower.svg antenna.svg Arduino Nano3_schematic.svg Arduino-Fio-v22_schematic.svg Arduino-Mini-v5_schematic.svg Arduino-Pro-Mini-v13_schematic.svg Arduino_ADK_MEGA_2560-Rev3_schematic.svg Arduino_bt07_schematic.svg Arduino_DUE_V02b_schematic.svg Arduino_Esplora_schematic.svg Arduino_Ethernet_schematic.svg Arduino_Leonardo_Rev3_schematic.svg Arduino_MEGA_2560-Rev3_schematic.svg Arduino_Micro_Rev03_schematic.svg Arduino_Motor_Shield_rev3_schematic.svg Arduino_Pro_schematic.svg arduino_Uno_Rev3-02-TH_schematic.svg arduino_Uno_Rev3_schematic.svg avr_isp_10_pin_schematic.svg basic_transistor_npn.svg basic_transistor_pnp.svg Battery_block_9V82.svg capacitor.svg capacitor_polar.svg capacitor_variable_2_legs.svg capacitor_variable_3_legs.svg controller_arduino_mini_usb_adapter_schematic. crystal.svg dcpower.svg dc_motor.svg dc_powersupply.svg diode_schottky.svg diode_zener.svg DS1307_schematic.svg fet_n.svg fet_p.svg Fritzing icon.svg Fuse_with_Handler_schematic.svg GSM-Quectel_updateTID_2_v1.3_schematic.svg HIH-4030_Breakout-v10_schematic.svg inductor.svg ldr.svg led-SuperFlux.svg LICENSE.txt LilyPad-Simple-v25_schematic.svg LilyPad_Arduino_USB_schematic.svg Lilypad_PowerSupply-v18_schematic.svg Lilypad_Vibe_Motor.svg lm34_schem.svg lm358_schematic.svg loudspeaker.svg piezo_sensor.svg PowerSupply-Lipo-v15_schematic.svg QFN-20-0.4MM_schematic.svg QFN-24_schematic.svg QFN-28_schematic.svg QFN-32_schematic.svg QFN-36_schematic.svg QFN-64_schematic.svg raspberry_pi_a_schematic.svg raspberry_pi_rev1_schematic.svg raspberry_pi_rev2_schematic.svg resistor.svg resonator-3pin.svg rfid_reader_id12.svg RJ45_TRXCOM_schematic.svg Rotary_Encoder.svg schematic-arduino-lilypad.svg Shield_Eth06-PoE_schematic.svg spdt-switch.svg stereo-jack-3_5mm.svg Teensy_3.0+pads_schematic.svg Teensy_3.0_schematic.svg TI_Launchpad_MSP430G2_schematic.svg TMP102_Breakout-v11_schematic.svg tmp36_schem.svg Tricolor-LED v16_schematic.svg tsop312_schematic.svg ULN2803A_schematic.svg usb_connector.svg voltage_regulator_5v.svg voltage_regulator_7833.svg voltage_regulator_LM317.svg xbee.svg

davidperrenoud commented 10 years ago

From irasc...@gmail.com on November 11, 2013 05:37:34

@comment 12: The same list is below, with * next to the ones which need hand-work. The rest can be generated. Probably images already exist for some of the ones needing hand-work, so we could just copy files and change the name.

Cc: bluearc....@gmail.com
Labels: -Type-Defect Type-Enhancement

davidperrenoud commented 10 years ago

From irasc...@gmail.com on November 12, 2013 02:41:23

generated the rectangular ones above, so the remaining list is now:

dc_powersupply.svg in 4 x AAA Battery Mount.fzp acpower.svg in acpower.fzp antenna.svg in Antenna.fzp avr_isp_10_pin_schematic.svg in avr_isp_10_pin.fzp spdt-switch.svg in basic-toggle-switch.fzp fet_n.svg in basic_fet_n.fzp fet_p.svg in basic_fet_p.fzp basic_transistor_npn.svg in basic_power_transistor_npn.fzp basic_transistor_pnp.svg in basic_power_transistor_pnp.fzp Battery_block_9V82.svg in Battery block 9V.fzp capacitor.svg in capacitor_ceramic_100mil.fzp capacitor_polar.svg in capacitor_electrolytic_large.fzp crystal.svg in CRYSTAL - kHz.fzp dcpower.svg in dcpower2.fzp dc_motor.svg in dc_motor.fzp diode_schottky.svg in diode_schottky_1N5817_300mil.fzp diode_zener.svg in diode_zener_0_5w_3_6v_300mil.fzp Fuse_with_Handler_schematic.svg in Fuse_with_Handler.fzp inductor.svg in inductor.fzp ldr.svg in LDR_photocell_300mil.fzp led-SuperFlux.svg in led_flux_blue_anode.fzp lm358_schematic.svg in lm358.fzp loudspeaker.svg in loudspeaker.fzp piezo_sensor.svg in piezo sensor.fzp resistor.svg in resistor.fzp resonator-3pin.svg in resonator-3pin.fzp RJ45_TRXCOM_schematic.svg in RJ45_TRXCOM.fzp Rotary_Encoder.svg in Rotary_Encoder.fzp stereo-jack-3_5mm.svg in stereo-jack-3_5mm.fzp tsop312_schematic.svg in tsop312.fzp usb_connector.svg in USB connector.fzp

davidperrenoud commented 10 years ago

From bluearc....@gmail.com on November 15, 2013 04:08:26

dc_powersupply.svg in 4 x AAA Battery Mount.fzp -> sparkfun-electromechanical_battery_schematic.svg !!!ATTENTION!!! connectors are reversed acpower.svg in acpower.fzp -> i have to draw/scale it antenna.svg in Antenna.fzp -> i have to draw/scale it avr_isp_10_pin_schematic.svg in avr_isp_10_pin.fzp -> generic_female_pin_header_10_100mil_10thin_double_schematic.svg spdt-switch.svg in basic-toggle-switch.fzp -> sparkfun-electromechanical_toggle_schematic.svg fet_n.svg in basic_fet_n.fzp -> sparkfun-discretesemi_mosfet-nchannel-1_schematic.svg fet_p.svg in basic_fet_p.fzp -> sparkfun-discretesemi_mosfet-pchannel_schematic.svg basic_transistor_npn.svg in basic_power_transistor_npn.fzp -> sparkfun-discretesemi_npn_schematic.svg basic_transistor_pnp.svg in basic_power_transistor_pnp.fzp -> sparkfun-discretesemi_pnp_schematic.svg Battery_block_9V82.svg in Battery block 9V.fzp -> sparkfun-electromechanical_battery_schematic.svg capacitor.svg in capacitor_ceramic_100mil.fzp -> sparkfun-passives_cap_schematic.svg capacitor_polar.svg in capacitor_electrolytic_large.fzp -> sparkfun-passives_cap_pol_schematic.svg !!!ATTENTION!!! connectors are reversed crystal.svg in CRYSTAL - kHz.fzp -> sparkfun-freqctrl_q_schematic.svg dcpower.svg in dcpower2.fzp -> sparkfun-electromechanical_battery_schematic.svg dc_motor.svg in dc_motor.fzp -> sparkfun-electromechanical_motor_schematic.svg diode_schottky.svg in diode_schottky_1N5817_300mil.fzp -> diode-schottky.svg !!!ATTENTION!!! connectors are reversed diode_zener.svg in diode_zener_0_5w_3_6v_300mil.fzp -> diode-zener.svg !!!ATTENTION!!! connectors are reversed Fuse_with_Handler_schematic.svg in Fuse_with_Handler.fzp -> sparkfun-passives_fuse_schematic.svg inductor.svg in inductor.fzp -> sparkfun-passives_inductor_schematic.svg ldr.svg in LDR_photocell_300mil.fzp -> sparkfun-sensors_photocell_schematic.svg led-SuperFlux.svg in led_flux_blue_anode.fzp -> sparkfun-led_led_schematic.svg lm358_schematic.svg in lm358.fzp -> sparkfun-analogicop-amp-_mix_1_schematic.svg loudspeaker.svg in loudspeaker.fzp -> sparkfun-electromechanical_speaker_schematic.svg piezo_sensor.svg in piezo sensor.fzp -> sparkfun-electromechanical_buzzer_schematic.svg resistor.svg in resistor.fzp -> sparkfun-passives_resistor_schematic.svg resonator-3pin.svg in resonator-3pin.fzp -> sparkfun-freqctrl_resonator_schematic.svg RJ45_TRXCOM_schematic.svg in RJ45_TRXCOM.fzp -> sparkfun-connectors_magjack_schematic.svg Rotary_Encoder.svg in Rotary_Encoder.fzp -> sparkfun-electromechanical_encoder-quadrature_schematic.svg stereo-jack-3_5mm.svg in stereo-jack-3_5mm.fzp -> sparkfun-connectors_audio-jack_schematic.svg tsop312_schematic.svg in tsop312.fzp -> i have to draw/scale it usb_connector.svg in USB connector.fzp -> sparkfun-connectors_usb_schematic.svg !!!ATTENTION!!! pinorder is different

davidperrenoud commented 10 years ago

From irasc...@gmail.com on November 26, 2013 03:50:25

unable to find the following part 0.3.schem.7segment13an at .../partfactory/.../core/0.3.schem.7segment13an.fzp

this happens when the search bin contains an 0.3.schem part from a prior search ( )

davidperrenoud commented 10 years ago

From irasc...@gmail.com on November 26, 2013 06:32:04

@comment15: I have done the renaming, so the list of core parts needing 0.1 images is now down to:

acpower.svg in acpower.fzp -> i have to draw/scale it antenna.svg in Antenna.fzp -> i have to draw/scale it avr_isp_10_pin_schematic.svg in avr_isp_10_pin.fzp -> generic_female_pin_header_10_100mil_10thin_double_schematic.svg (I am not sure whether the pins correspond) tsop312_schematic.svg in tsop312.fzp -> i have to draw/scale it usb_connector.svg in USB connector.fzp -> sparkfun-connectors_usb_schematic.svg !!!ATTENTION!!! pinorder is different

Note that there are a number of broken parts from the list in comment15; in particular I have seen the usual Illustrator crap in the connector IDs. In general, all the new schematics need to be tested.

davidperrenoud commented 10 years ago

From irasc...@gmail.com on November 26, 2013 06:38:31

check whether we should convert the schematic frame part

davidperrenoud commented 10 years ago

From irasc...@gmail.com on December 14, 2013 23:29:59

Issue 2814 has been merged into this issue.

davidperrenoud commented 10 years ago

From irasc...@gmail.com on December 19, 2013 13:52:20

Issue 2831 has been merged into this issue.

davidperrenoud commented 10 years ago

From andre.knoerig@gmail.com on January 09, 2014 09:49:09

The design specification :)

Attachment: SchematicViewGraphic_Template1.svg

davidperrenoud commented 10 years ago

From irasc...@gmail.com on January 18, 2014 04:07:03

closing this overall issue; treat new bugs as separate issues

Status: Fixed