Inventor Fusion Is Finally Out, But...

...it is not what they say it is. At least, not yet. All that marketing talk about "uniting direct and parametric workflows" is just that - talk. Inventor Fusion Technology Preview 1 is just a preview of the direct modeling workflow and has nothing related to the history side of things. And this is precisely how the brains at Autodesk Marketing appear to have planned it. According to the Autodesk press release, the "technology preview is the first step in delivering the full vision of Inventor Fusion". So instead of releasing their "full vision", Autodesk intends to dish it out in installments, thereby dragging this issue for as long as they possibly can. I am not sure whether this approach is designed get people like me to write about Fusion as much as possible, although it certainly looks that way. Frankly, after all that noise, I don't think so the world is interested in seeing part of their vision, especially the part which just about every other CAD vendor has already implemented.

Don't get me wrong. I have been playing around with Fusion for the past three weeks now and its direct modeling capabilities are great. But truth be told, Direct Modeling has ceased to amaze me, especially after seeing what SpaceClaim, Synchronous Technolgy and the other CAD systems that came before them can do. What will amaze me is the "fusion" part. The part where Inventor Fusion will let me open a history based model, let me thrash it around and then let me save it back to a history based model. This will be part of Technology Preview 2, which is due to be released late summer.

Kevin Schneider, Product Manager, Manufacturing Emerging Products and Technologies at Autodesk, could not be more explicit when he told me exactly what Fusion will eventually be able to do:

"[Technology Preview 2] will allow history free edits made in Fusion on Inventor native data to be read back into Inventor and converted into features. And this is not tweak features at the end of the tree. The changes will be to the source features. This allow users to make traditional parametric edits to their Inventor data using Inventor or use Fusion to make history free edits to the same data and then have those edits be converted automatically as parametric feature edits if they need them. This is truly giving customers the best of booth."

Usually companies spend years on a new technology using code names and shrouded in secrecy. Then when they are ready they go ahead and make a big splash. Someone at Autodesk decided to do exactly the opposite.

This is more like a strip tease and I am pissed because I am not yet feeling horny. Wake me up when she's about to take it all off.

I Love My Company But...

...maybe not this much.

The Magic of COFES

As I was asking the bartender for a beer at the Scottsdale Plaza during COFES 2009, so was another person. We shook hands, introduced ourselves to each other and began a conversation, which then spilled over to another beer.

This person was Francis Cadin, the CEO of DATAKIT, a French CAD software company that specializes in data exchange software. Technically, DATAKIT and SYCODE are business rivals because we have have a few products that overlap. So needless to say, Francis and I, knew quite a bit about each others companies, but we knew absolutely nothing about each other. However, a warm handshake followed by a couple of beers had changed all that. We really enjoyed our conversation, at the end of which, we exchanged business cards and decided to stay in touch.

And stay in touch we did. So much so that today DATAKIT and SYCODE issued a joint press release announcing a collaboration to offer hi-end Data Exchange solutions. DATAKIT's strength lies in their ability to read and write native file formats like CATIA, Pro/ENGINEER, SolidWorks, Solid Edge, Inventor, etc. whereas SYCODE's strength lies in developing plug-ins for a wide range of CAD systems. DATAKIT also developing plug-ins, but not for as wide a range of CAD system like SYCODE and SYCODE also has the ability to read and write native file formats, but not as wide a range as DATAKIT. So by simply adding the two together we will now be able to offer hi-end native file format import and export plug-ins for almost all the major CAD systems.

Its a win-win situation for everyone - DATAKIT, SYCODE and our customers. Funny thing is that this kind of a partnership never struck either of us in all these years. Its a wonder what a couple of beers and the right kind of atmosphere can do to business rivals.

And that, precisely, is the magic of COFES.

Linear and Non-Linear Modeling

For those interested in the Direct Modeling and History Based Modeling discussion, I strongly recommend that you read this post at the Solid DNA Blog on Linear and Non-Linear Modeling. I don't believe the idea here is to throw another couple of terms and add to the confusion. Rather, the author uses the terms "linear" and "non-linear" to put his views across in a simple and straightforward manner. Definitely worth a read.

ODA and LEDAS Get Constrained

