About VM for SW future

All discussion related to VisualCAM for SolidWorks
Locked
ftec
Posts: 60
Joined: Sat Apr 19, 2008 12:33 pm

About VM for SW future

Post by ftec »

I know this is a tough question to answer without being able to see in the future, but any considerations about keeping future VM Pro for SW versions backwards compatible with say the SolidWorks version 2010?

I was one of the first using SolidWorks in our country over 10 years ago but stopped paying maintenance in 2004 after moving to another line of business from design engineering. From that point there was no need to be able to have the lates SW file versions, which was one of the main reasons for annual upgrades.

If I now get a deal for a onetime upgrade to SW 2010 just to get the VM Pro for SW, that upgrade would do well in my current need for CAD for many years to come. What concerns me is that, as SW has it's annual upgrades, would I perhaps be required get that as well?

Thanks,
Risto
MecSoft Support
Posts: 2405
Joined: Wed Aug 01, 2007 4:15 pm
Location: Irvine, CA, USA
Contact:

Post by MecSoft Support »

Backwards compatibility is determined by the Solidworks developers. If they don't change the programing API then we will have this but if they do then we cannot. In the past Solidworks has been very cavalier in their attitude about changing the API and consequently breaking applications. They have been good for the past 3 releases going back to 2008. However one never knows!
ftec
Posts: 60
Joined: Sat Apr 19, 2008 12:33 pm

Post by ftec »

Thanks,

I'm not sure if I understood completely what you said, but just to clarify a bit further what I meant.

I did SW API programming for one year back in 2001-2. At that time SW API supported functions of older versions to some extent. Sometimes an old function (name) had ceased to exist in the later version and in that case the only way to keep the API program backwards compatible was to identify the SW version and select the appropriated function accordingly. This applied to functions that had their name altered or parameters changed in some way, but still same functionality existed.

So, actually I wanted to know if you have considered to use an approach of something similar when you make new version of VM for SW?

If new possibilities arise based on new SW API functions those would of course not work with an older SW version. However, at least all the other enhancements and fixes that you may make in VM would be available for older SW version users.

Thanks,
Risto

PS. After writing that I realized that it may be a better idea to stick with the standalone VM in a case like mine...
MecSoft Support
Posts: 2405
Joined: Wed Aug 01, 2007 4:15 pm
Location: Irvine, CA, USA
Contact:

Post by MecSoft Support »

It is not that simple because we have to link with different class libraries etc. and keep and maintain older versions on our computers. So my feeling is that development will probably not spend effort maintaining backward compatibility (actually would be a back port) if it is broken by Solidworks. If it is something simple then I am sure we should be able to do it. Our hope is that if we develop CAM in a current version (2009 say) it would run in a future version without problems. This way we can maintain a single development environment. If Solidworks breaks this then we will be forced to move to the latest version. Hope this makes sense.
ftec
Posts: 60
Joined: Sat Apr 19, 2008 12:33 pm

Post by ftec »

It does, thanks!
Normand Blais
Posts: 31
Joined: Wed Aug 01, 2007 4:15 pm
Location: Montreal Quebec Canada
Contact:

Post by Normand Blais »

Hi
Is it the same with rhino?
MecSoft Support
Posts: 2405
Joined: Wed Aug 01, 2007 4:15 pm
Location: Irvine, CA, USA
Contact:

Post by MecSoft Support »

Yes that is the same with Rhino. For instance RhinoCAM 1.0 was based on Rhino 3.0 SDK. When Rhino 4.0 came we had to rebuild RhinoCAM using the Rhino 4.0 SDK. RhinoCAM 2.0 was based on Rhino 4.0 SDK (because the 3.0 SDK was not upward compatible) and will not run in Rhino 3.0 because the SDK's are not backward compatible. Now that Rhino will be coming out with Rhino 5.0 we have RhinoCAM 2.0 running inside Rhino 5.0 because Rhino has not broken their SDK. We hope this continues because we would like our next release or RhinoCAM to run in both Rhino 4.0 and Rhino 5.0.
Locked