Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Proper Display of User G-Codes
#1
Perhaps this is not an issue in the latest version of NC, but I just wrote a User G-Code (G61.1) running in an NC 2.36 environment. The G-Code executes just fine. It is essentially a one-line canned cycle.

The problem is getting the UI to properly display line execution in AUTO mode. I have a program that runs many lines, each line is the custom G-code and the parameters that get passed. The UI doesn't step through line by line in the display (i.e. doesn't highlight completed lines and current line properly). Sometimes it stalls and randomly jumps forward. The program itself executes just fine, it is simply a UI problem.

I recall having to do something with M165, but I don't remember and don't know where to find it. Anyone have a fix?
Reply
#2
These G-codes are not usually modal so if they execute quickly their display is transient (using our expected mechanism). The expected coding is:
//--------------------G60.2----------------
N60200
@SET_ON(VS_GGROUP20_1_M,2) // this activates the display
// Add User Code
@SET_OFF(VS_GGROUP20_1_M,2) // this deactivates the display
RETURN

You can however code them to be modal by not setting the bits in VS_GGROUP20_1_M off. Note that unlike some of the others (VS_GGROUPxx_1_M) you set individual bits of the word VS_GGROUP20_1_M; not assign a value. Setting bit one of this should display G60.1, bit two G60.2 and so on.
Reply
#3
Thanks Steve, correct me if I am wrong, but setting the M variable on will get the G code to display as "active". My problem is that the block execution area of the UI, where the completed lines turn yellow, current line turns red, etc., doesn't step through line by line. Sometimes it jumps several lines, sometimes it seems to work. I notice it more in Auto mode than MDI. I would like this display to step through line by line.

my high-level code looks like:

G61.1X_Z_A_B_
G61.1X_Z_A_B_
G61.1X_Z_A_B_
.
.
.
G61.1X_Z_A_B_

etc.,

Are we talking about the same thing?
Reply
#4
Another way of asking the question...what causes the line cursor on the display (which indicates the currently executing line) to scroll to the next line?
Reply
#5
This is done at the parsing level in the PC. Since the PC cannot see inside of a G-code (in PROG 1000) these are not displayed.
Reply
#6
What synchronizes the PMAC to the PC in this sense? Whatever it does it is either missing or is behaving asynchronously with my G61.1. Inside of the G61.1 it reads parameters, commands a G0 to a position, waits for a condition using a while loop, does a synchronous m-variable assignment, commands a second G0 position, waits for a condition using a while loop, does a second synchronous m-variable assignment, then returns. It is basically a canned cycle that turns an output on and off between moves and then returns. It works great, but the operators have a hard time knowing which line of code it is on because the "current-line" cursor display is not timed to anything. Is this simply a bug with user g-codes, or am I missing some command status somewhere, or will setting the code group m-variable that you mention above magically fix it?
Reply
#7
We have never displayed code "within" a user G-code (G61.x). Some of the standard canned cycles may show pieces of code as these are parsed in by the PC.

The synchronization is done at parsing by sending M20=={line number} to the rotary buffer.

You could use the messaging to display text from the ERRORS.DAT file for indication to the operator.
Reply
#8
Thanks. I am not trying to display the code within the G61.1. I simply told you approximately what was there to see if that is related to the problem.

My problem is as follows: assume that I have multiple lines, N20, N30, N40, etc. ( I am not actually using line numbers, but it helps me illustrate my point) On each line there is a single command, a G61.1. When the machine is executing line N20, the UI might be highlighting N100, or some other line. I am guessing that the M20== assignment is not being done when the parser sees the G61.1, and is instead issuing M20== commands for certain lines inside of the G61.1. Is this possible?
Reply
#9
I'm not sure why it would do this. give me a call to discuss other options: 818-717-5658.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)