EEVblog Electronics Community Forum
Electronics => PCB/EDA/CAD => DIPtrace => Topic started by: Eternauta on October 27, 2017, 06:04:46 am
-
Just posted on the forum from DT Team:
We have published new version 3.2 today, the major thing we changed in it is polishing of existing features (added in 3.0 and 3.1). However some new tricks have been added too:
1. DRC same net clearance check (Trace to Trace, SMD to Pad, SMD to Via, SMD to SMD).
2. Improved highlight and selection of objects in PCB Layout (traces and all other objects under footprints are highlighted and can be edited in default mode).
3. Polishing of length matching and meander features.
4. Storing common solder mask swell and paste mask shrink with the project file.
5. Always open/soldered option in custom mask/paste settings for pads and vias.
6. Rotate Group and Flip Group commands in Component and Pattern Editors.
7. Additional fields in Pick and Place, tab divider in text files for BOM and Pick and Place.
What we are working on:
1. Interactive push and shove router and trace editor. You will not get power of PADs or other high-end EDAs in the first versions, but this is what we want to reach for this feature.
2. Overall improvements of routing usability and bus routing.
3. RF circuits support.
4. Controlled impedance.
5. KiCAD import/export
6. Eagle export (import is already here).
7. Also some smaller features like BOM in PCB Layout, tear-drops, etc.
-
Just posted on the forum from DT Team: We have published new version 3.2 today
Yes, it is all great news.
Some 8 or 9 Altium Designer power users have been working with the DipTrace Design Team to implement some of the higher end features of Altium into DipTrace.
So there are many of us out there that are very happy to see these updates :)
-
5. Always open/soldered option in custom mask/paste settings for pads and vias.
6. Rotate Group and Flip Group commands in Component and Pattern Editors.
oh, yes.
What we are working on:
1. Interactive push and shove router and trace editor. You will not get power of PADs or other high-end EDAs in the first versions, but this is what we want to reach for this feature.
7. Also some smaller features like BOM in PCB Layout, tear-drops, etc.
nice
no mention of making the library organization better. hope we won't have to wait until 4.0 :(
-
3. Polishing of length matching and meander features.
That saved my day. I switched for a specific layout today (DDR memory chip) from CS to DT, just because of this!
Big thumps up for DipTrace :-+ :-+ :-+
-
2. Improved highlight and selection of objects in PCB Layout (traces and all other objects under footprints are highlighted and can be edited in default mode).
I can report that these improvements are great. I do a lot boards with custom copper areas (& associated solder masks & paste masks) on the board for heat sinking purposes & these are now much easier to modify.
DipTrace has come a long way since ver 2.4
-
no mention of making the library organization better. hope we won't have to wait until 4.0 :(
Please describe what things are not good here. We have redesigned library system in 2.4 and seems there are no big complains at the moment, we still plan to improve it, but not redesign organization.
Regards,
Stanislav Ruev
DipTrace CEO
-
Library organization is fine. Unless something has changed, what's not fine is the precision when changing back and forth between imperial and metric, the craziness with how pin numbers are handled, and not having relative paths. DipTrace's library/component/footprint system is so simple as to make library management irrelevant IF they could make it so that libraries could have relative paths. Maybe this is now fixed and I'm just out of date.
-
Library organization is fine. Unless something has changed, what's not fine is the precision when changing back and forth between imperial and metric, the craziness with how pin numbers are handled, and not having relative paths. DipTrace's library/component/footprint system is so simple as to make library management irrelevant IF they could make it so that libraries could have relative paths. Maybe this is now fixed and I'm just out of date.
Configurable precision is in the nearest plans - there are number of complains about it. Relative paths - I will think how to handle this, probably add some constants like "project_dir", it's not hard, but we should think how it should be before implementation (your thoughts are welcome). What is wrong with pin numbers?
-
...
Any word on the native Mac version that’s been in the pipeline for the past two years? I’d be really happy to not have to keep a VM fired up just for designing PCBs anymore. And no, the WINE version isn’t even close to good enough for me. Aside from issues with multiple monitors, it also creates new folders in the root of my home directory, which is very un-Mac like! (Albeit, that’s new behavior since 3.0; in fact all the WINE related problems I’ve come across appeared with 3.0.)
I was under the impression that the newest version of Delphi (or whatever it’s called these days) makes it relatively easy to cross-compile between platforms, so what’s the hold up?
-
Please describe what things are not good here. We have redesigned library system in 2.4 and seems there are no big complains at the moment, we still plan to improve it, but not redesign organization.
For instance I am sure I am not the only one that would prefer Sub-Categories instead of a big cauldron of parts..
Manufacturer -> Family of components -> Components
I already mantain my own libraries this way...
I Have Microchip MCUs, Microchip Analog, Microchip Power, Microchip Converters.
The advanges are that it's easier to
- Find out what i need when i don't remember the exact part number
- Looks like smaller libraries take less time to load and to search into
In the forum users have proposed a database-style library, so one can look for OPAMPS or for all TO-92 package parts and so on..
besides that, have you ever considered separating diptrace updates from library updates? those could be more frequent and subjected to user feedback.. there are many components i have remade because they were unusable as they were (probably auto-generated)
-
I was under the impression that the newest version of Delphi (or whatever it’s called these days) makes it relatively easy to cross-compile between platforms, so what’s the hold up?
It's not easy task with Delphi - need to redesign all project structure for FireMonkey to support both platfroms from single source-code. It will hold main development line for 6 months to 1.5 years, then require in-depth tests. Anyway we have plans to make DipTrace cross-platform in the future.
For instance I am sure I am not the only one that would prefer Sub-Categories instead of a big cauldron of parts..
Manufacturer -> Family of components -> Components
I already mantain my own libraries this way...
I Have Microchip MCUs, Microchip Analog, Microchip Power, Microchip Converters.
The advanges are that it's easier to
- Find out what i need when i don't remember the exact part number
- Looks like smaller libraries take less time to load and to search into
In the forum users have proposed a database-style library, so one can look for OPAMPS or for all TO-92 package parts and so on..
besides that, have you ever considered separating diptrace updates from library updates? those could be more frequent and subjected to user feedback.. there are many components i have remade because they were unusable as they were (probably auto-generated)
Categories, types and subtypes are already in all standard libraries and available for our library developers. But there is no functionality within the program to handle them yet. Independent library updates are also almost done - we need to test and integrate them. Currently all libraries are under review and redesign, then we will make more functionality in this direction.
-
Since virtual machines are available, to run windows on Mac and on Linux, and that both together share very small market isn't worth the effort and the extra layer of trouble, maintain dip trace as is fast and simple
-
Since virtual machines are available, to run windows on Mac and on Linux, and that both together share very small market isn't worth the effort and the extra layer of trouble, maintain dip trace as is fast and simple
Virtual Machines are also large and consume a ton of system resources. That’s simply to boot into the guest OS! Then there’s the matter of 3D acceleration, which all modern EDA software requires, including DipTrace. Since the guest OS doesn’t have direct access to the GPU, like it does with the CPU, 3D performance is significantly limited. (Assuming you don’t install a second graphics card and pass it through to the VM like you can with Virtual Box and some versions of VMWare; this method also has certain issues and limitations.)
At any rate, once they’ve “reorganized” their code, it’s a simple matter of telling the compiler to produce a native Mac binary. The UI and system libraries are already obfuscated behind higher level calls, so it’s not like they’d have to implement those things separately for each platform. Aside from a bit of simple code they’d need to add, there’s really nothing else they’d need to do.
That’s the beauty of the tool they’re using. It can produce binaries (using native UI widgets) for Windows, macOS, iOS, Android, etc. all from the same code base. So I don’t see how it would make the Windows version of DipTrace “slower and more complex” as you seem to think.
Based on the latest numbers I’ve seen, the Windows 10 adoption rate is pretty dismal while macOS and Linux are growing faster than ever. Combine that with the fact that Eagle has gone subscription based and you’d be stupid *not* to provide your EDA tool on those platforms. Especially when you can do it with (comparatively) little effort.
-
It's not true, Delphi to be used on Mac or Linux, need to use other components called firemonkey, and isn't at the same level of the VCL they used for windows.
I run Altium and deep trace and even some 3d games perfectly well on virtual machine on my I7-5960 with 64Gb ram runs a litle slow but near the same as native inclusive using multimonitor.
Why they will change the full platform for very few user, while they have a solution but they don't want to use.
-
That’s the beauty of the tool they’re using. It can produce binaries (using native UI widgets) for Windows, macOS, iOS, Android, etc. all from the same code base. So I don’t see how it would make the Windows version of DipTrace “slower and more complex” as you seem to think.
Based on the latest numbers I’ve seen, the Windows 10 adoption rate is pretty dismal while macOS and Linux are growing faster than ever. Combine that with the fact that Eagle has gone subscription based and you’d be stupid *not* to provide your EDA tool on those platforms. Especially when you can do it with (comparatively) little effort.
Reality is a bit different: Windows support is made with VCL and MacOS with Firemonkey, you can compile Firemonkey for Windows too, but that is not good way to go for Windows. Actually as far as I know for MacOS Delphi uses some kind of virtual machine to look like native. The way to go is redesigning application structure to be able easily change firemonkey UI units to VCL UI units, so it should be some kind of internal interface which connects program logic to the selected widgets and compile for both platforms with single logic sources, but different UI sources.
Finally the easiest way to go:
1. Make internal interface similar to VCL and replace VCL with it in existing source codes (to avoid redesigning logic and breaking anything, some tweaks will be applied though).
2. Copy existing VCL UI before step 1, remove all logic from there and just make links from it to internal interface.
3. Design similar UI in Firemonkey and link it to the internal UI.
4. Redesigning all platform dependent things like registry, etc. + add tweaks depending on the platform (some logic things work differently).
-
Library organization is fine. Unless something has changed, what's not fine is the precision when changing back and forth between imperial and metric, the craziness with how pin numbers are handled, and not having relative paths. DipTrace's library/component/footprint system is so simple as to make library management irrelevant IF they could make it so that libraries could have relative paths. Maybe this is now fixed and I'm just out of date.
Configurable precision is in the nearest plans - there are number of complains about it. Relative paths - I will think how to handle this, probably add some constants like "project_dir", it's not hard, but we should think how it should be before implementation (your thoughts are welcome). What is wrong with pin numbers?
That's good to hear about the precision. One of my main frustrations is switching back and forth between metric and inches, and suddenly nothing can be lined up anymore.
re: library paths
Here's my situation. I have custom libraries, and I have all of my projects under source control (including all of the libraries, of course). When I switch to another source control directory, perhaps to where I have my releases archived, everything breaks because it goes looking for everything on an absolute path.
All I really want is that ANYWHERE I specify a library (components, linked schematic, whatever...anything having to do with my project) store it as a relative path to wherever my project file is. You don't even need a checkbox or anything like that. Common convention is to give you drive letters for an absolute path, and anything else would be considered a relative path.
re: pin numbers
It's been a while but I have sent some notes about this in the past. Let me try and remember precisely...
Let's say you have a JFET. Depending on the package, this JFET has it's drain, source, etc on different pins. It makes sense to have the pin numbers of the JFET pattern match the pin numbers for the package/datasheet, right?
So I drop this JFET onto my schematic in 50 places, and then I realize I want to use a different JFET. Since DipTrace links the component pin to the package pin via the component pin number, when you replace the component with another component that happens to have a different package, DipTrace will reconnect all of the wires to the original component pin number. Well, Pin 1 used to be drain, but on this package it's Source.
Now I have to rewire my entire schematic by hand. You can imagine how annoying and error prone this is.
Two potential solutions are:
- allow multiple patterns to be attached to a single component
- attach the wires on the schematic based on pin NAME instead number...the default pin name is just the pin number, and I'll change it to something meaningful later if I want to.
IMHO, I don't even think a component needs a pin number at all. It could potentially only have a pin name (which could simply default to a number). Schematic should be attached by pin name. Pin number should be inherited from whichever pattern you've selected.
This way everything makes logical sense. Schematic connects by name and will never change when a component is replaced. Attaching a pattern to a component links the pattern pin number to the component pin name. If you display the pin NUMBER on the schematic, you get the pin number from the attached pattern.
Now I have all the information I need, and the logical connections on the schematic are completely decoupled from the physical pattern. This also makes it pretty easy to have multiple patterns attached to the same component, or lays the groundwork for that anyhow. The ideal situation is to have both solutions, and I think they go hand in hand because they're both based on the same idea of decoupling the schematic from the pattern.
I don't know if I explained it well but I think it would be a very worthwhile change to consider.
-
Categories, types and subtypes are already in all standard libraries and available for our library developers. But there is no functionality within the program to handle them yet. Independent library updates are also almost done - we need to test and integrate them. Currently all libraries are under review and redesign, then we will make more functionality in this direction.
Oh cool :D very good to know
-
Unless something has changed, what's not fine is the precision when changing back and forth between imperial and metric,
Hi John.
A lot depends on the grid chosen when making the component footprint. For this reason when making a component, I always choose 1mil or 0.01mm to minimise off grid problems when depositing the component onto the PCB.
IF they could make it so that libraries could have relative paths. Maybe this is now fixed and I'm just out of date.
Yes, ver 3 has addressed a lot of these library problems. Now you can select your personal library(s) from within the main library box. Just scroll down & your personal libraries (once loaded for the first time) will always appear below DipTrace's standard libraries. This has been a BIG improvement.
One of my main frustrations is switching back and forth between metric and inches, and suddenly nothing can be lined up anymore.
I have problems when trying to show dimensions on the PCB. I choose many different grids, however when trying to place (say) a dimension of 5.0mm it wants to only let me choose something like 4.93mm or 5.01mm (for instance). Any suggestions much appreciated.
re: library paths
Here's my situation. I have custom libraries, and I have all of my projects under source control (including all of the libraries, of course). When I switch to another source control directory, perhaps to where I have my releases archived, everything breaks because it goes looking for everything on an absolute path.
Pretty much fixed in ver 3.2
re: pin numbers
So I drop this JFET onto my schematic in 50 places, and then I realize I want to use a different JFET. Since DipTrace links the component pin to the package pin via the component pin number, when you replace the component with another component that happens to have a different package, DipTrace will reconnect all of the wires to the original component pin number. Well, Pin 1 used to be drain, but on this package it's Source.
Now I have to rewire my entire schematic by hand. You can imagine how annoying and error prone this is.
You can now allocate "G" "D" "S" instead of pin numbers "1" "2" "3". This gets around the problem.
-
Well, I'll look at the latest release, then. I know I've looked at it in the past, and I don't remember any of that being fixed. Honestly, I have no problem with the library management in my old 2.4 version. Maybe I'm just not very picky about it. :)
-
I have no problem with the library management in my old 2.4 version. Maybe I'm just not very picky about it. :)
We all learn't to work with ver 2.4 & the quirky library arrangement. I actually thought it was one of the worst aspects of DipTrace (I preferred the way Protel 2.8 worked with their libraries).
However ver 2.9 showed some improvement & ver 3.0 to 3.2 showed a big improvement.
I would like to be able to lay down a polygon copper area, then copy it & move that copy to any other layer (ie a mask layer). You can do it the other way round, just not this way. I'll mention it again in the DipTrace Forum.
-
The #1 feature I would like to see added to diptrace is some sort of 'single click' export tool for packaging files for manufacturing. It continues to frustrate me that I have to do the same 20 steps (or more) every time I get a file ready for manufacturing.
I'd like to be able to specify which layers to export to gerbers, and which drill files to export, etc. and then have diptrace remember this setting, which can be re-played by clicking on 'export manufacturing file set' or something like that. Added bonus if diptrace will bundle them all into a .zip file.
Oh, which also reminds me: Something really needs to be done to improve directory handling. I try to keep all of my design files + exports for a specific project in the same directory, one for each project. Diptrace 'remembers' the last directory I used to export the gerbers - usually in a different project. It would be nice to set as a preference the default directory location for each type of file. i.e. export gerbers to a specific directory, or the project directory, etc.. As it is now, I spend a lot of time changing directories. And if I forget I get files in the wrong directory.
In the 'in my wildest dreams' category I would love push&shove manual routing. But that is only slightly irritating in comparison to the above.
-
I'd like to be able to specify which layers to export to gerbers .... and then have diptrace remember this setting....
You can :)
FILE
EXPORT
GERBER
Then select
FILES
and select the Gerbers you want included in your Gerber Export All Table (see the screen shot). DipTrace will remember your preferences for the future.
Note that when you export the files you will be asked each time if you really want that particular Gerber saved. A bit weird, however I just click 7 or 8 times to export all the Gerbers I want.
Then I navigate to the saved folder, highlight all the Gerbers & the drill file, then right click for PeaZip to add them into a single archive.
I do agree that having the facility within DipTrace to export all Gerbers directly to Zip would be nice.
-
But the drill file is separate :/ Making the app open the schematic/layout folder instead of the last folder where a file was saved would be nice indeed
-
But the drill file is separate :/
Quite true.
Making the app open the schematic/layout folder instead of the last folder where a file was saved would be nice indeed
Yes, I agree.
-
Note that when you export the files you will be asked each time if you really want that particular Gerber saved. A bit weird, however I just click 7 or 8 times to export all the Gerbers I want.
That's pretty much how I do it, but the 'have to click each time' is irritating. Along with 'the file already exists' for every file if I have to re-export because I found an error.
Plus as JPortici the drill file is separate. I also have to export p&p data which is also separate. The filenames for the drill and p&p need to be modified if I remember right (or maybe one of them is this way and not the other). Also, the directory thing is weird as well.
On the p&p output, the units in the file is based on the units you are viewing the design in, and isn't settable/viewable on the output screen. I wish this could be set as something liek 'always export in mm'. I think the drill file has similar issues, but it doesn't seem to affect me getting boards made.
It's more of a ongoing irritation than anything. I look at other tools which do quick bundling based on preferences and I get a bit jealous. Especially since this seems like a relatively low-impact thing for novarm to add (when compared to something like push/shove routing and length matching/impedance/etc).
-
but the 'have to click each time' is irritating. Along with 'the file already exists' for every file if I have to re-export because I found an error.
Yes, it would be great if there were some "Global Preference" dialog boxes along the lines of:
1/ Tick for all Gerbers to be auto-generated
and
2/ Tick for auto-overwrite of existing files of the same name
Plus as JPortici the drill file is separate.
Plus
3/ Tick to auto-include drill file
I also have to export p&p data which is also separate.
Plus
4/ Tick to auto-include Pick and Place file
On the p&p output, the units in the file is based on the units you are viewing the design in ..... I wish this could be set as something like 'always export in mm'.
Plus a global dialogue box
5/ Tick to export P&P file in mm
6/ Tick to export drill file in mm
7/ Tick to auto-generate Zip archive of all exported files
The filenames for the drill (file) needs to be modified if I remember right
Yes, many board shop want the drill file as "drill.txt" instead of "drill.drl" When saving this file you are given the choice to change its name ..... but it would be nice to have a dialog box that simply allows for a fixed extension to be applied as a default.
Especially since this seems like a relatively low-impact thing for novarm to add (when compared to something like push/shove routing and length matching/impedance/etc).
Fully agree.
-
2/ Tick for auto-overwrite of existing files of the same name
Just an extra button on the overwrite confirmation prompt for "This file already exists. Do you want to replace it?" that is "Yes to All" would go a long way to alleviating the tedious task of clicking 'Yes' for each and every file. Of course, this extra button would only show up if you'd clicked "Export All" in the export window.
And speaking of "Export All", the feature to specify which sets of files and their names could be improved by having a presets facility (much like the DRC) where you can store certain filename configurations under a given name. Useful for if you use multiple PCB houses who have differing file naming conventions.
-
As long as we are talking about adding tick boxes to automate tedious mouse-button-consuming tasks: i want to propose an "export placement file" too.
How i'm doing it now:
-View -> Assemly Layers -> tick on Pattern Dimensions, Markings and Silkscreen.
-Preview
-Adjust preview scale
-Select only Board Dimension and Assembly Layers
-Print
-Untick bunch of shit
I'm lucky i almost always not print component markings onto the silkscreen so i can set them to be in "middle" position
Another feature i'd like to be automated: Sheet Text. Unless there are $Variables i don't know about. I admit i never read that part of the documentation...
-
5. Always open/soldered option in custom mask/paste settings for pads and vias.
I've just noticed an omission related to this new feature. The 3D Preview doesn't appear to take into consideration the new mask settings.
If I take a via and set both its Top and Bottom solder mask state to 'Open', then view the 3D Preview - ensuring 'Open Vias' setting is not turned on, of course - the via is still covered with mask on both sides.
-
Something i would like to see in DipTrace with regard to libraries, is some support for library distribution and updates, preferably version controlled.
Component, pattern, and 3d models.
The use cases should be fairly obvious,
* novarm wants to have good distribution and version controlled updating of it's standard libraries
* business wants to have it's own libraries, which is updated consistently and in a version-controlled manner in it's developer's systems
* third party library creator wants to have good version control of their libraries, preferably without having to do ASCII export, massage to neutralise paths, replace into version control...
* component seller/manufacturer wants to have good distribution of their libraries for parts they stock
While we are at it, some better (or rather, any) documentation for the ASCII library formats. Having an editable format is good but having to do guess work to figure it out isn't as I documented here (https://diptrace.com/forum/viewtopic.php?f=8&t=11551&p=22246#p22246).
-
Hopefully the Diptrace developers taking notes, because I see some really good points pass by.
My main bit of critique is that still some shortcuts are missing, the GUI can't be changed by the user, but most of all, my right mouse button is almost totally useless.
Why can't I have a custom menu with shortcuts with my right mouse button? Drives me insane to always have to go to the top menu bar or to the left bar :scared:
Especially because they have the shortcut keys anyway.
-
Hopefully the Diptrace developers taking notes, because I see some really good points pass by.
To ensure your requests are looked at by the developers, register & log your requests on the Diptrace Forum which is the official support channel:
https://www.diptrace.com/forum/ (https://www.diptrace.com/forum/)
my right mouse button is almost totally useless.
This is true if your mouse courser is in free space, however different options come up if you are hovering over a track or pad or copper plane edge etc etc ........ so it works pretty well really.