OK mmoe,,
I have to hand it to you guys this is cool.I have to ask though,on super high end systems,money no object,do they have simulation with flutes on EM,spindle rotating, and Chips flying off ?
OK mmoe,,
I have to hand it to you guys this is cool.I have to ask though,on super high end systems,money no object,do they have simulation with flutes on EM,spindle rotating, and Chips flying off ?
I would not be surprised of anything our Government might have that we are not privy to.Probably some real cool software they use for stuff.
New problem now. When I post code, the Z values are all compensated for tool length. If a Z value should post at Z0, it's posting at Z75 when the tool protrusion length is 75mm. I've never had Bobcad compensate for tool length in the post processor, so really not sure what's going on there. I do know that it's directly linked to the tool protrusion length, since if that is changed, the Z values in the post change exactly the same way.
I was trying to follow your explained setup. Not sure I did well enough to recognize it right off. I'm not confident that the way you are doing it is going to be what's needed. (the ole machine with all the reversed axis movements and all)
Maybe Remember to look into the machine definition of posting either work or real coords, on the multi axis posting area and see what change those make to that output.
I've toggled between the real machine coordinates and the work coordinates setting in the machine definition, but it doesn't seem to have any effect on the way the simulation runs. May be strictly related to multiaxis situations? Changing the work coordinates in the machine setup within the CAM tree is very consistently adjusting the simulation and it's very predictable. If you take away that you are essentially making the work offset adjustment without the tool length or tool holder being accounted for,(since Bobcad does that automatically in addition to the work offset), the way the work offset is used is virtually the same as it is at the machine itself. It's just a different number is all. If I've got 130mm of tool and toolholder and subtract that plus the stock thickness, it comes out very close to my work offset at the machine itself, but in Bobcad you don't subtract the 130mm of tool and toolholder, so the number just initially looks wrong (too large).
If I can figure out why the tool height compensation is being applied in my post processor, I'm pretty much golden. It's seems exactly like the difference between machine compensation and software compensation for profiling, but it's the tool length and it's in all toolpath strategies. I can repeatably change the Z values in the post by exactly the amount I change the "Protrusion Length" in the tool setup.
It changes the code output, not the sim.
I didn't mean to insinuate that anything about the setup is wrong. More that It's hard for me to follow and discuss the output in general.Changing the work coordinates in the machine setup within the CAM tree is very consistently adjusting the simulation and it's very predictable. If you take away that you are essentially making the work offset adjustment without the tool length or tool holder being accounted for,(since Bobcad does that automatically in addition to the work offset), the way the work offset is used is virtually the same as it is at the machine itself. It's just a different number is all. If I've got 130mm of tool and toolholder and subtract that plus the stock thickness, it comes out very close to my work offset at the machine itself, but in Bobcad you don't subtract the 130mm of tool and toolholder, so the number just initially looks wrong (too large).
If I can figure out why the tool height compensation is being applied in my post processor, I'm pretty much golden. It's seems exactly like the difference between machine compensation and software compensation for profiling, but it's the tool length and it's in all toolpath strategies. I can repeatably change the Z values in the post by exactly the amount I change the "Protrusion Length" in the tool setup.
The work offset setup you described sounded more complex than what's necessary by default. I didn't want to start asking questions about where your stls are zeroed and how your machine def is setup.
Figured it out. The post won't generate with the machine definition set to work coordinates due to tripping axis limits, so that does have an effect. It did not have any relation to the tool protrusion though, which is what is generating my problem, so I set it back to Real Machine Coordinates. I did notice while messing with that setting that there is a drop down menu just below that called "Move List Coordinates" which defaults to "No Machine Compensation", which looked quite similar to the machine comp vs. software comp setting I eluded to earlier. In that drop down menu, there is a setting called "Machine Compensation in Z Only" which eliminated the tool protrusion compensation that I was experiencing. Now I get the correct Z values when I post the code while it also does not seem to be having any adverse effects on the simulation, so it seems that all is good. The only improvement at this point would be if there was an automated ISO view to see the machine from the correct direction, but that's a small thing I could live with. I just hit the back face view and do a quick manual rotate for now. A user assignable view might be a great addition.
Thanks Burrman,
Even if it doesn't seem so, you pushed me in the right direction to figure it out. I doubt I would have discovered that setting as soon otherwise.
Just wanted to say that I am still following this thread with much interest. I will be updating my own thread on Simulation soon. I seem to be having trouble tripping my limits.
The problem (as it appears to me) is that the limit check is happening before the tool length offset is applied. If I have something bolted to the table (or really close to the table) I will trip the limit even when using a long tool. Technically it IS out of limits, but not when TLO is applied. I hope that makes sense. I'm still working it out but does this sound similar to what you are experiencing?
I really have not much knowledge of what you guys are doing,but have read here and there.I thought I would throw this out there,do you think somehow,somewhere the simulation still has a vise height in its data bank?In other words any height lower than the deck of the vise,simulation would think a crash?
Yes, this is pretty much the part of the setup that I'm trying to explain but having trouble putting into words. You have to think about the zero position after the work offset as the position that you would want the spindle at before the tool and tool holder are accounted for. Then, when the tool is accounted for by Bobcad, which is done after the work offset is achieved, there will only be a limit switch issue if there would be one in real life. Just be sure that you have zero'd your machine STLs so that the machine coordinates zero is at the point where your tool holder model starts. If your tool holder goes up into the head (for tool changer where you modeled it to show the full holder), you would have to place the machine zero at that point, not at the end of the open spindle. If you only model the exposed part of the tool holder, you would place the machine zero at the end of the spindle.
If you were setting zero to the top of a vice, for example, you could then figure out the top of the vice to the machine zero difference and enter that as the work offset. This would place the end of the spindle at the surface of the vice, followed by the adjustment for the tool and tool holder and then any clearance or rapid plane setting that might be currently active. This would put the end of the tool just above the surface of the vice.
Hope that helps. It really is difficult to explain and I haven't really thought of a good diagram for it yet either. As soon as I can, I'll put a schematic up that hopefully illustrates how it seems the work offset relates to the machine coordinates. You'll notice that as you change tools or tool holders, the head shifts down or up to account for any differences, so the work offset does not read quite so straight forward when you are messing with it from tool to tool, but once you get it, you'll find it is much easier than you probably think.
I think you could set it up so that the limits are triggered when the zero position reaches the vice surface. The way that Bobcad then accounts for the tool/tool holder combination would also trigger the limit when the tool tip itself hits that zero position, so it does seem to be pretty intelligent as to the fact that every tool is going to be different. If you have an error in your tool offset at the machine, it obviously can't account for that, so there will still be the human error element. If you have all your tools properly set up to offset the height at the machine, the simulation will behave the same way. You then just set your Z min to the real machine coordinates position that equates to the work offset zero at the vice surface. If you can't follow that last comment, believe me when I say that I know it's not easy to follow. Even having written it, I have to think about it.If the motion of the machine hits that real machine coordinate you set to be the limit, I think it will show a collision even with the tool compensation. I believe the other thing is that if you model the vice as a separate element, you can have the software collision check against that element specifically, regardless of the limits. It would if any part of the tool were to touch that element, I think it would trigger a collision warning as well. I'm guessing there is a couple of ways that you could provide this kind of check.
A possible confusion point that I thought I discovered was that the machine limits set were using real machine movement "ONLY" and not work offset values. so limit is gauged from machines stl placement. Adding stock and tools and cutlist would quickly add up to trip exact numbers.
Yes, setting up the work offset coordinates in the machine setup portion of the CAM tree directly moves the simulation. Unless you were to have some sort of custom post processor, the work offsets do not seem to have any effect on the code, only the simulation of the code. In many ways, it works the same as the real machine. I don't set up tool length compensation for my machine since it's just easier to include that in the work offset, but if you did then the work offset in Bobcad should very closely match the work offset on the machine itself, with the only remaining difference being how the machine handles the tool holder as part of the equation, where Bobcad includes that as one of the things it compensates for.
Just playing around with the "Create Presentation" function and made the attached quick test file. One thing I noticed is that when I'm doing a full simulation at the highest quality, it stutters a bit when in the time mode, which I take it to mean that there just isn't enough juice to make it go smoothly. I thought this might be video card related since I don't use a workstation graphics card, but as it turns out it appears to be processor related. When running the simulation within Bobcad, the simulation processes are part of Bobcad from what I can tell. By this I mean that if you check your CPU load in the task manager, you see that the load is the Bobcad application itself. For my system, that load never gets above about 25%, which means that it's using about 2 cores of the 8 cores available.
What I find interesting is that the "Presentation" simulation runs much smoother, and in fact I can run it at the highest quality setting while even speeding it up in the time based mode and it is perfectly smooth. After a bit of investigating, it appears that the presentation makes a completely separate application, which then works as an individual process capable of using a full 50% of my computer resources where the same simulation has only got access to 25% from within Bobcad. It only takes moments to generate the presentation version, plus the presentation version is more of a full screen application. IMHO, I'm thinking that they may want to consider having Bobcad just launch this system as an external operation instead of keeping it integrated fully, as I suspect it would behave more like the presentation, which is hands down a better simulation in terms of smoothness of motion at a higher level of detail, even when in "fast forward" type speeds.
Curious if any of you have tried the "Create Presentation" feature and if you had the same kind of performance difference. As amazing as the Simulation Pro system is, I think the performance boost of running it outside of Bobcad would make it feel exceptionally responsive.
FWIW, I have a 3.7 ghz quad core I7 running on 16gb of quad channel memory (X79) with a good 1gb ram video card, so the lack of umph within Bobcad certainly doesn't seem like it's a result of a weak system.
Here's a link to a test presentation if anyone wants to try it out:
https://files.secureserver.net/0s6DppzEihNbh0
Create Presentation has to be stand alone,as in you can give anybody the file,anybody,and they can run on their computer without BobCAD on it.
The file size,as is you noticed is huge,which makes it a bummer for normal E-Mail and such.That's why you don't see people uploading presentations on here,files too big.But yeah,load it on a stick and give it to whoever you want,and they can simulate your part,with use of the controls that are in simulation.This was new to V25.
When it first came out,I did use an app. to send some bigger E-Mails out to my dad,who was able to accept them,just for fun.
I did come to the conclusion it was probably best not to let customers have though.As the Engine Guy pointed out a couple years ago to me,it could also lead a customer to thinking it's easy to make his parts,and they can also turn on the timer and see times,and etc, and etc.They might get the impression you are charging too much for something that looks so simple in the simulation,without taking into account all that is involved.
Read what I edited above,,,
I struggled with that thought for awhile,decided no.I use it around friends and such.It is too bad we cannot use it on here without fancy links and such as you have done.Just upload the presentation on here or other message boards when conversing with people without BoB would be cool.
I can see that point of view for a business who is more geared toward high tolerance machine parts that require more machining knowledge. Cutting plywood or plastic sheet goods on a CNC Router is not nearly as demanding in that regard. Most of my work can be done by cutting out a profile and drilling a couple holes, so I think most of my clients don't think the work is very difficult even before we start talking about contracting it out to my machine. In most cases, what they are after from me is saving money over their current process. In some cases it's just that they don't have any other way to produce what they need than CNC, so then it's a matter of pricing over anything else. With a dual head/dual drill machine (drills aren't shown in the model), I can be very competitive on pricing since most jobs can be cut two at a time with a single router and drill needed for each part (both heads or drills down and cutting simultaneously).
I'm not sure that I would want or need to send the actual file to a client, but I do think that when I try to sell them on having me machine their product, it would be a great visual to put up on my laptop or even better on a tablet (don't have one currently). My jobs are not terribly complex, ideally just high quantity of the same part over and over if it's a good job, so the pricing is pretty much by the minute plus fixturing expenses if any. One client I'm going to be talking with soon is a company (keep anonymous) that makes athletic paddles (like large ping pong paddles). They currently do the process by hand, but I think I can cut the time to make them down by nearly 5 times plus utilize more of the material than they currently do. Even if I cost three times as much per minute as their in-house production, I believe it will cut their costs about in half. For a client like that, I think this simulation would give them the kind of visual information that makes the concept a bit more real than just talking to me at their shop. They can see the efficiency of both the speed at which the part is processed and the additional utilization of the material that currently is tossed. With some education about the fact that this visualization is the culmination of a great deal of effort on my part through the programming and setup (I'm pretty good at talking my efforts up without starting to offend), I think they would take it as a presentation that had effort involved to be as informative as possible. I can honestly tell them that I went through great trouble to accurately model my machine's kinematics so that I can proof a job prior to cutting it, preventing unwanted mistakes that waste material, preventing possible tool/machine collisions and visualizing the toolpath so that it can be evaluated for possible increases in efficiency through variations on the toolpath strategies. I think with that information, most people will be inclined to feel you are a professional that takes their work seriously rather than someone who's making an easy buck with a fancy machine.![]()
I think that the "integration" is most valuable though. For just simple jobs, you can just jump back and forth pretty quick, and most times I'm using tool focus.What I find interesting is that the "Presentation" simulation runs much smoother, and in fact I can run it at the highest quality setting while even speeding it up in the time based mode and it is perfectly smooth. After a bit of investigating, it appears that the presentation makes a completely separate application, which then works as an individual process capable of using a full 50% of my computer resources where the same simulation has only got access to 25% from within Bobcad. It only takes moments to generate the presentation version, plus the presentation version is more of a full screen application. IMHO, I'm thinking that they may want to consider having Bobcad just launch this system as an external operation instead of keeping it integrated fully, as I suspect it would behave more like the presentation, which is hands down a better simulation in terms of smoothness of motion at a higher level of detail, even when in "fast forward" type speeds.
For heavy jobs, this could look problematic, but you point out the extra step to get the quality output. I think both are valuable, but you would have to start with integration as the first step, with the other output as the option.
Also, I'm not a fan of the executable. It's not something we should be sharing, or want to be sharing in places like this. (Great for your purposes with a customer in your presence, but I wouldn't want to receive one from a shop I was in contact with through email...
There are other ways it could be packaged that should be explored, IMO. I've said that before.
For me, I create the presentation, then I run it and grab the extracted folder and repackage it myself. I can make an autorun and burn a cd or some type of other thumb media to send out. But I very well may be breaking one of the Eula's if I send those files off around the world.