Creating Post processors.

[Sgt_Hindsight]

So been fiddling with this post processing file for a day or so and started todo alot of optimization to it today and it occured to me..

These could be alot more effectivly coded. Basicly they use Javascript - and that means you could make it faster ALOT faster for large programs. For one thing, you can remove the switch command in the code and utilize an object properly and call the command based on its name instead of using case that is in a optimization view really bonkers slow (ecma deoptimizises kinda bad when using switches and for loops).

Next step is do a generally prototype for what outlines a post process. I looked thru a few of em and they are quite similar. That makes it possible to make a generator where features can be selected based on different things such as machine, brand quirks and so on kinda easily and just generate a post process skeleton. And make the alterations to it afterwards.

Just by doing the the small optimizations above like removing the switch and handling it properly as a prototype, basicly halfed the processing time out of Fusion when running a large job with 30 or so operations, 9 tool changes (in my case manual) And even makes it possible to add stops for fixturing changes. By acting on the change in G54, G55 code change.

Anyone interested in collabing around making a "general" post generator. It is really possible actually due to the selection of language in the post process engine. I have done some rudimentary tests to check it already. 😃

[Laurens-3DTechDraw]

Yes, you could make a sort of generic post for 3-axis machines that run Fanuc style code. For adding in Siemens, Heidenhain and 5-axis commands will be much more tricky due to the difference in them. Apart from that the 5-axis will need an update in the CAM system and might be handled differently in the future(I have no idea, and no inside info but this might be the case.)

Though making the post faster is just for the record. I mean posting files with 50 operations and 5 million lines goes faster than most people can think so for me that really is a non issue.(Maybe fusion does something weird with the post processing but for Inventor HSM and HSMWorks it's really not something that really can be improven)

[Anonymous]

Did you do something? I'm interested.

[Rob_Lockwood]

Agreed..

But on the same subject, i've always found it puzzling that the post processors are as forked as they are. I'm not sure why more effort hasn't been put in place to keep a connection back to the main post processor that a specific post is forked from. It's annoying that once you go and modify, there's really no way to push updates into your modified post.

Ironic that one of the most parametric CAM companies isn't capitalizing on the benefits of parametric post processors 🙂

[Laurens-3DTechDraw]

---

@Rob_Lockwood wrote:

Agreed..

But on the same subject, i've always found it puzzling that the post processors are as forked as they are. I'm not sure why more effort hasn't been put in place to keep a connection back to the main post processor that a specific post is forked from. It's annoying that once you go and modify, there's really no way to push updates into your modified post.

Ironic that one of the most parametric CAM companies isn't capitalizing on the benefits of parametric post processors 🙂

---

Well, you must keep in mind a lot of people aren't always looking for the next new option but are looking for a solid working system.

Updating a post processor automatically is the worse thing one could do. People trust on them since they've worked for years and then it would be updated and you get a big crash. Is Autodesk going to pay for that crash? No so they can't take that chance.

[Rob_Lockwood]

Yeah, there's definitely some truth to that..

But the post processor is equally as susceptible to garbage in = garbage
out as any other system.. if the input data is changing, is there really
such a thing as a solid/proven post? changes on the input side are just as
likely to cause issues as changes to the interpreter itself right? 🙂

[Laurens-3DTechDraw]

---

@Rob_Lockwood wrote:
Yeah, there's definitely some truth to that..

But the post processor is equally as susceptible to garbage in = garbage
out as any other system.. if the input data is changing, is there really
such a thing as a solid/proven post? changes on the input side are just as
likely to cause issues as changes to the interpreter itself right? 🙂

---

Well if you look at the changing history the guys only add new stuff to the post processor and not actually change the info that is to be interpreted differently by the post. I mean of course a bad toolpath will give a bad output. But for the things the post processor does normally there is not much to interpret so to speak. So the post can solid, but the toolpaths could be at fault yes.

Apart from the fact that if there is one thing that can cause a post to be less certain we shouldn't risk all on it right?

[Rob_Lockwood]

Couldn't the same logic apply to post changes as well? And there's no need
to have this happen automatically, I'd definitely rather have the option to
push a button and have my forked post updated for me to prove out than need
to do it manually..

Besides, a good argument exists for putting pressure onto the situation.

Currently, there's no system in place at all, so a dangerous situation
exists (the wild west of included/VAR/user posts) and as such everything
need be treated as "use at your own risk".. at some point, taking
responsibility for the performance/reliability of the posts themselves
would ultimately cause their reliability to increase.

With what sounds like a push towards new machine configurations, I'd be
surprised if we don't start seeing "gold stamped/certified"
post/config/simulation, where all of the functions and features of some of
the more prolific machines are fully fleshed and reliable.

Wouldn't it be nice if the "proven/stable" posts were so because the post
team/manufacturer guarantee them as such? 🙂

[Laurens-3DTechDraw]

---

@Rob_Lockwood wrote:
Wouldn't it be nice if the "proven/stable" posts were so because the post
team/manufacturer guarantee them as such? 🙂

---

This is only possible with deals like Autodesk and Haas have.

You need the machine manufacturer, and it seems they don't really seem to have any relation like that with any other brand of machines.

---

@Rob_Lockwood wrote:

With what sounds like a push towards new machine configurations, I'd be
surprised if we don't start seeing "gold stamped/certified"
post/config/simulation, where all of the functions and features of some of
the more prolific machines are fully fleshed and reliable.

---

I wish this were true. These new machine configurations are highly needed but this does not seem to have any priority. I would agree that having most of the post config live in the machineconfig and still be able to edit the post like it is now would be great but this is all something that lives in dreams and my imagination and not something that could happen anytime soon.