Solidworks for$40

[lankyyorky]

Hi all,

I've been using Fusion 360 for a while now and quite like it but Autodesk have just announced that the free version is going to be severely limited from October.

It probably wont affect me too much as I do most design work in 2d cad and use F360 for creating 3d printing parts and generating stl files which I can save on my computer, not in the cloud.

Browsing the web for more information on Autodesk's intentions I came across this on http://www.hackaday.com:

wittenbunk says:
September 17, 2020 at 4:01 am

I paid $40 for my legit copy of solidworks….

Solidworks education edition is free to download for members of Experimental Aircraft Association:
www.eaa.org/eaa/eaa-membership/eaa-member-benefits/solidworks-resource-center

It seems you could sign up for a year's membership and download a personal use copy of Solidworks for the $40 membership fee.

The programme requires quite a high spec computer to run on so I'll pass on this at the moment as my machine is pretty ancient but does all I need.

There is also this link now:

Hxd says:
September 17, 2020 at 1:56 am

Solid edge student edition is available for free for self-education:

solidedge.siemens.com/en/solutions/users/students/

If I remember the only restriction is interoperability with the commercial software. No CAM, but everything else I needed up until now is there. Usability is not the best but in comparison to other alternatives in terms of features and pricing it’s the best deal for me.

I am not familiar with either programme so I don't know what the differences are between the two.

[uuu]

I use the free Solid Edge 2D program, but have not worked up to the 3D version. As well as "students" it is definitely free for hobbyists: Siemens

Wilf

[Roger]

It's worth looking at this comprehensive explanation of what those new Fusion360 restrictions are. They aren't that draconian, so it's still a useful tool. Alternatively, it might be worth just paying the subscription if it's not too expensive. Although I own my Alibre Design and Mecsoft CAM, there always comes a time when you're forced to pay for an update, so it's not so different to an annual fee really. You can't expect to get something for nothing in the long term.

[lankyyorky]

I believe the minimum subscription will be $300 a year, which I suppose isn't too bad, I'll continue using the free version as what I use it for doesn't seem to be affected; mainly creating parts and exporting as stl files for 3d printing.

Most people seem to be annoyed that they can't export step and dxf files or open more than ten documents at a time after October with the free version, does make you wonder how many hobbyists would need ten drawings open at a time.

I mentioned Solidworks as the chance to download it legitimately for $40 is a bargain if you have a computer capable of running it.

[David]

The price I got for a subscription was about $600 AU a year. Too much. I'm wondering if the post processor can be made to emit some marker comments that makes it easier to restore rapids but if they remove them at generic toolpath generation time (before the post processor is called) that won't work. You can put them back manually by searching for positive Z moves.

The only restriction that bothers me is the removal of rapid moves. When you do a tool change it takes a very long time for the spindle to move up to the safe position and back down again, or when the table is moving to get a lathe tool back to the start of a toolpath. I think losing multiple tools in a single file was enough to annoy production people but I guess Autodesk decided it was too easy to stitch the files together.

I don't mind the one tool per file thing - it means I no longer worry about tool offsets. I just set the height after changing the tool each time using a broken 20mm endmill stub which doesn't take long for the small jobs I do.

I'm wondering if the EAA offer is global, and if they'll stop it once a lot of F360 refugees start to take advantage of it.

Alibre has just introduced a reasonably priced CAD/CAM package but it's geared more towards 3D printers and wood carving. In their FAQ they say it's not meant for people cutting metal - they don't stop you of course but said they have deliberately left out some stuff that metalworkers would like. And there doesn't seem to be a lathe option either. So that was briefly exciting but not for long.

[Neale]

I've been a keen F360 user for some time and worried about the "they've brain-damaged it - it's useless!" reaction. However, as poachers are always a head in front of the gamekeepers, take a look at this - github.com/TimPaterson/Fusion360-Batch-Post