Earlier I had mentioned that there were some interesting things going in the ODA on the technology front. Today I can tell you what. The ODA and LEDAS, a Russian software company, formalized their partnership by issuing a press release announcing that LEDAS would implement their LGS 2D Geometric and Dimensional Constraint Solver into DWGdirect, a main component of the ODA Platform. This will give all ODA members (and hence ITC members as well) the ability to have a 2D constraint system in their applications, something that was introduced in AutoCAD 2010. So when the ITC does come out with IntelliCAD 7.0 (whenever that may be), every ITC member will be able to license the constraint technology from LEDAS and offer a similar constraint system as AutoCAD 2010.

At the ODA World Conference in Leiden, Holland, this April, LEDAS presented their proof of concept - A DRX plug-in running inside Bricscad, the only DWGdirect hosted application in the market. Earlier the same day, Siemens had made a similar presentation, showing their 2D DCM (Dimensional Constraint Manager), the constraint management system licensed by Autodesk for use in AutoCAD 2010. It looks like LEDAS beat Siemens to it.

I had a feeling that it would turn out this way. I remember the Siemens presentation ending with the presenter saying something like, "If there is sufficient interest among ODA members then we can consider working towards implementing 2D DCM into ODA technology". Then later in the day, LEDAS floored the audience with their Bricscad plug-in. "We have already done it", was how the LEDAS presenter started his presentation.

It will be interesting to see how good the LEDAS constraint system turns out to be. 2D DCM is seasoned technology used in a number of CAD systems for a number of years. LEDAS is basically a outsourcing company that uses its revenue earned though it outsourcing activities to fund the development of technologies like LGS 2D and 3D (yes, they have a 3D solver as well). But as far as high end scientific and mathematical software like solvers is concerned, the Russians do it like no other. Also, as far as licensing cost is concerned, I suspect that LEDAS would be able to offer ODA members a sweeter deal than Siemens.

I don't think we will need to wait for long to find out. I suspect LGS 2D will soon find its way into a not so distant version of Bricscad.

Critical Bugs and Stop Ship Issues

After reading my opinions in the last couple of posts and comments on the issue of bugs and known issues some readers of this blog think that I have lost it. I now know why. It appears that my readers and I are not talking about the same thing, and maybe I am to blame for that.

Throughout this discussion I have used the word "crash" in conjunction with "bug" to signify that I am talking about bugs that cause a crash, not "this-tool-does-not-work-that-way or that-tool-does-not-work-this-way" kind of logical bugs. I am talking Crash! Boom! Bang! here.

As always, things are best explained by means of an example. So I will use one that I talked about on this blog earlier - the AutoCAD PolyFace Mesh issue. After I reported the problem to Autodesk (for the second time), they analyzed it, admitted it was a bug, limitation or whatever you want to call it, after which they arrived at the conclusion that it was not a "stop ship issue". Means it didn't cause a crash. Means there was no need to stop shipping the product. Surely reporting that a mesh has -1218 vertices and 0 faces (see image) is as big a bug as can be. But it didn't cause a crash. So they went ahead and released AutoCAD 2010 with this bug/limitation. And this kind of a bug is precisely what I have NOT been talking about.

Compare this to what Kevin Quigley said in a comment:

"I am talking about bugs that are logged in the system as bugs, that are perhaps not critical but cause features to fail or behave inconsistently. These are bugs, they are logged as bugs and they are released as known bugs - just look at the release notes of any application under 'known issues'. In your utopian programmers world no software should be released like this? Really? That is a recipe for bankruptcy."

Clearly we are talking two very different things here. Lets be clear. Bugs that cause crashes are critical bugs, stop ship issues or whatever fancy term that a developer many choose to use to describe them. My point is that no self respecting developer, whether it is a mammoth company like SolidWorks or a puny outfit like SYCODE, will (or rather should) ship a software with a critical bug that causes a crash. And if they have to release the software for whatever reason, they will (or rather should) convert it into a known issue by hard coding a check just before the crash occurs which make the operation abort gracefully. I don't think I can be more clear that that.

Now if any user (SolidWorks or otherwise) can show me a critical bug (which caused a crash) that was reported and which was not addressed in a future service pack or new version, I would appreciate it.

Of course, contrary to what some think, I happen to live in the real world and can understand if a few critical bugs slip though the cracks. But for users to come up in arms like the way they have, these issues have to be much more than just a "few".

Bugs and Known Issues

