CAM with extensive api

[Qwan]

Be careful of terminology here. Macro is commonly referred to as simply automating picks or steps, not actually accessing the underlying api. I'm not saying that there are are no cam systems that use macros in that fashion, I'm just pointing out the functionality differences. Also, when macros are are used to record a series of steps, or clicks it is not uncommon for them to break from version to version whereas api/vb is accessing functions. I have yet to see those break in NX and I'm willing to be that any cam system using api/vb will not break between versions either. That's one of the huge advantages of api/vb automation over a function that merely records steps or clicks.

 

[goooose]

, I think that it is important to distinguish an API from macro functionality. Both do allow automation. However, macros are often limited to the application scope, in that they only allow automation within the "parent" program's functionality.

Back to my post#2, Esprit uses VBA. VBA is/was the best 'macro' interface going. It's built into the application, no need to run special software, and is fully capable of interacting with other programs ie Excel. However, VBA was killed off by Microsoft, it was supposed to be fully removed but those who had it in their software got a grandfather clause so it has stuck around with no new support. Heck, Microsoft still uses it themselves. I think the Excel automaters were the reason VBA wasn't fully dropped.

If you want to easily get into automation, VBA can't be beat. If you've ever gone through the steps of 'connecting' your programming software to your CAM software you know why VBA wins!

 

[carbonbl]

Back to my post#2, Esprit uses VBA. VBA is/was the best 'macro' interface going. It's built into the application, no need to run special software, and is fully capable of interacting with other programs ie Excel. However, VBA was killed off by Microsoft, it was supposed to be fully removed but those who had it in their software got a grandfather clause so it has stuck around with no new support. Heck, Microsoft still uses it themselves. I think the Excel automaters were the reason VBA wasn't fully dropped.

If you want to easily get into automation, VBA can't be beat. If you've ever gone through the steps of 'connecting' your programming software to your CAM software you know why VBA wins!

Interesting reply because it illuminates the advantages of an integrated macro solution while also revealing some downsides.

I've never developed in VBA, although I've worked alongside developers who used it and I'm aware of how useful it is for automation in the MS ecosystem. I would think that your automation workflows would have to be tied into other VBA-native MS applications (like Excel)? One of the benefits of being able to use Python or C, for example, is that you can use the crazy amount of third party libraries for those languages. What does that look like for VBA?

With Microsoft gradually ending support of VBA in favor of Javascript APIs for MS Office automation, I would think you would have to be fairly cautious in deciding to use it for a new automation workflow in 2020. How much longer will Esprit build macro functionality on an "officially" dead language until the technical debt becomes too much and something's gotta give? If you need to hack together a 20 line macro for a job due tomorrow, this is a moot point. But if you're designing an extensive automation workflow for a startup where you want to make sure you're not burdened by legacy tech, it's a huge deal.

Having it integrated into the application is convenient and great from a training perspective. However, when I read that as a software developer, I'm immediately wondering if it will be problematic to use my standard suite of external development tools. Can I use my preferred IDE? How can I integrate automated testing? Version control? If you're a one man band that is only programming fairly simple macros, these may not be an issue. But as the complexity of development and the size of your dev team increases, the importance of these other tools grows exponentially.

 

[goooose]

Interesting reply because it illuminates the advantages of an integrated macro solution while also revealing some downsides.

How much longer will Esprit build macro functionality on an "officially" dead language until the technical debt becomes too much and something's gotta give?

Having it integrated into the application is convenient and great from a training perspective. However, when I read that as a software developer, I'm immediately wondering if it will be problematic to use my standard suite of external development tools.

Ya, I don't think VBA is in Esprit TNG. I don't think its an option for new software. Esprit 20xx doesn't seem to be going away nor do I think they would remove the VBA from it. Does automating Esprit 20xx make sense now? Tough question that ties into my next reply. (I still think yes)

How many machine shops have the budget for a dedicated software developer? How many machine shops would use VBA style 'macros' if the software included it? (specifically looking at those who do not have a dedicated software developer). Sure, the software developer will be able to do more but most CAM programmers do not even know what Visual Studio is let alone how to use it or connect it to their CAM software.

I guess my point is CAM software needs an easier automation interface like VBA so more automation can be done by the people using the software. VBA in Esprit nails this...and it can still be used with Visual Studio or whatever other IDE you prefer for that extra bit of power.

 