I've been playing with this add-in recently and it seems to do what it says on the tin. It overcomes the "separate files per tool" restriction (although as has been mentioned, that's not much of an issue if you are manually changing tools anyway) but more importantly it tracks down all those "G1 instead of G0" rapid feed limitations and puts the G0 back again. Good to see full rapid speed repositioning in the middle of a cut! It can't do anything for >3 axis CAM which is a shame for those with a 4th axis machine. BTW, you can (at least at the moment) get round the "separate gcode files per tool" restriction by creating a pattern in CAM with all the toolpaths you want to include, and then post-processing that. Even with a one-instance "pattern", this seems to do the trick.

Personally, I haven't seen any material change in the 3D modelling capabilities - so if you are using it for modelling, you haven't lost anything. OK, no simulation/stress modelling and stuff like that, but in all honesty that's not a common amateur requirement. There is no PDF output from the drawing module - but that's easily fixed by using the "Print" feature and directing to PDF. The output I get looks exactly like it used to with the direct output-to-PDF facility.

Just recently I've been playing with Solid Edge 2021 Community Edition. This looks as if it has even more modelling power than F360, and Siemens claim that it has all the capabilities of their "premium" commercial version. Big downside is no CAM although I am assured by a friend that you can export step model format and import that into F360 to make use of its CAM. And it's free - not even $40 to pay!

[David]

I have tried Tim's addon too, but didn't like the way to processed all setups and it didn't work that well for me. I started reading the code to see if I could make it work for the selected setup or toolpaths but it's more work than I can put into it given I have mostly what I want.

I thought the patterns might be a work-around because I was using a pattern last week and saw rapid Z moves in it! But the next set of ops I posted didn't have them so that was weird. Maybe because I don't want all tools posted any more and I was posting the individual toolpaths.

I'd be wary of any "free" community edition from now on. Draftsight and F360 both went back on their "free forever" claims and I can't see why Solid Edge won't do it too at some point. It just can't make sense from the business's point of view. Very few hobbyists will turn into paying customers and it's too easy for commercial users to abuse.

F360 is still just on the right side of usable which is good. Losing the rapids was a blow but I only use my machine very rarely so mucking about with Z moves isn't too much hassle yet.

[David]

Neale,

I had a closer look at Tim's add-on code today and found his experimental restore rapids code loads the already post-processed g-code and analyses that. So that meant it might be worth looking at the actual post-processor to see if I could recognise the lines I was changing manually - a move to +Z with no X/Y move.

Have a look at a patch for the post processor: www.model-engineer.co.uk/forums/postings.asp?th=167916&p=4#2666974

It gives back Z rapids based upon the patterns of g-code F360 seems to generate. I always have Z = 0 as the top of my stock, and +Z is above the stock. So if there is a move to Z > 0 and nothing in X/Y it replaces the G1 with a G0 and strips the feed. It seems to work for the toolpaths I get. The feed is output on the next G1 command.

I don't know if there are missing X/Y rapids. I may look at more generated g-code and see if there are X/Y moves after a move to Z > 0. If so, they might have used to be rapids. I also have all my old g-code on the Tormach so I can look through that too.

[Neale]

I agree that it would be more useful to me if it would just handle one toolpath at a time as well - a click box to turn the this on/off would be good.

I had started musing on writing a bit of code that could recognise any moves that took place above a certain Z height, and then changed any moves in any axis to g0. Looking at what the plugin does shows that it's slightly more complicated than that. F360 uses the normal short-cut of just issuing coordinates for moves, assuming the previous g1 is still in effect. You need to pick up these and make sure that after adding a g0, you put in the necessary g1 later. None of this is rocket science but there are little gotchas like this! The plugin does mean that XY rapids work, though.

I'm about to upgrade my CNC facilities with a machine using pre-loaded toolholders rather than swapping tools in a collet so I'm going to be able to use tool offset tables and my thinking on the whole tool-change process will be different. I guess that that's why people see different effects of the F360 changes.

Coming back to the original topic (although I doubt if the thread will stay there!), does the version of SolidWorks mentioned include CAM?

[David]

I think it does include CAM.

I agree my changes are quite conservative so far and I did not analyse Tim's code further once I saw it loaded the post processed file and worked with that. I may take a closer look at his code.