In the comments to my last post "Users and Non-Users", a couple of SolidWorks users leveled what I believe to be a pretty serious accusation against SolidWorks. They claim that SolidWorks finds bugs in their software, does not fix them due to lack of time and goes ahead and releases the software. As a software developer I find this pretty hard to believe. But then maybe that's because I draw a clear distinction between "bugs" and "known issues".

Known issues are problems in the software that programmers have come to know of and are unable to fix for a variety of reasons, some of which may be beyond their control. For example, the compiler used to create the software may have a bug that prevents a fix. The data being sent to the software for processing may be just too large. In such cases, programmers hard code in a check just before a problem can occur so that the software aborts gracefully and does not crash. This information and the behavior related to it is then passed on to the people writing the documentation and they add it to "Known Issues" section of the product documentation. This is perfectly fine with me and should be fine with any reasonable user as well.

A bug, on the other hand, is something that the programmers have come across or users have reported, the cause of which is yet to be ascertained or the solution to which is yet to be implemented. Personally I consider releasing software with such unfixed bugs, without converting them to known issues, is sacrilege. It is unpardonable. It is like Boeing shipping a plane to a customer comforting itself with the hope that the chance of it crashing is fairly low. OK, maybe I am exaggerating a little here, but I think you get my point.

Earlier I mentioned that programmers may not be able to fix bugs for a variety of reasons. Time should not one of them. That's why, in principle, I am against this annual release cycle thing that some CAD software vendors have got going. Now we all know that it makes good business sense to do that. But having said that, I would like to share something which an extremely successful businessman, Bob McNeel, said to me at COFES 2009 when I asked him when Rhinoceros 5.0 would be released. He replied, "I don't know". I almost spat out the beer that I was drinking. He went on to explain, "Of course, we do have a date in mind, but it all depends upon how the software looks like at that point in time. We have never had an annual release cycle. That would just makes a mess of everything."

Great minds think alike, eh?

User and Non-Users

In a comment, Matt Lombard asked me to comment on something that I have been trying to avoid talking about for quite some time. He asked:

"To the best of my very poor memory, all of the proponents of Direct Editing as the New World Order for CAD are non-users, and the proponents of history are users ...[snip]... Any comments on that?"

If you are a so called user, please forgive me if you find some of what you are about to read offending. It is not my intention to offend anyone. Definitely not Matt whose blog, I believe, is one of the best CAD blogs out there, not just for the content, but also for the way he puts it.

I want to keep Direct Modeling out of this discussion and only talk about this concept of users and non-users that Matt brought up. Over the years I have been reading comments from users which imply that the CAD media, analysts, authors, etc. have their heads in the clouds and do not know what they are talking about because they do not do real modeling work. I have even heard pretty derogatory comments (especially from SolidWorks users) saying things like, "The programmers at SolidWorks should be made to use their own software."

This kind of thinking is similar to questioning the wisdom of asking a priest for advice on your marriage. After all, what the hell does a priest know about married life, right? And yet they are very effective in sorting out marital problems. I don't know about the West, but here in a place like India, they are wizards. For a doctor to be able to write a prescription for a patient, he does not need to be ill. Furthermore, the patient does not even know or care how other patients in the clinic feel. But the doctor does. All that matters to each patient is his health, that's all.

My point is that a user normally thinks only in terms of the software that he is trained to use. For the most part, he is unaware of features and methods implemented in other software. I see this every day at SYCODE. We specialize in developing data exchange plug-ins for almost all the major CAD systems and we get questions from customer of all shapes and sizes. The kind of queries that we receive make me sometimes wonder whether users wear blinders that prevent them from looking at all the other stuff around them.

Now coming to the view that the CAD media, analysts, authors, etc. do not use CAD software. I will let others speak for themselves. But before I have my say, let me list the CAD systems along with their versions that are currently installed on my computer in office.

Acrobat Pro Extended (9.0)
Alibre Design (11.0)
AutoCAD (2000, 2000i, 2002, 2004, 2005, 2006, 2007, 2008, 2009, 2010)
Bricscad and dozen other IntelliCAD variants
Cobalt, Graphite (V8)
CoCreate Modeling 2.0
DoubleCAD XT and Pro
Inventor (10, 11, 2008, 2009, 2010)
IRONCAD & INOVATE (11.0)
KeyCreator (7.5)
KOMPAS 3D (V10)
Moment Of Inspiration (1.0, 2.0)
Pro/ENGINEER Wildfire (1.0, 2.0, 3.0, 4.0, 5.0 Preproduction)
Rhinoceros (3.0, 4.0, 5.0 Beta)
SketchUp (6.0, 7.0)
Solid Edge (ST)
SolidWorks (2006, 2007, 2008, 2009)
SpaceClaim (2009)
TurboCAD (15.0)
VectorWorks (2009)