[boosted]

Esprit TNG definitely has an API. IIRC it uses simple "VBA like" programming. It's been many years though - I can't say for certain. I do seem to recall that it was missing a bunch of functionality from the legacy software and it didn't have the amazingly thorough documentation that sets 20xx apart. But again, that data is many years old now, so take it with a grain of salt.

But back where I wanted to start - are we positive that Esprit 20XX is here to stay? Support for it several years ago was hit-and-miss, because so many resources were being dumped into TNG. What's Hexagon's plan there? My point is not to bash Esprit so much as to say that it seems crazy to choose this time to attach yourself to their legacy product.

 

[carbonbl]

...

I guess my point is CAM software needs an easier automation interface like VBA so more automation can be done by the people using the software. VBA in Esprit nails this...and it can still be used with Visual Studio or whatever other IDE you prefer for that extra bit of power.

When discussing ease of use, I think it's worth mentioning that there are a huge amount of younger people coming into the labor force who have had some exposure to Python as it seems to be one of the most popular choices in HS/College programming education. I'm not even talking about CS grads, just folks who have had to take one or two 100-level STEM courses. You really can't say that about VBA. I would wager that in most labor markets, your pool of (non-software developer) hires includes a significantly larger number of people familiar with Python than VBA (or any flavor of G Code, even). And that proportion is bound to grow, while the proportion of VBA-savvy folks will shrink. If your CAM programmer is already familiar with writing Python, that's a huge plus in my book and doesn't require a separate software dev hire, which I agree is out of the reach of most machine shops.

 

[CarbideBob]

VBA is not fast code but it gives you access to the entire windows API at a somewhat easy level compared to C.
One can even intercept the low level messages to a "window" and pass on or modify them. Fake mouse position or clicks and the keyboard or and user interaction.
Admittedly this level not for the faint of heart but the fact that one can do it in Basic sort of neat.
Bob

 

[goooose]

When discussing ease of use, I think it's worth mentioning that there are a huge amount of younger people coming into the labor force who have had some exposure to Python as it seems to be one of the most popular choices in HS/College programming education. I'm not even talking about CS grads, just folks who have had to take one or two 100-level STEM courses. You really can't say that about VBA. I would wager that in most labor markets, your pool of (non-software developer) hires includes a significantly larger number of people familiar with Python than VBA (or any flavor of G Code, even). And that proportion is bound to grow, while the proportion of VBA-savvy folks will shrink. If your CAM programmer is already familiar with writing Python, that's a huge plus in my book and doesn't require a separate software dev hire, which I agree is out of the reach of most machine shops.

Not trying to be rude here but have you been in a machine shop? I will say with great confidence that the number of machinists who even know what Python is, is extremely small. Ya STEM has been a buzz word for what, 5-10ish years now? Those kids are still in highschool and probably if they were really into the science and math they are headed down the university path to engineering of some sorts.
Machinists will always be blue collar. The best CAM programmers will always be seasoned machinists...guys/gals who hated classrooms and just wanted to make shit...somehow a boss/manager convinces them to start programming CAM, their backs are sore enough that the all day chair seems like a reasonable trade off....these people have never heard of Python. If automation requires 15 hoops to jump through first, it isn't going to happen. Automation is the only way we can compete. It needs to be as simple as possible to implement.

I'm not saying VBA is the best choice. I'm just saying its the only one (I know of) that is built into a CAM application and also gives access to Windows/Excel/SolidWorks etc etc. Is there anything else comparable?

 

[goooose]

Esprit TNG definitely has an API. IIRC it uses simple "VBA like" programming. It's been many years though - I can't say for certain. I do seem to recall that it was missing a bunch of functionality from the legacy software and it didn't have the amazingly thorough documentation that sets 20xx apart. But again, that data is many years old now, so take it with a grain of salt.

But back where I wanted to start - are we positive that Esprit 20XX is here to stay? Support for it several years ago was hit-and-miss, because so many resources were being dumped into TNG. What's Hexagon's plan there? My point is not to bash Esprit so much as to say that it seems crazy to choose this time to attach yourself to their legacy product.

I have no inside info but I don't see why they would drop 20xx. It sucks that its 32 bit software but its just sooo good it makes it ok.
I imagine the Hexagon deal was ok'd to help boost TNG. Hexagon has deep pockets. TNG was a huge undertaking. I expect TNG to replace 20xx only due to functionality benefits, not because the product is killed.

Again, does it makes sense to undertake a 2000hr automation project in VBA for Esprit 20xx, probably not. Any project of that size you're looking at dedicated CS programmers using some other IDE anyways. For your everyday automation, absolutely Esprit 20xx is still viable. Not only for VBA but their other Knowledge Based automation as well.

 

[CNC Hacker]

I just flipped thru the Esprit TNG help documents and they do mention VBA in the section about expressions and equations. Don't know if it's as fleshed out as 2000 series, but as far as I know the knowledgebase still works for automation tasks mostly the same way.

 

[DouglasJRizzo]

For a low cost alternative, PowerStation allows macros and has the ability to have you write your own posts and incorporate machine specific macros into them.

 

[carbonbl]

Not trying to be rude here but have you been in a machine shop? I will say with great confidence that the number of machinists who even know what Python is, is extremely small. Ya STEM has been a buzz word for what, 5-10ish years now? Those kids are still in highschool and probably if they were really into the science and math they are headed down the university path to engineering of some sorts.

OK

Machinists will always be blue collar. The best CAM programmers will always be seasoned machinists...guys/gals who hated classrooms and just wanted to make shit...somehow a boss/manager convinces them to start programming CAM, their backs are sore enough that the all day chair seems like a reasonable trade off....these people have never heard of Python. If automation requires 15 hoops to jump through first, it isn't going to happen. Automation is the only way we can compete. It needs to be as simple as possible to implement.

I'm not saying VBA is the best choice. I'm just saying its the only one (I know of) that is built into a CAM application and also gives access to Windows/Excel/SolidWorks etc etc. Is there anything else comparable?

You say machinists will always be blue collar but in the same breath you say automation is the only way we can compete? Don't you see the contradiction there? Developing and integrating automation is a highly skilled, technical field. Let's not let the aesthetics of who is and isn't blue collar get in the way here. We're both posting on PM, so you and I both respect skilled machinists and know they are just as smart and technically minded as any white collar software developer, just in different knowledge domains.

I'm not here to hate on VBA- like I said in my last post I know it's super useful for a variety of things. I'm interested in talking about what the next 5, 10, 20 years will look like for the field. I think it's worth considering what kind of skills people in the next generation will enter the workforce with. Yep, I agree that most machinists now have no idea what Python/C/JavaScript are. But for the people who are now starting their careers or will be in the next 5-10 years? I think that will change.

 

[EmanuelGoldstein]

... most CAM programmers do not even know what Visual Studio is let alone ...

Fairly soon no one will know what it is because a while back Oracle/Sun won a lawsuit against Mickey and part of the terms involved removing all the Visual Studio stuff, and anything that used it. That's one reason a whole bunch of older stuff has disappeared from MSoft's downloads.

I don't believe software wears out either, but this could create something of a future problem ...

 

[bryan_machine]

Visual Basic is end of life, but Visual Studio? Visual Studio Codespaces (cloud platform) is being replaced by GitHub....

The Java suit was settled in like 2002. So it's not clear what EG is talking about.

Older stuff disappearing could be due to losing a suit, but it's also because they have a burning desire to not support or deal with holder stuff, and a crushing desire to move people to things like the microsoft store - because they have apple revenue envy. The small point that the key apps in the world (like CAD) would basically move to linux before giving MSFT a cut seemed to elude them.

None of this has much to do with OP's question.

 

[CarbideBob]

Yep, I agree that most machinists now have no idea what Python/C/JavaScript are. But for the people who are now starting their careers or will be in the next 5-10 years? I think that will change.

This I highly doubt.
30 years back and change the names of coding tools used and I would have agreed but never any movement in this area and RS-274 is the most any achieve.
Adventurous souls may try macros.
Learning C and it's variants takes a lot of time and energy without much payback for a cnc machinist.

Code will always become obsolete. The API in your CAD/CAM will change over time. Functions you depended on will disappear, others may be there but be called differently so one has to re-code.
I was one of the biggest haters of MS operating systems and products at one point on the curve. Looking back that was a huge arrogant mistake IMO and killed a huge market in the tooling world for me.
Bob

 

[JNieman]

