Author Topic: DipTrace 3.2  (Read 8733 times)

0 Members and 1 Guest are viewing this topic.

Offline Eternauta

  • Contributor
  • Posts: 25
  • Country: it
DipTrace 3.2
« 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.

 
The following users thanked this post: DerekG, 2N3055, Ash

Offline DerekG

  • Frequent Contributor
  • **
  • Posts: 880
  • Country: nf
Re: DipTrace 3.2
« Reply #1 on: October 27, 2017, 06:26:02 am »
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  :)
I also sat between Elvis & Bigfoot on the UFO.
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 2560
  • Country: it
Re: DipTrace 3.2
« Reply #2 on: October 27, 2017, 06:32:31 am »
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.

Quote
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 :(
 

Offline hammy

  • Supporter
  • ****
  • Posts: 435
  • Country: 00
Re: DipTrace 3.2
« Reply #3 on: October 30, 2017, 09:34:40 pm »
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  :-+ :-+ :-+
 

Offline DerekG

  • Frequent Contributor
  • **
  • Posts: 880
  • Country: nf
Re: DipTrace 3.2
« Reply #4 on: October 30, 2017, 10:30:28 pm »
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
I also sat between Elvis & Bigfoot on the UFO.
 

Offline novarm44

  • Contributor
  • Posts: 30
  • Country: ua
    • DipTrace
Re: DipTrace 3.2
« Reply #5 on: November 04, 2017, 10:09:07 pm »
Quote
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
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: us
Re: DipTrace 3.2
« Reply #6 on: November 05, 2017, 12:39:57 am »
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.

 

Offline novarm44

  • Contributor
  • Posts: 30
  • Country: ua
    • DipTrace
Re: DipTrace 3.2
« Reply #7 on: November 05, 2017, 07:58:18 am »
Quote
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?
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2528
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: DipTrace 3.2
« Reply #8 on: November 05, 2017, 09:16:05 am »
Quote
...

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?


Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 2560
  • Country: it
Re: DipTrace 3.2
« Reply #9 on: November 05, 2017, 08:57:28 pm »
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)
 

Offline novarm44

  • Contributor
  • Posts: 30
  • Country: ua
    • DipTrace
Re: DipTrace 3.2
« Reply #10 on: November 05, 2017, 11:17:33 pm »
Quote
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.
Quote
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.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 1830
  • Country: 00
Re: DipTrace 3.2
« Reply #11 on: November 06, 2017, 09:36:46 am »
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
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2528
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
DipTrace 3.2
« Reply #12 on: November 06, 2017, 02:19:46 pm »
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.
« Last Edit: November 06, 2017, 02:21:27 pm by timb »
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 1830
  • Country: 00
Re: DipTrace 3.2
« Reply #13 on: November 06, 2017, 04:33:37 pm »
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.
 

Offline novarm44

  • Contributor
  • Posts: 30
  • Country: ua
    • DipTrace
Re: DipTrace 3.2
« Reply #14 on: November 06, 2017, 09:19:36 pm »
Quote
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).
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: us
Re: DipTrace 3.2
« Reply #15 on: November 07, 2017, 11:27:55 am »
Quote
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.
« Last Edit: November 07, 2017, 11:30:37 am by John Coloccia »
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 2560
  • Country: it
Re: DipTrace 3.2
« Reply #16 on: November 07, 2017, 12:19:01 pm »
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
 

Offline DerekG

  • Frequent Contributor
  • **
  • Posts: 880
  • Country: nf
Re: DipTrace 3.2
« Reply #17 on: November 08, 2017, 01:16:24 pm »
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.

Quote
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.

Quote
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.

Quote
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

Quote
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.
I also sat between Elvis & Bigfoot on the UFO.
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: us
Re: DipTrace 3.2
« Reply #18 on: November 09, 2017, 02:14:39 am »
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. :)
 

Offline DerekG

  • Frequent Contributor
  • **
  • Posts: 880
  • Country: nf
Re: DipTrace 3.2
« Reply #19 on: November 09, 2017, 04:32:15 am »
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.
I also sat between Elvis & Bigfoot on the UFO.
 

Offline forrestc

  • Supporter
  • ****
  • Posts: 504
  • Country: us
Re: DipTrace 3.2
« Reply #20 on: November 10, 2017, 05:50:17 am »
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.
 

Offline DerekG

  • Frequent Contributor
  • **
  • Posts: 880
  • Country: nf
Re: DipTrace 3.2
« Reply #21 on: November 10, 2017, 11:33:33 am »
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.
I also sat between Elvis & Bigfoot on the UFO.
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 2560
  • Country: it
Re: DipTrace 3.2
« Reply #22 on: November 10, 2017, 12:22:27 pm »
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
 

Offline DerekG

  • Frequent Contributor
  • **
  • Posts: 880
  • Country: nf
Re: DipTrace 3.2
« Reply #23 on: November 10, 2017, 12:30:41 pm »
But the drill file is separate :/

Quite true.

Quote
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.
I also sat between Elvis & Bigfoot on the UFO.
 

Offline forrestc

  • Supporter
  • ****
  • Posts: 504
  • Country: us
Re: DipTrace 3.2
« Reply #24 on: November 11, 2017, 07:01:33 am »
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).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf