cancel
Showing results for 
Search instead for 
Did you mean: 

Post Builder vs. Post Configurator

Legend
Legend

Mark Rief wrote about future of Post Builder vs development of Post Configurator:
  • Execution of Post Builder post will continue unchanged, no plans to retire MOM, MOM events or the underlying architecture

If the underlying architecture is the same, what's difference between these products?
As far as I see, Post Configurator provides 1) the new graphic interface of editor, 2) encryption and binding to some licenses. Or something else? Access to some libraries and procedures unavailable for old software?

 

46 REPLIES

Re: Post Builder vs. Post Configurator

Siemens Genius Siemens Genius
Siemens Genius

Hello Frobi,

 

thanks for you question. There is no real short answer for this question, but Post Configurator and Post Builder are fundamentaly different. As Mark stated they run on the same API (=MOM), but work differently ontop of that. 

 

Post Builder concentrates on changes based on MOM_events, MOM_variables and Custom Commands. Post Configurator on the other side is option/configuration based. Siemens provides controller based libraries which the user then can configure by selecting the right settings through an NX-integrated user interface. Additional, developers have ways to extend or modify the available options and modify the output thorugh Tcl commands. We added a few features like time limitation and licensing through the possibility to encrypt parts of the post processor. 

 

Due to that fact the post processors of PB and PC are not compatible to each other, but they execute in the same way. PC based post processors can be executed NX9 and up, even if they were created in a later version (=backwards compatibility). An end user will not notice a difference between them, but post developers have to work differently. 

 

Hope I could bring some light into this,

 

Regards, 

Florian

Re: Post Builder vs. Post Configurator

Legend
Legend

Thank you and Mark for good explanation.

Does it mean the situation where open-source posts (Post Builder concept) vs encrypted posts (Post Configurator concept) based both on the same MOM-data?

Re: Post Builder vs. Post Configurator

Siemens Genius Siemens Genius
Siemens Genius

Yes that is the case. Both tools use the same MOM events and variables. There is no difference of the available data for PB or PC. Both tools are treaded equaly when i comes to the API, means there is nothing that is PC exclusive. Imrpovements made will benefit both tools. 

Re: Post Builder vs. Post Configurator

Legend
Legend

Ok. Let's look at this item in future.
Now we have PB with some set of templates, procedures and globals described in the Post Builder Help, so that I am able to manipulate them even manually, in any text editor, without Post Builder.
Perhaps, tomorrow new MOM-data will be added in NX. Can I get their description in future? Or it will be available only for developers of PC?

Re: Post Builder vs. Post Configurator

Siemens Genius Siemens Genius
Siemens Genius

As said before, enhancements of the MOM architecture will benefit both tools, and will be documented as such. There are no MOM variables/events that are PC exclusive. 

 

Advanced features like encryption, licensing, time restriction, easy updatability and layer structure are features of PC and will not be available for PostBuilder. 

Re: Post Builder vs. Post Configurator

Phenom
Phenom

Florian,

 

I just wondered if you can comment on what below are inaccurate statements, designed in differences, and are part of "the gap" Mark mentions.

 

1) Post configurator is designed for and will be best used to make use of the dropdowns in the interface. End user configuration is not intended to be done outside of the options available.

2) If an end user (post writer) wants to change something that is not available by setting dropdowns in interface:

  a) A special license is needed.

  b) TCL code changes must be made considering hidden code - or completely overridden/recreated from the event down.

  c) Formatting configuration will not have a graphic inteface like in PB.

  d) Output of a code block will never be done in hidden code (allowing complete configuration.)

3) There will still be mom_pos and mom_mcs_goto's unaffected as they are sent from NX.

4) Update (for version change) of posts will be done the same (or are not necessary) with PC.

5) Obviously PC is meant to be more of a configuration free route to the end user with posts obtained off the shelf from Siemens or included OTB. What ratio will there be? Will OTB offerings be similar to what we have with PB?

 

Thanks, Daland

 

 

NX10.03
Windows 7 Pro

Re: Post Builder vs. Post Configurator

Siemens Genius Siemens Genius
Siemens Genius

Hello Study, 
 
I'm happy to comment on your statements and give some insights on Post Configurator:

 

1) Post configurator is designed for and will be best used to make use of the dropdowns in the interface. End user configuration is not intended to be done outside of the options available.

 

Florian: Correct, Post Configurator aims to enable post developers to do post processor modifications through an UI instead of requiring the need to write Tcl custom code.

 

2) If an end user (post writer) wants to change something that is not available by setting dropdowns in interface:

  a) A special license is needed.

 

Florian: Correct, in order to do Tcl changes to the post processor the Post Configurator Full license is required.

 

  b) TCL code changes must be made considering hidden code - or completely overridden/recreated from the event down.

 

Florian: Correct, but we offer multiple ways of reacting to output generated by unknown code, like the sequences, entry points or through fields in UI.

 

  c) Formatting configuration will not have a graphic inteface like in PB.

 

Florian: Correct, that is a gap right now, but we are working on a solution for this, which will close this soon. So, stay tuned for the upcoming NX releases.

 

  d) Output of a code block will never be done in hidden code (allowing complete configuration.)

 

Florian: I do not 100% understand that statement, but what for what I understand it, it is not correct. Encrypted layers can output templates, code lines, or blocks.

 

3) There will still be mom_pos and mom_mcs_goto's unaffected as they are sent from NX.

 

Florian: Correct, MOM API (incl. mom_pos, mom_mcs_gotos) is unchanged, and the same for PB and PC. No plans to change that.

 

4) Update (for version change) of posts will be done the same (or are not necessary) with PC.

 

Florian: Not correct. Updating a PB post and updating a PC post is different and will not be done the same way. Where Post Builder "auto"-updates a post processor for a new NX version, the PC developer needs to update a post processor to a new version, by upgrading the corresponding layers to the new version manually right now. But this can be done easily due to the layer structure of those posts.  

 

5) Obviously PC is meant to be more of a configuration free route to the end user with posts obtained off the shelf from Siemens or included OTB. What ratio will there be?

 

Florian: No planed ratio, but our focus is on Post Configurator. So most new post processors coming from Siemens will be Post Configurator based.

 

Will OTB offerings be similar to what we have with PB?

 

 Florian: Yes, we are working on migrating the OOTB kits to Post Configurator to showcase the potential of this new tool. Those post processor can deliver at least the same functionality than the PB based ones. For the time being, there will be both post processors available in the OOTB machines, but this may change in the future.

 

Hope that helps and best regards,

Florian

Re: Post Builder vs. Post Configurator

Legend
Legend

Florian,
one more question about migration from PB to PC.
From your words I understand that the both concepts are too different to import old projects (files pui, def, tcl) into PC, and re-creation of the postprocessor should be done only in PC from "zero". Is it so?

Re: Post Builder vs. Post Configurator

Phenom
Phenom

Hi Florian,

Thanks for the response. However it seems - I understand the design goal (and challenge of it when comparing to what we have with PB.) I have (with PB) sourced both open and encrypted code. When I have encrypted code - I tried to only put code in there related to introducing a new kinematic setting - similar to what NX might have done. Typically this was done for situations with 3 rotaries or head attachments etc. I take cl positions and make mom_pos's. I didn't write out any G code in encrypted areas. I was careful to leave no reason to know any details of what is done in the encrypted area (very clear purpose of the code there.) If the next person working with the post didn't want to use it - don't source it (and hopefully no immediate errors.) Hopefully those of us who do venture into trying to do more configuration (that the dropdowns) in PC will be able to work with it to do some of the same things without relying on a PR which is not timely enough for a person trying to run a part off on a machine.

Thanks again,

Study

NX10.03
Windows 7 Pro

Learn online





Solution Information