I use the TTS system which means I could use length offsets (and did until this recent change to F360). But what I've found is that for one offs, which is 99.9999% of what I do, things like drills are a real nuisance. You never have enough chucks and end up changing the drills in the 3 chucks you have for each job so have to measure them anyway. It's just as easy to set their offset using the dowel on the job before kicking their program off. It also means I can be a bit sloppy with tool numbers - I could even just give each drill chuck a tool number rather than every different diameter drill. That's one real annoyance with CNC - I always end up changing even the endmills because I don't have enough TTS holders. Then one breaks and you have to remeasure... this one tool at a time is actually working well for me because I don't do production.

Changing Tim's code to only work with the selected setup or toolpaths should be easy enough. As a prelude to changing the add-on I wrote a script that simply gave a message with the name of the selected setup so it's easy to figure that out. Tim's code does something weird with empty toolpaths etc and a lot of that complexity could be dropped in my case because my CAM is so primitive. Contour, trace, drill, that's about it for me. The occasional 3D op, but quite rare. But given all I wanted was rapids restored I think I'm better off changing the post processor itself, maybe using his algorithms.

It's an interesting mix. The post processor seems to be in JavaScript but the script API is C++ or Python. JavaScript would have been just as easy to integrate as Python and then been the same as the post processor but maybe Python has better IDE support.

[jasonb]

Nov 30, 2020 10:46:53 GMT David said:

The only restriction that bothers me is the removal of rapid moves. When you do a tool change it takes a very long time for the spindle to move up to the safe position and back down again

You can always set the position the head moves to as less. Not having any quick change tooling I delete out the G28 that F360 puts in and my tool tends to stop at 15mm above Z0 in the last XY position. I then just jog up enough to change the tool in the collet or chuck and set it's height with a block so at most the tool is only having to rapid 20mm at the start of finish of a path. Even with TTS you only really need to move a couple of inches up so the holder can be removed.

I also wonder on one off jobs if going through many lines of code looking for rapids to correct will take longer than just leaving the thing with slow rapids. It's easy to see how much time you will loose by right clicking on an operation and then clicking "machining time" this shows how much time is spent cutting and how much during rapids, simply change the rapid speed to the feed rate and you can see the time change. I've looked through several of the items I did before the changes and the loss of rapids is only a few percent of the total time so hardly worth the bother unless you had a whole batch but I do tend to feed mostly 300-500mm / min not snails pace.

I tend to vary the position of my Z0 as the top quite often gets machined I would loose the ref for subsequent tools which would make it harder to visually look for code.

[David]

I like doing the toolchange up high - I'm clumsy enough I'd bonk the tool into the job or the vise if I tried to save time there.

The Z moves on the toolpaths don't seem to be too hard to analyse. It will always rapid to the clearance height, then move to the start X/Y, then rapid to the feed or safe height, then start the lead-in/ramp whatever. A lead-out, then rapid to the feed or safe height, move to the next X/Y, etc.

So there are 3 Z values you need to look for - the clearance, feed, safe. Not sure where retract comes into it. Maybe I'm mixing up feed and retract. But all the g-code I looked at yesterday only seems to use up to 3 Z values for rapid move levels.

I was hoping I could analyse the toolpaths using the F360 API but it doesn't give you access to the actual toolpath moves, just whether there is one and if it is generated/valid. But you can get access to the height values for each operation. So one relatively safe way would be to write those out to a file, or into the post-processed .nc file, so subsequent code can use them when looking at Z moves.

I think any Z-only move to one of those heights is a rapid, then any X/Y-only moves after that are rapids. Any move containing a Z component to a height of less than one of those 3 special values has to be a G1. This holds true for every 2D and 3D toolpath I've looked at so far. The smarts is in the cutting moves, not the rapid positioning.

Unfortunately the solution to restoring them does not seem possible either in the API or post-processor alone, it will require a combination of both.

You can tell I'm much more interested in solving a software problem than in making parts on this thing :-\ Far more playing to my strengths.

And yes, that I cut at between 10-30% of the speed you do makes a difference. Watching the head crawl up and down irritates me no end.

