Jump to content

Welcome to eMastercam

Register now to participate in the forums, access the download area, buy Mastercam training materials, post processors and more. This message will be removed once you have signed in.

Use your display name or email address to sign in:

Post Debugger - Variable watch - Server Error


Kevin E
 Share

Recommended Posts

When using the Post Debugger, for quite some time I have had problems with watching variables. Instead of showing me the value of the variable, it instead just displays "server error".

The only thing I've thought could be causing it is that the post processor, as well as machine and control definitions, are on another drive than Mastercam's installed folder. My next step is to create a temporary test definition and post on the local drive.

Anyone have experience with this and know what I should be doing to see the variable values again?

image.png.f1345883c7a29c9de99dc15805101f14.png

Link to comment
Share on other sites
6 minutes ago, Kevin E said:

Anyone have experience with this and know what I should be doing to see the variable values again?

The debugger was bought as a third party item and has not been completely integrated.

Yes I have come across this, sometimes you have to start a new debug session. It just doesn't reset properly.

Sometimes just rerunning will do the trick.

I have rebuilt watchlists too.

If anyone else has any tricks they use I'd like to hear them too

Link to comment
Share on other sites

Well, I just tried rerunning and restarting multiple times. Also, copied the definition and post files to the local drive and reset all the file targets and tried again with that.

No luck!

The debugger is not so helpful if you can't watch the variables!

Link to comment
Share on other sites
  • 11 months later...
  • 2 months later...

I just started forcing output of variables during development to see what they are.  I have given up on watch lists in the debugger.  Also another very experienced and helpful user in another forum subject suggested using mprint to output messages on variables during posting, and I have used that lately in addition to the forced output.

  • Like 1
Link to comment
Share on other sites

Honestly, I gave up on using the Debugger long ago. It is ok, when debugging 3-Axis and 4-Axis posts. It becomes more cumbersome than it is worth, when attempting to debug a 5-Axis Post.

Are you aware of the Command Variable 'bug4$'?

This variable controls the formatting of Debug Output.

What is 'Debug Output', you may then ask?

The MP Post Language has a Variable Modifier, called the "debug modifier", which allows you to output any variable, without changing the value or modality of the variable. This modifier is the Tilde Character (~).

Speaking of Modality, you may or may not be aware of how MP controls the Modality of Numeric Variables. 

When a variable is created (initialized), in the MP Language, MP automatically creates 2 variables in Memory. These are the Initial and Previous value of the variable. On initialization, MP takes whatever your variable name is, and it appends the characters "prv_", to the front of your variable, thus creating the 'previous value slot' in Memory. At initialization, MP loads the Initialization Value (number), into both the current and previous variable slots.

When a numeric variable is encountered on an 'output line', MP compares the current value to the previous value. If the variable values are different, MP forces output of the 'current' value, and then updates the previous value to whatever was output.

You might  notice there is a 'Update Modifier' in the MP Language as well. The exclamation point (!) Is the Update Modifier. This updates the previous value to the current, without outputting to the NC Output Stream.

With the 'bug4$' Command Variable, set the value to '-1', so you can get the "Raw" value (unformatted value), of the variable when using the Debug Modifier. 

Example:

     "Debug my_var:", ~my_var, e$
     "Debug prv_my_var:", ~prv_my_var, e$

 

  • Like 2
Link to comment
Share on other sites
2 hours ago, kcham said:

Are you running the postprocessor file itself through Vericut?

Tim is speaking of something completely different from what we've been discussing. 

He is talking about using Fanuc Macro B Variables within the NC Code File. Within the Vericut program, he is able to define Vericut Variables which mimic the Fanuc Macro B variables in scope, and allow you to perform complex calculations, jumps, etc., within the NC Program, and to interpret and trace, not only the variable values, but the Nested Subroutine Calls within the Fanuc control.

These are really two completely different subjects, and Variable Tracking in Vericut has no bearing on MP Variable Debugging. Vericut interprets NC Code, while MP and MP Post Variables, interpret NCI Data to format and output NC Code. 

Vericut is a great tool for simulation of your machine and shop environment. It is a great complement to Mastercam, but it is divorced from the NC Code generation. CAMplete, on the other hand, combines Post Processing and Machine Simulation into a single platform. I prefer the combination of Mastercam and CAMplete, versus Mastercam and Vericut, because you have to configure two different systems to work together. With Vericut, you have to get a good Post Processor (often from a 3rd party), and work to set it up and debug the output. Then, you must do the same thing with Vericut. You must set it up, and debug any issues. Most of the time, the issues are only detected when there is a problem. So you play a "find and fix the error game", until the Simulation is fully debugged and works great. But it can often be a painful and costly process of development. 

I find that CAMplete is setup to work "out of the box", much better than Vericut. It is easier to debug, since the software environment already comes with "your base machine" already modeled. Both systems have pros and cons of course, and are both great at different things. Some functionality overlaps between the systems. 

Link to comment
Share on other sites
13 minutes ago, Colin Gilchrist said:

Tim is speaking of something completely different from what we've been discussing. 

He is talking about using Fanuc Macro B Variables within the NC Code File. Within the Vericut program, he is able to define Vericut Variables which mimic the Fanuc Macro B variables in scope, and allow you to perform complex calculations, jumps, etc., within the NC Program, and to interpret and trace, not only the variable values, but the Nested Subroutine Calls within the Fanuc control.

These are really two completely different subjects, and Variable Tracking in Vericut has no bearing on MP Variable Debugging. Vericut interprets NC Code, while MP and MP Post Variables, interpret NCI Data to format and output NC Code. 

Vericut is a great tool for simulation of your machine and shop environment. It is a great complement to Mastercam, but it is divorced from the NC Code generation. CAMplete, on the other hand, combines Post Processing and Machine Simulation into a single platform. I prefer the combination of Mastercam and CAMplete, versus Mastercam and Vericut, because you have to configure two different systems to work together. With Vericut, you have to get a good Post Processor (often from a 3rd party), and work to set it up and debug the output. Then, you must do the same thing with Vericut. You must set it up, and debug any issues. Most of the time, the issues are only detected when there is a problem. So you play a "find and fix the error game", until the Simulation is fully debugged and works great. But it can often be a painful and costly process of development. 

I find that CAMplete is setup to work "out of the box", much better than Vericut. It is easier to debug, since the software environment already comes with "your base machine" already modeled. Both systems have pros and cons of course, and are both great at different things. Some functionality overlaps between the systems. 

Colin great response and if you don't mind me going even further OT. (OT Police 👮‍♂️ will be along any minute to give me warning points and kick me off the forum, but I digress.)

Well with CAMplete being bought by a competitor of Mastercam not sure how long that is going to be a viable option. Great Software and think they do some pretty amazing things, but like you said things they don't do needed for certain project like Autodiff and building your own machines make it a deal breaker for a lot of companies.

CNC Software 3rd parties are some of the best in the business and yes on very complex involved machines it can be some work, but for 90-95% of the users out there out of the box takes care of everything they need. The 5-10% users will always have some development getting them dialed in and yes even CAMplete needs help in this area just like any other CAV.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.

Join us!

eMastercam - your online source for all things Mastercam.

Together, we are the strongest Mastercam community on the web with over 56,000 members, and our online store offers a wide selection of training materials for all applications and skill levels.

Follow us

×
×
  • Create New...