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 ISO Format. We would be happy to get some feedback from you before we put it into production.
Feel free to download and test this post processor and provide any feedback you might have.
@3341540682, thank you for this information. Do you have access to a programming manual that describes the 5-axis code supported by Biesse in the updated controls, preferably in English.
I have a Biesse Rover J 1530, and I am having difficulty getting the axes oriented properly with this ISO post processor. Currently, the Z-axis movements appear to be flipped such that lifts are plunges and vice-versa. This was my first day of getting an ISO file posted to run on the machine, so I currently don't know if it's a post processor issue, an issue with my machine kinematics settings, or my naivety with settings in a setup or machining operation.
The machine's coordinate system uses standard right-hand rule axes orientation, but the axes are rotated 180 degrees about the X-axis where X+ points to the right, Y+ points toward the front and Z+ points downward. Having run into this issue with both an SCM machine and two Biesse machines when using Vectric's VCarve, I looked for a place in the post to scale the Z axis by -1 for a quick fix but didn't see one, so I just downloaded the post processor training guide and I'm about to get into the nitty-gritty of it.
It is quite simple to change the sign of an output coordinate. For the Z-axis, you will want to create a zFormat format variable similar to the xyzFormat variable, with the added scale factor as shown below.
var xyzFormat = createFormat({decimals:(unit == MM ? 3 : 4), forceDecimal:true});
var zFormat = createFormat({decimals:(unit == MM ? 3 : 4), forceDecimal:true, scale:-1});
Now you will need to reference this format in the zOutput variable.
var zOutput = createVariable({onchange:function() {retracted = false;}, prefix:"Z="}, zFormat);
It is possible that you may have to change references to xyzFormat to zFormat in places where it outputs a Z-axis position. For example, in the writeContour function.
Thanks Bob. I hesitated to do that because I feared I'd have to change all the xyzFormat vars to xFormat, yFormat and zFormat, but your example makes the changes clear and less worrisome 🙂
However, before I do this, I feel like a more correct solution might involve reorienting the WCS in the Setup, and then editing the post to overcome a Work plane is not supported error. In the pic below, I have flipped the Z-axis and moved the part position to reflect exactly how machine axes are oriented and how the raw material will be positioned against the stops at the machine origin.
I then flip the Z-axis of the tool orientation, and I get the following simulation which looks correct, except for the small detail of the axes triad orientation not matching the machine's axes.
This Setup and machining combination, however, results in a Work plane is not supported error at the first tool change contour. And when I Show Toolpath Data on this result, it reflects X, Y and Z values that would be correct for the Fusion view, so I have no idea if these would translate properly during the post.
I have made so many changes to my Fusion file that I have lost the combination of settings that gave me my very first runable .ISO file (waaaay off the spoilboard in air), but I still have that first .ISO file itself for examination. I mention this because, with the machine axes rotated differently than the normal Z-up WCS in Fusion, every operation I try with an origin where I think it should be has resulted in negative Y machining coordinates that are outside my machine limits and cause the file to fail validation when run. So my head is hurting trying to get back to a runable file 😕
On a good note, the CAM training guide has a good section on operation properties that helped implement some machine specific features like dust hood position and motion control settings, so that's a plus 🙂
Glad to hear you are getting useful information from the training guide. If you would like to setup the tool orientation as it is on the machine, you can do this, but you will need to define the spindle axis as 0,0,-1 in the post, as the post will always try to align the Setup orientation to the Machine orientation.
function onOpen() {
...
if (!is3D()) { // note: setup your machine here
...
}
machineConfiguration.setSpindleAxis(new Vector(0, 0, -1)); // <<< ADD THIS LINE
I spent the weekend reading, instrumenting functions and learning. I basically have two code forks and in the first, I commented-out a lot of code to simplify the post to a pure 3D post supporting the WCS in my machine's 0,0,-1 orientation. Without flipping the spindle in the machineConfig, I had perfectly valid Gcode coordinate output using a WCS of 0,0,-1 and a workplane flipped in the Z-axis. However, when I then implemented some safety checks to ensure pure 3D operations, I ran into issues with is3D() which doesn't seem to report properly when the WCS has a workplace flipped in the opposite Z direction. When I then turned to onOpen to debug the machineConfiguration properties, things turned confusing... I don't quite understand the relationship between the machine definition and the machineConfiguration because my first assumption was that the post pulled info from the machine definition, but when I printed some machineConfiguration properties that I expected to have values, they were empty. So I need to digest this topic to get a better understanding.
On a totally different note, when trying to learn how the post handles coordinate transformations, mapWorkOrigin and mapToWCS are totally EVIL. And to add to it, whoever decided that these assignments should be parsed even when commented-out should be given a new career... I wasted a couple hours in frustration until it sank in that they were parsed even when in comment form, because when I changed a value and later commented it out, the post behavior didn't change. Seriously not kosher. Why not a const or simply an accessor that optionally gets called once in onOpen? I hope this wasn't your doing... Rant over.
So I paused on this first code fork, and switch to the second fork using the -1 scaled Y and Z axes. This works and I'm currently running successfully on the machine, but there are some scary issues with this post as it is 😕 I had to disable all circular, helical and spiral interpolation even though I was scaling with a new jFormat for jOutput by -1, my machine was reversing some arcs and running into interpolation time issues. Also, feedrates and plunges are handled inconsistently in the post (some dynamic from tool data and some hard-coded), and since the Biesse Rover J likes feedrates in m/min, the mm/min values being used cause some insanely fast plunges and movements at odd times... I'm assuming some feedrates aren't getting set so the machine is using the last federate specified. My machine rapids at 2200 in/min with 5G acceleration, so mistakes are really noticeable 🙂
I'm happy to take things private and help however I can. The productivity leap I can get from using Fusion and going straight to the machine is huge! Onshape hasn't released their CAM yet, and the chance of getting a Biesse post when it does come out of private beta is slim to none. I do have access to a Biesse employee friend in Charlotte, NC that writes Vectric posts as a side gig (since he knows them intimately), and my VCarve post has many different parameters being set than you are setting in this ISO post. I will try to get more info on their ISO format because it looks like this post could also use a number of additional properties scoped as "post" and/or "operation" to handle the breadth of variation in Biesse machines. I know I'm doing it for dust hood positioning and motion control datasets to name two really important ones.
Looks like you really dug into the post. I can answer to the behavior of the post in regard to issues you ran into.
I ran into issues with is3D() which doesn't seem to report properly when the WCS has a workplace flipped in the opposite Z direction.
is3D() does check for a tool orientation of 0,0,1, so as you found out will not report a program with a 0,0,-1 tool orientation in any operation as a 3-axis program. You can write your own is3D function to handle a 0,0,-1 orientation.
function is3D() {
for (var i = 0; i < getNumberOfSections(); ++i) {
var section = getSection(i);
if (section.isMultiAxis() || Vector.areDifferent(section.getWorkPlane.forward, new Vector(0, 0, -1))) {
return false;
}
}
return true;
}
I don't quite understand the relationship between the machine definition and the machineConfiguration because my first assumption was that the post pulled info from the machine definition
The Machine Definition settings should be stored directly into the Machine Configuration. If you have some settings that don't match, can you provide more information?
mapWorkOrigin and mapToWCS are totally EVIL.
Yes, these assignments have caused some issues over the years. The post is scanned for these text assignments, as the transformation is handled in Fusion, the post processor script is not being processed at this time, which is why placing it in a comment has no effect. If you look at the Post Processor Reference Manual, you will see that it recommends placing these commands in a comment for this reason.
I had to disable all circular, helical and spiral interpolation even though I was scaling with a new jFormat for jOutput by -1, my machine was reversing some arcs and running into interpolation time issues.
If you reverse only one linear axis in a machining plane, in your case the Y-axis, then you will also need to reverse the circular direction codes, since this plane is now a mirrored plane. This is needed for the secondary spindle in some Mill/Turn posts, the Doosan for example. You could copy the isMirrored function from this post and modify the onCircular function similar to that in the Doosan code to handle mirrored planes.
function onCircular(clockwise, cx, cy, cz, x, y, z, feed) {
var directionCode;
if (isMirrored(getCircularPlane())) {
directionCode = clockwise ? 3 : 2;
} else {
directionCode = clockwise ? 2 : 3;
}
Also, feedrates and plunges are handled inconsistently in the post (some dynamic from tool data and some hard-coded),
The cutting feedrates should all come from Fusion and not hardcoded in the post. Can you explain which feedrates are hardcode?
Feel free to DM me if you have questions or information that would not benefit the community.
Thanks for the great info - I really appreciate the help learning.
You can write your own is3D function to handle a 0,0,-1 orientation.
Super! It's nice to know some things can be overridden... And am I correct in assuming that any functions that we override will always be the implementations that are called?
The Machine Definition settings should be stored directly into the Machine Configuration. If you have some settings that don't match, can you provide more information?
I'll print some more debug comments and see what I was missing there... I remember trying to inspect the machine definition properties to see if I could deduce which way the axes were pointing to help figure out orientation. It felt odd that the definition has axes ranges but no vector directions, and I think I was trying to see if my Z range of -200mm to 1mm was inferring a direction that I could use, if that makes sense 😕 I didn't want to code something if it was already possible using the machine definition.
...You will also need to reverse the circular direction codes, since this plane is now a mirrored plane.
Makes perfect sense - thanks.
Can you explain which feedrates are hardcode?
I saw two.. safePlungeFeed and safeRetractFeed, but these values were probably not being used in my case... My issue stemmed from the CNC wanting m/min while the values posted were in mm/min, so my super fast movements came from that multiplier which I corrected with an added scale:(unit == MM ? 0.001 : 1) in feedFormat. But after those crazy movements, I looked for anything relevant. And even thought we just have G20 & G21 now, I tend to code defensively and will make all "unit ==" statements compare same units and not flip-flop between them.
It looks like you are getting a pretty good handle on the internal workings of the post processor and machine definitions now. In answer to your question,
You can overwrite any post engine function in the post processor JavaScript.
The Machine Definition and Machine Configuration should be identical, BUT if you look at the machine-v2 global parameter, you will see it does not include all of the settings from the Machine Definition, such as the spindle axis, when looking at the dumper output.