I don't think I know a programmer who would suggest /starting/ with vba these days. If you already know it, have used it, and are invested in it, sure. We still maintain a bunch of Excel and even some Inventor automation from back in the day. Otherwise for that stuff, we all moved to python and .NET (C#/VB) languages. I think some of our controls guys use C++ for stuff but I don't even think that's very popular.

I just mean to say... if you don't already know vba, don't waste time learning it. As stated, it's dead, dying, and on its way out. Even javascript would be better. Autodesk's Fusion uses it, but I don't know who else does.

It's just silly to think that anyone in the business of automation would /pick up/ vba in the year 2020.

Most of all stay adaptive. Stop riding a dead horse. You won't pick up anything that will stay current for the rest of your life, but there's no reason to pick something that's already most-way in the grave!

Honestly I've found that editing Fusion's post-processor to be easy but I use Fusion for pretty niche stuff rather than general machining. We have MasterCAM in-house for the general machining side, but it was fleshed out before I came on board here, and we have our own code expert who maintains that post, so I haven't messed with it. They have their own language.

I would say, don't be afraid of learning a new language to learn to fix your post. If all you're doing is tweaking M/G usage here and there for basic stuff to suit your controller, you don't even need to know the language well. That's simplas as a "find/replace".

I don't think there is one language that will rule them all (in before python nerds show up to argue) as it largely depends on /what/ you're automating, as to what you need to know.

I've gotten a /lot/ done using VB.NET but that's only because there's an API for everything I've needed it for, so far, with one exception where I had to use C# and the aforementioned javascript.

Gotta be flexible... but holy shit don't bother with vba.

 

[goooose]

but holy shit don't bother with vba.

Maybe I need to re-read my posts but I don't think I suggested that VBA was the best language to use. My point was that it's the easiest to implement.

Also, seems many of you are confusing automation with automating. We're talking automating some repetitive tasks in CAM software not automation of an assembly line.

Automating tasks being done by a CAM programmer who is probably a machinist first. Not many machinists are going to have previous experience with any computer programming languages, C#/Java/VBA/whatever, let alone have the knowledge/desire to install an IDE and then connect that to their CAM software. VBA is just easier since it is built into the software. There's a reason Esprits Automating forums are rife with activity while other CAMs are nothing but crickets...its just easier to get started with VBA! Not because its the VBA language but because its directly in the software! The same can be said for Excel. Why don't more accountants use C# inside of Visual Studio for automating Excel? Because VBA is way easier since it's built into the software!

...Excel is the reason VBA will never die even though it was supposed to ~10 years ago.

 

[CarbideBob]

I LOVE VBA.
Have the tee shirt that says "Real Programmers do it in Hex" but did Octal first.
I also liked Forth as a control language so I'm the guy who is mad.
VBA is simpler to use and more important easy to read. Added that it allows me to take control of every button on the screen you may click on if you want to go deep.

Try to teach C++, Python or VBA to your floor guys and see which works out better.
KISS.
Bob

 

[gregormarwick]

I LOVE VBA.
Have the tee shirt that says "Real Programmers do it in Hex" but did Octal first.
I also liked Forth as a control language so I'm the guy who is mad.
VBA is simpler to use and more important easy to read. Added that it allows me to take control of every button on the screen you may click on if you want to go deep.

Try to teach C++, Python or VBA to your floor guys and see which works out better.
KISS.
Bob

In the long run, Python might well become the defacto standard for applications automation. It already is outside of the MS sphere, and it probably has orders of magnitude more active users than VBA. It's every bit as easy to learn as basic.

I am not a fan of Python, but it is what it is. The low barrier to entry is a double edged sword and there are lots of extremely poorly implemented solutions to problems out there as a result. Py advocates always harp on about it getting more people into programming, and it definitely does do that. Problem is that rather than being the stepping stone it was intended to be, people get stuck on it and never learn anything else.

MS have been pushing JS as the replacement for VBA for years now. It's a better option than Py I guess, but I dream in C++ so my opinion is biased. And JS is absolutely more difficult to learn than Py or VB.

 

[fostereast]

Old Thread, but... CAMWorks has an API. Not sure if it's published, but the guys that wrote the original version of CAMWorks were on contract with SOLIDWORKS in the mid 90's and when starting CAMWorks wanted to create an API in the same vein as SOLIDWORKS. Note: Not a plug for CAMWorks, just offering feedback on the OP's question. I suspect to get info, you would have to contact the Scottsdale office for HCL/CAMWorks.