And these are just general CAD systems, not specialized CAD software like industry specific solutions for Rapid Prototyping, Reverse Engineering, etc. Now these CAD systems don't just sit there and occupy my hard disk space. I use these systems on a daily basis. I have spent the last decade solving people data exchange problems by figuring out how these CAD systems work internally. Apart from a few personal projects like designing my house and the stuff in it, I do not create a lot of design data. But I sure as hell modify data created by others. The data I am referring to here is live data from customers (or should I say users?), often sensitive information for which I need to sign Non Disclosure Agreements. The kind of stuff that eventually end up as products, buildings, etc.

But what is more important to understand is the fact that at SYCODE, we do not offer design services. Rather we offer plug-ins and custom solutions that automate the tasks of creating and modifying design data. So I need to wear the hat of a user as well as a programmer to be able to automate a user's workflow in his CAD system or between his CAD systems. So when someone refers to me as a non-user, you can imagine why I would find that a particularly difficult pill to swallow.

And lastly coming to the view that programmers should be made to use the software that they develop, I believe that apart from reflecting insolence, this kind of thinking shows stupidity in its purest form. I think this is best explained by means of an example.

Like I said before, at SYCODE, we specialize in data exchange plug-ins for CAD systems, one of which is SolidWorks. I find myself using the Import Diagnosis feature of SolidWorks a lot on models imported by our import plug-ins. It is not uncommon for the Import Diagnosis feature to not fill all holes and close all gaps because its success or failure depends upon the quality of the imported data. But sadly, it is also not uncommon for me to hear customers bitch about SolidWorks not being able to do a good job. Now consider this for a moment. A user will use a feature like Import Diagnosis probably a few times a month, if at all. Can you even imagine how many times the programmers who developed this tool used this feature to create, update, test, debug and continuously maintain their code? As programmers we use the software that we create after every tweak in our code and after every rebuild. We use our software with all kinds of design data that we can gather or conceive. We sometimes programatically create data that a user would normally never create, just so that we can stress-test our software. Heck, we use our software so much that we often need to write code that continuously runs data though our software on a dedicated testing server 24 hours a day, 7 days a week, 365 days a year. Think about it. If you are amazed at the speed at which demo jocks work, I suggest you take a look at programmers. Just because they work in the back room invisible to the world, it does not mean that they do not use the software they create. They use it far more than these so called users do. The reason I call this line of thinking stupid is because its more like a cab driver scoffing at a bunch of automobile engineers who designed the car that he is driving.

And while I am at it, I would like to draw attention to another thing I find quite repulsive. When a user creates a design and it fails or does not work as intended, he goes ahead and modifies it and gives it a revision number. In programming parlance the failure is called a Bug and the revision is called a Service Pack. Users should start calling their failures bugs and revisions service packs and then they will be able to appreciate the saying "to err is human".

I often hear users say that CAD vendors should sort out all the bugs before releasing their software and not make paying customers debug their software for them. I have even heard some users say that the CAD vendors should pay them for reporting bugs. I can turn this argument on its head and ask users to design products that never fail so that people who paid money for the products they designed do not have to pay the price for their "revisions" as well.

Sounds fair, doesn't it?

Is the Direct Modeling Honeymoon Over?

In a comment, Matt Lombard remined me what Dan Staples, Director of Solid Edge at Siemens PLM, said to him last October:

"Ten years from now history based modeling will not exist"

Today, Dora Smith, Director - Global Social Media at Siemens PLM told me something which appears to quite the opposite:

"We have no plans to deliver NX or Solid Edge without a history-based option."

I believe 10 years is a very long time in the world of technology and would prefer to go with Dan Staples. I also feel that Dora is merely addressing the immediate concerns of her customers.

I simply cannot bring myself to believe that the best way to create and modify a solid model is by cooking it up in a sequential manner all the time. Features are here to stay, at least for the length of my lifetime. Whether they need to be created and maintained in an orderly manner is something that I am not comfortable with.

