[SBC Cycle]

Can you tell me what happens if you leave the UCS at the origin? Does it have to be rotated for a reason or can it remain at the origin?

I don't think your model as it is needs to be rotated but I think it should be translated to BobCAD 0,0,0 UCS. You can override how your STL's were "saved" in relation to the UCS and move them around in the Machine Definition but after experimenting with my own machine models, it's better if the center and face of my spindle is always at X0, Y0, Z0, the same as it is when I push "Home G28" on the Haas or line up the CS (Zero) position of my Fadal. Of course both the Fadal and the Haas allows for a "Home" position different from Machine Coordinate Zero, but I made a decision several years before we even purchased CAM software that I would never do that just in case I get full Simulation. All axis set to Zero in Simulation (right click the Axis controls, set to Zero) should look just like the real machine when it is sent to "home" when looking from the top of the machine. Again, I say should but I don't believe it is absolutely necessary, it's whatever you want. I want it EXACTLY like my machine.

Part of what I was asking about the geometry (STL) files used for each component is if you can keep them separate for cosmetic purposes as well. It would be great if you can import an STL of just the MDF top on the table and make it look like MDF in color, while the subtable remains the machine color. Or the profiled rails separately from the main machine body so that you can color each in a more realistic rendering. I can see instances where this would add some polish to a presentation. Clients are always amazed by watching things like that and rarely enjoy watching the actual machine (deafening load, move much slower than you can simulate and lots of dust). It would also be cool to be able to emboss a number into each head, so the head number is obvious to anyone using the simulation. If you can import more than one file for each section, that would be possible. I've been trying to do so, but so far I get an error message when I set it up that way.

You can stack as many geometry files as you want on an axis in the Machine Definition. I haven't investigated whether this makes your Machine in simulation occupy more resources but I believe it would. Like the MDF spoilboard on the top. If you lump the table, vacuum plate, and spoilboard all together, is that STL smaller than all three STL's individually loaded into Simulation? I would think it would be because lumped together you don't have the faces (and the little triangles that make them up) in between.

[BurrMan]

So here are some screenshots of the stls in BobCad:

Attachment 212384

Attachment 212386

Having the model rotated just has the sim load up needing to be rotated to the back to see anything. You COULD flip the cords in the definition an get it to be back view and post correctly there, but seeting it up this way, has it open looking at your machine and ready to go.

The only change would be the lifted Z head would also need to be dropped down to the zero point position to get it setup. In these def's, it's just attached 110 up and to the head 1. (as a start)

There are 2 things I think that were confusing your initial setup. In your model, the stls for the heads are "up and away" in the home postion. You were trying to set up the machine to "start there" in the sim and getting limit tripping when you didn't think it should. However, I think a part of the sim is not working yet which is under multi axis posting in the machine definition. There is a setting for "real machine zero or work offset zero"... I think the sim ONLY uses work offset zero in conjunction with the stl's. So, if you load your stls way up there at the machine zero position you have modeled them at, then when you run a program in the sim, it loads the "head" stl, which is already out of limits, in "RELATION to where the head would be at start of sim (down at the workpoece). We'll have to bring this up to BobCad about the machine or work offsets multi axis posting setting.

Also, setting up the "initial start position" isn't working for me at this point. The machine always loads the machine at the start of the tool.