I'm still waiting for a 4mm collet to arrive so I can try your cutting parameters. After I broke my last 6mm shank endmill 30 seconds into a cut last week I sprung to ordering from an in-AU supplier to try and get one more quickly, but a week later it's not here. It's taking at least a week for a parcel (different item - I'd have driven there to get the collet) from a town a 40 minute drive away to get here so Aus Post is struggling at present.

I think I did get up to 90mm/min @ 5000rpm last week when doing thin brass parts with no trouble until the cutter got dull. Then I tried a 2 flute 2.5mm cutter at a bout 30mm/min because it looked delicate and it pinged in 30 seconds But it had long flutes, about 12-15mm - no idea what sort of job it was for.

[jasonb]

Dec 2, 2020 22:11:04 GMT David said:

I like doing the toolchange up high - I'm clumsy enough I'd bonk the tool into the job or the vise if I tried to save time there.

You can tell I'm much more interested in solving a software problem than in making parts on this thing :-\ Far more playing to my strengths.

You can still let the code finish at say Z15 then just hit the jog button to move the head up as far as you feel you need to do a change, jog back down to set tool height and then start next code from there. That way most of the movement will be faster than your feed rate.

I'm the opposite preferring to make the part and not delve into the software

[David]

You obviously don't know how many tools I've broken by pressing the wrong jog button or not noticing I was on continuous rather than stepped jog mode (most recently last week). I'm really bad at this CNC game, and don't ever seem to get better at it :-\

It wasn't the original plan to be learning the F360 API and post-processor but we're here now. I do worry that if I find ways around their current limitations they'll just add others so I'm a bit tempted to not publish a more complete solution than I already have and keep it for myself. It was interesting to find the tool change method that Wilf and others have explained in the past is actually easier for one-offs like I do than constantly tweaking the controller offset tables etc. Trying to keep a consistent offset table is beyond me for some reason.

I was excited by Alibre Workshop - the price is right and the CAD side seems like it's fine. But when I learned the only way to communicate the model to the CAM side was via STL, and the FAQ emphasises that it's not meant for serious metal toolpaths, it put me off. I'll still give the trial a go the next time I have a relatively complicated part to make though, just it in case it does work out ok. I just don't want to waste the trial period on a trivial profiling cut. Not having lathe toolpaths was also a blow. They're clearly aiming it at the 3D printer and wood router crowd.

[jasonb]

Well at least the info is there for those that are happy to change lower down and use the jog.

I did download the trial. As you say it's a separate CAM package MeshCAM so if you want to alter a part you have to do all the cam again although that is what I do with my Alibre drawings I'm able to tolerate for the free F360 but would want it as one if paying and can always do a bit of drawing in F360 if needed..

The moment I tried Meshcam it was obvious it was aimed at the hobby maker with a basic gantry router as the materials listed are woods, plastics and ali/brass. And the rest seems very basic for the £240 it would cost without Atom.

Looks like Fusions tempt them in for free and they won't want to leave tactic worked!

[David]

Turns out a simple way to decide on a safe Z level for rapids is to add a property to the post-processor. Anything at or above that value can be considered a move into the rapid zone. The value of the property can be changed in the post-process dialog.

This avoids worrying about where the stock origin point is and having to extract the heights from the toolpaths and get them into the intermediate CNC stream as comments, then parsing those comments in the post-processor.

As long as I set that property to a value that suits the current setup and its toolpaths it should work.

[David]

My custom post processor is going well even with the primitive strategy outlined above.

The part resting in the bobbin went from 3:15 hours to 23mins with the restored X/Y rapids. That part is 12.7mm diameter, so the table isn't moving very far to get from one side to the other. I'll admit I cut the stepover in half on the two last stages, but I'm sure this change has still saved over an hour on the part.



The parts I was cutting yesterday (pictured in my other thread) also benefited. In a toolpath including 4 contours, F360 did the first two to full depth one after the other but it decided the 2nd two (that were the same) would be done by moving between each at each different depth pass. So without the rapids the table would have been crawling 40mm right and then left again at the feed speed for each pass.

If anyone with a Tormach wants to try it, PM me. I'm still leery of publishing it in case Autodesk decide to then implement more draconian measures.