But there is another solution, something which just about everyone I have spoken to, including myself, feels is next to impossible. That is, to have a history tree containing features and allow the user to make direct edits to the features, but not add these direct edits as new features at the bottom of the history tree. Rather directly edit the existing features in the history tree. If such a solution exists then probably I could live with the history tree because I would not need to figure it out before I make any change to the model. Current history based modelers do only a fraction of this. I say fraction, because you can push/pull only those faces which have a clear relation to an underlying feature. Case in point, Instant3D by SolidWorks.

However, Autodesk claims that Inventor Fusion will do exactly what I said above was next to impossible. If that is indeed the case, then this year's Nobel Prize (doesn't matter which category) should go to the person at Autodesk who figured this out. I can think of few cases when this solution may be made possible, but there would be severe limitations to how much you can mess with the solid model. But then maybe I am not Nobel Prize material.

So to answer the question, "Is the Direct Modeling Honeymoon Over?", I say "No". I would say that probably the marriage between History Based Modeling and Direct Modeling has only just begun and they are now fighting over which one of them is wearing the pants.

Siemens Holds on to History

In an earlier post titled "PTC Joins the Direct Modeling Bandwagon" referring to PTC's announcements and demos at PTC/USER 09, I wondered:

"So does that mean that like Siemens, PTC is abandoning the history based feature modeling approach that they pioneered years ago?"

As it turns out there was something fundamentally wrong with the question. I have access to Solid Edge only and assumed that Synchronous Technology was implemented in NX in the same way, which apparently, it is not. An anonymous commenter pointed out:

"In NX, you can CHOOSE to have Synchronous features seamlessly integrated with the 'old' history-based modeling approach, OR, to go with a completely history-free approach. It is UP TO THE USER TO DECIDE. In Solid Edge, it seems you have to choose one or the other.

... [snip] ...

It is very unfortunate that the differences in implementation of ST between NX and Solid Edge are being confused (by everyone, from Siemens to the blog media etc)."

This is precisely the reason why I allow anonymous comments on my blog. So after I was enlightened I decided to get it straight from the horse's mouse. So I asked Dora Smith, Director - Global Social Media at Siemens PLM Software, two specific questions:

(1) Will Siemens continue to develop new technologies that are based on the “history based” parametric modeling?
(2) In the future will Siemens ship a version of Solid Edge and/or NX that will not have the “history based” parametric modeling option.

Her reply to question 1 was:

"We have definitely NOT 'abandoned' history-based modeling. We continue to invest in history-based modeling AND synchronous technology. The feedback from our customers so far is they want the best of both worlds: history-based and history-free modeling."

In response to question 2, Dora said:

"We have no plans to deliver NX or Solid Edge without a history-based option."

So there you have it. As far as Siemens is concerned, history is not going to be history. I was pretty alarmed by something that Al Dean said in a comment to the same post:

"I've heard of users reevaluating their Solid Edge licenses, some even dropping it and moving to another direct editing system that's more mature. Why? because of this notion that history is being dumped."

If Al is right, then maybe Siemens is not doing a very good job getting the message across to its customers. Either way, I am still trying to figure out the reason for implementing Synchronous Technology differently in Solid Edge and NX. It is quite obvious to me that giving a user the option to integrate Synchronous features in the history based modeling method is far better than not giving the option. So why is Solid Edge being left out of the party? Is Siemens facing the same problem that Dassault is facing with smaller brother SolidWorks stepping on the toes of bigger brother CATIA? Or is there something that I am not seeing here?

If any of you know the reason why Synchronous Technology was implemented differently in Solid Edge and NX, I would appreciate it if you could enlighten me a bit further.

GRX - Another ObjectARX Source Compatible SDK

Today the Chinese IntelliCAD developer, GStarSoft announced that they would be releasing GRX, an AutoCAD source compatible SDK, in a couple of months. According to the press release, "GRX, short for GstarCAD Runtime eXtension, is highly compatible with AutoCAD ARX interface. With GRX, one set of source codes can support two platforms (AutoCAD and GstarCAD)."

I think I should maintain a list of these ObjectARX source compatible SDK's, because I don't believe that we have seen the last of them. Here is the list:
1) BRX from Bricsys. This SDK is in production use by many AutoCAD plug-in developers.
2) FRX from Graebert. This is part of their new Argon platform which is still is Beta.
3) ObjectDRX from ZWCAD. The only information about it is as cryptic as the Chinese can make it.
4) GRX from GStarSoft. To be released in a couple of months.