(you'll notice I made my own little tool thing just to represent something. This would need to be changed out with what you really want to use.)

So, I'll make a video in a minute of running the sim, and you can generate some questions and answers regarding what you want.

Talk in a bit

[BurrMan]

Ok, so I was wrong about the model rotation. I did some samples and both the back and front facing machines sim and create a "Move list" which is the same.

However, the posted code for my front facing machine differs from the movelist. The back facing machine outputs the code the same as the movelist created in both setups.

So, the "sim" shows the stock and cut, but I think the tool is cutting in the "upper mirrored" area.

I'm not clear on which way you liked it and were speaking about being used to having the "mirror", so in this vid, I'll show both machines and the setup, and then output code. We'll have to decide which is the one you are looking for

[mmoe]

Burrman,
That's pretty much what I'm seeing, so I think you're explaining it pretty well. It would be nice if there were additional ISO views available in the simulator, as that would make it pretty fast to switch the view around. One thing I wonder is whether I need to position the STLs so that the head number 1 collet end is at machine 0 for the Z axis. I've been working on the simulator just about all night and finally have a very good machine setup, other than that it probably needs to be adjusted down so that it's more representative of the machine coordinates. I initially modeled everything with the top lower left corner of the table at 0,0,0 but it probably needs to be at 0,0,-208.5 (or whatever the full Z stroke is) as well as adjusting the limits to match. Here's the files I've come up with including the post processor as it already was. Still need to think about what has to happen there, but I've got a lot of time before I can put it to use anyways.

[mmoe]

Also, a couple of things I've found to be "What not to do" for those setting up machines. I first used a folder to organize the STLs thinking that you could place folders inside the machine definition folder. I like to keep things neat when possible, but as it turns out, you can't do that. Keep the STLs in the same folder as the machine XML. The other thing I ran into is that you may need to bring your STLs in from other sources than Bobcad. This depends on how detailed you want your model. If you don't make it detailed, there isn't really any problems. If you bring the SAT files I've made and try to create all the parts individually, which then get put into the simulation as separate files, the file sizes are just a bit too big and it takes a very long time to load the simulation. I ended up using Viacad to export STLs, and got them down to very small file sizes since you have a lot of control over that aspect of exporting from Viacad. Once I got the STLs optimized, the simulation loads just about instantly on my computer (granted it's pretty fast, I'll have to try it on my laptop as well). Smaller STL files don't look any worse in the simulation, so make them as small as possible. In some cases, I went from several megabytes down to a few hunderd kilobytes. The difference in responsiveness is enormous.

Another issue I encountered is that you can't name the geometries the same name, even if they are under a different part of the tree. If you have two sets of bearing blocks and name the both "Bearing Blocks", you'll get an error even if on is under X and the other under Y or Z. The name of each geometry can't be the same. If you are going to add a lot of geometry as I did, you want to keep a copy of the working machine definition, add a new geometry and test just that one, then make a new copy if it's still working. I got a few instances of OpenGL (I think) errors that were not able to be eliminated by simple removing what caused them. A working copy needs to be kept as you go or you could be starting over.

[BurrMan]

So here's a first video that show both machines from yesterday and today (the front machine and the back machine.)

shinx setup rev 1 - YouTube

So you may tell me, No Burr, rotate it back to face the other way is how I want it.

I think it describes the setup and the rotation/origin setting issue so we can move forward with how you want it...

Let me know.

Regarding the stl's. Yes, the poly count in the stl will be affecting the sim. For the stls I'm making, I am meshing them with an angle of 12 and a divide larger than 5... I wanted to keep a good detail for starting. We can look at shrinking them down a bit more and check the display.

Here's a shot of the sizes as I have them now. I'm pretty sure we can get them smaller.

And Yes, BobCad doesn't give any real way to really control the mesh at export.

[BurrMan]

Ok, so, in the machine that's rotated to face front, the code change is the work offset values being added to the movelist values, where in the back machine, the movelist values are raw.

[mmoe]

Great work on the video, I'm still digesting it as there's a lot in there. First thing is that I do normally set up the machine as you have it in the first and second simulations, where I keep the UCS at the origin and then place my stock as you show it in those simulations, so as you look at it, the stock is rotated backwards when viewed from the control panel. Basically, those simulations look exactly the way it actually cuts. Here's a quick image of an asymmetrical shape in Bobcad and how it would be oriented on the machine:




So when setting up the machine as in the second simulation, where the machine is rotated but the part is still working off the origin, what settings are you using in the Direction values? It seems like you have to flip the X and Y values to get the motion right?

Also, if the move list has larger XY values from the work offset, does that mean that Bobcad is making the compensation instead of letting the machine do it through G54, G55 etc.? I think it would be preferable to use Gcode work offsets instead of adjusting the positions, since if you need to adjust the offset for any reason, you can always do that by changing the G54, G55 values at the controller without needing to change the program. If the program has the offset hard coded into it, you'd have to go all the way back and repost it with the new offset, so not as desirable. I'm still using V24 for my programming, since that's my most current registered version, but there isn't really a whole lot of options for machine offsets in V24 so I'm still not decided how I'd implement that when I upgrade.

[mmoe]

Here's a diagram of how I work with the machine. I consider the end of the router bit when the machine is at the Machine Origin to be 0,0,0. I then position Head 1 so that the bit would be just inside of the cutting area by perhaps 10mm in X and Y and set the work coordinates to be X0Y0 at that point. I then set the Z axis to be flush with the top of the stock and zero that out as well. With the cutter just inside the table perimeter and touching the top of stock, the G54 work coordinates is then 0,0,0. Head number two would have a shift in the X direction of 304.8mm further than the X shift in G54, and that would be entered as G55. The tool in Head 2 would also be a different length, so I calibrate the head to set the Z height in G55 so that zero is again at the top of the stock. I don't use H offsets for the tools, just work coordinates. The knobs on the top-front of the heads allow me to fine tune the depth of cut for each tool by about .02-03mm increments (it's a pretty fine adjustment) and can take up several millimeters up or down as needed.

[BurrMan]

Great work on the video, I'm still digesting it as there's a lot in there. First thing is that I do normally set up the machine as you have it in the first and second simulations, where I keep the UCS at the origin and then place my stock as you show it in those simulations, so as you look at it, the stock is rotated backwards when viewed from the control panel. Basically, those simulations look exactly the way it actually cuts. Here's a quick image of an asymmetrical shape in Bobcad and how it would be oriented on the machine:

So when setting up the machine as in the second simulation, where the machine is rotated but the part is still working off the origin, what settings are you using in the Direction values? It seems like you have to flip the X and Y values to get the motion right?

.

Yes, I think I figured it out and also understand what your looking for. For what "I" was trying to do, by making your stls face forward and reverse the origin in the machine setup to get the setup you wanted, All your work in BobCad would have to be setup and done in the lower left quadrant, otherwise, the work offsets from the machine setup definition are added to the gcode and don't work for you.

Lets just suffice it to say I need to leave your stls facing the way you wanted in the first place and just have to hit the back view when the sim starts, Or I would have to say "Change all other aspects of your workflow. (I still have a couple tests I can run, but that can wait till later) We can talk about the definition settings when I get it setup like you.

Also, if the move list has larger XY values from the work offset, does that mean that Bobcad is making the compensation instead of letting the machine do it through G54, G55 etc.? I think it would be preferable to use Gcode work offsets instead of adjusting the positions, since if you need to adjust the offset for any reason, you can always do that by changing the G54, G55 values at the controller without needing to change the program. If the program has the offset hard coded into it, you'd have to go all the way back and repost it with the new offset, so not as desirable. I'm still using V24 for my programming, since that's my most current registered version, but there isn't really a whole lot of options for machine offsets in V24 so I'm still not decided how I'd implement that when I upgrade

no, BobCad does do the work offsets by G54 etc. The "added value by offset" thing comes into play when changing the "origin" in the WCS using the machine setup. The code then comes out with "THAT" added to the movelist values... Not what we want here. so, Because I moved the origin and flipped it to the other corner, the cut was happening further in the x (the stock amout further) and added those values to the movelist values. The only way to keep the same code output, would be to move the model into the lower left quadrant so the new origin was in the same place as the WCS, or machine defined zero. THis is where I think the sim is not performing as they want, by being able to run from the work coord AND/OR the machine cords. I think it's only doing the work cords, so you have to setup your stl's and machine definition at WCS X0Y0Z0..............

So I did see that the spindle was setup just a little to the negative X of the corner of the Y table, like you are showing in your picture. But am not sure how to handle this yet. I've noted that the sim is not reading the machine coords AND the work cords, which it seems they insinuate that it should... ? I've sent them a note asking about this. But what that means, is if that corner of the Y table is what represents X0Y0, then that's where you'll have to put your stl's so that everything matches up with the WCS X0Y0 in BobCad.

I could still be wrong about a few things though.... I'm going to grab your machine files and try to get it setup the way you work, then look further at things.

[BurrMan]

Holding the bus for a minute...

[BurrMan]

Ok so I'll have to apologize. Dragging it out, I'm in the same place as you and have mislead you a bit too.

To start, you can define your machine in your original file with the heads up and away like you have, so it's kindof like a G53. I told you, you had to move your model to the BobCad WCS zero point. This is not true. If you leave your model (and the stls) in their original places, this is where you can get those dims, then they are enterned into the "holder transform shift" field. So if the z head was up 200mm and over -50, you put those values in and the stl is read correctly from the sim.

So with that new info, I returned to your initial post in this thread and realized I'm at the same place you were. Stuck on the reversed Z output. Sim correctly, but improper code. (with the reversed limits set)

But, I think there is supposed to be a way. The machine definition has a machine transform as well as the holder transform, but I don't know yet if they work, or how they work. Like setting negative values and a holder transform.... I have the question in. hopefully it is a matter a designing the definition tree with the right components to reverse things the way you need, and get the code out properly. I'll have to wait for some answers and also fool around a bit to see.

[mmoe]

Burrman,
You've still provided a lot of information so far that was not very obvious otherwise. Thanks for the time and I'm sure we'll get there eventually. One quick question (OK probably not quick) on general simulation setup. I use a tool holder which is inserted to the spindle collet, mostly because the collets my machine takes are a type Yukiwa YCC 20 (machine is from Japan) and they are both expensive and hard to come by. I decided just to buy some ER 20 tool holders instead until I can get a good supplier for the YCC collets. Assuming that the machine will be set up at G53 0,0,0, (at it's home position), is it most ideal to set STLs in relation to the end of the spindle collet, the end of the tool holder collet, or the end of the tool?

My current methods would most align with setting G53 0,0,0 with the end of the tool since I don't use height offsets, instead compensating for tool length in the G54 or G55 work offsets, but I am not opposed to changing that philosophy either. If I set it at the end of the tool, and don't use any tool height compensation in Bobcad, will it just render the center of the end of the tool at the 0,0,0 point? If so, then I think I would set the machine up using the end of the generic endmill in the photo below and let it shove the tool in or out of the tool holder as needed when rendering. The tool holder itself is not always in the exact same position either since it's a straight shank 3/4" shaft, so it's more of an estimation of where it would be located and provides at least a reasonable representation to watch for collisions (though probably won't collision check the machine?).



I'll have an updated machine definition a little later today and will post it if you care to download it. I've made some minor adjustments to the positioning of some components after carefully verifying where things are located in the model vs. the real thing. At this point, I think my model is very, very close to the actual machine dimensions with most parts being +/-.5mm, which is as close as I think I'm ever going to be able to measure such a big object. For now, I'll set it up at the end of the tool, but it's pretty easy to move the machine and resave it if one of the other scenarios is better.

From what I'm seeing, and to restate if others are trying to follow along, if the Z axis is set up so that it simulates right and outputs the right code, the only issue is that the limits are hit when they really shouldn't be. Both with or without work offset, the toolpaths are all well within the limits, so there seems to be something in error in how it is checking the limits. Let's say that I have a 19mm deep part with the top of stock at 0, and I set the clearance height to 10mm, the program will run between -19mm and +10mm, and the limits are set to -200 and +25. Even if you were to flip the program around and have +19 and -10, it is still within limits, but I get an error stating that it has gone past the limits to +42 (or similar seems to vary a bit). There is no place in the program where the tool should move past a value of 19 and if you generate the code, there is no value above 10 or below -19 just as there should be. If you flip the Z axis Max and Min (-25 and +200) you can get it to post code, but then the values are not correct for the simulation side of things. If you flip the Z direction, you can post code with the correct values, but you get the wrong code in the program (- instead of +, + instead of -). The only thing I have not tried is putting +200 in the Min and -50 in the Max, so maybe that will work......

[BurrMan]

Hey mmoe,
Well thats good that some of it is still useful.

Regarding the toolholder/tool geometry setup, I cant follow well all the variables of your workflow with how/why, but I understand what you are describing. You can define your own geometry so it is even more accurate in the sim, but, the variable of "how it shoves up into the spindle, may need to be manually set. If you were using the tool definition in the feature dialogues, then it would be dynamically adjusted at sim time. However, if some of those variable are just things "you" do, then I think it would need to be done on the machine definition holder transform shift value, FOR EACH setup, to get a proper sim. There still may be a way to do it with a definition and from the feature, but it's new territory for me and dont know yet. For sure you can do it from the transform shift. I think it would have to be that way whether you made your own, or used the default sim tool group.

With regard to the limit trips, this is what I was fooling around with a bit last night. I think the issue you are describing is comming from the "STL'S" placement/relation and definition in regards to what the actual travel of the STL is. So something like the actual limit, "Plus" where the stl actually is and it's size. So, -25 in X on a zero'ed stl x table, is no longer -25 when some type of tranform is placed on it (moved or "MACHINE COORDS" Stl placed up and away using the holder transform shift and such.

It becomes difficult because of a few things. Mostly, the lack of total understanding, but also I think my struggle is exagerated by a couple things that arent working right. (machine coords/work coords with relation to the defined STL's) But it's hard to pinpoint whats me and not. Also, I really need to get a grasp of metric units! lol.

Talk more in a bit.

[mmoe]

That all makes sense. I also think the placement of the STLs must be a key somehow. I am finding that if I place the tool tip in the model at the origin, then export the STLs, it simulates with the tool tip exactly at the origin on the simulation as well. How the translations for tool holders, etc. affect this is definitely a bit of a mystery as I fool around with it. Without being able to simulate the parts, all I can do for now is just move the axis around and make sure the code is posting correct. I don't know how I managed it, but this machine definition seems to be posting the code right while not producing any limit errors while set to "All Limits". The main difference was changing the origin of the STLs to the tool tip instead of the surface of the table, so perhaps that is the fix? It didn't work yesterday, but I completely reworked it today and have no idea what I did differently that made it right if it's not that. Can you test it out at your end and see if you get the same results now?

I was pretty conservative on the STL sizes and will probably start revising the STL outputs to see how much detail can be had without slowing down the simulation. Right now, the simulation opens the instant I click on it (from already inside the simulation module since I'm in demo mode). I suspect I can make them quite a lot larger and may look at some of the existing machines to get an idea for the total size in MB to shoot for. It's sitting at less than 500kb in this version.

Most cabinet hardware comes set up for a metric hole system to mount everything, so when I bought my first machine about 10 years ago (big and old SCM Routomat), I decided that I'd make the switch then. Probably took about a month to get completely comfortable with it, but that was working daily with it. Most of it is easier in the end, the only exception being when you have to match something that is not metric. Tooling is the one thing that seems to always need converting, but once you memorize the various bit sizes, it's no longer an issue. I don't have to think for a moment what a 9.525mm bit is, I just know it's a 3/8" bit now. Other than bit sizes, everything else is just easier than dealing with inches, even compared to decimal inches.

[mmoe]

Look like I've got the work offset figured out as well. If I enter an offset for tool 1 in machine setup 1, it will generate the unmolested code that I need and show the simulation (without the machine in the demo) shifted as it would be in G54. Because the G55 will be output without the simulation realizing it, the simulation will just change the tool in head 1 for a second tool and run it aligned with the first one as long as I stay in the same machine setup. It won't show the second head working, but that's not that big of a deal so long as it shows the parts that would be cut. The actual machine would shift to a new work coordinate to compensate for the second head, and do the same thing the simulation showed, it would just do it with head 2 instead of head 1 as the simulation shows. This is really not a big deal and will provide all the same checks that running with both heads would need. The only adjustment I should probably make is to shorten the X axis stroke by 304.8mm. If the toolpath moves head 2 the full 1550mm in addition to the work offset, it would collide with the limits. Perhaps it would catch that as maybe it is aware that the limits are based on G53. Either way, it makes more sense to change it if it's using only one head in simulation since the actual cutting area is only 1250 wide.

It's a bit of a shame that it seems the simulator won't start at the origin as the machine itself would, and that it doesn't finish the job with the code inserted at the end of the file. A lot of mistakes are made in the initial move to the start of the toolpaths and the return to the home position at the end of the program. Unless I'm mistaken, these moves are not tracked by the simulator. May need to send in a feature request there if that's the case.

[SBC Cycle]

I don't think your model as it is needs to be rotated but I think it should be translated to BobCAD 0,0,0 UCS. You can override how your STL's were "saved" in relation to the UCS and move them around in the Machine Definition but after experimenting with my own machine models, it's better if the center and face of my spindle is always at X0, Y0, Z0, the same as it is when I push "Home G28" on the Haas or line up the CS (Zero) position of my Fadal.

Probably worth repeating.

[SBC Cycle]

I have your model pulled up and it is beautiful mmoe, truly a work of art. I noticed that you renamed your geometry with the color added. If I could offer a tip, backup your machine.xml and edit the machine definition with notepad or an XML editor. I'm in the process of freshening up my memory on HTML and Style Sheets to represent the XML in a clearer and easier to read format. If you delete an axis (and all the STL geometry) in the BobCAD dialog, you lose all those color settings and the order of certain things. Editing the XML isn't for everyone, but you will likely find it a lot easier once you get the hang of the setup. Anyway...

The only thing "wrong" with what I see is still the Z. You have a 3/4" collet that never gets removed from the machine? The bottom face of that should be your Zero, IMO. I suppose there are reasons not to do that, but I think the key is that BobCAD is going to expect the nose of the spindle to be Z zero if you want to use "full limits" without a lot of work that isn't worth it. Everything can be overridden but I think your setup, although exotic, will simulate perfectly as you expect it to if you put the face of your collet at Z0. The tool holder definition in the CAM side is expecting to attach to that, then the arbor, then the shaft, then the flute - just as you see it in the machine definition dialog and in the SIM window. If the nose of your spindle is not at Z zero, your going to have to account for that with a transform. Then it gets tricky

I added a screenshot to show you how I'm editing my machine definition. I am just using XML Notepad 2007 for now but it's still a lot easier to use because I can drag folders around to change the order of things instead of having to delete and recreate them.

[mmoe]

SBC,
I did read your earlier post, but had not really got to the point where it was understood. I think your earlier UCS statements make more sense to me now, so they are worth the repeat. Have you worked with the tool holders as a separate geometry? The problem I recall was that there were only certain tool holders in the library, but I wonder if I can use the tool holder geometry I created to work in that manner. I think that in order for that to work, I'd have to work with tool height offsets which I currently do not.

If I continue to avoid using the height offset, I think I have to stick with the machine coordinates set to 0,0,0 at the "tool tip". I'll be removing the tool I drew, and I suspect that the automated Bobcad tool will just intrude on the tool holder geometry and appear like it's in a collet. Without the height offset, I'm guessing that the simulator generated tool will start at the tool tip as I've defined it (0,0,0) and stick up into the tool holder. If that's the case, I think I'm fine with it that way. It allows me to just set my G54 and G55 offset as needed to match the top of stock at the controller and it will all be the same (I think).

I've been editing the XML in Notepad, but it sure isn't organized like that! It looks more like HTML in notepad, no real code organization, just straight text. What program is that, or is it just standard Notepad with some sort of different setting? One major thing I've noticed is that if you create your machine definition in inches, it will only recognize the STLs as inches as well even if you are in metric afterwards. If you go into the XML, you can change it to metric by manually inserting "metric" for "inches" into the code. From that point on, it will see the geometry in metric instead of inches.

I'm still a ways from finishing up the simulation (thanks for the compliments, by the way), so I'll back it all up as you suggest when I'm 100% done. I have the full model (done in Viacad) backed up and in 6 different stages (currently rev. 5). I need to add some more dust collection pipe to the X axis (doesn't move up or down) so that the pipe can telescope without revealing the end. I forgot to select the hinge bracket for the control panel arm this time, so it's missing. I also hope to add a few more items that are finishing touches (just for fun) such as the limit switches and brackets, and the exhaust fans on the end of the gantry where the X motor is mounted. I will remove the tool so that it appears blank and then re-evaluate where to zero the model to. When it's all finalized, I'll then start figuring out exactly how much detail I can leave in the files while keeping the simulator working smoothly and opening fast. The original model can output what is now less than 500kb all the way up to several GB, so the detail is retained in the nurbs model that I'm extracting the STLs from. Looking at some of the Bobcad simulations, there are a few that are around 2mb, so I could easily expand the data quite a lot and get an even smoother looking machine model and add some of those extra details. I also want to add a bit of the reflective bitmap to some of the metal surfaces, which I think will be easiest through hand editing the XML.

[mmoe]

Here's another modification to the machine definition. This has most of the geometry changes I wanted to make (haven't added the details I will eventually add) and it also has some reflective elements added. If you do reflective elements, I found that this is best done in the XML editor. For some reason, Bobcad outputs a reflective number that is about 1/100th what you actually set it at. If you try to do a reflective surface and it appears that it has not worked, this is probably the reason. I think you would have to do a number of around 1000 to get 100% reflective. If you edit it in XML, that would be a value of 1.0. Most things are good at around a value of .05-.15, so be conservative unless you want a mirror. I set my chrome handles to .5 and they are maybe even a bit too shiny.

I removed the tool from head one, so if anyone can see if the simulation will basically substitute a tool there, that would be great. I can't try that on the demo. The work offset to set the tool to be 10mm on center from the edge of the table (corner nearest the machine origin) is as follows:





I think that if you set the work offset in the machine setup to these figures, it would put the tool end right on the table surface. If you want to zero to the top of the part, you'd have to add that amount from the Z value. For 20mm stock, you'd set the Z to -68.5432, for example. Curious to know if it works that way.