Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
We are working on a generic post processor for the Biesse Woodworking Router with CIX Format.. We would be happy to get some feedback from you before we put them into production.
Feel free to download and test this post processor and provide any feedback you might have.
hello everyone, i downloaded this postprocessor and i tested it and i want to know if this post processor will work for 5 axis operation or its only for 3 axis ,and beside of that i have some problems with the post i would like to share with you in the forum . and sorry if my question is primitive because i'm very new to hsm .
The "CIX" format is good, it allows you to program any machine running "biessework". but you can not use the machines optimally. and you will not have a full five-axis milling, because this simply can not "biessework".why do not you want to create a postprocessor through the "iso" code? through "iso" you can do everything and optimize the machine."Biessework" simply hangs when there is a lot of trajectory.
here such products can not be made in "biesseworks" cnc:biesse rover C6.50
optimal work is possible only through "iso"
so why do not you want to create a postprocessor under the "iso" code ??
for me it's wrong. from one "CAM" send the trajectory to another "CAM", and then run it on the machine. Can the code go directly to the machine?
@Anonymous I don't know what you mean by you made an "optimization in BiesseWorks'. Can you explain further what you did to cause the error to popup. The post currently does not support true 5-axis machining, only 3-axis machining on each of the sides of the parts. We will look into adding 5-axis support to the post, but as @grigorov.rv says 5-axis is only supported in the Biesse control by using ISO code.
@grigorov.rv The users who requested the post for the Biesse router requested that the output be in CIX format, which is why we developed this post first. As you are probably aware, creating an ISO post is much simpler than a CIX based post processor, but we look to deliver what the customers are requesting. We will look into adding an ISO post with 5-axis capabilities.
@Anonymous Could you please provide the output file from the post (file.cix) so that I can evaluate it and see if I can find the problem. I sent you a PM with our e-mail address. There currently is no ISO post available, but we are adding it to the list of posts to create. When it is finished a notification will be posted here.
We have been told by Biesse that they recommend posts to create the CIX format, then use macros/subprograms to refer to ISO code for the simultaneous 4 & 5 axis toolpaths.
In my experience, when using ISO code, there is very little consistency between various Biesse machines, so every one we come across needs fairly substantial modifications. The one advantage for CIX, is that Biesse tell us it's much more compatible with a wide range of their machines, so in theory at least, one CIX post could cover a bigger range of machines.
I've worked in a shop that uses Biesse machine for nearly a year and I'm still learning the quirks of their crazy programming. Not the easiest machines to understand coming from a G code world.
I've been testing this post for the past few days and I haven't been super successful getting it to work, but I've learned a ton about what BiesseWorks is expecting to get from a CIX. Hopefully you'll find what I've learned useful. If you have any questions or want me to test something out on our machines let me know. I would love to help however I can. Getting HSM to be able to output code to our Biesses would be incredible.
Here's the biggest thing I've learned: when defining points within the "GEO" macro, BiesseWorks doesn't accept sequential points that have the same X and Y values but a differing Z value. Say for example we want to start at 0,0,-10, plunge to 0,0,5, and then move to 0,20,5. The current post writes each step in sequence (keep in mind that to the best of my knowledge, the X and Y values here are absolute, and the Z values are relative to the previous point):
START_POINT X=0 Y=0 Z=-10
LINE_EP XE=0 YE=0 ZS=0 ZE=5
LINE_EP XE=0 YE=20 ZS=0 ZE=0
What BiesseWorks is expecting, however, is something like this:
START_POINT X=0 Y=0 Z=-10
LINE_EP XE=0 YE=20 ZS=5 ZE=0
Notice that the plunge move is included in the line segment as the Z start value of the line segment.
I have also found out the same code that gives the processor a hard time while in a "GEO" macro does just fine in a "ROUT" macro instead. EnRoute exports CIX files with the geometry inside of a ROUT macro.
I've linked below to a Google Drive folder with a few files. "Outside Cut" is the original CIX generated by your post. "Outside Cut Corrected" is a modified CIX that I exported out of BiesseWorks after copying the geometry to a "ROUT" macro instead. I've also attached a page of the BiesseWorks manual that helps explain the logic of the Z levels.
Thanks so much for your work on creating this post! I've tried digging into the post config myself but I have to admit I'm a little out of my depth there. Let me know if you need a guniea pig to test anything.
It's probably too late on a Friday night to be continuing to look into this, but from what I can find it looks like most 3rd party posts for BiesseWorks put all the geometry into a ROUT macro. Biesse controllers are pretty strange coming from a G Code world. The kind of input for geometry they're expecting is pretty basic CAD shapes. Lines, arcs, etc. Most of the complex parts of the tool path, such as lead in, lead out, rapids, clearance above the material, are all handled within BiesseWorks.
From my experience engineering and programming parts to be cut on Biesse machines, when BiesseWorks gets geometry, it's expecting basic CAD shapes such as the outline of a part, or the profile of a pocket. Once in BiesseWorks you can apply machining to the geometry that includes all of the other details such as lead in/out, number of passes, step over, etc. If those complex details are already included in the geometry, when you apply a routing operation to the geometry things can get pretty confused.
Putting those same lines/points within the routing operation lets you think of the geometry much more like standard G code. Go here, then go here, etc. No need to validate the continuity of the geometry - the tool just goes from point to point. This method seems simpler to implement in a post.
@Anonymous Thanks for taking the time for testing this post and providing the detailed feedback. The original design of this post did use the ROUT Macro, but when working with Biesse in testing the post they highly recommended that we use the GEO/ROUTG Macros since this is how they like to run the machine. I believe there are some idiosyncrasies with the ROUT Macro, such as not moving at a rapid rate between profiles (per Biesse).
Since there will probably be two different camps on the preferred method, we will add an option to output in either format. Thanks for the heads up on the plunge move, this will be fixed in the post also. With this machine there will probably have to be certain rules/limitations that need to be followed for the entry and exit moves.
@bob.schultz I can definitely see how useful the GEO/ROUTG workflow would be. That method is certainly useful for fine tuning things on the controller using the BiesseWorks native tools. One of the biggest hopes I have for the post is the ability to use tool diameter compensation, which we can't currently do with our EnRoute post that goes straight to ROUT.
If the GEO/ROUTG method is dependable and flexible enough to support a wide variety of operations I think that's the way to go.
A new version of the Biesse CIX post is now available. It has the following fixes and additions.
Added a property to choose between GEO/ROUTG and ROUT Macro style output.
Added a property and the "HOOD:n" Manual NC command to control the hood position.
Fixed the output of the positioning moves when using the GEO/ROUTG style of output.
Increased the accuracy of the linear coordinates to alleviate problems with circular interpolation and the final point is now adjusted to lie exactly on the circle.
Thank you @Anonymous for testing the post and providing valuable feedback.
We are not planning on implementing an Biesse ISO version of the post processor (except where it is required for 5-axis support). You can visit the HSM Post Processor Forum and search for 'Biesse'. There are at least a couple of Forum threads that contain attached posts for a Biesse machine in the ISO format.
You can also add another Idea to create a Biesse ISO post processor if you like.
Glad to see there is a CIX Post available! I hadn't had a look for the same reasons as grigorov above - it's more powerful using ISO.
I have been working with the available ISO Post you mention - To be frank it's more trouble than it's worth! I'm back in a workshop running Biesse machines so have a chance to test edits on occasion.
I'll be in touch with the CAM Posts team, but from a cursory look:
FIXED
- Drilling defaults to G98 through-hole cycle and cannot drill blind holes.
- No support for radius cutting with tool compensation enabled. This has been fixed (Thanks CAM Team!)
TO FIX
- Vertical drills crash when invoked. The machine attempts to put them at safe height but it references the Z Absolute position rather than the relative drill tip - It drops too low!
- No support to drill anywhere other than the end of a program. This is probably due to a lack of information when it was written. It outputs code in a format that the 'edit hole' (Pre-BiesseWorks Optimiser) function can interpret. This is redundant as the drilling order optimisation should come from the CAM system with a specified tool.
- No support for Z Arc ramping. I see the instruction is set up in the post, but it doesn't get written as an instruction. I got 120 lines of code for a Z arc lead in which could be done in one!
UNKNOWNS
- I cannot check the functionality of horizontal boring, as these machines have only vertical boring spindles. The best I can do is compare the code to output from another old CAM system I have a proven post for.
PLEASE USE CAUTION AND YOUR OWN DUE DILIGENCE IF YOU TRY THE AVAILABLE POST.