The press release has a link to www.gstarsoft.com. If I remember correctly their web site was located at www.staricad.com. I wanted to see what had changed and so I clicked though and began looking around. I finally found myself on the About Us page staring in disbelief at the Autodesk Authorized Developer logo.

I thought Autodesk didn't partner with people who make AutoCAD clones. So I searched for "GStarSoft" or "GreatStar" or whatever name they go by now at the Autodesk Partner Index page. The search turned up empty.

I smell something fishy here. Do you?

The ODA Finally Gets It

More than seven months ago, in a post titled "DWGDirect and DRX Explained" I wrote:

"Take a look at their [ODA's] web site. This is what you see on the home page:

'The Open Design Alliance is a non-profit membership-based consortium of software companies, developers and users committed to promoting the open exchange of CAD data now and in the future. In addition to setting standards for CAD data formats, the ODA also focuses on the practical matter of developing software libraries of exceptional quality that enable ODA members to develop applications capable of reading and writing the popular DWG and DGN CAD file formats. ODA members use the following ODA software libraries to support their efforts of developing CAD solutions'

…and they go on and talk about DWGdirect and DGNdirect, about how these libraries can read and write DWG and DGN files. Absolutely nothing about anything I said above. No mention whatsoever about the DRX SDK. You need to click on a cryptic link called 'Public Downloads' to even know that they offer something called the DRX SDK."

Go take a look at the ODA web site today. This is what the home page says:

"The Open Design Alliance is a non-profit, membership-based consortium of software companies, developers and users committed to provide the ODA Technology Platform to its members, giving them the tools to create a wide range of technical graphics applications, including custom data access and editing utilities, visualization tools, and even full-scale CAD systems. The platform also supports the use of both DWG and DGN files, with import and export capabilities to other file formats."

I have been yelling myself hoarse on this blog and elsewhere, that reading and writing DWG files is just one of the many things that the ODA does. I even wrote a book to emphasize my point. It feels nice to know that the ODA has finally found itself. I have been privy to a few things going on at the ODA for some time. I would like to give a substantial amount of credit for this "makeover" to Arnold van der Weide, the president of the ODA. I know that there are other people involved as well, but let's give the devil his due. I am pretty sure that with the leadership and vision of Arnold, the ODA is a much stronger organization, which undoubtedly has a bright and strong future.

Today the ODA released DWGdirect.NET, the first ODA platform platform component built for use with the Microsoft .NET Framework. This opens the ODA's doors to a whole new class of programmers, the kind that do not need to mess with C++, but a more easier language like VB.NET. Full press release here.

Way to go, ODA!! Now go do what you do best. Crack that 2010 DWG format and piss all over Autodesk once again. I only hope that the ODA does not go ahead and do something stupid like the TrustedDWG thing they did the last time around. Otherwise Autodesk will be the one pissing all over the ODA in court.

PTC Joins the Direct Modeling Bandwagon

I guess I can open my trap now. People at PTC/USER 09 have started reporting on PTC's modeling plans. I was shown some of it during my visit to the PTC Headquarters in Needham this April, but was asked not to talk about it till PTC/USER 09.

Direct modeling will not be in Pro/ENGINEER Wildfire 5.0. Rather it will be part of Wildfire 6.0. But since they are already working on it, I suspect that it will be in the software but the functionality will be hidden from the user. When I asked PTC top management why they were not shipping this technology in Wildfire 5.0, they told me that they were not completely satisfied with the technology and in their view it would be in shipping condition in time for Wildfire 6.0.

So does that mean that like Siemens, PTC is abandoning the history based feature modeling approach that they pioneered years ago? Hell No! PTC has managed to find a way to do quick localized rebuilds so that a complicated history based parametric model can be solved much faster that it previously could, thereby giving the user the feel and easy of direct modeling. At least, that's what they told me.

DEVELOP3D is covering PTC/USER 09 live and has a sneak peek of the direct modeling that will become part of Wildfire 6.0.

PTC's New Blogger and Tweeter

Mark Lobo, PTC's Director of Windchill CAD Integrations, now has a blog. PTC/USER 09 starts tomorrow and Mark intends to blog and tweet live at the event.

Blog: http://marklobo.blogspot.com
Twitter: @marklobotweets