Would an API for Autodesk Fabrication products be useful?

[steven_butler]

Would you benefit from an API in Autodesk Fabrication CADmep, ESTmep or CAMduct? If so, please share with us your thoughts on the potential benefits this could provide? How might you use an API and what kind of API would you like?

[Anonymous]

Currently we're looking for an easy way to pull material chargeouts out of CAMduct and batch enter that information into our accounting system.  Other uses would include pulling out material needed reports that would compare inventory levels to those levels required by batches in the system.

Another problem we have is the shop enters the wrong job number and it doesn't get caught until several days later as we enter time.  If we had an API we could write something that runs in the back ground monitoring the API from autodesk and the odbc tables from our accounting vendor.

Next step would be able to push items into CAMduct.  Right now if we need 4 coil joints and a couple of elbows that has to go through the ticketing deartment. We'd like to see that accomplised via the web, excel, access or some other sysetem (even if it requieres CAMduct on that machine and a license for it).  The reasons for this is not to work around the license fee's it's to allow online orders for our Custom Standard products without double entry.  It also allows a lesser trained employee to do the task of a higher skilled employee.

This is where I'm at today trying to figure out.

Hope that helps

[Anonymous]

This is definitely needed.  Many users have been looking for ways to get to the data for years.  We really need this.

Please make sure you make access available through VB as AutoCAD has added support for this language again and IMHO  it is the quickest easiest way to program ACAD.

[Anonymous]

I would love to see API access to Camduct through VB. Scripting if ok for making some changes but is not flexible for some things. Most companies have their own particular requirements so having access in this way means everybody's happy..

[Anonymous]

Access via .NET would be really helpful. For such a large product to have absolutely no information exposed via API is getting pretty difficult now.

[tim-bot]

YES! YES YES YES!

Just now noticed this forum unfortunately, but yes, I’ve been asking for API access in the fabrication product each and every time i talk with anyone from Autodesk. Likely, very annoying, but it's something we desperately need! below are some reasons off the top of my head:

1. SPEED!

• No joke, the COD scripts are dreadfully slow!
• Often times we have to run scripts that have to either iterate the entire drawing or the entire database, this get’s to be soo slow…

2. Additional Functionality

• A properly implemented API would give us access to iteratable data that we could use LINQ queries on and stuff like that.
• WPF – Need I say more?
• Connecting data to and from external sources would be invaluable
• Being able to read what’s in the drawing without fully opening it up
•     Currently, to iterate many drawings, we have to programmatically completely open the drawing (not just the database) and then run scripts to get or affect data. this task keeps poping up AutoCAD on the computer it’s run on so the user (mainly ME) can’t get much done since it’s constantly in their face.
• Cleaning up our database
•     Currently we’re trying to find items with invalid, missing, or duplicate Harrison ids in a move we’re making to ESTmep. It’s extremely painful reading the data out, working on the data, then having to re-write (programmatically) COD files to load the data back into the database. Optimally the database would be changed to an SQL database instead so we can use that level of advanced functionality.
• Drawable overrides
•     We have need to display flange holes on our printout sheets. There’s excessively difficult and bulky methods currently in CADmep, but we don’t like them. we implanted a drawable overrule that generally works great that looks the data up from a database and draws some geometry based on what little information we can get from the MAPSCOMWLib.dll. there’s definitely some issues though that I’m having a very difficult time resolving. For example, we want to do our spools in sheet layouts instead of individual drawings since it’s much faster (and less data to store), but programmatically it’s very difficult to reliably get whether the flange holes need to drawn or not.
• Custom exporters
•     I could write something using a COD script that would tell me enough information to programmatically generate the model in a different application such as Revit, but that would take too much time, and make me crazy. Crazier…? Having direct access may lead to us being able to roll something out that would satisfy our customers a little better (who are on us on every project to get that fabrication model back into Revit as actual Revit objects with all their data and everything)
• SPEED! Did I say that already?

3. Advanced Functionality

• Currently no one here is aware of any method of programmatically adding new fabrication objects into the drawing. I think you can only modify existing items. Being able to programmatically add things here or there as needed, or even to generate whole layouts in some way may be something that would be appealing

4. Extended access

• There’s only so much that little scripting language can do. But there’s so much more to CADmep that we can’t touch except thru manual input by a user. This is not good. and can many times lead to invalid input and human error. Very bad things.

I’m sure there’s more I could think of if I just kept going, but I’m going to stop for now. but I’ll be back with more, oh yes, so much more B)

[tim-bot]

Error handling! so i don't get 99% of the way thru and the script crashes! that sucks! i'd like to report out my errors but continue with the rest of the work. then i could focus on the 1% that failed instead of having to run the whole thing again...

[tim-bot]

we're also having issues with some of our layouts that we've outsourced where the hangers were not cut-in but inserted and copied around in the model. this eliminates any connection to the size of the supported pipe which prevents us from being able to run scripts to adjust the sizing of the rods for those hangers. what we can do now is find hangers that instersect a pipe and then run a programatically re-written script on just those items that would do that, but that's a ton of work. being able to adjust these parameters without all that, or being able to re-connect programaticaly to the supported pipe would also be of great value to us.

[Anonymous]

Either .NET or COM

.NET would allow the same plugin to be used for multiple products.

COM on the other hand is more extendible to other API plaforms like ARX, Lisp  (even other non-traditional languages) as well as it would make it easy to use VB/VBA.

COM would seem to be the most flexible choice but with wavering support from Microsoft (we're killing it, we're keeping it...make up your mind already), .Net seems to be perhaps the longer term solution.

Honestly, I don't see anything wrong with the existing COD scripting other than it's buggy and limited. Fix the bugs and provide support for creating/drawing in addition to editing properties, and have it be able to call other functions like Lisp, .Net, VB, scripts, etc.

Then, all the other Autodesk API's can just reference the existing COD interpreter.

[Anonymous]

.NET PLEASE

.NET is faster in most cases and more secure. Locations of items and their settings would allow for smoother development then the current systems. Currently we have programs that use .net, COD and lisp to accomplish task that not alone can complete. .NET could reduce a lot of development issues.

[Anonymous]

We have been using CAMDuct since 2006 and would really like to have an API to directly access the .Maj file.  API to VB would be great and will enable us to get data directly from the file and not have to open the file via CAMduct first, then export or view data.

 I'm also thinking of having my own Tracking software that will import the data directly from the .maj file to a database (mysql,postgres,oracle) that can do a single item multiple quantity tracking,  multiple delivery reports, can generate a lable with 3D barcode.  We are currently using Autodesk Fabrication tracking but its not a fit for us and with the API,  I could have a third party make me my customize tracking system that will be able to integrate to our Customize ERP system.

[Anonymous]

We are looking for an easy way to pull material chargeouts out of CAMmep and CADmep and batch enter that information into our accounting system.  Other uses would include pulling out material needed reports that would compare inventory levels to those levels required by batches in the system. With and API this would eliminate copy paste errors from exported TXT files. Existing COD scripting is buggy and limited. Fix the bugs and provide support for creating/drawing in addition to editing properties, and have it be able to call other functions like Lisp, .Net, VB, scripts, etc.